Spark Stand Alone - 最后一步saveAsTextFile花费很多时间使用很少的资源编写CSV文件

我们在独立模式下运行Spark，并在240GB“大型”EC2框中使用3个节点将读取到DataFrame中的三个CSV文件合并为JavaRDD，使用s3a在S3上输出CSV部分文件。Spark Stand Alone - 最后一步saveAsTextFile花费很多时间使用很少的资源编写CSV文件

我们可以从Spark UI中看到第一阶段的读取和合并，以达到预期的100％CPU的最终JavaRDD运行，但使用saveAsTextFile at package.scala:179在CSV文件中写出的最后阶段会在很长时间内“卡住” 3个节点中的2个，其中32个任务中的2个需要花费数小时（盒的CPU占用率为6％，内存占用率为86％，网络IO为15kb/s，磁盘IO整个周期为0）。

我们正在读取和写入未压缩的CSV（我们发现未压缩的速度比gzipped CSV快得多），在三个输入数据帧的每一个上都有重新分区16，并且不会共享写入。

希望得到任何提示，我们可以调查为什么最后阶段需要花费很多时间在我们的独立本地群集中的3个节点中的2个上做很少的工作。

非常感谢

--- UPDATE ---

我试着写到本地磁盘，而不是S3A和症状是相同的 - 的32个任务2在最后阶段saveAsTextFile“被困“几个小时：

来源

2016-11-18 user894199

我见过类似的行为。截至2016年10月，HEAD存在错误修复，可能与有关。但现在你可能使

spark.speculation=true

在 SparkConf

或spark-defaults.conf。

让我们知道是否可以缓解问题。

来源

2016-11-18 05:53:40 javadba

感谢。我尝试过，但症状是一样的，没有明显的变化。 – user894199

如果您通过s3n，s3a或其他方式写入S3，除非要运行输出损坏的风险，否则不要设置spark.speculation = true。我怀疑发生的事情是该进程的最后阶段是重命名输出文件，该文件在对象存储上涉及复制大量数据（很多GB？）。重命名发生在服务器上，客户端只保持打开HTTPS连接直到完成。我估计S3A的重命名时间约为6-8兆字节/秒......这个数字是否与你的结果相符？

然后写入本地HDFS，然后上传输出。

gzip压缩不能分割，所以Spark不会将处理文件的部分分配给不同的执行者。一个文件：一个执行者。
尝试并避免使用CSV，这是一种丑陋的格式。拥抱：Avro，Parquet或ORC。 Avro非常适合其他应用程序流入，其他应用程序更适合在其他查询中进行下游处理。显着更好。
并考虑使用诸如lzo或snappy等格式压缩文件，这两种文件都可以拆分。

又见幻灯片上21-22：http://www.slideshare.net/steve_l/apache-spark-and-object-stores

来源

2016-11-18 15:35:31

嗨史蒂夫。非常感谢您的回复。是的，我听说过重命名的问题，但是我们4个小时的闲置时间将意味着100GB的输出文件 - 我们预计约5Gb。不幸的是，上游和下游处理我们不受我们的控制，并使用CSV。我们正在使用Spark 1.6。也许我们应该尝试升级到2.0，如果写入HDFS然后上传不解决问题？ – user894199

我也尝试过幻灯片21-22：http://www.slideshare.net/steve_l/apache-spark-and-object-stores，它们没有什么区别。 – user894199

您可以尝试升级 - 值得其他原因（提示：DataFrames），但它不会更改低级S3连接或文件输出提交者。上传被锁定时，请执行kill -QUIT以显示所有被阻止的线程的堆栈 –

Spark Stand Alone - 最后一步saveAsTextFile花费很多时间使用很少的资源编写CSV文件

回答

相关问题