Spark I/O 与 S3

Question

阅读以下内容 https://blog.duyet.net/2021/04/spark-kube.netes-performance-tuning.html

使用 S3 的 I/O

append 数据到现有数据集的时间更长，特别是，所有 Spark 作业都已完成，但您的命令尚未完成，这是因为驱动程序节点正在将任务的 output 文件从作业临时目录移动到最终目标目录-by-one ，这在云存储（例如 S3）中很慢。

启用此优化：spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version=2

• 我想检查大胆的说法是否属实。 我从来没有听说过 Spark Driver 用 S3 写文件/控制写。 当然，不是 HDFS 集群，而且 Spark Driver 确实需要从 S3 读取数据。 我的知识是执行器将数据写入 rest 或 KAFKA 的数据，即使在 AWS 上运行 Spark 也是如此。 但是，大概我错了，或者不是？

• 如果为真，ADLS2 也一样吗？

评论“我遇到了同样的问题，我发现将内容写入临时 HDFS 目录并使用诸如 s3-dist-cp 之类的命令将内容移动到 S3 更快”不是我要问的.

Answer 1

写那篇文章的人并没有完全理解整个工作提交问题，并且具有危险的误导性。

1. 作业：查询/rdd 写入的整个执行
2. 任务尝试在不同的进程上执行工作； 在本地生成 output。 TA 可能会失败，因此这是孤立完成的。
3. 任务提交将任务尝试的工作提升为作业的工作。 必须是原子的，所以如果一个任务在中途失败（或者更糟的是，来自 spark 驱动程序的分区但继续进行），另一个任务尝试可能会被执行并提交。
4. job commit接受已提交任务的所有工作（未提交/失败任务中没有任何工作）并提升最终目录。

v1 提交算法包括

1. 任务提交：将任务尝试 src 树重命名为作业尝试目录（在 _tmp/ 下）。 依赖于 dir 重命名是 (1) 原子和 (2) 快速。 s3 的要求都不满足
2. 工作提交。 列出所有任务尝试目录树，将目录/文件重命名为目标，一个接一个。 期望上市和重命名是快速的。

v2 提交算法是

1. Task commit：列出task attempt src tree中的所有文件，并一一重命名为dest dir。 这不是原子的，不符合spark的要求。
2. 工作承诺。 写入 0 字节 _SUCCESS 文件。

博客作者指出 v1 的作业提交速度很慢是正确的。 真正的问题不是性能，而是正确性，因为任务提交在 s3 上不是原子的。

但是，v2到处都是不正确的，即使在 hdfs 上也是如此，因为 v2 任务提交是非原子的。 这就是为什么即使速度更快，您也不应该使用它。 任何地方。 真的。

那么对于 s3，如果你想将数据写入经典的“目录树”布局

• ASF spark/hadoop 版本：使用内置于最新 hadoop-aws 版本中的 s3a 提交者。 阅读 hadoop 文档以了解操作方法。
• EMR 使用 EMR S3 提交器。

这两者都通过将文件作为 S3 分段上传写入最终目的地来避免重命名，但直到作业提交才完成上传。 这使得作业提交更快，因为它只不过是列出/加载由每个任务尝试创建的单个清单文件（其中列出了其未完成的上传），然后发布完成。 没有重命名，并要求任务提交是一个 JSON 文件的 PUT，快速且原子。

如果为真，ADLS2 也一样吗？

v1 在那里工作，虽然列表很慢并且重命名不是很好，它比 HDFS 慢一点。它可以在作业提交的负载下进行限制，并出现奇怪的“古怪”失败，其中重命名被报告为 503/throttle 但实际上采取地方...这使 revoer 变得复杂。

Hadoop 3.3.5+ 添加了一个 Intermediate Manifest committer 以提高 Azure 和 Google GCS 的性能。 这些还通过在任务提交中编写清单来提交工作。 作业提交是这些的并行化列表/加载，然后并行化重命名。 将其视为 v3 提交算法。

• GCS：任务提交变得原子化且快速（其目录重命名为非原子 O(files)，这就是 v1 不安全的原因）
• ABFS：确实在任务提交中列出，因此避免了作业提交（时间，IOP），重命名是并行的但速率有限（规模）并且通过记录源文件的 etags，能够从节流相关的重命名失败误报中恢复（即如果 dest 文件存在并且 etag==source etag 一切都很好）

最后，还有云优先格式：Iceberg、delta lake、Hudi，这些通过在某处编写单个清单文件以原子方式提交作业； 查询计划成为列出/加载清单文件链的工作，从而识别要处理的数据文件。 这些被所有从事spark/hive云性能问题工作的人广泛认可为未来。 如果你能使用这些，你的生活会更好。

延伸阅读：

• spark 文档：安全快速地将工作提交到云存储中。
• 与“S3A 提交者”一起将工作提交给 S3
• 使用经 EMRFS S3 优化的提交程序
• 零重命名提交者：对象存储作为 Apache Hadoop 和 Spark 的目的地
• Azure 和谷歌云存储的清单提交者
• 清单提交者协议

在出现故障时将工作提交到持久存储的整个机制是分布式计算的一个迷人部分。 如果您阅读了零重命名提交者论文，最后一章实际上讨论了生产中仍然出错的地方。 事后看来，这是比当时更好的读物。 每个人都应该记录他们的生产问题。