hadoop - hdfs mv命令如何工作

Question

我想知道 hdfs 中的 mv 命令是如何工作的？

1. 这是否只是一个象征性的变化，没有任何实际的数据移动？

   • 如果 moveTo 目录存在(可能在 diff 分区上)
   • 如果moveTo是一个新目录

2. 在 hadoop 中移动大文件时是否可能损坏数据？那么 cp 或 distcp 哪个更安全？

Answer 1

当用户调用hdfs dfs -mv时，HDFS保证重命名操作的原子性。运行此命令时，客户端对 NameNode 进行 RPC 调用。此 RPC 的 NameNode 实现在修改 inode 树时持有锁，并且仅在重命名完成后释放该锁，无论成功或失败。 (它可能会因权限或配额违规等原因而失败。)

由于实现完全在 NameNode 中执行并且仅操作文件系统元数据，因此不涉及实际的数据移动。在 hdfs dfs -mv 命令期间实际上没有与 DataNode 交互。文件的所有 block 都保持不变，与 inode 关联的 block 列表也保持不变。 NameNode 只是简单地从一个地方获取该文件的 inode 并将其移动到文件系统树中的另一个地方。不可能破坏 block 数据。

由于 NameNode 提供了重命名的保证原子实现，因此也不存在元数据损坏的可能性。不可能以“半完成”状态结束，文件在两个地方都存在，或者更糟糕的是，被完全删除。

现在我需要在上面的答案上添加一个细微的变化。大多数时候，在运行 HDFS shell 命令时，通常将 HDFS 作为后备文件系统进行交互。然而，这并不是唯一可能的文件系统实现。 Apache Hadoop 发行版附带了用于 S3 的替代文件系统插件, Azure Storage和 OpenStack Swift .还有许多供应商创建了自己的文件系统插件。这些替代文件系统是否提供原子重命名语义是那些其他文件系统的实现细节。 S3 和 Swift 插件将重命名实现为先复制后删除，因此它们肯定不提供原子性保证。 Azure 存储插件确实通过使用 Azure 存储 blob 租约为原子重命名提供了一些可选支持，但这不是默认行为。

此外，因此，无法跨不同的文件系统运行 hdfs dfs -mv。您必须为此使用复制命令，然后它将涉及完整的数据副本。以下是当您尝试跨文件系统重命名时会发生的情况。该示例尝试为我的 HDFS 安装中的源文件和本地文件系统上的目标运行 hdfs dfs -mv。命令被拒绝。

> hdfs dfs -mv hdfs:///testData file:///tmp/testData
mv: `hdfs:///testData': Does not match target filesystem

问题的最后一部分询问是否有可能在复制时损坏数据。 Hadoop 将在读取文件时执行校验和验证，因此预计客户端不会看到损坏的数据。 DistCp还可以在后处理步骤中执行源和目标之间的校验和比较。