Hadoop NameNode元数据相关文件目录解析

本文转自 Hadoop NameNode元数据相关文件目录解析

---

一. NameNode 元数据相关文件目录架构

在第一次部署好 Hadoop 集群的时候，我们需要在 NameNode（NN）节点上格式化磁盘：

$HADOOP_HOME/bin/hdfs namenode -format

格式化完成之后，将会在 $dfs.namenode.name.dir/current 目录下如下的文件结构

current/
|-- VERSION
|-- edits_*
|-- fsimage_0000000000008547077
|-- fsimage_0000000000008547077.md5
`-- seen_txid

其中的 dfs.namenode.name.dir 是在 hdfs-site.xml 文件中配置的，默认值如下：

<property>
  <name>dfs.namenode.name.dir</name>
  <value>file://${hadoop.tmp.dir}/dfs/name</value>
</property>

hadoop.tmp.dir 是在 core-site.xml 中配置的，默认值如下

<property>
  <name>hadoop.tmp.dir</name>
  <value>/tmp/hadoop-${user.name}</value>
  <description>A base for other temporary directories.</description>
</property>

dfs.namenode.name.dir 属性可以配置多个目录，如 /data1/dfs/name，/data2/dfs/name ，/data3/dfs/name 等。各个目录存储的文件结构和内容都完全一样，相当于备份，这样做的好处是当其中一个目录损坏了，也不会影响到 Hadoop 的元数据，特别是当其中一个目录是 NFS（网络文件系统 Network File System，NFS）之上，即使你这台机器损坏了，元数据也得到保存。

---

二. 元数据相关文件解析

下面对 $dfs.namenode.name.dir/current/ 目录下的文件进行解释

---

2.1 VERSION 文件

VERSION 文件是 Java 属性文件，内容大致如下：

#Sun Dec 20 03:37:06 CST 2015
namespaceID=555938486
clusterID=CID-6d9c34e0-9d84-45be-8442-be73a03ddea8
cTime=0
storageType=NAME_NODE
blockpoolID=BP-391569129-10.6.3.43-1450226754562
layoutVersion=-59

其中

1. namespaceID ：是文件系统的唯一标识符，在文件系统首次格式化之后生成的

2. cTime ：表示 NameNode 存储时间的创建时间，由于笔者我的 NameNode 没有更新过，所以这里的记录值为 0，以后对 NameNode 升级之后，cTime 将会记录更新时间戳

3. storageType ：说明这个文件存储的是什么进程的数据结构信息（如果是 DataNode，storageType=DATA_NODE）

4. blockpoolID：是针对每一个 Namespace 所对应的 blockpool 的 ID，上面的这个 BP-391569129-10.6.3.43-1450226754562 就是在我的 nameserver1 的 namespace下的存储块池的 ID，这个 ID 包括了其对应的 NameNode 节点的 ip 地址。

5. layoutVersion ：表示 HDFS 永久性数据结构的版本信息， 只要数据结构变更，版本号也要递减，此时的 HDFS 也需要升级，否则磁盘仍旧是使用旧版本的数据结构，这会导致新版本的 NameNode 无法使用

6. clusterID ：是系统生成或手动指定的集群 ID，在 -clusterid 选项中可以使用它；如下说明

• 使用如下命令格式化一个 Namenode：

$HADOOP_HOME/bin/hdfs namenode -format [-clusterId <cluster_id>]

选择一个唯一的 cluster_id，并且这个 cluster_id 不能与环境中其他集群有冲突。如果没有提供 cluster_id，则会自动生成一个唯一的 ClusterID。

• 使用如下命令格式化其他 Namenode：

$HADOOP_HOME/bin/hdfs namenode -format -clusterId <cluster_id>

• 升级集群至最新版本。在升级过程中需要提供一个 ClusterID，例如：

$HADOOP_PREFIX_HOME/bin/hdfs start namenode   --config $HADOOP_CONF_DIR  -upgrade -clusterId <cluster_ID>

如果没有提供 ClusterID，则会自动生成一个 ClusterID。

---

2.2 seen_txid 文件

$dfs.namenode.name.dir/current/seen_txid 这个文件非常重要，是存放 transactionId 的文件，format 之后是 0，它代表的是 namenode 里面的 edits_*文件的尾数，namenode 重启的时候，会按照 seen_txid 的数字，循序从头跑 edits_0000001~ 到 seen_txid 的数字。所以当你的 hdfs 发生异常重启的时候，一定要比对 seen_txid 内的数字是不是你 edits 最后的尾数，不然会发生建置 namenode 时 metaData 的资料有缺少，导致误删 Datanode 上多余 Block 的资讯。

---

2.3 fsimage 和 edits 及 md5 校验文件

$dfs.namenode.name.dir/current 目录下在 format 的同时也会生成 fsimage 和 edits 文件，及其对应的 md5 校验文件。fsimage 和 edits 是 Hadoop 元数据相关的重要文件。接下来将重点讲解。

---

三. 文件系统元数据 fsimage 和编辑日志 edits

其中存在大量的以 edits 开头的文件和少量的以 fsimage 开头的文件。那么这两种文件到底是什么，有什么用？下面对这两中类型的文件进行详解。在进入下面的主题之前先来搞清楚 edits 和 fsimage 文件的概念：

---

3.1 edits 和 fsimage 文件的概念

1. fsimage文件
fsimage 文件其实是 Hadoop 文件系统元数据的一个永久性的检查点，其中包含 Hadoop 文件系统中的所有目录和文件 idnode 的序列化信息；

2. edits文件
存放的是 Hadoop文件系统的所有更新操作的路径，文件系统客户端执行的所以写操作首先会被记录到 edits文件中。

---

3.2 fsimage 和 edits 的工作原理

fsimage 和 edits 文件都是经过序列化的，在 NameNode 启动的时候，它会将 fsimage 文件中的内容加载到内存中，之后再执行 edits 文件中的各项操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作。

NameNode 起来之后，HDFS 中的更新操作会重新写到 edits 文件中，因为 fsimage 文件一般都很大（GB 级别的很常见），如果所有的更新操作都往 fsimage 文件中添加，这样会导致系统运行的十分缓慢，但是如果往 edits 文件里面写就不会这样，每次执行写操作之后，且在向客户端发送成功代码之前，edits 文件都需要同步更新。如果一个文件比较大，使得写操作需要向多台机器进行操作，只有当所有的写操作都执行完成之后，写操作才会返回成功，这样的好处是任何的操作都不会因为机器的故障而导致元数据的不同步。

fsimage 包含 Hadoop 文件系统中的所有目录和文件 idnode 的序列化信息；

• 对于文件来说，包含的信息有修改时间、访问时间、块大小和组成一个文件块信息等
• 对于目录来说，包含的信息主要有修改时间、访问控制权限等信息

fsimage 并不包含 DataNode 的信息，而是包含 DataNode 上块的映射信息，并存放到内存中，当一个新的 DataNode 加入到集群中，DataNode 都会向 NameNode 提供块的信息，而 NameNode 会定期的“索取”块的信息，以使得 NameNode 拥有最新的块映射。因为 fsimage 包含 Hadoop 文件系统中的所有目录和文件 idnode 的序列化信息，所以如果 fsimage 丢失或者损坏了，那么即使 DataNode 上有块的数据，但是我们没有文件到块的映射关系，我们也无法用 DataNode 上的数据！所以定期及时的备份 fsimage 和 edits 文件非常重要！

在前面我们也提到，文件系统客户端执行的所以写操作首先会被记录到 edits 文件中，那么久而久之，edits 会非常的大，而 NameNode 在重启的时候需要执行 edits 文件中的各项操作，那么这样会导致 NameNode 启动的时候非常长！

---

其他信息

备用 NameNode

ameNode保存了文件系统的修改信息，并将其作为一个本地的日志文件edits。当NameNode启动时，它从映像文件fsimage中读取HDFS的状态，并开始操作一个空的edits文件。由于NameNode仅在启动时合并fsimage和各edits文件，所以日志文件edits在一个很忙的集群上会变得越来越大。大日志文件edits另一个副作用是会使NameNode在下次启动时变长。

备用NameNode周期性地合并fsimage和edits文件，将edits限制在一个范围内，备用NameNode与主NameNode通常运行在不同的机器上，因为备用NameNode与主NameNode有同样的内存要求。

备用NameNode上检查点进程的运行受两个配置参数控制：

dfs.namenode.checkpoint.period，两次连续的检查点之间的最大的时间间隔，缺省值是1小时
dfs.namenode.checkpoint.txns，最大的没有没有执行检查点的事务数目，即使执行检查点的周期未到，也将执行一次紧急检查点，缺省值是1百万

备用NameNode存储最新的检查点，它目录结构与主NameNode一致，所以这个备用的检查点映像在主NameNode需要时，总是能访问的。

Checkpoint节点

NameNode采用两个文件来保存命名空间的信息：fsimage，它是最新的已执行检查点的命名空间的信息；edits，它是执行检查点后命名空间变化的日志文件。当NameNode启动时，fsimage和edits合并，提供一个最新的文件系统的metadata，然后NameNode将新的HDFS状态写入fasimage，并开始一个新的edits日志。

Checkpoint节点周期性地创建命名空间的检查点。它从NameNode下载fsimage和edits，在本地合并它们，并将其发回给活动的NameNode。Checkpoint节点通常与NameNode不在同一台机器上，因为它们有同样的内存要求。Checkpoint节点由配置文件中的bin/hdfs namenode –checkpoint来启动。

Checkpoint(或Backup)节点的位置以及附带的web接口由dfs.namenode.backup.address anddfs.namenode.backup.http-address参数指定。

Checkpoint进程的运行受两个配置参数控制：

dfs.namenode.checkpoint.period，两次连续的检查点之间的最大的时间间隔，缺省值是1小时
 dfs.namenode.checkpoint.txns，最大的没有没有执行检查点的事务数目，即使执行检查点的周期未到，也将执行一次紧急检查点，缺省值是1百万

Checkpoint节点上保存的最新的检查点，其目录结构与NameNode上一样，这样，如果需要，NameNode总是可以读取这上面的已执行检查点的文件映像。参见“import checkpoint”。

多个Checkpoint节点可以在集群的配置文件中指定。

参考 http://blog.csdn.net/guxch/article/details/18189105