使用临时目录的 Spark 事务写入操作

Question

根据databricks上的这篇博客，spark 依赖于 Hadoop 的提交协议类，因此如果由于某些故障而导致作业未完成，输出目录不会更改（部分输出文件不会发生）。

所以我的问题是；

在出现故障（HDFS、S3 等）时，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 分区，因此不能提交，但通常这一切都取决于心跳和假设一旦任务超时，它就不会重新出现。如果您自己实现提交算法，请确保在整个作业提交后挂起的任务提交者不会影响输出

对于对象存储：

• 数据块 DBIO。没有看到代码，听起来他们将 DynamoDB 用于 XA。
• IBM Stocator：阅读论文 Stocator: A High Performance Object Store Connector for Spark。重点是最小化 HTTP 请求并能够从失败的作业/任务提交中回滚。
• Hadoop 3.1 的 S3A 提交者，阅读：零重命名提交者。提交任务的时间取决于选择的提交者；在最坏的时间将数据从 VM 上传到 S3。任务故障可恢复。作业提交：每个创建的文件一个 *HTTP POST，可并行化，所以O(files/threads）。作业提交期间的失败不可恢复。

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