一、NameNode 元数据的目录结构

NameNode 元数据相关的目录结构配置在hdfs-site.xml 上的dfs.name.dir 项，具体目录为$dfs.name.dir/current。在目录下主要有VERSION，edits，fsimage 和seen_txid 等文件。其目录结构如图3-2 所示：

图3-2　NameNode 元数据目录结构

1. VERSION

VERSION 文件是Java 属性文件，内容如下：

（1）namespaceID ：是文件系统的唯一标识符，在文件系统首次格式化之后生成。

（2）cTime：表示NameNode 存储时间的创建时间，由于NameNode 没有更新过，所以这里的记录值为0，以后对NameNode 升级之后，cTime 将会记录更新时间戳。

（3）storageType：说明这个文件存储的是什么类型的数据结构信息（如果是DataNode，storageType=DATA_NODE）

（4）blockpoolID：是针对每一个NameSpace 所对应的blockpool 的ID，上面的这个BP-1359655638-192.168.254.128-1503016375293 就是在master 的NameSpace 下的存储块池的ID，这个ID 包括了其对应的NameNode 节点的ip 地址。

（5）layoutVersion：表示HDFS 永久性数据结构的版本信息，只要数据结构变更，版本号也要递减，此时的HDFS 也需要升级，否则磁盘仍旧是使用旧版本的数据结构，这会导致新版本的NameNode 无法使用

（6）clusterID：是系统生成的集群ID。(www.daowen.com)

2. fsimage 和edits

fsimage 和edits 是NameNode 中两个很重要的文件。fsimage 镜像文件包含了整个HDFS 文件系统的所有目录、文件的indoe 信息和文件块到文件的映射。对于目录来说包括修改时间、访问权限控制信息（目录所属用户，所在组等）；对于文件来说包括了文件块描述信息、修改时间、访问时间等。

edits 文件主要是在NameNode 已经启动情况下对HDFS 进行的各种更新操作进行记录，HDFS 客户端执行所有的写操作都会被记录到edits 文件中。例如，在HDFS 中创建一个文件，Namenode 就会在edits 中插入一条记录来表示；同样地，修改文件的副本系数也将往edits 插入一条记录。

NameNode 元数据是保存在内存中的，由DataNode 向其汇报每个节点所保存的相关信息，当用户访问文件时，通过NameNode 就可以知道到哪个DataNode 访问哪些文件块。NameNode 元数据的逻辑关系如图3-3 所示：

file1.txt 文件占用三个块， 分别是BlkA、BlkB、BlkC，BlkA 的三个副本分别保存在DN1、DN5、DN6 上，BlkB 的三个副本分别保存在DN2、DN3、DN4 上，以及BlkC 的三个副本分别保存在DN1、DN3、DN4 上，至于读取file1.txt 的时候会分别到哪个DataNode 上读取，在本章的3.3.1 有详细介绍，这里不做过多赘述。

图3-3　元数据逻辑关系示意图

二、HDFS 的启动流程

当NameNode 启动时，从本地文件系统中读取edits 和fsimage 文件，将所有edits中的事务作用在内存中的fsimage 上，并将这个新版本的fsimage 从内存中写入到本地文件上，然后删除旧的edits（这个过程称为检查点），最后等待各个DataNode 向NameNode 汇报文件块的信息来组装block ID 映射关系。

DataNode 启动时会扫描本地文件系统，产生一个本地文件对应的HDFS 文件块的列表（每个文件块会对应一个本地文件），然后作为报告发送到NameNode（这个报告称为块状态报告）。NameNode 在接收到每个DataNode 的块汇报信息后，将其和所在的DataNode 信息等保存在内存中。

在Hadoop1.x 中如果NameNode 失效，可以通过Secondary NameNode 中保存的fsimage 和edits 数据恢复出NameNode 最近的状态。为了加快NameNode 重启速度慢，Secondary NameNode 还会定期合并edits。

在Hadoop2.x 中不再使用Secondary NameNode 作为NameNode 的恢复手段，而是采用了HA 机制。在Hadoop 集群中有多台NameNode，但只有一台NameNode 处于Active 状态，其余的均处于Standby 状态。Active NameNode 负责集群中所有客户端的操作；而Standby NameNode 主要用于备用，它主要维持足够的状态，如果必要，可以提供快速的故障恢复。

为了让Standby NameNode 的状态和Active NameNode 保持同步，即元数据保持一致，会通过一组称作JournalNode（JournalNode 至少部署在三个节点上，而且必须是奇数）的独立进程进行相互通信。当Active NameNode 的命名空间有任何修改时，它需要持久化到一半以上的JournalNode 上（通过edits 持久化存储）。Standby NameNode 有能力读取JournalNode 中的变更信息，并且一直监控edits 的变化，并把变化应用于自己的命名空间。Standby NameNode 可以确保在集群出错时，命名空间状态已经完全同步，然后就可以切换到Active 状态。