Hadoop二次开发必备，Hadoop源码分析（七）

DataNode的介绍基本告一段落。我们开始来分析NameNode。相比于DataNode，NameNode比较复杂。系统中只有一个NameNode，作为系统文件目录的管理者和“inode表”（熟悉UNIX的同学们应该了解inode）。为了高可用性，系统中还存在着从NameNode。
先前我们分析DataNode的时候，关注的是数据块。NameNode作为HDFS中文件目录和文件分配的管理者，它保存的最重要信息，就是下面两个映射：
文件名à数据块
数据块àDataNode列表
其中，文件名à数据块保存在磁盘上（持久化）；但NameNode上不保存数据块àDataNode列表，该列表是通过DataNode上报建立起来的。
下图包含了NameNode和DataNode往外暴露的接口，其中，DataNode实现了InterDatanodeProtocol和ClientDatanodeProtocol，剩下的，由NameNode实现。



ClientProtocol提供给客户端，用于访问NameNode。它包含了文件角度上的HDFS功能。和GFS一样，HDFS不提供POSIX形式的接口，而是使用了一个私有接口。一般来说，程序员通过org.apache.hadoop.fs.FileSystem来和HDFS打交道，不需要直接使用该接口。DatanodeProtocol：用于DataNode向NameNode通信，我们已经在DataNode的分析过程中，了解部分接口，包括：register，用于DataNode注册；sendHeartbeat/blockReport/blockReceived，用于DataNode的offerService方法中；errorReport我们没有讨论，它用于向NameNode报告一个错误的Block，用于BlockReceiver和DataBlockScanner；nextGenerationStamp和commitBlockSynchronization用于lease管理，我们在后面讨论到lease时，会统一说明。NamenodeProtocol用于从NameNode到NameNode的通信。下图补充了接口里使用的数据的关系。





--------------------------------------------------------------------------------------------------------



我们先分析INode*.java，类INode*抽象了文件层次结构。如果我们对文件系统进行面向对象的抽象，一定会得到和下面一样类似的结构图（类INode*）：




INode是一个抽象类，它的两个字类，分别对应着目录（INodeDirectory）和文件（INodeFile）。INodeDirectoryWithQuota，如它的名字隐含的，是带了容量限制的目录。INodeFileUnderConstruction，抽象了正在构造的文件，当我们需要在HDFS中创建文件的时候，由于创建过程比较长，目录系统会维护对应的信息。
INode中的成员变量有：name，目录/文件名；modificationTime和accessTime是最后的修改时间和访问时间；parent指向了父目录；permission是访问权限。HDFS采用了和UNIX/Linux类似的访问控制机制。系统维护了一个类似于UNIX系统的组表（group）和用户表（user），并给每一个组和用户一个ID，permission在INode中是long型，它同时包含了组和用户信息。

INode中存在大量的get和set方法，当然是对上面提到的属性的操作。导出属性，比较重要的有：collectSubtreeBlocksAndClear，用于收集这个INode所有后继中的Block；computeContentSummary用于递归计算INode包含的一些相关信息，如文件数，目录数，占用磁盘空间。

INodeDirectory是HDFS管理的目录的抽象，它最重要的成员变量是：

private List<INode> children;

就是这个目录下的所有目录/文件集合。INodeDirectory也是有大量的get和set方法，都很简单。INodeDirectoryWithQuota进一步加强了INodeDirectory，限制了INodeDirectory可以使用的空间（包括NameSpace和磁盘空间）。

INodeFile是HDFS中的文件，最重要的成员变量是：

protected BlockInfo blocks[] = null;

这是这个文件对应的Block列表，BlockInfo增强了Block类。

INodeFileUnderConstruction保存了正在构造的文件的一些信息，包括clientName，这是目前拥有租约的节点名（创建文件时，只有一个节点拥有租约，其他节点配合这个节点工作）。clientMachine是构造该文件的客户端名称，如果构造请求由DataNode发起，clientNode会保持相应的信息，targets保存了配合构造文件的所有节点。

上面描述了INode*类的关系。下面我们顺便考察一下一些NameNode上的数据类。

BlocksMap保存了Block和它在NameNode上一些相关的信息。其核心是一个map：Map<Block, BlockInfo>。BlockInfo扩展了Block，保存了该Block归属的INodeFile和DatanodeDescriptor，同时还包括了它的前继和后继Block。有了BlocksMap，就可以通过Block找对应的文件和这个Block存放的DataNode的相关信息。

接下来我们来分析类Datanode*。DatanodeInfo和DatanodeID都定义在包org.apache.hadoop.hdfs.protocol。DatanodeDescriptor是DatanodeInfo的子类，包含了NameNode需要的附加信息。DatanodeID只包含了一些配置信息，DatanodeInfo增加了一些动态信息，DatanodeDescriptor更进一步，包含了DataNode上一些Block的动态信息。DatanodeDescriptor包含了内部类BlockTargetPair，它保存Block和对应DatanodeDescriptor的关联，BlockQueue是BlockTargetPair队列。

DatanodeDescriptor包含了两个BlockQueue，分别记录了该DataNode上正在复制（replicateBlocks）和Lease恢复（recoverBlocks）的Block。同时还有一个Block集合，保存的是该DataNode上已经失效的Block。DatanodeDescriptor提供一系列方法，用于操作上面保存的队列和集合。也提供get*Command方法，用于生成发送到DataNode的命令。

当NameNode收到DataNode对现在管理的Block状态的汇报是，会调用reportDiff，找出和现在NameNode上的信息差别，以供后续处理用。readFieldsFromFSEditLog方法用于从日志中恢复DatanodeDescriptor。

下一篇

Hadoop二次开发必备，Hadoop源码分析（八）

上一篇

Hadoop二次开发必备，Hadoop源码分析（六）