在NameNode的${dfs.namenode.name.dir}/current目錄下，有這樣幾個(gè)文件：

 

在數(shù)據(jù)庫系統(tǒng)中，log是用于記錄寫操作的日志的，并使用該Log進(jìn)行備份、恢復(fù)數(shù)據(jù)等工作。有關(guān)寫的操作的記錄的，目前見過了兩種：關(guān)系型數(shù)據(jù)庫的log，HBase的WALs等等都是這樣的寫操作的日志。

HDFS也采用了類似的機(jī)制。在HDFS中，會(huì)將第一次的文件操作，看作一個(gè)事務(wù)。譬如說一個(gè)文件的創(chuàng)建、文件內(nèi)容追加、文件移動(dòng)等等寫操作。從這個(gè)角度來看呢，fsimage文件就相當(dāng)于HDFS 的元數(shù)據(jù)的數(shù)據(jù)庫文件了，而edit log就相當(dāng)于是操作日志文件了。

 

Fsimage：

         每個(gè)fsimage文件都會(huì)包括整個(gè)文件系統(tǒng)中所有的目錄和文件inodes信息。每個(gè)inode是HDFS內(nèi)部的一個(gè)代表文件、或者目錄的元數(shù)據(jù)，如果inode代表一個(gè)文件，它包括：文件的備份級(jí)別、修改時(shí)間、訪問時(shí)間、訪問權(quán)限、block的size、所有blocks的構(gòu)成等信息。如果inode代表一個(gè)目錄，它包括：修改時(shí)間、權(quán)限、其它相關(guān)元數(shù)據(jù)等。

 

Edit log：

       它在邏輯上，是一個(gè)實(shí)例（也就是說可以理解為一個(gè)對(duì)象），實(shí)際上是由多個(gè)文件組成的。每個(gè)文件都被稱為一個(gè)segment，并以 edits_作為前綴，文件名后面的是事務(wù)id。

譬如上面的：edits_0000000000011403382-0000000000011403408 就代表該文件中放的是

事務(wù)Id為0000000000011403382到0000000000011403408之間的那些事務(wù)的信息。當(dāng)客戶端完成了一個(gè)寫操作，并收到namenode的success的響應(yīng)碼時(shí)，Namenode才會(huì)將該事務(wù)信息寫到editlog文件中。

 

為什么將事務(wù)信息處理后不直接寫到fsimage中？

         如果這樣做的話，也就是每個(gè)write操作完畢時(shí)，都去更新fsimage文件，在一個(gè)大的文件系統(tǒng)中，文件就會(huì)變得很大，上GB都是有可能的，那么將是一個(gè)緩慢的過程。

 

先寫到edit log中，怎么合并到fsimage中呢？

         解決方案是啟動(dòng)一個(gè)Secondary namenode。它的存在就是在內(nèi)存中生成Primary NameNode的fsimage文件。它的處理過程是這樣的：

 移動(dòng)開發(fā)培訓(xùn),Android培訓(xùn),安卓培訓(xùn),手機(jī)開發(fā)培訓(xùn),手機(jī)維修培訓(xùn),手機(jī)軟件培訓(xùn)

 

1、Secondary 告訴Primary去滾動(dòng)它的in-progress edits文件，這樣新來的write操作就會(huì)放到一個(gè)新的edit 文件中。同時(shí)Primary也會(huì)更新seen_txid文件。

2、Secondary 通過HTTP GET方式從Primary獲取到最新的fsimage和edits文件

3、Secondary 將fsimage加載到內(nèi)存中，并從edits文件中取出每一次事務(wù)，應(yīng)用到fsimage上，如此就產(chǎn)生了一個(gè)合并的新的fsimage文件。

4、Secondary將這個(gè)新合并的fsimage文件通過HTTP PUT發(fā)到Primary，Primary把它保存到臨時(shí).ckpt文件中。

5、Primary再把臨時(shí)文件重命名，并使它可用。

 

同時(shí)，這也是為啥Secondary需要與Primary類似的內(nèi)存配置，并且需要部署在一個(gè)單獨(dú)的機(jī)器。

 

NameNode為什么不自己做合并，而是由Seconary NameNode來做呢？

        NameNode不是不自己做，只是在啟動(dòng)時(shí)做。

        首先，所有的寫操作都會(huì)經(jīng)過NameNode來處理，所以faimage的內(nèi)容，在NameNode的內(nèi)存里，

肯定是有同樣的一份。所以在運(yùn)行期間，不需要通過合并來保證與內(nèi)存一致。

        其次，NameNode只是在啟動(dòng)時(shí)才進(jìn)行合并操作。

        也正由于這兩點(diǎn)原因，所以需要由Secondary NameNode來完成了。不然NameNode運(yùn)行了很長時(shí)間，比如累積了大量的editlog，而fsimage又是NameNode啟動(dòng)后的那一次合并后的狀態(tài)。那么NameNode重啟后必然要進(jìn)行長時(shí)間的合并操作。

作者: 房繼諾
出處：http://www.cnblogs.com/f1194361820
版權(quán)：本文版權(quán)歸作者和博客園共有
歡迎轉(zhuǎn)載，轉(zhuǎn)載請(qǐng)需要注明博客出處
技術(shù)交流QQ:1194361820，加好友請(qǐng)注明：來自博客園，不要說你是博客園，也可以掃描圖像二維碼直接加我。
移動(dòng)開發(fā)培訓(xùn),Android培訓(xùn),安卓培訓(xùn),手機(jī)開發(fā)培訓(xùn),手機(jī)維修培訓(xùn),手機(jī)軟件培訓(xùn)

http://www.cnblogs.com/f1194361820/p/6768623.html