2019獨角獸企業重金招聘Python工程師標準>>>

1. Hadoop 1.x 版本?fsimage和edits合并實現原理?

????????在NameNode運行期間，HDFS的所有更新操作都是直接寫到edits中，久而久之edits文件將會變得很大；雖然這對NameNode運行時候是沒有什么影響的，但是我們知道當NameNode重啟的時候，NameNode先將fsimage里面的所有內容映像到內存中，然后再一條一條地執行edits中的記錄，當edits文件非常大的時候，會導致NameNode啟動操作非常地慢，而在這段時間內HDFS系統處于安全模式，這顯然不是用戶要求的。能不能在NameNode運行的時候使得edits文件變小一些呢？其實是可以的，本文主要是針對Hadoop 1.x版本，說明其是怎么將edits和fsimage文件合并的，Hadoop 2.x版本edits和fsimage文件合并是不同的。
　　用過Hadoop的用戶應該都知道在Hadoop里面有個SecondaryNamenode進程，從名字看來大家很容易將它當作NameNode的熱備進程。其實真實的情況不是這樣的。SecondaryNamenode是HDFS架構中的一個組成部分，它是用來保存namenode中對HDFS metadata的信息的備份，并減少namenode重啟的時間而設定的！一般都是將SecondaryNamenode單獨運行在一臺機器上，那么SecondaryNamenode是如何namenode重啟的時間的呢？來看看SecondaryNamenode的工作情況：
　　（1）、SecondaryNamenode會定期的和NameNode通信，請求其停止使用edits文件，暫時將新的寫操作寫到一個新的文件edit.new上來，這個操作是瞬間完成，上層寫日志的函數完全感覺不到差別；
　　（2）、SecondaryNamenode通過HTTP GET方式從NameNode上獲取到fsimage和edits文件，并下載到本地的相應目錄下；
　　（3）、SecondaryNamenode將下載下來的fsimage載入到內存，然后一條一條地執行edits文件中的各項更新操作，使得內存中的fsimage保存最新；這個過程就是edits和fsimage文件合并；
　　（4）、SecondaryNamenode執行完（3）操作之后，會通過post方式將新的fsimage文件發送到NameNode節點上
　　（5）、NameNode將從SecondaryNamenode接收到的新的fsimage替換舊的fsimage文件，同時將edit.new替換edits文件，通過這個過程edits就變小了！整個過程的執行可以通過下面的圖說明：

　　在（1）步驟中，我們談到SecondaryNamenode會定期的和NameNode通信，這個是需要配置的,可以通過core-site.xml進行配置，下面是默認的配置：

<property><name>fs.checkpoint.period</name><value>3600</value><description>The number of seconds between two periodic checkpoints.</description> </property>

　　其實如果當fs.checkpoint.period配置的時間還沒有到期，我們也可以通過判斷當前的edits大小來觸發一次合并的操作，可以通過下面配置

<property> <name>fs.checkpoint.size</name> <value>67108864</value> <description>The size of the current edit log (in bytes) that triggers a periodic checkpoint even if the fs.checkpoint.period hasn't expired. </description> </property>

　　當edits文件大小超過以上配置，即使fs.checkpoint.period還沒到，也會進行一次合并。順便說說SecondaryNamenode下載下來的fsimage和edits暫時存放的路徑可以通過下面的屬性進行配置：

<property> <name>fs.checkpoint.dir</name> <value>${hadoop.tmp.dir}/dfs/namesecondary</value> <description>Determines where on the local filesystem the DFS secondary name node should store the temporary images to merge. Ifthisis a comma-delimited list of directories then the image is replicated in all of the directories for redundancy. </description> </property> <property> <name>fs.checkpoint.edits.dir</name> <value>${fs.checkpoint.dir}</value> <description>Determines where on the local filesystem the DFS secondary name node should store the temporary edits to merge. Ifthisis a comma-delimited list of directoires then teh edits is replicated in all of the directoires for redundancy. Default value is same as fs.checkpoint.dir </description> </property>

從上面的描述我們可以看出，SecondaryNamenode根本就不是Namenode的一個熱備，其只是將fsimage和edits合并。其擁有的fsimage不是最新的，因為在他從NameNode下載fsimage和edits文件時候，新的更新操作已經寫到edit.new文件中去了。而這些更新在SecondaryNamenode是沒有同步到的！當然，如果NameNode中的fsimage真的出問題了，還是可以用SecondaryNamenode中的fsimage替換一下NameNode上的fsimage，雖然已經不是最新的fsimage，但是我們可以將損失減小到最少！

2. 2.X 版本中fsimage和edits合并實現原理?

　我們知道，在Hadoop 2.x中解決了NameNode的單點故障問題；同時SecondaryName已經不用了，而之前的Hadoop 1.x中是通過SecondaryName來合并fsimage和edits以此來減小edits文件的大小，從而減少NameNode重啟的時間。而在Hadoop 2.x中已經不用SecondaryName，那它是怎么來實現fsimage和edits合并的呢？首先我們得知道，在Hadoop 2.x中提供了HA機制（解決NameNode單點故障），可以通過配置奇數個JournalNode來實現HA，如何配置今天就不談了！HA機制通過在同一個集群中運行兩個NN（active NN & standby NN）來解決NameNode的單點故障，在任何時間，只有一臺機器處于Active狀態；另一臺機器是處于Standby狀態。Active NN負責集群中所有客戶端的操作；而Standby NN主要用于備用，它主要維持足夠的狀態，如果必要，可以提供快速的故障恢復。
　　為了讓Standby NN的狀態和Active NN保持同步，即元數據保持一致，它們都將會和JournalNodes守護進程通信。當Active NN執行任何有關命名空間的修改，它需要持久化到一半以上的JournalNodes上(通過edits log持久化存儲)，而Standby NN負責觀察edits log的變化，它能夠讀取從JNs中讀取edits信息，并更新其內部的命名空間。一旦Active NN出現故障，Standby NN將會保證從JNs中讀出了全部的Edits，然后切換成Active狀態。Standby NN讀取全部的edits可確保發生故障轉移之前，是和Active NN擁有完全同步的命名空間狀態
　　那么這種機制是如何實現fsimage和edits的合并？在standby NameNode節點上會一直運行一個叫做CheckpointerThread的線程，這個線程調用StandbyCheckpointer類的doWork()函數，而doWork函數會每隔Math.min(checkpointCheckPeriod, checkpointPeriod)秒來坐一次合并操作，相關代碼如下：

try{Thread.sleep(1000* checkpointConf.getCheckPeriod());}catch(InterruptedException ie) { }publiclonggetCheckPeriod() {returnMath.min(checkpointCheckPeriod, checkpointPeriod); }checkpointCheckPeriod = conf.getLong(DFS_NAMENODE_CHECKPOINT_CHECK_PERIOD_KEY,DFS_NAMENODE_CHECKPOINT_CHECK_PERIOD_DEFAULT);checkpointPeriod = conf.getLong(DFS_NAMENODE_CHECKPOINT_PERIOD_KEY,DFS_NAMENODE_CHECKPOINT_PERIOD_DEFAULT); try{Thread.sleep(1000* checkpointConf.getCheckPeriod());}catch(InterruptedException ie) { }publiclonggetCheckPeriod() {returnMath.min(checkpointCheckPeriod, checkpointPeriod); }checkpointCheckPeriod = conf.getLong(DFS_NAMENODE_CHECKPOINT_CHECK_PERIOD_KEY,DFS_NAMENODE_CHECKPOINT_CHECK_PERIOD_DEFAULT);checkpointPeriod = conf.getLong(DFS_NAMENODE_CHECKPOINT_PERIOD_KEY,DFS_NAMENODE_CHECKPOINT_PERIOD_DEFAULT);

上面的checkpointCheckPeriod和checkpointPeriod變量是通過獲取hdfs-site.xml以下兩個屬性的值得到：

<property><name>dfs.namenode.checkpoint.period</name><value>3600</value><description>The number of seconds between two periodic checkpoints.</description> </property><property><name>dfs.namenode.checkpoint.check.period</name><value>60</value><description>The SecondaryNameNode and CheckpointNode will poll the NameNodeevery'dfs.namenode.checkpoint.check.period'seconds to query the numberof uncheckpointed transactions.</description> </property>

當達到下面兩個條件的情況下，將會執行一次checkpoint：

booleanneedCheckpoint = false; if(uncheckpointed >= checkpointConf.getTxnCount()) {LOG.info("Triggering checkpoint because there have been " +uncheckpointed + " txns since the last checkpoint, which " +"exceeds the configured threshold " +checkpointConf.getTxnCount());needCheckpoint = true; }elseif(secsSinceLast >= checkpointConf.getPeriod()) {LOG.info("Triggering checkpoint because it has been " +secsSinceLast + " seconds since the last checkpoint, which " +"exceeds the configured interval " + checkpointConf.getPeriod());needCheckpoint = true; }

　　當上述needCheckpoint被設置成true的時候，StandbyCheckpointer類的doWork()函數將會調用doCheckpoint()函數正式處理checkpoint。當fsimage和edits的合并完成之后，它將會把合并后的fsimage上傳到Active NameNode節點上，Active NameNode節點下載完合并后的fsimage，再將舊的fsimage刪掉（Active NameNode上的）同時清除舊的edits文件。步驟可以歸類如下：
　　（1）、配置好HA后，客戶端所有的更新操作將會寫到JournalNodes節點的共享目錄中，可以通過下面配置

<property><name>dfs.namenode.shared.edits.dir</name><value>qjournal://XXXX/mycluster</value> </property><property><name>dfs.journalnode.edits.dir</name><value>/export1/hadoop2x/dfs/journal</value> </property>

　　（2）、Active Namenode和Standby NameNode從JournalNodes的edits共享目錄中同步edits到自己edits目錄中；
　　（3）、Standby NameNode中的StandbyCheckpointer類會定期的檢查合并的條件是否成立，如果成立會合并fsimage和edits文件；
　　（4）、Standby NameNode中的StandbyCheckpointer類合并完之后，將合并之后的fsimage上傳到Active NameNode相應目錄中；
　　（5）、Active NameNode接到最新的fsimage文件之后，將舊的fsimage和edits文件清理掉；
　　（6）、通過上面的幾步，fsimage和edits文件就完成了合并，由于HA機制，會使得Standby NameNode和Active NameNode都擁有最新的fsimage和edits文件（之前Hadoop 1.x的SecondaryNameNode中的fsimage和edits不是最新的）
?

轉載于:https://my.oschina.net/TomcatJack/blog/2996631

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的HDFS fsimage和edits合并实现原理的全部內容，希望文章能夠幫你解決所遇到的問題。

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