MapReduce 原子重命名

如何解决MapReduce 原子重命名

我正在阅读地图简化纸 here。该论文指出，reduce 工作人员将他们的输出写入临时文件，然后他们自动将其重命名为某个保留的输出文件名，以指示任务已完成。这在第 3.3 节（出现故障时的语义）中提到。

但是为什么重命名需要是原子的？这是我的猜测。

1. 假设两个 reduce Worker A、B 正在执行相同的任务。
2. 让此任务的最终输出文件的名称为 X。
3. 工人 A 开始将其临时文件重命名为 X。
4. 这不是原子操作，因此工作人员 B 开始重命名文件。
5. 工人 B 将其临时文件重命名为 X。
6. 工人 A 完成将临时文件重命名为 X。
7. 状态混乱？

如果这就是我们需要原子重命名的原因，那么我想知道重命名是如何工作的。否则，我想知道为什么我们需要原子重命名。

解决方法

并非所有文件系统都提供原子重命名，一些与 Hadoop 兼容的文件系统将重命名操作实现为非原子 cp + rm 并最终保持一致，并且在使用此类文件系统时会造成复杂性。

GCS rename is not atomic：

与许多文件系统的情况不同，gsutil mv 命令不执行单个原子操作。相反，它执行从源到目标的复制，然后删除每个对象的源。

S3 中的重命名不是原子性的，也不是立即一致的： 阅读Introduction to S3Guard

重命名目录时，列表可能不完整或过时，因此重命名操作会丢失文件。这是非常危险的，因为 MapReduce、Hive、Spark 和 Tez 都依赖于重命名将 worker 的输出提交到作业的最终输出。

HDFS 提供原子和一致的删除和重命名，但其他 Hadoop 兼容文件系统可能不完全支持它。

阅读这篇 Apache Hadoop requirements of a Hadoop compatible filesystem

在原子性部分声明重命名文件或目录必须是原子性的，但同时在介绍的开头你可以阅读：

其他 Hadoop 文件系统的行为没有经过严格测试。捆绑的 S3 文件系统使亚马逊的 S3 对象存储（“blobstore”）可以通过文件系统 API 访问。 Swift FileSystem 驱动程序为 OpenStack Swift blobstore 提供了类似的功能。 branch-1-win 中的 Azure 对象存储文件系统与微软的 Azure 等效。 所有这些都绑定到对象存储，它们确实有不同的行为，尤其是在一致性保证和操作原子性方面。

GCS、S3 和其他一些与 Hadoop 兼容的文件系统不提供重命名的原子性，这会导致 Hive 或 Spark 出现问题，尽管可以使用其他工具或技术（例如使用 S3Guard 或创建新分区）或多或少地成功修复这些问题每次重写分区时基于时间戳/运行ID的位置，并依赖Hive等中的原子分区挂载等

现实世界并不理想。 Hadoop Mapreduce 中的映射器最初打算尽可能在数据所在的数据节点上运行以加快处理速度，但像亚马逊这样的公司正在单独销售计算集群和存储。您可以关闭或调整一个集群，启动另一个集群并访问 S3 中的相同数据，数据和计算完全分离。