Question

我使用'hdfs oiv'命令将fsimage读入xml文件。

hdfs oiv -p XML -i  /../dfs/nn/current/fsimage_0000000003132155181 -o fsimage.out

根据我的理解，fsimage应该存储“块图”，就像文件如何分成块，以及每个块存储的位置。但是，这是记录inode在输出文件中的样子。

<inode>
    <id>37749299</id>
    <type>FILE</type>
    <name>a4467282506298f8-e21f864f16b2e7c1_468511729_data.0.</name>
    <replication>3</replication>
    <mtime>1442259468957</mtime>
    <atime>1454539092207</atime>
    <perferredBlockSize>134217728</perferredBlockSize>
    <permission>impala:hive:rw-r--r--</permission>
    <blocks>
        <block>
            <id>1108336288</id>
            <genstamp>35940487</genstamp>
            <numBytes>16187048</numBytes>
        </block>
    </blocks>
</inode>

然而，我期待的东西，如文件的hdfs路径，文件如何分解成更小的部分以及每个部分的存储位置（比如哪台机器，哪个本地fs路径......等等）

名称服务器上的任何位置是否包含映射，包含：

inode映射的HDFS路径
blockid到本地文件系统路径/磁盘位置映射？

Answer 1

有点晚了，但是因为我现在正在研究这个问题并且偶然发现了你的问题。

首先，有点背景。

（我正在使用Hadoop 2.6）

Name服务器负责维护INodes，它是（虚拟）文件系统结构的内存中表示，而Blocks由数据节点维护。我认为Name节点有几个原因不能维护其余的信息，比如指向数据存储在每个INode内的数据节点的链接：

需要更多内存来表示所有信息（内存是实际限制可写入HDFS集群的文件数量的资源，因为整个结构都保存在RAM中，以便更快地访问）
如果文件从一个节点移动到另一个节点，或者安装了新节点并且需要将文件复制到该节点，则会在名称节点上引发更多工作负载。每次发生时，Name节点都需要更新其状态。
灵活性，因为INode是一个抽象，因此添加链接会将其绑定到确定的技术和通信协议

现在回到你的问题：

fsimage文件已包含到HDFS路径的映射。如果您在XML中仔细查看，则每个INode，无论其类型是否具有ID（在您的情况下为37749299）。如果您在文件中查看更多内容，可以找到<INodeDirectorySection>部分，其中包含父级和子级之间的映射，此ID字段用于确定关系。通过<name>属性，您可以轻松确定您在HDFS资源管理器中看到的结构。
此外，您有<blocks>部分，其中包含ID ID（在您的情况下为1108336288）。如果仔细查看Hadoop的源代码，可以在idToBlockDir中找到方法DatanodeUtil，它可以提示如何在磁盘上组织文件并执行块ID映射。

基本上原始id被移位两次（16位和8位）。

int d1 = (int)((blockId >> 16) & 0xff);
int d2 = (int)((blockId >> 8) & 0xff);

最终目录使用获得的值构建：

String path = DataStorage.BLOCK_SUBDIR_PREFIX + d1 + SEP + DataStorage.BLOCK_SUBDIR_PREFIX + d2;

使用blk_<block_id>命名格式的文件中存储块的地方。

我不是Hadoop专家，所以如果能够更好地理解这一点的人能够纠正我逻辑中的任何流程，请这样做。希望这会有所帮助。

Hadoop inode到路径

1 个答案: