HDFS中NameNode的fsimage和edits
① NameNode元数据的设计
- 在HDFS中，需要经常访问元数据，并且还要求NameNode能高效地响应Client的请求。如果将元数据存储在NameNode的磁盘中，必然效率太低。
应该将元数据存到内存中。
- 但是，元数据如果存储在内存中，一旦断电，就会丢失。重启后，整个集群便无法工作。
应该在磁盘中对元数据进行备份，叫做fsimage。
- 内存中的元数据发生更新，磁盘中的fsimage也需要同时更新，才能保证数据的一致性。但是，如果内存中的元数据每更新一次，就同步到磁盘，效率会非常低下。
- 引入EditLog文件（简称edits），用来记录Client更新元数据的每一步操作（只进行追加操作，效率很高）。
- 每当元数据有更新时，就把更新操作记录到edits中，edits也存放在硬盘中。
- 一旦NameNode节点断电，可以通过fsimage和edits合并，生成最新的元数据。
- 如果长时间将操作记录添加到edits中，会导致文件数据过大，效率降低。而且，断电后的恢复时间变长。
需要对fsimage和edits定期进行合并。
- 如果，fsimage和edits定期的合并操作都交给NameNode节点完成，则又会造成效率降低
引入了一个辅助NameNode的节点，SecondaryNameNode，专门用于fsimage和edits的合并
- NameNode的元数据设计：
- 为了保证元数据既能高效访问，又能持久化存储，需要在内存和磁盘中都存放元数据。前者存储的时完整的元数据，后者存储的时元数据镜像（fsimage）。
- 磁盘中的fsimage不能每次都更新，先借助磁盘中追加写的edits文件存储更新，然后定期合并以保证edits追加写的高效。
- 为了减轻NameNode的工作量，合并工作由
SecondaryNameNode完成。 - 系统重启时，通过合并fsmige和edits文件，便可以重新在内存中产生完整的元数据。
② fsimage和edits的定义
- fsimage： NameNode内存中元数据的镜像文件，是元数据的一个永久性checkpoint，包含了HDFS的所有目录和文件idnode的序列化信息。
- edits： 用于衔接内存元数据和fsimage之间的操作日志，保存了自最后一次检查点之后，所有针对HDFS文件系统的操作，比如增加文件、重命名文件、删除目录等等。
-
edits.new： 又称
edits_inprogress，正在写入的edits文件，用于存储最新的操作日志。每次checkponit，fsimage更新完成之后，重命名为edits。 - fsimage、edits、
edits_inprogress的命名以及具体实例：
Hadoop Namenode HDFS metadata directories
带你真正理解HDFS-Namenode运行机制
③ fsimage的更新
-
SecondaryNameNode周期性的检查edits的大小，当edits达到指定大小或者到达合并时间，通过RollEditLog()方法进行合并。 - 首先停止对当前edits的写入，并产生临时的edits.new文件，之后新的操作记录都写入edits.new。（日志的回滚）
-
SecondaryNameNode通过http get方法，从NameNode获取新edits和fsimage文件。 -
SecondaryNameNode合并edits和fsimage文件，产生fsimage.ckpt文件。 -
fsimage.ckpt文件以http post的方式发送到NameNode。 - NameNode将
fsimage.ckpt重命名为fsimage，即更新fsimage；fsimage更新完成后，将edits.new重命名为edits文件。
-
fsimage与edits合并的条件，由
core-site.xml中fs.checkpoint.period和fs.checkpoint.size共同控制：- fs.checkpoint.period: 表示多长时间记录一次hdfs的镜像，默认是一个小时（3600s)
- fs.checkpoint.size: 表示一次记录多大的size，edits达到一定大小时也会触发合并（默认64MB)
-
还有第二种说法： edits.new在checkpoint时，滚动写为edits文件，并创建新的edits.new。之后，fsimage更新后，无需重命名edits.new。
-
个人更认同第二种说法，具体可以查看NameNode元数据及checkpoint分析。
-
注意：
rollEditLog()的作用，需要查看源码！！！
④ 参考链接
- 第一种说法的参考链接：
Hadoop Namenode元数据持久化机制与SecondaryNamenode的作用详解
Fsimage与EditLog定义及合并过程 - 第二种说法的参考链接：
三十九、NameNode工作机制、镜像文件、编辑日志文件、namenode版本号
浅谈HDFS（二）之NameNode与SecondaryNameNode
⑤ 常见误区
-
误区：
SecondaryNameNode是NameNode的备份，以支持HA。 -
SecondaryNameNode只是为了定期合并edits和fsimage，以减轻NameNode的负载。