阅读 179

HDFS 05 - HDFS 的元数据管理(FSImage、EditLog、Checkpoint)

HDFS 05 - HDFS 的元数据管理(FSImage、EditLog、Checkpoint)

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)

来源https://www.cnblogs.com/shoufeng/p/14855242.html

文章分类
后端
版权声明:本站是系统测试站点,无实际运营。本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 XXXXXXo@163.com 举报,一经查实,本站将立刻删除。
相关推荐