NameNode是如何管理Block块的
NameNode基于
edits记录每次操作
fsimage记录某一个时间节点前的当前文件系统全部文件的状态和信息维护整个系统元数据
edits文件会被移动到fsimage中，这个合并理由：
SecondaryNameNode来操作
fsimage记录的内容是：文件的信息
edite文件
在hdfs中，文件是被划分了一堆堆的block块，那如果文件很大，以及文件很多，Hadoop是如何记录和整理文件和block块的关系呢
答案就在于NameNode
edits文件，是一个流水账文件，记录了hdfs中的每一次操作，以及本次操作影响的文件其对应的block，会想如下一样记录下来
如果要查看某个文件内容，我们只能看最后一个edits文件才能知道文件当前的状态
所以就要合并edits文件，得到最终的结果
fsimage文件
将全部的edits文件，最终为合并结果，即可得到一个FSImage文件
NameNode元数据管理维护
NameNode基于edits和FSImage的配合，完成整个文件系统文件的管理
1.每次对HDFS的操作，均被edits文件记录
2.edits达到大小上线后，开启新的edits文件记录
3.定期进行edits的合并操作
如果当前没有fsimage文件，将全部edits合并为第一个fsimage
如果当前已存在fsimage文件，将全部edits和已存在的fsimage进行合并，形成新的fsimage
元数据合并控制参数
对于元数据的合并，是一个定时过程，基于
dfs.namenode.checkpoint.period ,默认3600秒即为1小时
dfs.namenode.checkpoint.txns,默认1000000即为100w次事务
只要有一个达到条件就执行
检查是否达到条件，默认60秒检查一次，基于：
dfs.namenode.checkpoint.check.period，默认60秒，来决定
SecondaryNameNode的作用
NameNode只会写edits文件，合并是哦SecondaryNmaeNode做的
所以启动的时候必须要启动SecondaryNameNode要不然NameNode的edits文件会越来越多，HDFS也就会卡
对于元数据的合并，还记得之前基础的时候有一个角色是，SecondaryNameNode
合并元数据就是他来做的，SecondaryNameNode会通过http从NameNode拉取数据（edits和fsimage）
然后合并完成后提供给NameNode使用
