HDFS 05 - HDFS 的元数据管理（FSImage、EditLog、Checkpoint）

目录

• 1 - NameNode 的启动流程
• 2 - NameNode 的元数据
  • 2.1 EditLog 操作日志
  • 2.2 查看 EditLog 文件
  • 2.3 FSImage 元数据镜像
  • 2.4 查看 FSImage 文件
• 3 - Checkpoint 检查点操作
  • 3.1 为什么要 Checkpoint
  • 3.2 Checkpoint 的过程
• 4 - SNN 辅助管理 FSImage 和 EditLog
  • 4.1 相关配置
  • 4.2 管理流程
• 参考资料
• 版权声明

1 - NameNode 的启动流程

1）Loading fsimage - 从 fsimage file 中读取最新的元数据快照（最近生成的 fsimage_xx）；

2）Loading edits - 读取 fsimage_xx 之后的所有事务的 edit logs，将 edit logs 中的操作重新执行一遍，此时 NameNode 就恢复到上次停止时的状态了；

3）checkpoint - 将当前状态写入新的 checkpoint 中，即产生一个新的 fsimage_xx 文件；

4）Safe mode - 等待各个 DataNodes 汇报自己的 block 信息，形成 blockMap，然后退出安全模式。

此时 NameNode 启动结束，等待接受用户的操作请求，并把用户操作写入新的 edit log 中，定期进行 checkpoint，对元数据执行快照。

2 - NameNode 的元数据

NameNode 的所有操作及整个集群的状态都存储在 元数据 中，元数据都保存在 fsImage 和 eidts 文件中。

它们的主要作用是：在集群启动时将集群的状态恢复到关闭前的状态。

第一次启动 NameNode 前的格式化（hdfs namenode -format）操作会创建 fsimage 和 edits 文件。

非第一次启动，NameNode 会进行数据恢复：首先把 FSImage 文件加载到内存中形成文件系统镜像，然后再把 EditLog 中 FsImage 的结束事务 id 之后的 EditLog 回放到这个文件系统镜像上。这个时候，集群也就恢复到关闭前的状态了。

它们的位置需要在 hdfs-site.xml 文件中指定：

<!-- NameNode 元数据的存放目录 -->
<property>
    <name>dfs.namenode.name.dir</name>
    <value>file:/Users/healchow/data/hadoop/namenode</value>
</property>
<!-- NameNode 日志文件的存放目录 -->
<property>
     <name>dfs.namenode.edits.dir</name>
     <value>file:/Users/healchow/data/hadoop/namenode/edits</value
</property>

2.1 EditLog 操作日志

1）客户端对 HDFS 的写操作会首先被记录在 edits 文件中；

HDFS 客户端提交的创建、移动、删除文件等 写操作 的时候，NameNode 会首先把这些操作记录在 EditLog 文件中。

2）edits 修改完成之后，会再更新内存中的文件系统镜像；

edits 文件会不断增大（导致系统运行、重启恢复等过程非常缓慢），在一定条件下会和 fsimage 文件合并，从而减小 EditLog 文件的体积。

3）记录在 EditLog 中的每一个操作又称为一个事务，每个事务有一个整数形式的事务 id 作为编号。

（临时总结，不一定对）EditLog 就是事务日志，主要作用是用来记录写操作，以支持系统的恢复。

2.2 查看 EditLog 文件

EditLog 会被切割成很多段，每一段称为一个 Segment。正在写入的 Segment 处于 in-progress 状态，其文件名形如 edits_inprogress_${start_txid}，其中 ​${start_txid} 表示这个 Segment 的起始事务 id。

已经写入完成的 Segment 处于 finalized 状态，其文件名形如 edits_${start_txid}-${end_txid}，其中 ${start_txid} 表示这个 Segment 的起始事务 id，${end_txid} 表示这个 Segment 的结束事务 id。

查看 edits 中的文件信息

hdfs oev 回车后会显示命令的帮助信息：
cd ~/data/hadoop/namenode
hdfs oev -i edits_0000000000000000865-0000000000000000866 -p XML -o myedit.xml

2.3 FSImage 元数据镜像

1）FSImage 是 NameNode 中关于元数据的镜像，一般称为检查点的镜像；

2）FSImage 是 NameNode 自上次 checkpoint 之后生成的元数据，并不是实时的数据；

3）FSImage 保存了 NameNode 管理下的所有 DataNode 的文件和目录信息：

对文件来说：包括文件的 block、各个 block 所在的 DataNode，以及它们的修改时间、访问时间等；

对目录来说：包括修改时间、访问权限控制信息（权限、属组）等。

FSImage 默认会保存2个，由属性 dfs.namenode.num.checkpoints.retained 控制。

内存中的 FSImage 用于 NameNode 向客户端提供读服务，而 EditLog 仅仅只是在数据恢复的时候发挥作用。

2.4 查看 FSImage 文件

FSImage 文件的文件名形如 fsimage_${end_txid}，其中 ${end_txid} 表示这个 FSImage 文件的结束事务 id。

查看 fsimage 中的文件信息：

hdfs oev 回车后会显示命令的帮助信息：

cd ~/bigdata/data/hadoop/namenode
hdfs oiv -i fsimage_0000000000000000864 -p XML -o hello.xml

3 - Checkpoint 检查点操作

3.1 为什么要 Checkpoint

HDFS 的每个写操作都会写入EditLog 中，随着时间的积累 EditLog 会变的很大，极端情况下会占满整个磁盘。

另外，由于 NameNode 在启动的时候，需要将 EditLog 中的操作重新执行一遍，过大的 EditLog 会延长 NameNode 的启动时间。

所以，通过 Checkpoint 定期对元数据进行合并。

3.2 Checkpoint 的过程

Checkpoint 会把 FSImage 和 EditLog 的内容进行合并生成一个新的 FSImage。

这样在 NameNode 启动的时候就不用将巨大的 EditLog 中的事务再执行一遍，而是直接加载合并之后的新 FSImage ，然后重新执行未被合并的 EditLog 文件就可以了。

创建新 FSImage 的过程需要大量的I/O、内存等资源，为了减轻影响，可将 Checkpoint 过程放在 SecondaryNameNode 或 StandbyNameNode 中（不同机器上）。

NameNode 在 Checkpoint 的时候会限制用户的访问（Hadoop 进入安全模式，此时需要管理员使用 dfsadmin 的 save namespace 来创建新的检查点）；

4 - SNN 辅助管理 FSImage 和 EditLog

4.1 相关配置

SNN（SecondaryNameNode，备份 NameNode）节点要在 conf/masters 文件中指定；

SNN 的 hdfs-site.xml 文件中需要配置下述参数：

<property>
  <name>dfs.http.address</name>
  <value>host:50070</value>
</property>

SecondaryNameNode 会定期合并 FSImage 和 EditLog，把 EditLog的体积控制在一个合理的范围内。

Checkpoint 的触发条件取决于两个参数，可在 NameNode / SNN 的 core-site.xml 中配置：

<!-- 两次 checkpoint 的时间间隔，默认3600秒，即1小时 -->
<property>
    <name>dfs.namenode.checkpoint.period</name>
    <value>3600s</value>
</property>
<!-- 新生成的 EditLog 中积累的事务数量达到了阈值，默认1000000次。优先级高于上述参数 -->
<property>
    <name>dfs.namenode.checkpoint.txns</name>
    <value>1000000</value>
</property>
<!-- 每隔多久检查一次 HDFS 未记录到检查点的事务数，默认60秒 -->
<property>
    <name>dfs.namenode.checkpoint.check.period</name>
    <value>60s</value>
</property>

<!-- 一次记录文件的大小，默认64MB -->
<property>
    <name>fs.checkpoint.size</name>
    <value>67108864</value>
</property>

4.2 管理流程

1. SecondaryNameNode 通知 NameNode 停止使用 EditLog，暂时将新的写操作存放到 edits.new 文件；

2. SecondaryNameNode 通过 HTTP 的 GET 请求，从 NameNode 中获取 FSImage 和 EditLog，将它们加载到内存中；

3. SecondaryNameNode 合并 FSImage 和 EditLog，合并完成后生成新的 FSImage；

4. SecondaryNameNode 通过 HTTP POST 请求方式，将新的 FSImage 发送给 NameNode；

5. NameNode 把原有的 FSImage 替换为新的 FSImage，把 edits.new 变成 edits，同时更新 fstime（即最后一个检查点的时间戳）。

参考资料

NameNode原数据及checkpoint分析

版权声明

作者：瘦风(https://healchow.com)

出处：博客园-瘦风的南墙(https://www.cnblogs.com/shoufeng)

感谢阅读，公众号 「瘦风的南墙」 ，手机端阅读更佳，还有其他福利和心得输出，欢迎扫码关注

本文版权归博主所有，欢迎转载，但 [必须在页面明显位置标明原文链接]，否则博主保留追究相关人士法律责任的权利。