HDFS元数据信息FSimage和Edits以及SecondaryNameNode辅助管理元数据信息

元数据：讲的通俗点就是描述数据的数据
在hadoop2.x当中，使用如下的架构的时候：

所有的元数据信息都保存在了FsImage与Eidts文件当中，这两个文件就记录了所有的数据的元数据信息，元数据信息的保存目录配置在了hdfs-site.xml当中：

<property>
                <name>dfs.namenode.name.dirname>
                <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatasvalue>
        property>
<property>
                <name>dfs.namenode.edits.dirname>
                <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/editsvalue>
  property>

FSImage与Edits详解：

• 客户端对hdfs进行写文件时会首先被记录在edits文件中，edits修改时元数据也会更新。
• 每次hdfs更新时edits先更新后客户端才会看到最新信息。
• fsimage:是namenode中关于元数据的镜像，一般称为检查点。

一般开始时对namenode的操作都放在edits中，为什么不放在fsimage中呢？

因为fsimage是namenode的完整的镜像，内容很大，如果每次都加载到内存的话生成树状拓扑结构，这是非常耗内存和CPU。
fsimage内容包含了namenode管理下的所有datanode中文件及文件block及block所在的datanode的元数据信息。随着edits内容增大，就需要在一定时间点和fsimage合并。

secondarynameNode如何辅助管理FSImage与Edits文件？

1. secnonaryNN通知NameNode切换editlog
2. secondaryNN从NameNode中获得FSImage和editlog(通过http方式)
3. secondaryNN将FSImage载入内存，然后开始合并editlog，合并之后成为新的fsimage
4. secondaryNN将新的fsimage发回给NameNode
5. NameNode用新的fsimage替换旧的fsimage
   
   

完成合并的是secondarynamenode，会请求namenode停止使用edits,暂时将新写操作放入一个新的文件中（edits.new)。secondarynamenode从namenode中通过http get获得edits，因为要和fsimage合并，所以也是通过http get 的方式把fsimage加载到内存，然后逐一执行具体对文件系统的操作，与fsimage合并，生成新的fsimage，然后把fsimage发送给namenode，通过http post的方式。namenode从secondarynamenode获得了fsimage后会把原有的fsimage替换为新的fsimage,把edits.new变成edits。同时会更新fstime。

hadoop进入安全模式时需要管理员使用dfsadmin的save namespace来创建新的检查点。
secondarynamenode在合并edits和fsimage时需要消耗的内存和namenode差不多，所以一般把namenode和secondarynamenode放在不同的机器上。

fs.checkpoint.period: 默认是一个小时（3600s)
fs.checkpoint.size: edits达到一定大小时也会触发合并（默认64MB)