HDFS元数据管理机制

元数据管理概述

　　HDFS元数据，按类型分，主要包括如下几个部分：

　　　　一、文件、目录自身的属性信息，例如文件名，目录名，修改信息等。

　　　　二、文件记录的信息的存储相关的信息，例如存储块信息，分块状况，副本个数等。

　　　　三、记录 HDFS 的 Datanode 的信息，用于 DataNode 的管理。

　　按形式分为内存元数据和元数据文件两种，分别存在内存和磁盘上。

　　HDFS 磁盘上元数据文件分为两类，用于持久化存储：

　　fsimage 镜像文件：是元数据的一个持久化的检查点，包含 Hadoop 文件系统中的全部目录和文件元数据信息，但不包含文件块位置的信息。文件块位置信息只存储在内存中，是在 datanode 加入集群的时候，namenode 询问 datanode 获得的，而且间断的更新。

　　Edits 编辑日志：存放的是 Hadoop 文件系统的全部更改操做（文件建立，删除或修改）的日志，文件系统客户端执行的更改操做首先会被记录到 edits 文件中。

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

　　当客户端对 HDFS 中的文件进行新增或者修改操做，操做记录首先被记入 edits 日志文件中，当客户端操做成功后，相应的元数据会更新到内存元数据中。由于 fsimage 文件通常都很大（GB 级别的很常见），若是全部的更新操做都往 fsimage 文件中添加，这样会致使系统运行的十分缓慢。

　　HDFS 这种设计实现着手于：一是内存中数据更新、查询快，极大缩短了操做响应时间；二是内存中元数据丢失风险颇高（断电等），所以辅佐元数据镜像文件（fsimage）+编辑日志文件（edits）的备份机制进行确保元数据的安全。

　　NameNode 维护整个文件系统元数据。所以，元数据的准确管理，影响着 HDFS 提供文件存储服务的能力。

 

元数据目录相关文件

　　在 Hadoop 的 HDFS 首次部署好配置文件以后，并不能立刻启动使用，而是先要对文件系统进行格式化。须要在 NameNode（NN）节点上进行以下的操做：

　　　　$HADOOP_HOME/bin/hdfs namenode –format

　　在这里要注意两个概念，一个是文件系统，此时的文件系统在物理上还不存在；二就是此处的格式化并非指传统意义上的本地磁盘格式化，而是一些清除与准备工做。

　　格式化完成以后，将会在$dfs.namenode.name.dir/current 目录下建立以下的文件结构，这个目录也正是 namenode 元数据相关的文件目录：

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

 

　　dfs.namenode.name.dir 属性能够配置多个目录，各个目录存储的文件结构和内容都彻底同样，至关于备份，这样作的好处是当其中一个目录损坏了，也不会影响到 Hadoop 的元数据，特别是当其中一个目录是 NFS（网络文件系统 Network File System，NFS）之上，即便你这台机器损坏了，元数据也获得保存。

 

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

 

VERSION

namespaceID=934548976
clusterID=CID-cdff7d73-93cd-4783-9399-0a22e6dce196
cTime=0
storageType=NAME_NODE
blockpoolID=BP-893790215-192.168.24.72-1383809616115
layoutVersion=-47

 

　　namespaceID/clusterID/blockpoolID 这些都是 HDFS 集群的惟一标识符。标识符被用来防止 DataNodes 意外注册到另外一个集群中的 namenode 上。这些标识在联邦（federation）部署中特别重要。联邦模式下，会有多个 NameNode 独立工做。每一个的 NameNode 提供惟一的命名空间（namespaceID），并管理一组惟一的文件块池（blockpoolID）。clusterID 将整个集群结合在一块儿做为单个逻辑单元，在集群中的全部节点上都是同样的。

　　storageType 说明这个文件存储的是什么进程的数据结构信息（若是是 DataNode，storageType=DATA_NODE）；

　　cTime NameNode 存储系统建立时间，首次格式化文件系统这个属性是 0，当文件系统升级以后，该值会更新到升级以后的时间戳；

　　layoutVersion 表示 HDFS 永久性数据结构的版本信息，是一个负整数。

 

 

　　补充说明：

　　　　格式化集群的时候，能够指定集群的 cluster_id，可是不能与环境中其余集群有冲突。
　　　　若是没有提供 cluster_id，则会自动生成一个惟一的 ClusterID。

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

 

 

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 最后的尾数。

Fsimage & edits

　　$dfs.namenode.name.dir/current 目录下在 format 的同时也会生成 fsimage 和 edits文件，及其对应的 md5 校验文件。

 

 

secondary namenode

 

　　NameNode 职责是管理元数据信息，DataNode 的职责是负责数据具体存储，那么SecondaryNameNode 的做用是什么？对不少初学者来讲是很是迷惑的。它为何会出如今HDFS 中。从它的名字上看，它给人的感受就像是 NameNode 的备份。但它实际上却不是。

　　你们猜测一下，当 HDFS 集群运行一段事件后，就会出现下面一些问题：

　　　　edit logs 文件会变的很大，怎么去管理这个文件是一个挑战。

　　　　NameNode 重启会花费很长时间，由于有不少改动要合并到 fsimage 文件上。

　　　　若是 NameNode 挂掉了，那就丢失了一些改动。由于此时的 fsimage 文件很是旧。

　　所以为了克服这个问题，咱们须要一个易于管理的机制来帮助咱们 减少 s edit logs 文件的大小和获得一个最新的fsimage 文件，这样也会减少在 NameNode 上的压力。这跟Windows 的恢复点是很是像的，Windows 的恢复点机制容许咱们对 OS 进行快照，这样当系统发生问题时，咱们可以回滚到最新的一次恢复点上。

　　SecondaryNameNode 就是来帮助解决上述问题的，它的职责是合并 NameNode 的 editlogs 到 fsimage 文件中。

 

 

 Checkpoint

　　每达到触发条件，会由 secondary namenode 将 namenode 上积累的全部 edits 和一个最新的 fsimage 下载到本地，并加载到内存进行 merge（这个过程称为 checkpoint），以下图所示：

 

 

 

 Checkpoint 详细步骤

 

• NameNode 管理着元数据信息，其中有两类持久化元数据文件：edits 操做日志文件和fsimage 元数据镜像文件。新的操做日志不会当即与 fsimage 进行合并，也不会刷到NameNode 的内存中，而是会先写到 edits 中(由于合并须要消耗大量的资源)，操做成功以后更新至内存。

• 有 dfs.namenode.checkpoint.period 和 dfs.namenode.checkpoint.txns 两个配置，只要达到这两个条件任何一个，secondarynamenode 就会执行 checkpoint 的操做。

• 当触发 checkpoint 操做时，NameNode 会生成一个新的 edits 即上图中的 edits.new 文件，同时 SecondaryNameNode 会将 edits 文件和 fsimage 复制到本地（HTTP GET 方式）。

• secondarynamenode 将下载下来的 fsimage 载入到内存，而后一条一条地执行 edits 文件中的各项更新操做，使得内存中的 fsimage 保存最新，这个过程就是edits 和fsimage文件合并，生成一个新的 fsimage 文件即上图中的 Fsimage.ckpt 文件。

• secondarynamenode 将新生成的 Fsimage.ckpt 文件复制到 NameNode 节点。

• 在 NameNode 节点的 edits.new 文件和 Fsimage.ckpt 文件会替换掉原来的 edits 文件和 fsimage 文件，至此恰好是一个轮回，即在 NameNode 中又是 edits 和 fsimage 文件。

• 等待下一次 checkpoint 触发 SecondaryNameNode 进行工做，一直这样循环操做。

 

 Checkpoint 触发条件

 

　　Checkpoint 操做受两个参数控制，能够经过 core-site.xml 进行配置：

<property>
　　<name> dfs.namenode.checkpoint.period</name>
　　<value>3600</value>
　　<description>
　　　　两次连续的 checkpoint 之间的时间间隔。默认 1 小时
　　</description>
</property>
<property>
　　<name>dfs.namenode.checkpoint.txns</name>
　　<value>1000000</value>
　　<description>
　　　　最大的没有执行 checkpoint 事务的数量，知足将强制执行紧急 checkpoint，即便
　　　　还没有达到检查点周期。默认设置为 100 万。
　　</description>
</property>

 

从上面的描述咱们能够看出，SecondaryNamenode 根本就不是 Namenode 的一个热备，其只是将 fsimage 和 edits 合并。其拥有的 fsimage 不是最新的，由于在他从 NameNode 下载 fsimage 和 edits 文件时候，新的更新操做已经写到 edit.new 文件中去了。而这些更新在 SecondaryNamenode 是没有同步到的！固然， 若是 NameNode 中的 fsimage 真的出问题了，仍是能够用SecondaryNamenode 中的 fsimage 替换一下NameNode 上的 fsimage ，虽然已经不是最新的 fsimage ，可是咱们能够将损失减少到最少！