我正在阅读地图缩减论文here。该论文指出，reduce 工作人员将他们的输出写入一个临时文件，然后他们以原子方式将其重命名为某个保留的输出文件名，以表明任务已完成。这在第 3.3 节（出现故障时的语义）中有所提及。
但是为什么重命名需要是原子的？这是我的猜测。
如果这就是我们需要原子重命名的原因，那么我想知道重命名是如何工作的。否则，我想知道为什么我们需要原子重命名。
【问题讨论】：
标签： mapreduce distributed-computing distributed-system atomic acid
并非所有文件系统都提供原子重命名，一些与 Hadoop 兼容的文件系统将重命名操作实现为非原子 cp + rm 并最终保持一致，并且在使用此类文件系统时会产生复杂性。
与许多文件系统的情况不同，
gsutil mv命令不执行单个原子操作。相反，它执行从源到目标的复制，然后删除每个对象的源。
S3 中的重命名不是原子的，也不是立即一致的： 阅读Introduction to S3Guard
重命名目录时，列表可能不完整或已过期，因此重命名操作会丢失文件。这是非常危险的，因为 MapReduce、Hive、Spark 和 Tez 都依赖 rename 将 worker 的输出提交到作业的最终输出。
HDFS 提供原子和一致的删除和重命名，但其他 Hadoop 兼容的文件系统可能不完全支持它。
阅读这篇 Apache Hadoop requirements of a Hadoop compatible filesystem
在原子性部分中声明重命名文件或目录必须是原子的，但同时在简介的开头您可以阅读以下内容：
其他 Hadoop 文件系统的行为没有经过严格测试。捆绑的 S3 FileSystem 使 Amazon 的 S3 对象存储（“blobstore”）可以通过 FileSystem API 访问。 Swift FileSystem 驱动程序为 OpenStack Swift blobstore 提供了类似的功能。 branch-1-win 中的 Azure 对象存储文件系统与 Microsoft 的 Azure 等效项通信。 所有这些都绑定到对象存储，它们确实具有不同的行为，尤其是在一致性保证和操作的原子性方面。
GCS、S3 和其他一些与 Hadoop 兼容的文件系统不提供重命名的原子性，这会导致 Hive 或 Spark 出现问题，尽管使用其他工具或技术（如使用 S3Guard 或创建新分区）或多或少可以成功修复这些问题每次重写分区时基于时间戳/runId的位置，并依赖于Hive等中的原子分区挂载等
现实世界并不理想。 Hadoop Mapreduce 中的映射器最初旨在尽可能在数据所在的数据节点上运行以加快处理速度，但亚马逊等公司正在单独销售计算集群和存储。您可以关闭或调整一个集群的大小，启动另一个集群并在 S3 中访问相同的数据，数据和计算完全分离。
【讨论】：