Question

我们开发了一个工作，该工作使用Spark 2.3在Amazon S3（s3a）中的镶木地板中进行处理并写入大量文件。每个源文件都应在S3中创建一个不同的分区。该代码已经过测试（文件更少）并且可以按预期工作。

但是，在使用实际数据执行后，我们注意到某些文件（总数很小）没有写入镶木地板。日志中没有错误或任何奇怪的内容。我们再次测试了丢失文件的代码，它可以工作？我们想在生产环境中使用代码，但是我们需要在这里检测出问题所在。我们正在这样写实木复合地板：

dataframe_with_data_to_write.repartition($"field1", $"field2").write.option("compression", "snappy").option("basePath", path_out).partitionBy("field1", "field2", "year", "month", "day").mode(SaveMode.Append).parquet(path_out)

我们使用了推荐的参数：

spark.sparkContext.hadoopConfiguration.set("mapreduce.output.fileoutputformat.compress", "true")
spark.sparkContext.hadoopConfiguration.set("mapreduce.fileoutputcommitter.algorithm.version", "2")  
spark.sparkContext.hadoopConfiguration.set("mapreduce.fileoutputcommitter.cleanup-failures.ignored", "true")
spark.conf.set("spark.serializer", "org.apache.spark.serializer.KryoSerializer")

使用此参数是否存在已知的bug问题？也许具有S3最终一致性的东西？有什么建议吗？

任何帮助将不胜感激。

Answer 1

是的，这是一个已知问题。通过在尝试工作目录中列出输出并重命名到目标目录来提交工作。如果该列表未报告文件：输出丢失。如果该清单列出了不存在的文件，则提交失败。

修复了ASF Hadoop版本。

hadoop-2.7-2.8连接器。写入HDFS，复制文件
Hadoop 2.9-3.0启用S3Guard以获得一致的S3列表（为此使用DynamoDB）
Hadoop 3.1，切换到the S3A committers，其设计时考虑了一致性和性能问题。 netflix的“ staging”是在这里最简单的使用。

进一步阅读：A zero-rename committer。

2019年11月1日更新，Amazon拥有自己的ASF zero rename committer的闭源实现。要求EMR团队提供自己的正确性证明，因为我们其他人无法验证这一点。

从Spark将许多文件写入木地板-缺少一些木地板文件

1 个答案: