一. NameNode 元数据目录结构
- 在/root/hd/dfs/name/current目录下。
/root/hd/dfs/name/current-rw-r--r--. 1 root root 1048576 1月 3 23:40 edits_0000000000000000323-0000000000000000362
-rw-r--r--. 1 root root 1048576 1月 4 15:47 edits_0000000000000000363-0000000000000000363
-rw-r--r--. 1 root root 523 1月 4 16:45 edits_0000000000000000364-0000000000000000372
-rw-r--r--. 1 root root 100 1月 4 17:45 edits_0000000000000000373-0000000000000000375
-rw-r--r--. 1 root root 1048576 1月 4 17:45 edits_0000000000000000376-0000000000000000376
-rw-r--r--. 1 root root 1048576 1月 4 22:18 edits_0000000000000000377-0000000000000000377
-rw-r--r--. 1 root root 42 1月 4 23:02 edits_0000000000000000378-0000000000000000379
-rw-r--r--. 1 root root 1048576 1月 4 23:02 edits_inprogress_0000000000000000380
-rw-r--r--. 1 root root 1159 1月 4 22:18 fsimage_0000000000000000376
-rw-r--r--. 1 root root 62 1月 4 22:18 fsimage_0000000000000000376.md5
-rw-r--r--. 1 root root 1159 1月 4 23:02 fsimage_0000000000000000379
-rw-r--r--. 1 root root 62 1月 4 23:02 fsimage_0000000000000000379.md5
-rw-r--r--. 1 root root 4 1月 4 23:02 seen_txid
-rw-r--r--. 1 root root 219 1月 4 22:18 VERSION有VERSION，see_txid,frimage,edits.这些文件。
- fsimage：元数据镜像文件。就是将内存中的元数据信息保存到磁盘，需要的时候就再从磁盘读取出来到内存。
- edits：操作hdfs的日志文件
- fstime：保存最后一次的还原点时间
VERSION文件内容是：
#Fri Jan 04 22:18:53 CST 2019
namespaceID=436986712
clusterID=CID-4c506078-e726-4ee2-bcf0-5cd0e8d057b2
cTime=1545556579425
storageType=NAME_NODE
blockpoolID=BP-1936340378-192.168.146.137-1545556579425
layoutVersion=-63- namespaceID ：是文件系统的唯一标识符，在文件系统首次格式化之后生成的
- clusterID ：是系统生成或手动指定的集群 ID
- cTime ：表示 NameNode 存储时间的创建时间
- storageType ：说明这个文件存储的是什么进程的数据结构信息（如果是 DataNode，storageType=DATA_NODE）
- blockpoolID：是针对每一个 Namespace 所对应的 blockpool 的 ID，上面的这个 BP-1936340378-192.168.146.137-1545556579425就是在我的 nameserver1 的 namespace下的存储块池的 ID，这个 ID 包括了其对应的 NameNode 节点的 ip 地址。
- layoutVersion ：表示 HDFS 永久性数据结构的版本信息， 只要数据结构变更，版本号也要递减，此时的 HDFS 也需要升级，否则磁盘仍旧是使用旧版本的数据结构，这会导致新版本的 NameNode 无法使用
注：当客户端对hdfs中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存meta.data中
namenode如何管理元数据
流程图:
分析：
1、当客户端向namenode发出更新元数据的请求时，namenode会根据更新的数据内容存放位置等从而来更新好元数据。而每次做的更新操作都会被记录到操作日志文件中（edits）。
2、为了防止namenode挂掉数据丢失从而准备了一个secondaryNamenode，从而可以将namenode上的数据备份。它会每隔一段时间（默认是30分钟）去询问一次namenode，看看是否需要合并（checkpoint），当namenode上的操作日志文件大到一定的时候会告诉secondaryNamenode需要合并。
3、此时namenode会滚动当前在操作的日志文件edits.inprogress（目的是多下载一些到secondaryNamenode）。
4、secondaryNamenode会将edits文件和镜像文件fsimage下载下来，接着会根据操作日志文件根据一些算法计算出元数据从而来和镜像文件（保存了namenode的元素据）进行合并存到内存中。
5、secondaryNamenode会将内存中合并后的的元数据存到硬盘，序列化上传到namenode，最后namenode会将secondaryNamenode上传的元数据存到镜像文件中，这样镜像文件就达到了备份的效果，同时secondaryNamenode上也有对应的元数据，即使namenode挂掉我们也可以复制secondaryNamenode上的数据到namenode。
一些问题
注1：namenode和secondary namenode的工作目录存储结构完全相同，所以，当namenode故障退出需要重新恢复时，可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录，以恢复namenode的元数据。
注2：checkpoint时，把正在写的滚动一下，然后把fsimage和日志文件下载到secondaryNamenode机器上，但是只有第一次才会下载fsimage文件，因为这个时候fsimage不是很大，下载效率不会慢，以后就只会下载日志文件了，因为每隔一定时间和条件就会下载所以下载量也不会太大。
注3：当namenode宕机的时候，hdfs是否还能正常工作？答案是不能，因为secondaryNamenode虽然有元数据但是并不能代替namenode，比如namenode能对客户端做响应而secondaryNamenode就不行，也不能更新数据，只起到了备份元数据的作用。
注4：如果namenode的硬盘损坏（或者说是工作目录没了）那么元数据还能恢复吗？答案是能恢复大部分数据，上面第五步已经给出了解释，我们可以将secondaryNamenode的目录复制粘贴给它，因为两者的结构数据是一样的。但是如果操作过快，比如我刚创建了一个文件夹。然后删掉了目录，这个时候secondaryNamenode都没来得及下载备份，所以这条数据不能回复。
注5：配置namenode工作目录参数的时候，最后将namenode的工作目录配在多块磁盘上，同时往2块磁盘上写数日志，内容是一样的。如下
<property>
<name>dfs.name.name.dir</name>
<value>/root/hadoop/hdf1,/root/hadoop/hdf2</value>
</property>三，edits 和 fsimage 文件的概念
1. fsimage文件
fsimage 文件其实是 Hadoop 文件系统元数据的一个永久性的检查点，其中包含 Hadoop 文件系统中的所有目录和文件 idnode 的序列化信息；
2. edits文件
存放的是 Hadoop文件系统的所有更新操作的路径，文件系统客户端执行的所以写操作首先会被记录到 edits文件中。
