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

2019年7月28日 216次阅读

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

我们可以从Spark UI中看到,读取和合并的第一个阶段是按照预期在100％CPU上运行最终的JavaRDD,但最后阶段使用save.sTela：179中的saveAsTextFile写出CSV文件会被许多人“卡住” 3个节点中的2个小时,32个任务中的2个占用数小时(盒子占6％CPU,内存占86％,网络IO占15kb / s,整个时间内占用磁盘IO 0).

我们正在读取和编写未压缩的CSV(我们发现未压缩的CSV比gzip压缩得快得多),在三个输入DataFrame中的每一个上都有重新分区16,而不是写入.

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

非常感谢

—更新—

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

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

最佳答案 如果您通过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

点赞