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

?

先看下namenode節(jié)點(diǎn)的備份節(jié)點(diǎn)? ? namesecondary節(jié)點(diǎn)

?

?

?

?

一、FsImage和Editslog分別是什么 ？

Editslog ：保存了所有對(duì)hdfs中文件的操作信息
FsImage：是內(nèi)存元數(shù)據(jù)在本地磁盤的映射，用于維護(hù)管理文件系統(tǒng)樹，即元數(shù)據(jù)(metadata)
在hdfs中主要是通過(guò)兩個(gè)數(shù)據(jù)結(jié)構(gòu)FsImage和EditsLog來(lái)實(shí)現(xiàn)metadata的更新。在某次啟動(dòng)hdfs時(shí)，會(huì)從FSImage文件中讀取當(dāng)前HDFS文件的metadata，之后對(duì)HDFS的操作步驟都會(huì)記錄到edit log文件中。

metadata信息就應(yīng)該由FSImage文件和edit log文件組成。fsimage中存儲(chǔ)的信息就相當(dāng)于整個(gè)hdfs在某一時(shí)刻的一個(gè)快照。

　　FsImage文件和EditsLog文件可以通過(guò)ID來(lái)互相關(guān)聯(lián)。如果是非HA集群的話，這兩個(gè)數(shù)據(jù)文件保存在dfs.namenode.name.dir設(shè)置的路徑下，會(huì)保存FsImage文件和EditsLog文件，如果是HA集群的話，EditsLog文件保存在參數(shù)dfs.journalnode.edits.dir設(shè)置的路徑下，即edits文件由qjournal集群管理。

查看namenode節(jié)點(diǎn)? ? ? fsimage和editlog文件

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

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

在啟動(dòng)HDFS時(shí)，只需要讀入fsimage_0000000000000000058以及edits_inprogress_0000000000000000062就可以還原出當(dāng)前hdfs的最新狀況。

（FsImageid總是比editslogid小）

但是這里又會(huì)出現(xiàn)一個(gè)問(wèn)題，如果edit log文件越來(lái)越多、越來(lái)越大時(shí)，當(dāng)重新啟動(dòng)hdfs時(shí)，由于需要加載fsimage后再把所有的edit log也加載進(jìn)來(lái)，就會(huì)出現(xiàn)第一段中出現(xiàn)的問(wèn)題了。怎么解決？HDFS會(huì)采用checkpoing機(jī)制定期將edit log合并到fsimage中生成新的fsimage。這個(gè)過(guò)程就是接下來(lái)要講的了。?

那么這兩個(gè)文件是如何合并的呢？這就引入了checkpoint機(jī)制

二、checkpoint機(jī)制：

fsimage和edit log合并的過(guò)程如下圖所示：?
　　?
因?yàn)槲募喜⑦^(guò)程需要消耗io和cpu所以需要將這個(gè)過(guò)程獨(dú)立出來(lái)，在Hadoop1.x中是由Secondnamenode來(lái)完成，且Secondnamenode必須啟動(dòng)在單獨(dú)的一個(gè)節(jié)點(diǎn)最好不要和namenode在同一個(gè)節(jié)點(diǎn)，這樣會(huì)增加namenode節(jié)點(diǎn)的負(fù)擔(dān)，而且維護(hù)時(shí)也比較方便。同樣在HA集群中這個(gè)合并的過(guò)程是由Standbynamenode完成的。

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

?

1.合并的過(guò)程：過(guò)程類似于TCP協(xié)議的關(guān)閉過(guò)程（四次揮手）

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

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

（2） Edits中的事務(wù)條數(shù)達(dá)到{dfs.namenode.checkpoint.txns}限制，

事物條數(shù)又由{dfs.namenode.checkpoint.check.period(默認(rèn)值是60）}決

定，checkpoint節(jié)點(diǎn)隔60秒就會(huì)去統(tǒng)計(jì)一次hdfs的操作次數(shù)。

?

?

三、HA模式下Checkpointing過(guò)程分析

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

?

?

?

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。