我在这里看地图论文。本文指出，reduce工作者将其输出写入临时文件，然后自动将其重命名为某些保留的输出文件名，以表明任务已经完成。这在第3.3节(出现故障时的语义)中提到过。
但是为什么rename必须是原子的呢?这是我的猜测。
- 假设两个reduce工人A, B正在执行相同的任务。
- 让此任务的最终输出文件名称为x。
- Worker A开始将其临时文件重命名为x。
- 它不是原子的，所以worker B开始重命名文件
- Worker B将其临时文件重命名为x。
- Worker A完成对临时文件的重命名。
- 混乱状态?
如果这就是我们需要原子重命名的原因，那么我想知道重命名是如何工作的。否则，我想知道为什么我们需要原子重命名。
不是所有的文件系统都提供原子重命名，一些与Hadoop兼容的文件系统将重命名操作实现为非原子的cp+rm，并最终一致，这在使用此类文件系统时造成了复杂性。
GCS重命名不是原子的:
与许多文件系统不同，
gsutil mv命令不执行单个原子操作。相反，它执行从源到目标的复制，然后为每个对象删除源。
S3中的Rename不是原子的，不是立即一致的:阅读S3Guard简介
在重命名目录时，清单可能不完整或过期，因此重命名操作会丢失文件。这是非常危险的，因为MapReduce, Hive, Spark和Tez都依赖于rename来将worker的输出提交到作业的最终输出。
HDFS提供原子和一致的删除和重命名，但其他Hadoop兼容的文件系统可能不完全支持它。
阅读Apache Hadoop对Hadoop兼容文件系统的要求
在原子性一节中指出，重命名文件或目录必须是原子的，但同时，在引言的开头，你可以读到:
其他Hadoop文件系统的行为没有经过严格的测试。捆绑的S3文件系统使Amazon的S3对象存储("blobstore")可以通过文件系统API访问。Swift文件系统驱动程序为OpenStack Swift blobstore提供了类似的功能。branch-1-win中的Azure对象存储文件系统与微软的Azure对等物对话。所有这些都绑定到对象存储，它们确实有不同的行为，特别是关于一致性保证和操作的原子性。
GCS, S3和其他一些hadoop兼容的文件系统不提供重命名的原子性，这会导致Hive或Spark的问题，尽管这些问题或多或少可以成功地使用其他工具或技术来修复，如使用S3Guard或在重写分区时每次基于时间戳/runId创建新的分区位置，并依赖于Hive中的原子分区挂载等
现实世界并不理想。Hadoop Mapreduce中的映射器最初的目的是尽可能在数据节点上运行，这样可以加快处理速度，但像亚马逊这样的公司正在分别销售计算集群和存储。您可以关闭或调整一个集群，启动另一个集群，并在S3中访问相同的数据，数据和计算完全分离。