NN与fsimage、edits文件

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

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

fsimage文件(镜像文件)，以fsimage_为前缀，是序列化存储的元数据的整体快照；

edits文件（又称edit log），以edits_为前缀，是顺序存储的元数据的增量修改（即客户端写入操作）日志。

这两类文件均存储在${dfs.namenode.name.dir}/current/路径下，如下所示。

[root@master current]# pwd
/usr/local/src/hadoop-2.6.1/dfs/name/current
[root@master current]# ls -l
total 1040
-rw-r--r-- 1 root root 1048576 Aug 18 02:07 edits_inprogress_0000000000000000001
-rw-r--r-- 1 root root     351 Aug 18 01:59 fsimage_0000000000000000000
-rw-r--r-- 1 root root      62 Aug 18 01:59 fsimage_0000000000000000000.md5
-rw-r--r-- 1 root root       2 Aug 18 02:00 seen_txid
-rw-r--r-- 1 root root     206 Aug 18 01:59 VERSION

可见，当前正在写入的edits文件名会有"inprogress"标识，而seen_txid文件保存的就是当前正在写入的edits文件的ID。

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

SNN与checkpoint过程

为了避免edits文件过大，以及缩短NN启动时恢复元数据的时间，我们需要定期地将edits文件合并到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之间最大允许进行的操作数，默认为100万。

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

NN生成新的edits_inprogress文件，后续的修改日志将写入该文件中，之前正在写的edits文件即为待合并状态。

将待合并的edits文件和fsimage文件一起复制到SNN本地。

SNN像NN启动时一样，将fsimage文件加载到内存，并重放edits文件进行合并。生成合并结果为fsimage.chkpoint文件。

SNN将fsimage.chkpoint复制回NN，并重命名为正式的fsimage文件名。

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

如果开启了NN高可用呢？

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