Hadoop1.x和2.X的HDFS fsimage和edits文件运行机制对比

一、概述

二、fsimage和edits文件的作用

    先来看看关于NameNode元数据相关的目录结构,也就是配置在hdfs-site.xml上的dfs.name.dir项,具体目录为$dfs.name.dir/current。看看目录(hadoop2.2.0版本):

Hadoop1.x和2.X的HDFS fsimage和edits文件运行机制对比

我们发现有些以edites_开头和少量以fsimage开头的文件。fsimage和edites文件都是hadoop文件系统元数据的组成部分。

    其中fsimage镜像文件包含了整个HDFS文件系统的所有目录和文件的indoe信息。对于文件来说包括了数据块描述信息、修改时间、访问时间等;对于目录来说包括修改时间、访问权限控制信息(目录所属用户,所在组等)等。

    另外,edit文件主要是在NameNode已经启动情况下对HDFS进行的各种更新操作进行记录,HDFS客户端执行所有的写操作都会被记录到edit文件中。

--------------------------------------分割线 --------------------------------------

--------------------------------------分割线 --------------------------------------

三、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的工作流程简单地画了一下图:

Hadoop1.x和2.X的HDFS fsimage和edits文件运行机制对比

 

简单描述一下具体流程:

步骤一:SSN在一个checkpoint时间点和NameNode进行通信,请求NameNode停止使用edits文件记录相关操作而是暂时将新的Write操作写到新的文件edit.new来。

步骤二:SSN通过HTTP GET的方式从NameNode中将fsimage和edits文件下载回来本地目录中。

步骤三:SSN中合并edits和fsimage。SSN将从NameNode中下载回来的fsimage加载到内存中,然后逐条 执行edits文件中的各个操作项,使得加载到内存中的fsimage中包含edits中的操作,这个过程就是所谓的合并了。

步骤四:在SSN中合并完fsimage和edits文件后,需要将新的fsimage回传到NameNode上,这个是通过HTTP POST方式进行的。

步骤五:NameNode将从SSN接收到的新的fsimage替换掉旧的fsimage。同时将edits.new文件转换为通常的edits文件,这样edits文件的大小就得到减少了。SSN整个合并以及和NameNode的交互过程到这里已经结束。

相关推荐