我們知道HDFS是一個分布式文件存儲系統，文件分布式存儲在多個DataNode節點上。一個文件存儲在哪些DataNode節點的哪些位置的元數據信息（metadata）由NameNode節點來處理。隨著存儲文件的增多，NameNode上存儲的信息也會越來越多。那么HDFS是如何及時更新這些metadata的呢？?
　　在HDFS中主要是通過兩個組件FSImage和EditsLog來實現metadata的更新。在某次啟動HDFS時，會從FSImage文件中讀取當前HDFS文件的metadata，之后對HDFS的操作步驟都會記錄到edit log文件中。比如下面這個操作過程?
　　?
　　那么完整的metadata信息就應該由FSImage文件和edit log文件組成。fsimage中存儲的信息就相當于整個hdfs在某一時刻的一個快照。?
　　FSImage文件和EditsLog文件可以通過ID來互相關聯。在參數dfs.namenode.name.dir設置的路徑下，會保存FSImage文件和EditsLog文件，如果是QJM方式HA的話，EditsLog文件保存在參數dfs.journalnode.edits.dir設置的路徑下。

?

先看下namenode節點的備份節點? ? namesecondary節點

?

?

?

?

一、FsImage和Editslog分別是什么 ？

Editslog ：保存了所有對hdfs中文件的操作信息
FsImage：是內存元數據在本地磁盤的映射，用于維護管理文件系統樹，即元數據(metadata)
在hdfs中主要是通過兩個數據結構FsImage和EditsLog來實現metadata的更新。在某次啟動hdfs時，會從FSImage文件中讀取當前HDFS文件的metadata，之后對HDFS的操作步驟都會記錄到edit log文件中。

metadata信息就應該由FSImage文件和edit log文件組成。fsimage中存儲的信息就相當于整個hdfs在某一時刻的一個快照。

　　FsImage文件和EditsLog文件可以通過ID來互相關聯。如果是非HA集群的話，這兩個數據文件保存在dfs.namenode.name.dir設置的路徑下，會保存FsImage文件和EditsLog文件，如果是HA集群的話，EditsLog文件保存在參數dfs.journalnode.edits.dir設置的路徑下，即edits文件由qjournal集群管理。

查看namenode節點? ? ? fsimage和editlog文件

cd?/usr/local/hadoop/hadoop-3.1.2/dfs/name/? ? ?

? ?? ?在上圖中edit log文件以edits_開頭，后面跟一個txid范圍段，并且多個edit log之間首尾相連，正在使用的edit log名字edits_inprogress_txid。該路徑下還會保存兩個fsimage文件（{dfs.namenode.num.checkpoints.retained}在namenode上保存的fsimage的數目，超出的會被刪除。默認保存2個），文件格式為fsimage_txid。上圖中可以看出fsimage文件已經加載到了最新的一個edit log文件，僅僅只有inprogress狀態的edit log未被加載。

在啟動HDFS時，只需要讀入fsimage_0000000000000000058以及edits_inprogress_0000000000000000062就可以還原出當前hdfs的最新狀況。

（FsImageid總是比editslogid小）

但是這里又會出現一個問題，如果edit log文件越來越多、越來越大時，當重新啟動hdfs時，由于需要加載fsimage后再把所有的edit log也加載進來，就會出現第一段中出現的問題了。怎么解決？HDFS會采用checkpoing機制定期將edit log合并到fsimage中生成新的fsimage。這個過程就是接下來要講的了。?

那么這兩個文件是如何合并的呢？這就引入了checkpoint機制

二、checkpoint機制：

fsimage和edit log合并的過程如下圖所示：?
　　?
因為文件合并過程需要消耗io和cpu所以需要將這個過程獨立出來，在Hadoop1.x中是由Secondnamenode來完成，且Secondnamenode必須啟動在單獨的一個節點最好不要和namenode在同一個節點，這樣會增加namenode節點的負擔，而且維護時也比較方便。同樣在HA集群中這個合并的過程是由Standbynamenode完成的。

其實這個合并過程是一個很耗I/O與CPU的操作，并且在進行合并的過程中肯定也會有其他應用繼續訪問和修改hdfs文件。所以，這個過程一般不是在單一的NameNode節點上進行從。如果HDFS沒有做HA的話，checkpoint由SecondNameNode進程(一般SecondNameNode單獨起在另一臺機器上)來進行。在HA模式下，checkpoint則由StandBy狀態的NameNode來進行。?
　　什么時候進行checkpoint由兩個參數dfs.namenode.checkpoint.preiod(默認值是3600，即1小時)和dfs.namenode.checkpoint.txns(默認值是1000000)來決定。period參數表示，經過1小時就進行一次checkpoint，txns參數表示，hdfs經過100萬次操作后就要進行checkpoint了。這兩個參數任意一個得到滿足，都會觸發checkpoint過程。進行checkpoint的節點每隔dfs.namenode.checkpoint.check.period(默認值是60）秒就會去統計一次hdfs的操作次數

?

1.合并的過程：過程類似于TCP協議的關閉過程（四次揮手）

首先Standbynamenode進行判斷是否達到checkpoint的條件（是否距離上次合并過了1小時或者事務條數是否達到100萬條）
當達到checkpoint條件后，Standbynamenode會將qjournal集群中的edits和本地fsImage文件合并生成一個文件fsimage_ckpt_txid（此時的txid是與合并的editslog_txid的txid值相同），同時Standbynamenode還會生成一個MD5文件，并將fsimage_ckpt_txid文件重命名為fsimage_txid
向Activenamenode發送http請求（請求中包含了Standbynamenode的域名，端口以及新fsimage_txid的txid），詢問是否進行獲取
Activenamenode獲取到請求后，會返回一個http請求來向Standbynamenode獲取新的fsimage_txid，并保存為fsimage.ckpt_txid，生成一個MD5，最后再改名為fsimage_txid。合并成功。
2.合并的時機：
什么時候進行checkpoint呢？這由兩個參數dfs.namenode.checkpoint.preiod(默認值是3600，即1小時)和dfs.namenode.checkpoint.txns(默認值是1000000)來決定

（1） 距離上次checkpoint的時間間隔 {dfs.namenode.checkpoint.period}

（2） Edits中的事務條數達到{dfs.namenode.checkpoint.txns}限制，

事物條數又由{dfs.namenode.checkpoint.check.period(默認值是60）}決

定，checkpoint節點隔60秒就會去統計一次hdfs的操作次數。

?

?

三、HA模式下Checkpointing過程分析

　　在HA模式下checkpoint過程由StandBy NameNode來進行，以下簡稱為SBNN，Active NameNode簡稱為ANN。?
　　HA模式下的edit log文件會同時寫入多個JournalNodes節點的dfs.journalnode.edits.dir路徑下，JournalNodes的個數為大于1的奇數，類似于Zookeeper的節點數，當有不超過一半的JournalNodes出現故障時，仍然能保證集群的穩定運行。?
　　SBNN會讀取FSImage文件中的內容，并且每隔一段時間就會把ANN寫入edit log中的記錄讀取出來，這樣SBNN的NameNode進程中一直保持著hdfs文件系統的最新狀況namespace。當達到checkpoint條件的某一個時，就會直接將該信息寫入一個新的FSImage文件中，然后通過HTTP傳輸給ANN。?
　　?
　　如上圖所示，主要由4個步驟：?
1. SBNN檢查是否達到checkpoint條件：離上一次checkpoint操作是否已經有一個小時，或者HDFS已經進行了100萬次操作。?
2. SBNN檢查達到checkpoint條件后，將該namespace以fsimage.ckpt_txid格式保存到SBNN的磁盤上，并且隨之生成一個MD5文件。然后將該fsimage.ckpt_txid文件重命名為fsimage_txid。?
3. 然后SBNN通過HTTP聯系ANN。?
4. ANN通過HTTP從SBNN獲取最新的fsimage_txid文件并保存為fsimage.ckpt_txid，然后也生成一個MD5，將這個MD5與SBNN的MD5文件進行比較，確認ANN已經正確獲取到了SBNN最新的fsimage文件。然后將fsimage.ckpt_txid文件重命名為fsimage_txit。?
　　通過上面一系列的操作，SBNN上最新的FSImage文件就成功同步到了ANN上。

?

?

?

文章部分內容參考：https://blog.csdn.net/q35445762/article/details/91472746

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?https://www.cnblogs.com/nucdy/p/5892144.html

總結

以上是生活随笔為你收集整理的hadoop3.1.2版本中FsImage与Editslog合并解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。