之前写过一篇非常详细的,利用QJM在HDFS2.0部署HA策略的文章，主要说了利用QJM进行HA部署以及其原理（ ）。但是，其中没有详细描述Hadoop2.x通过QJM部署HA完毕之后，ActiveNamenode和StandbyNamenode之间的元数据运行机制,实际上由于2.x的HA策略的引入，其元数据的运行机制和1.x比起来已经有了很大的不同。写这篇blog的目的主要是为了对hadoop1.x和hadoop2.x的元数据运行机制进行比较，当是自己的笔记吧。
二、fsimage和edits文件的作用
先来看看关于NameNode元数据相关的目录结构，也就是配置在hdfs-site.xml上的dfs.name.dir项，具体目录为$dfs.name.dir/current。看看目录(hadoop2.2.0版本)：
我们发现有些以edites_开头和少量以fsimage开头的文件。fsimage和edites文件都是hadoop文件系统元数据的组成部分。
其中fsimage镜像文件包含了整个HDFS文件系统的所有目录和文件的indoe信息。对于文件来说包括了数据块描述信息、修改时间、访问时间等；对于目录来说包括修改时间、访问权限控制信息(目录所属用户，所在组等)等。
另外，edit文件主要是在NameNode已经启动情况下对HDFS进行的各种更新操作进行记录，HDFS客户端执行所有的写操作都会被记录到edit文件中。
--------------------------------------分割线 --------------------------------------
Ubuntu 13.04上搭建Hadoop环境
Ubuntu 12.10 +Hadoop 1.2.1版本集群配置
Hadoop: The Definitive Guide【PDF版】
--------------------------------------分割线 --------------------------------------
三、NameNode简单启动过程
在HDFS中，任何一个文件，目录和block，在HDFS中都会被表示为一个object存储在namenode的内存中，每一个object占用150 bytes的内存空间。当NameNode启动的时候，首先会将fsimage里面的所有内容映像到内存中，然后再一条一条地执行edits中的记录，然后等待各个Datanode向自己汇报块的信息来组装blockMap，从而离开安全模式。在这里涉及到BlockMap结构，所谓的BlockMap结构就是记录着block的元数据（加载在NameNode的内存中）和其对应的实际数据（存储在各个DataNode中）的映射关系。真正每个block对应到datanodes列表的信息在hadoop中并没有进行持久化存储，而是在所有datanode启动时，每个datanode对本地磁盘进行扫描，将本datanode上保存的block信息汇报给namenode,namenode在接收到每个datanode的块信息汇报后，将接收到的块信息，以及其所在的datanode信息等保存在内存中。HDFS就是通过这种块信息汇报的方式来完成 block -> datanodes list的对应表构建。Datanode向namenode汇报块信息的过程叫做blockReport，而namenode将block -> datanodes list的对应表信息保存在一个叫BlocksMap的数据结构中。因此，我们可以得出一个非常重要的结论，NameNode不会定期的向各个DataNode去”索取“块的信息，而是各个datanode定期向namenode汇报块的信息。当组装完NameNode组装完BlockMap的信息后基本上整个HDFS的启动就完成了，可以顺利地离开安全模式了。分析到这里，我们就可以很清楚地知道整个HDFS的启动速度是由上面决定的了，第一：执行各个edits文件，这个也是我这篇blog重点讨论的。第二：各个DataNode向NameNode汇报块信息的进度（当99.9%的block汇报完毕才会离开安全模式）。
四、Hadoop1.x中fsimage和edits的合并机制
当edits文件很多很大的时候，NameNode在启动的时候需要逐一每条的执行这些edits文件，这就严重地影响了整个HDFS的启动时间。这问题在hadoop1.x是通过SecondaryNamenode机制将edits文件合并到fsimage中，其之得到解决，SecondaryNamenode在第一代的Hadoop中算是一个非热备的NameNode备份。整个SecondaryNamenode的工作流程简单地画了一下图：
简单描述一下具体流程：
步骤一：SSN在一个checkpoint时间点和NameNode进行通信，请求NameNode停止使用edits文件记录相关操作而是暂时将新的Write操作写到新的文件edit.new来。
步骤二：SSN通过HTTP GET的方式从NameNode中将fsimage和edits文件下载回来本地目录中。