首发于：https://www.jwldata.com/archives/14.html
NameNode与fsimage、edits文件
NameNode（简称NN）负责管理和保存HDFS中所有的元数据，包括但不限于文件/目录结构、文件权限、块ID/大小/数量、副本策略等等。当NameNode在运行时，元数据都是保存在内存中，以保证响应时间。元数据同时也会持久化到磁盘，dfs.namenode.name.dir参数指定了元数据的磁盘保存路径。NameNode内部有两类文件用于持久化元数据：
- fsimage文件，以fsimage_为前缀，是序列化存储的元数据的整体快照；
- edits文件（又称edit log），以edits_为前缀，是顺序存储的元数据的增量修改事务日志。
这两类文件均存储在NameNode的${dfs.namenode.name.dir}/current/路径下，如下图所示。
可见，当前正在写入的edits文件名会有"inprogress"标识，而seen_txid文件保存的就是当前正在写入的edits文件的ID。在任意时刻，最近的fsimage和edits文件的内容加起来就是全量元数据。NameNode在启动时，就会将最近的fsimage文件加载到内存，并重放它之后记录的edits文件，恢复元数据的现场。
SecondaryNameNode与checkpoint过程
为了避免edits文件过大，以及缩短NameNode启动时恢复元数据的时间，我们需要定期地将edits文件合并到fsimage文件，该合并过程叫做checkpoint。
对于大型的HDFS集群，fsimage能达到几个GB大小，NameNode通常需要处理非常多的事务，导致NameNode的负担比较重，再让它来进行I/O密集型的文件合并操作就不太合适了，所以HDFS引入了SecondaryNameNode专门负责这件事。也就是说，SecondaryNameNode（简称SNN）是辅助NameNode进行checkpoint操作的角色。
checkpoint的触发由hdfs-site.xml中的两个参数来控制：
- dfs.namenode.checkpoint.period：触发checkpoint的周期长度，默认为1小时。
- dfs.namenode.checkpoint.txns：两次checkpoint之间最大允许进行的操作数，默认为100万。
两个参数只要满足其一，就会触发checkpoint过程。默认情况下，SNN每隔1小时进行一次checkpoint，但如果还没到1小时，距离上一次checkpoint后事务累积已经超过了1百万，就会立刻触发一次checkpoint。
checkpoint过程如下：
- SNN请求NN生成新的edits_inprogress文件，后续新的edits将写入该文件中，之前正在写的edits文件成为待合并状态。NN同时更新seen_txid文件的内容为最新的edit文件ID。
- SNN使用HTTP GET请求的方式将待合并的edits文件和fsimage文件从NN复制到SNN本地。
- SNN将fsimage文件加载到内存，并重放edits文件中的事务进行合并，保存为新的fsimage文件。
- SNN使用HTTP PUT请求的方式将合并后的fsimage复制回NN，保存为.ckpt临时文件。
- NN将.ckpt临时文件重命名为正式的fsimage文件名。
SecondaryNameNode的目录结构如下，可以与前面NameNode的目录结构比对一下，加深认识。
如果开启了NameNode高可用
上面说的都是集群只有一个NameNode的情况。如果HDFS NameNode开启了HA的话，SecondaryNameNode会被替换成standby NameNode，checkpoint过程会直接交给standby NameNode来负责。active NameNode会将edits文件同时写到本地与共享存储（比如QJM方案就是JournalNode集群）上去，standby NameNode从JournalNode集群拉取edits文件，和从active NameNode拉取的fsimage进行合并，并保持fsimage文件与active NameNode的同步。
欢迎关注我的微信公众号“九万里大数据”，原创技术文章第一时间推送。
欢迎访问原创技术博客网站 jwldata.com，排版更清晰，阅读更爽快。