九、hdfs中Namenode元数据处理

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合并完成后使用。