来自EMR/Spark的S3写入速度非常慢

Question

我正在写,看看是否有人知道如何加速从EMR中运行的Spark的S3写入时间？

我的Spark Job需要4个多小时才能完成,但群集在前1.5个小时内仅处于负载状态.

我很好奇Spark一直在做什么.我查看了日志,发现了很多s3 mv命令,每个文件一个.然后直接看看S3我看到我的所有文件都在_temporary目录中.

其次,我关注我的集群成本,看来我需要为这项特定任务购买2小时的计算.但是,我最终买了5个小时.我很好奇EMR AutoScaling在这种情况下是否有助于降低成本.

一些文章讨论了更改文件输出提交器算法,但我没有成功.

sc.hadoopConfiguration.set("mapreduce.fileoutputcommitter.algorithm.version", "2")

写入本地HDFS很快.我很好奇,如果发出一个hadoop命令将数据复制到S3会更快吗？

Answer 1

你看到的是outputcommitter和s3的问题.提交作业适用fs.rename于_temporary文件夹,由于S3不支持重命名,这意味着单个请求现在正在复制并删除_temporary到其最终目的地的所有文件.

sc.hadoopConfiguration.set("mapreduce.fileoutputcommitter.algorithm.version", "2")仅适用于hadoop版本> 2.7.它的作用是从提交任务中的_temporary复制每个文件而不是提交作业,因此它是分布式的并且工作得非常快.

如果您使用旧版本的hadoop,我会使用Spark 1.6并使用:

sc.hadoopConfiguration.set("spark.sql.parquet.output.committer.class","org.apache.spark.sql.parquet.DirectParquetOutputCommitter")

*请注意,它不适用于打开规格或以附加模式书写

**还要注意它在Spark 2.0中已弃用(由algorithm.version = 2取代)

BTW在我的团队中我们实际上使用Spark写入HDFS并在生产中使用DISTCP作业(特别是s3-dist-cp)将文件复制到S3但是这样做是出于其他几个原因(一致性,容错)所以没有必要..你可以使用我的建议快速写入S3.

Answer 2

直接提交者从火花中被拉出,因为它不能承受故障.我强烈反对使用它.

Hadoop,s3guard正在进行工作,以添加0重命名提交者,这将是O(1)和容错; 密切关注HADOOP-13786.

暂时忽略"魔术提交者",基于Netflix的登台提交者将首先发布(hadoop 2.9？3.0？)

1. 这会在任务提交中将工作写入本地FS
2. 发出未提交的multipart put操作来写入数据,但没有实现它.
3. 使用原始的"算法1"文件输出提交器保存将PUT提交到HDFS所需的信息
4. 实现一个作业提交,它使用HDFS的文件输出提交来决定要完成哪些PUT以及取消哪些PUT.

结果:任务提交需要数据/带宽秒,但作业提交不会超过在目标文件夹上执行1-4 GET的时间和每个待处理文件的POST,后者将被并行化.

您可以从netflix中获取此作品所基于的提交者,并且今天可能会在spark中使用它.设置文件commit algorithm = 1(应该是默认值)或者它实际上不会写入数据.

Answer 3

我有类似的用例，其中我使用spark来写s3并出现性能问题。主要原因是spark正在创建大量零字节的零件文件，并将临时文件替换为实际文件名会减慢写入过程。尝试以下方法解决

1. 将spark的输出写入HDFS，并使用Hive写入s3。由于蜂巢创建的零件文件数量较少，因此性能要好得多。我遇到的问题是（使用spark时也有同样的问题），由于安全原因，prod env中未提供对Policy的删除操作。在我的情况下，S3存储桶已进行kms加密。

2. 将Spark输出写入HDFS，并将复制的hdfs文件写入本地，并使用aws s3复制将数据推送到s3。使用这种方法获得了第二好的结果。与亚马逊一起创建了票证，他们建议与该票证一起使用。

3. 使用s3 dist cp将文件从HDFS复制到S3。这没有问题，但性能不佳