Spark 避免在 S3 中创建 _temporary 目录答案

【问题标题】：Spark avoid creating _temporary directory in S3Spark 避免在 S3 中创建 _temporary 目录
【发布时间】：2018-03-21 18:37:13
【问题描述】：

我需要将数据帧上传到 S3 存储桶，但我没有存储桶的删除权限。有什么办法可以避免在 S3 上创建这个 _temporary 目录？也许在 spark 中以任何方式使用本地 FS 作为 _temporary 目录，然后将最终生成的文件上传到 S3 存储桶或完全避免 _temporary 目录。

提前致谢。

【问题讨论】：

标签： apache-spark amazon-s3

【解决方案1】：

没有。

数据被写入_temporary/jobAttemptID/taskAttemptID/，然后在任务/作业提交期间重命名为dest dir。

您可以做的是为您的作业写入 hdfs，然后使用 distcp 进行复制。这有很多优点，尤其是“使用一致的文件系统，您不会冒 s3n 或 s3a 连接器带来的数据丢失风险”

2019 年 7 月 11 日更新。 Apache Hadoop S3A 提交程序让您无需临时文件夹或重命名即可提交工作，即使针对不一致的 S3 存储也能提供性能和正确结果。这就是您可以安全地提交工作的方式。 Amazon EMR 对自己的工作有自己的重新实现，尽管（目前没有 Spark 期望的完整故障语义

【讨论】：

我在分区写入 hdfs 期间看到类似的行为，即 df.write.partitionBy(keys).parquet('/location') 这里有替代方案吗？
使用临时目录以便任务可以并行运行，并通过重试修复故障。由于 rename() 在 HDFS 上是快速且原子的，因此无需担心
你好史蒂夫，我在哪里可以了解更多关于这些 s3a 提交者的信息？他们可以使用 spark 2.2 和 spark 2.4 吗？
这里说docs.cloudera.com/HDPDocuments/HDP3/HDP-3.1.4/…只用于spark sql？还是那个链接不正确？ s3a 提交者是否有任何限制？
它们不在 ASF spark 发行版中；虽然他们将在 spark 3.0.它们在 HDP-3.x 中的所有 hadoop 和 spark 版本中；

【解决方案2】：

是的，您可以避免在将数据帧上传到 s3 时创建_temporary 目录。

当 Spark 将数据附加到现有数据集时，Spark 使用FileOutputCommitter 来管理暂存输出文件和最终输出文件。

默认情况下，输出提交者算法使用版本 1。在此版本中，FileOutputCommitter 有两种方法，commitTask 和 commitJob。 commitTask 将任务生成的数据从任务临时目录移动到作业临时目录，当所有任务完成后，commitJob 将数据从作业临时目录移动到最终目的地。

但是，当输出提交者算法使用版本 2 时，commitTask 将任务生成的数据直接移动到最终目的地，commitJob 基本上是空操作。

如何将 spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version 设置为 2？ 您可以使用以下任何一种方法设置此配置：

启动集群时，您可以将 spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version 2 在火花配置。
spark.conf.set("mapreduce.fileoutputcommitter.algorithm.version", "2")
使用 Dataset API 写入数据时，可以在选项，即 dataset.write.option("mapreduce.fileoutputcommitter.algorithm.version", "2")。

详细了解输出提交器算法版本databricks-blog 和mapred-default

【讨论】：

感谢您的链接，但这对我不起作用（Apache 2.3.3/Hadoop 2.7.3）。它仍然会创建 _temporary 目录。在“foo”下保存时：foo/_temporary/0/_temporary/attempt_...000000_0/part-00000-....snappy.parquet 但是，commitTask 临时写入任务，然后将该输出直接移动到最终目录（由执行程序完成，并行性，更快） commitJob（由驱动程序完成？）然后本质上是禁止的按照 Databricks 博客中的说明操作。
v2 提交算法仍然需要每个任务尝试的临时目录；这就是它如何从失败的任务尝试中恢复并支持推测执行。但是：虽然作业提交现在是可重复的，但任务提交期间的失败可能会使输出目录处于未知状态。 Spark 假设任务提交是原子的，只是在这里重试——实际上它应该会失败。 MR V2算法不安全； EMR 也不是“优化的提交者”github.com/steveloughran/zero-rename-committer/releases