HDFS中namenode部分概述（一）

野性酷女 2022-06-18 09:39 172阅读 0赞

关于hdfs源码的阅读，我这个小菜鸟觉得有这么两种方式去读，一是抓住它关键的数据结构，知道了他们是干什么用的，剩下的就是一些围着他们转的操作了；二是跟踪执行过程的流程式阅读，以mkdir为例，从client应用发出mkdir请求到传递给namenode，再在datanode上执行，这么一个过程详细地跟踪下来，就理解了一大片。两种路子没有孰优孰劣，配合使用或许更有效。本篇先从数据结构的角度分享一点自己读namenode部分源码的收获。

![2011090120573543.gif][]

这是一张任何介绍hdfs的文章都会出现的架构图。采用的是master/slave模型，一个hdfs cluster包含一个NameNode和若干的DataNode，NameNode（以下简称nn）是master，主要负责管理hdfs文件系统，具体地包括namespace管理（其实就是目录结构），block管理（其中包括 filename->block，block->ddatanode list的对应关系）。nn提供的是始终被动接收服务的server，主要有三类协议接口：ClientProtocol接口、DatanodeProtocol接口、NamenodeProtocol接口，貌似还有一种，忘记了。DataNode(简称dn)主要是用来存储数据文件，hdfs将一个文件分割成一个个的block，这些block可能存储在一个DataNode上或者是多个DataNode上。dn负责实际的底层的文件的读写，如果客户端client程序发起了读hdfs上的文件的命令，那么首先将这些文件分成block，然后nn将告知client这些block数据是存储在那些dn上的，之后，client将直接和dn交互。

体系结构中还有个节点没画出来，Secondary NameNode，该部分主要是定时对NameNode进行数据snapshots进行备份，这样尽量降低NameNode崩溃之后，导致数据的丢失，其实所作的工作就是从nn获得fsimage和edits把二者重新合并然后发给nn，这样，既能减轻nn的负担又能保险地备份。

好了，下面开始正题。

![2011090120561923.jpg][]

不管是client还是dn的消息发到nn后最终都会落到FSnamesystem身上，这是一个重量级家伙，如图，对各种服务请求的处理都转交给它完成，它提供了对各种数据结构操作的接口，这些数据结构共同维护了整个namenode的元数据信息。

nn的主要数据结构有：

![2011090121204512.jpg][]

一个一个介绍。

FSdirectory：

FSDirectory存储整个文件系统的目录状态，对整个目录结构的管理通过调用FSImage和FSEditLog的方法从namenode本地磁盘读取元数据信息和向本地磁盘写入元数据信息，并登记对目录结构所作的修改到日志文件。另外，FSDirectory保存了文件名和数据块的映射关系。

INode是对文件系统目录结构中一个节点的抽象

INodeFile和INodeDirectory均继承自INode类，分别表示文件节点和目录节点。

INodeFile类中最重要的数据结构是BlockInfo blocks\[\]，它记录了一个文件所包含的所有Block，成员方法的操作大都与Block相关

INodefileUnderConstruction表示正在都建的文件

INodeDirectory的关键数据结构是List<INode> children记录了目录下所有的子节点信息

INodeDirectoryWithQuota表示有配额限制的目录，根目录就是这种类型。

FSimage：

把文件和目录的元数据信息持久化地存储到fsimage文件中，每次启动时从中将元数据加载到内存中构建目录结构树，之后的操作记录在edits log中

定期将edits与fsimage合并刷到fsimage中

loadFSImage(File curFile)用于从fsimage中读入Namenode持久化的信息。fsimage中保存的元数据信息格式如下，hdfs加载和写入时都按照该格式进行

fsimage是一个二进制文件，当中记录了HDFS中所有文件和目录的元数据信息，格式如下，这是网上流传的一张经典图，这是淘宝的一个师兄画的，拿来站沾光。

![2011090121254947.jpg][]

imageVersion（int）——image版本号

namespaceID（int）——命名空间ID，在namenode的生命期内保持不变，datanode注册时

返回作为其registrationID，每次和namenode通信时都要检查，不认识的namespaceID拒绝连接.

numFiles（16版以后long型）记录文件系统中的文件数

genstamp（long）生成image时间戳

下面是numFiles个文件（目录）信息：

path（String）文件或目录路径

replication（int）副本数，会调用FSEditLog.adjustReplication(replication);调整，目录的为0

mtime（long）修改时间

atime（long）访问时间

blockSize（long）块大小，目录是0

NumBlocks（int）文件包含的块数（imageVersion 9以后的版本numBlocks>=0时表示文件，之前的版本>0时表示文件），目录的为-1，saveINode2Image方法中可以看到

如果是文件，下面是NumBlocks个block的相关信息：

blockId(long)：该文件的block的blockid，

numBytes(long)：该block的大小

generationStamp(long)：该block的时间戳

如果是目录，读入quota信息：

nsQuota（long）命名空间大小配额，默认-1

dsQuota（long）磁盘空间配额，默认-1

下面是权限相关

username（String）文件或目录的所属用户名

groupname（String）组名

permission（short）权限

如果前面的path.length==0，表示根目录，设置根目录的配额，修改时间，访问时间和权限信息。

将这些信息读入内存之后，构造一个文件目录结构树，将表示文件或目录的节点填入到结构中。

然后是加载datanode信息（新版已取消该项）

再之后是加载FilesUnderConstruction.

BlocksMap：

block->datanode的信息没有持久化存储，而是namenode通过datanode的blockreport获取block->datanode list

BlocksMap负责维护了三种信息：

block->datanode list

block->INodeFile

datanode->blocks

这要归功于一个很牛逼的结构：Object\[\] triplets

![2011090121284088.jpg][]

他是一个三元组，每个block有几个副本，就有几个三元组。三元组的第一个元素表示该block所属的Datanode，类型是DatanodeDescriptor，通过它获得

block->datanode list

第二/三个元素表示该block所在Datanode上的前/后一个block（前驱和后继），类型是BlockInfo，通过它获得datanode->blocks

借助这个三元组可以找到一个block所属的所有datanode，也可以通过三元组的后两个元素信息找到一个datanode上所有的block。

上面这两个结构介绍之后，nn需要的namespace信息和block信息基本就全了。在nn加载fsimage完成之后，BlocksMap中只有每个block到其所属的datanodes list的对应关系信息还没建立。然后通过dn的blockReport来收集构建。当所有的dn汇报给nn的blockReport处理完毕后，BlocksMap整个结构也就构建完成了。

[2011090120573543.gif]: /images/20220618/0dfbcd5b38394a27a039517100c51b82.png
[2011090120561923.jpg]: /images/20220618/3a3249c02f824ef68808a1ac72754a7e.png
[2011090121204512.jpg]: /images/20220618/1a76e785f88b4f2ebf64ed2509d5ebf6.png
[2011090121254947.jpg]: /images/20220618/ad15f250a9684d4ca21e8e68084c44d5.png
[2011090121284088.jpg]: /images/20220618/463607879f8f40108acd6fbce8dbdc25.png