浅谈HDFS的fsimage、edit log与SecondaryNameNode

前言

HDFS SecondaryNameNode是干什么的?

这是道经典的基础面试题,笔者问过面试者很多次(当然也被面试官问过很多次)。从印象看,大约有一半的被面试者无法正确作答,给出的答案甚至有“不就是NameNode的热备嘛”。本文来简单聊聊相关的知识,为节省篇幅,将SecondaryNameNode简称SNN,NameNode简称NN。

NN与fsimage、edit log文件

NN负责管理HDFS中所有的元数据,包括但不限于文件/目录结构、文件权限、块ID/大小/数量、副本策略等等。客户端执行读写操作前,先从NN获得元数据。当NN在运行时,元数据都是保存在内存中,以保证响应时间。

显然,元数据只保留在内存中是非常不可靠的,所以也需要持久化到磁盘。NN内部有两类文件用于持久化元数据:

  • fsimage文件,以fsimage_为前缀,是序列化存储的元数据的整体快照;
  • edit log文件,以edits_为前缀,是顺序存储的元数据的增量修改(即客户端写入事务)日志。

这两类文件均存储在${dfs.namenode.name.dir}/current/路径下,查看其中的内容:

[root@bigdata-test-hadoop10 current]# ll
总用量 412944
-rw-r--r-- 1 hdfs hdfs 46134049 6月  29 16:57 edits_0000000001876931538-0000000001877134881
-rw-r--r-- 1 hdfs hdfs 29205984 6月  29 17:57 edits_0000000001877134882-0000000001877229652
-rw-r--r-- 1 hdfs hdfs 28306206 6月  29 18:57 edits_0000000001877229653-0000000001877318515
-rw-r--r-- 1 hdfs hdfs 49660366 6月  29 19:57 edits_0000000001877318516-0000000001877544080
-rw-r--r-- 1 hdfs hdfs 50708454 6月  29 20:57 edits_0000000001877544081-0000000001877776582
-rw-r--r-- 1 hdfs hdfs 51308280 6月  29 21:57 edits_0000000001877776583-0000000001878012751
-rw-r--r-- 1 hdfs hdfs 28408745 6月  29 22:57 edits_0000000001878012752-0000000001878101834
-rw-r--r-- 1 hdfs hdfs  1048576 6月  29 22:58 edits_inprogress_0000000001878101835
-rw-r--r-- 1 hdfs hdfs 68590654 6月  29 21:57 fsimage_0000000001878012751
-rw-r--r-- 1 hdfs hdfs       62 6月  29 21:57 fsimage_0000000001878012751.md5
-rw-r--r-- 1 hdfs hdfs 69451619 6月  29 22:57 fsimage_0000000001878101834
-rw-r--r-- 1 hdfs hdfs       62 6月  29 22:57 fsimage_0000000001878101834.md5
-rw-r--r-- 1 hdfs hdfs       11 6月  29 22:57 seen_txid
-rw-r--r-- 1 hdfs hdfs      175 8月  27 2019 VERSION
[root@bigdata-test-hadoop10 current]# cat seen_txid 
1878101835

可见,fsimage和edit log文件都会按照事务ID来分段。当前正在写入的edit log文件名会带有"inprogress"标识,而seen_txid文件保存的就是当前正在写入的edit log文件的起始事务ID。

在任意时刻,最近的fsimage和edit log文件的内容加起来就是全量元数据。NN在启动时,就会将最近的fsimage文件加载到内存,并重放它之后记录的edit log文件,恢复元数据的现场。

SNN与checkpoint过程

为了避免edit log文件过大,以及缩短NN启动时恢复元数据的时间,我们需要定期地将edit log文件合并到fsimage文件,该合并过程叫做checkpoint(这个词是真正被用烂了哈)。

由于NN的负担已经比较重,再让它来进行I/O密集型的文件合并操作就不太科学了,所以Hadoop引入了SNN负责这件事。也就是说,SNN是辅助NN进行checkpoint操作的角色

checkpoint的触发由hdfs-site.xml中的两个参数来控制。

  • dfs.namenode.checkpoint.period:触发checkpoint的周期长度,默认为1小时。
  • dfs.namenode.checkpoint.txns:两次checkpoint之间最大允许进行的事务数(即edit log的增量条数),默认为100万。

只要满足上述两个参数的条件之一,就会触发checkpoint过程,叙述如下:

  1. NN生成新的edits_inprogress文件,后续的事务日志将写入该文件中,之前正在写的edit log文件即为待合并状态。
  2. 将待合并的edit log文件和fsimage文件一起复制到SNN本地。
  3. SNN像NN启动时一样,将fsimage文件加载到内存,并重放edit log文件进行合并。生成合并结果为fsimage.chkpoint文件。
  4. SNN将fsimage.chkpoint复制回NN,并重命名为正式的fsimage文件名。

Hadoop官方给出的图示如下。虽然文件名称不同,但思想是一样的。

另外,为了避免fsimage文件占用太多磁盘空间,通过dfs.namenode.num.checkpoints.retained参数可以指定保留多少个fsimage文件,默认值为2。

如果开启了NN高可用呢?

上面说的都是集群只有一个NN的情况。如果有两个NN并且开启了HA的话,SNN就没用了——checkpoint过程会直接交给Standby NN来负责。Active NN会将edit log文件同时写到本地与共享存储(QJM方案就是JournalNode集群)上去,Standby NN从JournalNode集群拉取edit log文件进行合并,并保持fsimage文件与Active NN的同步。

NN高可用的实现原理又是一个重要的话题,可以说很多,择日另外写文章讨论吧。

民那晚安晚安。

你可能感兴趣的:(浅谈HDFS的fsimage、edit log与SecondaryNameNode)