1、元数据的由来
在hdfs文件系统中，用户的每一次操作，都会对文件系统产生响应的影响，那么谁来记录这些影响呢？
在hdfs文件系统中，edits文件记录了hdfs中的每一次操作，以及本次操作影响的文件其对应的block。
但于此同时，会产生一个问题，那就是随着时间的推移，hdfs文件系统中的edits文件会越来越大，这是hdfs文件系统会将edits文件进行切分处理，以避免个别edits文件过大现象。
那么，是那个用户来统筹和操作edits文件呢？
答案是Namenode用户。
2、问题
（1）问题所在
当用户想要查看某个文件的操作记录时，这里以text.txt文件为例，那么需要去查询edits文件，请问查询到的第一条相关记录就是text.txt文件的最终呈现形式吗？
不是的，因为在此期间，用户可能对text.txt文件进行一系列操作，可能text.txt文件已经被用户删除。
（2）解决方案
对于这种问题，hdfs文件系统也存在响应的解决方案。
hdfs文件系统会每隔相应的时间，对edits文件进行合并处理，得到一个FSLmage文件，这个文件记录着每个被使用文件的最终结果。
3、NameNode元数据维护管理
（1）查看edits文件
hadoop@node1:~$ cd /data/nn
hadoop@node1:/data/nn$ cd ./current
hadoop@node1:/data/nn/current$ ls
edits_0000000000000000001-0000000000000000001 edits_0000000000000000030-0000000000000000030
edits_0000000000000000002-0000000000000000003 edits_0000000000000000031-0000000000000000031
edits_0000000000000000004-0000000000000000004 edits_0000000000000000032-0000000000000000032
edits_0000000000000000005-0000000000000000005 edits_0000000000000000033-0000000000000000034
edits_0000000000000000006-0000000000000000007 edits_0000000000000000035-0000000000000000067
edits_0000000000000000008-0000000000000000008 edits_0000000000000000068-0000000000000000083
edits_0000000000000000009-0000000000000000010 edits_0000000000000000084-0000000000000000096
edits_0000000000000000011-0000000000000000011 edits_0000000000000000097-0000000000000000097
edits_0000000000000000012-0000000000000000013 edits_0000000000000000098-0000000000000000119
edits_0000000000000000014-0000000000000000014 edits_0000000000000000120-0000000000000000120
edits_0000000000000000015-0000000000000000016 edits_0000000000000000121-0000000000000000134
edits_0000000000000000017-0000000000000000017 edits_0000000000000000135-0000000000000000135
edits_0000000000000000018-0000000000000000019 edits_inprogress_0000000000000000136
edits_0000000000000000020-0000000000000000020 fsimage_0000000000000000120
edits_0000000000000000021-0000000000000000022 fsimage_0000000000000000120.md5
edits_0000000000000000023-0000000000000000024 fsimage_0000000000000000134
edits_0000000000000000025-0000000000000000025 fsimage_0000000000000000134.md5
edits_0000000000000000026-0000000000000000027 seen_txid
edits_0000000000000000028-0000000000000000028 VERSION
edits_0000000000000000029-0000000000000000029（2）元数据合并控制参数
对于元数据的合并，是一个定时过程，基于：
~dfs.namenode.checkpoint.period，默认为3600（秒）一小时。
~dfs.namenode.checkpoint.txns，默认为1000000，即100W次事务。
对于上述两个条件，只要有一个达到条件就执行。
那hdfs文件系统多长时间检查一次是否满足条件呢？基于：
dfs.namenode.checkpoint.check.period，默认为60秒来决定。
4、secondaryNameNode的作用
在这里，可能会很疑惑，为什么要将secondaryNameNode的作用，对于整个hdfs文件系统来讲，Namenode负责不断的生成edits文件，但Namenode并不会处理edits(edits和fsimage)文件，这些edits文件会被SecondaryNameNode通过http协议进行拉取，经SecondaryNameNode合并完成后使用。
