Hadoop之NameNode目录结构
原文地址： https://itweknow.cn/detail?id=69 ，欢迎大家访问。
为了后面能够更加熟悉的保障Hadoop集群的平稳运行，我们需要深入的了解NameNode、SecondaryNameNode（也称辅助NameNode）以及datanode等HDFS组件在磁盘上的目录结构以及运行的原理。这篇文章我们就一起来看一下NameNode的目录结构。
namenode的目录结构一览
NameNode的工作目录就是我门指定的hadoop工作目录（由hadoop.tmp.dir配置项指定，配置在core-site.xml文件内）下的dfs/name目录。
root@test:~/hadoop/tmp/dfs# tree name
name
├── current
│ ├── edits_0000000000000000001-0000000000000000002
│ ├── edits_0000000000000000003-0000000000000000003
│ ├── edits_0000000000000000004-0000000000000000005
│ ├── edits_0000000000000000006-0000000000000000006
│ ├── edits_0000000000000000007-0000000000000000008
│ ├── edits_0000000000000000009-0000000000000000010
│ ├── edits_0000000000000000011-0000000000000000012
│ ├── edits_0000000000000000013-0000000000000000014
│ ├── edits_0000000000000000015-0000000000000000016
│ ├── edits_0000000000000000017-0000000000000000018
│ ├── edits_0000000000000000019-0000000000000000020
│ ├── edits_inprogress_0000000000000000021
│ ├── fsimage_0000000000000000000
│ ├── fsimage_0000000000000000000.md5
│ ├── fsimage_0000000000000000020
│ ├── fsimage_0000000000000000020.md5
│ ├── seen_txid
│ └── VERSION
└── in_use.lock
- edits_0000xxxx -> 编辑日志文件
- edits_inprogress_000xxx -> 当前打开可写的编辑日志
- fsimage_000xxx -> 文件系统镜像文件
- VERSION -> HDFS版本信息的描述文件
- in_use.lock -> 一个锁文件，namenode使用该文件为存储目录枷锁，避免其它namenode实例同时使用同一个存储目录的情况。
VERSION
VERSION文件中包含正在运行的HDFS的版本信息，一般情况下应该包含下面的内容：
#Wed Jan 02 07:08:58 UTC 2019
namespaceID=1447158958
clusterID=CID-67c5cf48-73da-4469-9c90-2759b2e0481c
cTime=1544608355749
storageType=NAME_NODE
blockpoolID=BP-1627059714-192.168.142.9-1544608355749
layoutVersion=-63
-
layoutVersion是一个负整数，描述HDFS持久性数据结构（也称之为布局）的版本，但是这个与Hadoop发布包的版本号无关。 -
namespaceID是文件系统命名空间的唯一标识，是在namenode首次格式化的时候创建的。 -
clusterID是将HDFS集群作为一个整体赋予的唯一标识符，对于联邦HDFS分厂中药，因为在联邦HDFS机制下一个集群由多个命名空间组成，每个命名空间由一个namenode管理。 -
blockpoolID是数据块池的唯一标识符，数据块池中包含了由一个namenode管理的命名空间中的所有文件 -
cTime属性标记了namenode存储系统的创建时间。对于刚刚格式化的文件系统这个属性值为0，在文件系统升级之后这个值就会更新到新的时间戳。 -
storageType说明该存储目录包含的是namenode的数据结构。
编辑日志和文件系统镜像
- 编辑日志
当我们操作HDFS中的文件时，这些操作首先会被写入到编辑日志中，然后相关的文件数据也会被更新。编辑日志文件在概念上是单个实体，但是它其实是存储在磁盘上的多个文件上的，我们看到了很多的edits_000xxx就是编辑日志。但是任何一个时刻都只有一个编辑日志文件处于打开可写的状态（edits_inprogress_000xxx）。
其实这个有点类似日志滚动的概念。
-
文件系统镜像
每个fsimage_000xxx文件都是HDFS文件系统的一个镜像（也称之为文件系统元数据的一个完整的永久性检查点），镜像文件的大小一般都比较大，我们对HDFS中文件的操作并不会直接记录到镜像文件中，而是写入到编辑日志中，在namenode启动的时候会首先载入最近的一个镜像文件，然后再读取编辑日志中的改变，这样我们就可以将namenode恢复到上一次正常工作时的状态了。 -
编辑日志合并到文件系统镜像
编辑日志不会是无限的增长的，集群中的SecondaryNameNode会定期为namenode内存中的文件系统元数据创建系统镜像，具体的创建过程参照下图。
编辑日志合并过程
- SecondaryNameNode请求NameNode停止使用当前打开的edits文件（即edits_inprogress_000xxx文件），并重新打开一个新的编辑日志文件以记录新的操作。
- SecondaryNameNode从NameNode中获取最近的fsimage和edits文件，使用HTTP GET方式获取。
- SecondaryNameNode将fsimage载入内存，然后逐一执行edits文件中记录的操作，然后创建一个新的镜像文件。
- SecondaryNameNode将合并后的镜像文件发送到NameNode（HTTP PUT）,NameNode将其保存为一个临时文件。
- NameNode重新命名该临时的镜像文件，此为最新的镜像文件。
edits日志文件合并的触发条件受两个配置项的控制，dfs.namenode.checkpoint.period（单位为秒），这个配置项是从时间维度上的控制，默认情况下是每隔1个小时触发一次合并。
第二个配置项是dfs.namenode.checkpoint.txns，这个配置是从编辑日志大大小维度上进行控制的，默认是如果从上一个检查点开始编辑日志已经达到了100万个事务就合并。检查编辑日志大小的频率默认是1分钟检查一次，可由dfs.namenode.checkpoint.check.period（单位为秒）配置项来改变。
