Spark Stand Alone - Last Stage saveAsTextFile使用非常少的资源来编写CSV部件文件需要花费很多时间

Question

我们在独立模式下运行Spark，在240GB“大型”EC2盒子上有3个节点，使用s3a将读入DataFrames的三个CSV文件合并到S3上的输出CSV部分文件。

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

我们正在读取和编写未压缩的CSV（我们发现未压缩的CSV比gzip压缩的速度快得多），在三个输入数据框架中的每一个上都有重新分区16而不是写入。

非常感谢任何提示，我们可以调查为什么最后阶段花了这么多时间在我们的独立本地群集中的3个节点中的2个上做很少的事情。

非常感谢

---更新---

我尝试写入本地磁盘而不是s3a并且症状相同 - 最后阶段saveAsTextFile中的32个任务中有2个被卡住了几个小时：

Answer 1

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

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

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

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

Answer 2

我见过类似的行为。自2016年10月起，HEAD中存在错误修复，可能相关。但是现在你可以启用

spark.speculation=true

位于SparkConf或spark-defaults.conf。

如果可以减轻这个问题，请告诉我们。