时间戳

首页 > 解决方案 > 使用临时目录的 Spark 事务写入操作

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

问题描述

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

所以我的问题是；

如果发生故障（HDFS、S3 等），Spark 是否会阻止对不同存储的部分写入？

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

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

标签： apache-sparkamazon-s3hdfs

解决方案

这是一个非常有趣的问题——对于如何以不可避免的失败规模实施数据分析至关重要。

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 提交程序。

推荐阅读