2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

1. Hadoop 1.x 版本?fsimage和edits合并實(shí)現(xiàn)原理?

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

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

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

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

<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>

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

<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的一個(gè)熱備，其只是將fsimage和edits合并。其擁有的fsimage不是最新的，因?yàn)樵谒麖腘ameNode下載fsimage和edits文件時(shí)候，新的更新操作已經(jīng)寫到edit.new文件中去了。而這些更新在SecondaryNamenode是沒有同步到的！當(dāng)然，如果NameNode中的fsimage真的出問題了，還是可以用SecondaryNamenode中的fsimage替換一下NameNode上的fsimage，雖然已經(jīng)不是最新的fsimage，但是我們可以將損失減小到最少！

2. 2.X 版本中fsimage和edits合并實(shí)現(xiàn)原理?

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

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以下兩個(gè)屬性的值得到：

<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>

當(dāng)達(dá)到下面兩個(gè)條件的情況下，將會(huì)執(zhí)行一次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; }

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

<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類會(huì)定期的檢查合并的條件是否成立，如果成立會(huì)合并fsimage和edits文件；
　　（4）、Standby NameNode中的StandbyCheckpointer類合并完之后，將合并之后的fsimage上傳到Active NameNode相應(yīng)目錄中；
　　（5）、Active NameNode接到最新的fsimage文件之后，將舊的fsimage和edits文件清理掉；
　　（6）、通過上面的幾步，fsimage和edits文件就完成了合并，由于HA機(jī)制，會(huì)使得Standby NameNode和Active NameNode都擁有最新的fsimage和edits文件（之前Hadoop 1.x的SecondaryNameNode中的fsimage和edits不是最新的）
?

轉(zhuǎn)載于:https://my.oschina.net/TomcatJack/blog/2996631

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

總結(jié)

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

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