apache-spark - 使用临时目录的 Spark 事务写操作

Question

根据 this在 databricks 的博客中，spark 依赖于 Hadoop 的提交协议(protocol)类，因此如果作业由于某些故障而未完成，输出目录不会更改(不会出现部分输出文件)。

所以我的问题是;

在发生故障时(HDFS、S3 等)，spark 是否可以防止部分写入不同的存储？

不同的 spark 作业是否可以在最终写入操作之前使用相同的临时位置？

多次提交的同一个 spark 作业是否可以使用相同的临时位置？

Answer 1

这是一个非常有趣的问题 — 也是您如何在不可避免地发生故障的规模上实现数据分析的基础。

Hadoop V1 算法

HDFS:O(1) 提交任务，对任务提交失败具有弹性。作业提交是 ~O(files) 有很多文件；如果中途失败，则输出状态未知。

S3:O(data) 提交任务，提交作业非常慢(O(data) 用于整个作业的输出)。缺乏原子重命名有潜在危险。

Hadoop V2 提交算法

HDFS:O(files) 提交任务，无法处理失败。作业提交是 O(1) touch _SUCCESS 调用。 S3: O(data) 提交任务，无法处理失败，并且提交的 COPY 操作时间更长，任务提交失败的几率更高。

我个人认为 V2 算法的失败语义不起作用； MapReduce 和 Spark 都假设在提交过程中失败的任务可以重复...这在这里不成立。

还有一些您不想知道的额外细节，例如驱动程序如何得出任务失败的结论，MapReduce 如何确定它已从 YARN 中分区，因此不能提交，但通常都归结为心跳和假设一旦任务超时它就不会重新浮出水面。如果您自己实现提交算法，请确保在整个作业提交之前一直挂起的任务提交者不会影响输出

对于对象存储:

• Databricks DBIO。没有看到代码，听起来他们使用 DynamoDB 作为 XA。
• IBM Stocator:阅读论文， Stocator: A High Performance Object Store Connector for Spark .重点是最大限度地减少 HTTP 请求并能够从失败的作业/任务提交中回滚。
• Hadoop 3.1 的 S3A 提交者，阅读:A Zero Rename Committer .提交任务的时间取决于选择的提交者；在最坏的时间将数据从 VM 上传到 S3。任务失败可恢复。作业提交:每个创建的文件一个 *HTTP POST，可并行化，因此 O(files/threads)。作业提交期间的失败不可恢复。

四舍五入； Azure 和谷歌云存储确实有目录重命名，尽管它们通常是 O(files)，而不是 O(1)——但至少不是 O(data)，比如 S3。您可以安全地使用 Hadoop V1 提交程序。