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

Question

我们开发了一项作业，该作业使用 Spark 2.3 在 Amazon S3 (s3a) 中处理和写入大量文件。每个源文件都应在 S3 中创建不同的分区。代码经过测试（文件较少）并按预期工作。

但是在使用真实数据执行后，我们注意到一些文件（总数的一小部分）没有写入 parquet。日志中没有错误或任何奇怪的东西。我们再次测试了丢失文件的代码并且它工作了¿?。我们想在生产环境中使用代码，但我们需要检测这里有什么问题。我们正在写这样的镶木地板：

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")

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

我们将不胜感激。

Answer 1

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

对 ASF Hadoop 版本的修复。

1. hadoop-2.7-2.8 连接器。写入 HDFS，复制文件
2. Hadoop 2.9-3.0 开启 S3Guard 以获得一致的 S3 列表（为此使用 DynamoDB）
3. Hadoop 3.1，切换到the S3A committers，它的设计考虑了一致性和性能问题。来自 netflix 的“暂存”版本在这里使用起来最简单。

延伸阅读：A zero-rename committer.

2019 年 11 月 1 日更新，亚马逊有自己的 ASF zero rename committer 的闭源实现。向 EMR 团队索取他们自己的正确性证明，因为我们其他人无法验证这一点。

2020 年 12 月 11 日更新：Amazon S3 现在完全一致，因此列表将是最新且正确的；更新不一致和 404 缓存不再。

• v1 提交算法仍然不安全，因为目录重命名是非原子的
• v2 提交算法在一个接一个地重命名文件时总是被破坏
• 重命名是 S3 上缓慢的 O(data) 复制操作，因此任务提交期间的失败窗口更大。

您不再面临数据丢失的风险，但是除了性能很糟糕之外，任务提交期间的失败也没有得到正确处理