黑猴子的家：Hadoop 中，什么是FSImage和EditsLog

我们知道HDFS是一个分布式文件存储系统，文件分布式存储在多个DataNode节点上。一个文件存储在哪些DataNode节点的哪些位置的元数据信息（metadata）由NameNode节点来处理。随着存储文件的增多，NameNode上存储的信息也会越来越多。那么HDFS是如何及时更新这些metadata的呢？
　　在HDFS中主要是通过两个组件FSImage和EditsLog来实现metadata的更新。在某次启动HDFS时，会从FSImage文件中读取当前HDFS文件的metadata，之后对HDFS的操作步骤都会记录到edit log文件中。比如下面这个操作过程

image.png

那么完整的metadata信息就应该由FSImage文件和edit log文件组成。fsimage中存储的信息就相当于整个hdfs在某一时刻的一个快照。
　　FSImage文件和EditsLog文件可以通过ID来互相关联。在参数dfs.namenode.name.dir设置的路径下，会保存FSImage文件和EditsLog文件，如果是QJM方式HA的话，EditsLog文件保存在参数dfs.journalnode.edits.dir设置的路径下。

image.png

在上图中可以看到，edit log文件以edits_开头，后面跟一个txid范围段，并且多个edit log之间首尾相连，正在使用的edit log名字为edits_inprogress_txid。该路径下还会保存两个fsimage文件，文件格式为fsimage_txid。上图中可以看出fsimage文件已经加载到了最新的一个edit log文件，仅仅只有inprogress状态的edit log未被加载。在启动HDFS时，只需要读入fsimage_0000000000000008927以及edits_inprogress_0000000000000008928就可以还原出当前hdfs的最新状况。
　　但是这里又会出现一个问题，如果edit log文件越来越多、越来越大时，当重新启动hdfs时，由于需要加载fsimage后再把所有的edit log也加载进来，就会出现第一段中出现的问题了。怎么解决？HDFS会采用checkpoing机制定期将edit log合并到fsimage中生成新的fsimage。这个过程就是接下来要讲的了。