术语

提交器(committer)的作用是确保作业的完整输出最终到达目标位置，即使在任务失败的情况下也是如此。

• 完成： 输出包含所有成功任务的工作。
• 独占性：失败任务的输出不会显示。
• 并发性: 当多个任务并行提交时，输出结果与任务串行提交时相同。这不是作业提交的必要条件。
• 可中止： 作业和任务可以在作业提交前中止，中止后它们的输出将不可见。
• 正确性连续性： 一旦作业提交，任何失败、中止或未成功任务的输出在未来某个时刻都不得出现。

对于Hive经典的层级目录结构表，作业提交要求将所有已提交任务的输出放置到目录树中的正确位置。

内置在hadoop-mapreduce-client-core模块中的提交器是FileOutputCommitter。

清单

设计了一个清单文件，其中包含（连同IO统计信息和其他一些内容）

1. 如果目标目录不存在，则必须创建的目标目录列表。
2. 需要重命名的文件列表，记录为（绝对源路径，绝对目标路径，文件大小）条目。

任务提交

任务尝试由以下方式提交：

1. 递归列出任务尝试工作目录以进行构建
2. 文件被重命名的一系列目录列表。
3. 要重命名的文件列表：源文件、目标文件、大小以及可选的etag。
4. 将该信息保存在作业尝试目录的清单文件中，文件名由任务ID派生。注意：为确保清单创建操作的原子性，将采用先写入临时文件再重命名为最终路径的方式。

不会进行重命名操作——文件将保留在其原始位置。

目录树遍历是单线程的，因此其复杂度为O(directories)，其中每个目录列表会使用一个或多个分页LIST调用。

这很简单，对于大多数任务来说，扫描不在作业的关键路径上。

统计分析可能证明未来转向并行扫描是合理的。

任务提交

作业提交包含以下内容：

1. 列出作业尝试目录中的所有清单文件。
2. 加载每个清单文件，创建尚不存在的目录，然后重命名重命名列表中的每个文件。
3. 保存一个与S3A提交器格式相同的JSON _SUCCESS文件（用于测试；使用写入和重命名实现原子保存）

任务提交阶段支持针对多个任务和每个任务的多个文件进行并行处理，具体包括：

1. 清单任务在一个“清单处理器”线程池中被加载和处理。
2. 目录创建和文件重命名操作分别在"executor"线程池中处理：由于它们使用最少的网络IO，因此可以并行执行多个重命名操作。
3. 作业清理可以并行化删除任务尝试目录。这很重要，因为目录删除在Google云存储上是O(files)复杂度，在使用OAuth认证的ABFS上也是如此。

祖先目录准备

可选扫描所有祖先...如果发现任何文件，则删除。

父目录创建

1. 探测共享目录映射以检查目录是否存在。如果找到：操作完成。
2. 如果映射为空，则在路径上调用getFileStatus()。未找到：创建目录，添加条目及其所有父路径的条目；找到且为目录：添加条目及其所有父路径的条目；找到且为文件：先删除，然后按前述方式创建。

高效处理目录的并发创建（或删除+创建）将是一个难点；为此投入了一些努力来构建需要创建的目录集合。

文件重命名

文件被并行重命名。

对目标路径进行预重命名检查（并删除现有内容）将是可选的。由于spark为每个文件生成新的UUID，这种情况不会发生，从而节省了HTTP请求。

验证

可选扫描所有已提交的文件，并验证长度以及已知的etag。用于测试和诊断。

缺点

• 需要一个全新的清单文件格式。
• May 使得任务提交更加复杂。

该解决方案对于GCS是必要的，并且在ABFS上应该也有益处，因为任务提交者会承担列表开销。

实现细节

约束条件

一个关键目标是保持清单提交器的独立性，既不触及现有的提交器代码，也不涉及hadoop代码库的其他部分。

它必须直接集成到MR和Spark中，除了已为S3A提交者实现的更改外，无需任何其他修改

• 自包含：不得要求更改hadoop-common等。
• 隔离性：不得对现有提交者进行更改
• 集成：必须通过PathOutputCommitterFactory进行绑定。

因此，这里有一些从其他地方复制粘贴的内容，例如 org.apache.hadoop.util.functional.TaskPool 是基于 S3ACommitter 的 org.apache.hadoop.fs.s3a.commit.Tasks。

_SUCCESS文件必须与S3A JSON文件兼容。这是为了确保任何现有的验证S3A提交器输出的测试套件都可以直接重定向到由清单提交器执行的作业，而无需任何修改。