MapReduce原子重命名

我正在看地图和报纸。本文指出reduce工作人员将其输出写入一个临时文件，然后将该文件自动重命名为某个保留的输出文件名，以指示任务已完成。第3.3节（出现故障时的语义）中提到了这一点

但为什么重命名必须是原子的呢？这是我的猜测

假设两个reduce工人A、B正在执行相同的任务

让此任务的最终输出文件名为X

工人A开始将其临时文件重命名为X

它不是原子的，所以worker B开始重命名文件

工人B将其临时文件重命名为X

工人A完成将临时文件重命名为X

混乱的状态

---

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

并非所有的文件系统都提供原子重命名，一些与Hadoop兼容的文件系统将重命名操作实现为非原子的

cp

+

rm

，并最终保持一致，并且在使用此类文件系统时会造成复杂性

:

与许多文件系统的情况不同，

gsutil mv

命令不执行单个原子操作。相反，它执行从源到目标的复制，然后删除每个对象的源

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

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

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

阅读这个ApacheHadoop

在“原子性”一节中指出，重命名文件或目录必须是原子的，但同时在引言的开头，您可以阅读以下内容：

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

GCS、S3和其他一些与Hadoop兼容的文件系统没有为重命名提供原子性，这会导致Hive或Spark出现问题，尽管这些问题或多或少可以通过其他工具或技术得到解决，比如使用S3Guard或每次重写分区时基于时间戳/runId创建新的分区位置，以及依赖配置单元中的原子分区装载等

现实世界并不理想。

---

Hadoop Mapreduce中的映射程序最初的目的是尽可能在数据所在的数据节点上运行，以加快处理速度，但像Amazon这样的公司正在分别销售计算集群和存储。您可以关闭或调整一个集群的大小，启动另一个集群并访问S3中的相同数据，数据和计算完全分离。

S3Guard（was）需要处理S3列表不一致；这不再是一个问题。但是，即使使用一致的AWS，重命名不是原子的事实也意味着提交算法是不安全的（而且速度非常慢）。这就是为什么emrfs和s3a fs都有特殊的提交者，他们依赖于文件上传是原子的，并且可以将上传推迟到作业完成commit@stevel你说这不再是个问题是什么意思？国际海事组织的删除仍然不一致。因此，更新是不一致的。尝试删除数千个文件并列出+全部读取，您将看到。。。FileNotFound异常。还是我遗漏了什么？这并不能解释为什么在我描述的那部分文章中使用了原子重命名。顺便说一句，如果我有一个名为X的文件，某个线程正在将另一个文件原子化重命名为X，并且我正在从原始的X读取，是否可以保证我一直从原始的X读取？@ArjunNair您描述的不是原子性。它是事务隔离。原子操作是不能部分执行的操作：如果失败，一切都保持不变，另一个事务不应看到部分更改，但如果没有隔离，第二个事务即使在原子操作之前启动，也会看到原子操作的结果。为了保证您继续读取相同的原始文件，需要一些锁定机制（或版本控制）来支持事务隔离。@leftjoin所以“不再是问题”w.r.t s3guard不需要担心列表不一致或404缓存，并且没有人需要担心更新不一致（我们无法处理）。create（overwrite=false）、rename file、rename dir、delete dir tree没有原子性，因此任何依赖这些元素来协调/排除工作进程的提交算法都注定会失败。幸运的是，在S3上重命名是如此缓慢，人们首先会注意到并抱怨这一点