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

Question

根据databricks的this博客，spark依赖于来自Hadoop的提交协议类，因此如果由于某些失败而未完成作业，则输出目录不会更改（不会发生部分输出文件）。

所以我的问题是;

如果发生故障（HDFS，S3等），火花会阻止对不同存储的部分写入吗？

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

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

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作为XAs。
• 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（文件），而不是O（1） - 但至少不是O（数据），如S3。您可以安全地使用Hadoop V1提交程序。

Answer 2

所有上述spark事务提交只能应用于hdfs，因为存在重命名目录的概念。在s3中没有重命名的概念，所以一旦将数据写入s3临时位置，它再次将该数据复制到新文件夹（In s3 Double copy）

如果发生故障（HDFS，S3等），火花会阻止对不同存储的部分写入吗？

没有Spark如果失败就不会阻止特定的写入，我们需要手动处理

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

临时位置位于最终目标文件夹内，其中temp为子文件夹

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

是的，他们使用outfolder / temp作为目的地