apache-spark - Spark Stand Alone - 最后阶段 saveAsTextFile 使用很少的资源来编写 CSV 部分文件需要很多小时

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

我们可以从 Spark UI 中看到，读取和合并以生成最终 JavaRDD 的第一阶段按预期以 100% CPU 运行，但使用 saveAsTextFile at package.scala:179 写为 CSV 文件的最后阶段在 3 个阶段中的 2 个阶段“卡住”了好几个小时32 个任务中有 2 个任务耗时数小时的节点(框为 6% CPU，内存 86%，网络 IO 15kb/s，整个期间磁盘 IO 0)。

我们正在读取和写入未压缩的 CSV(我们发现未压缩的 CSV 比 gzip 压缩的 CSV 快得多)，在三个输入 DataFrame 中的每一个上重新分区 16，并且不停止写入。

感谢您提供任何提示我们可以调查为什么最后阶段需要这么多小时在我们独立本地集群的 3 个节点中的 2 个节点上做很少的事情。

非常感谢

- - 更新 - -

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

最佳答案

如果您通过 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

关于apache-spark - Spark Stand Alone - 最后阶段 saveAsTextFile 使用很少的资源来编写 CSV 部分文件需要很多小时，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/40669368/