一、概述

之前寫過一篇非常詳細的,利用QJM在HDFS2.0部署HA策略的文章，主要說了利用QJM進行HA部署以及其原理(http://www.linuxidc.com/Linux/2014-10/107933.htm?)。但是，其中沒有詳細描述Hadoop2.x通過QJM部署HA完畢之后，ActiveNamenode和StandbyNamenode之間的元數據運行機制,實際上由于2.x的HA策略的引入，其元數據的運行機制和1.x比起來已經有了很大的不同。寫這篇blog的目的主要是為了對hadoop1.x和hadoop2.x的元數據運行機制進行比較，當是自己的筆記吧。

二、fsimage和edits文件的作用

先來看看關于NameNode元數據相關的目錄結構，也就是配置在hdfs-site.xml上的dfs.name.dir項，具體目錄為$dfs.name.dir/current。看看目錄(hadoop2.2.0版本)：

我們發現有些以edites_開頭和少量以fsimage開頭的文件。fsimage和edites文件都是hadoop文件系統元數據的組成部分。

其中fsimage鏡像文件包含了整個HDFS文件系統的所有目錄和文件的indoe信息。對于文件來說包括了數據塊描述信息、修改時間、訪問時間等；對于目錄來說包括修改時間、訪問權限控制信息(目錄所屬用戶，所在組等)等。

另外，edit文件主要是在NameNode已經啟動情況下對HDFS進行的各種更新操作進行記錄，HDFS客戶端執行所有的寫操作都會被記錄到edit文件中。

--------------------------------------分割線 --------------------------------------

--------------------------------------分割線 --------------------------------------

三、NameNode簡單啟動過程

在HDFS中，任何一個文件，目錄和block，在HDFS中都會被表示為一個object存儲在namenode的內存中，每一個object占用150 bytes的內存空間。當NameNode啟動的時候，首先會將fsimage里面的所有內容映像到內存中，然后再一條一條地執行edits中的記錄，然后等待各個Datanode向自己匯報塊的信息來組裝blockMap，從而離開安全模式。在這里涉及到BlockMap結構，所謂的BlockMap結構就是記錄著block的元數據(加載在NameNode的內存中)和其對應的實際數據(存儲在各個DataNode中)的映射關系。真正每個block對應到datanodes列表的信息在hadoop中并沒有進行持久化存儲，而是在所有datanode啟動時，每個datanode對本地磁盤進行掃描，將本datanode上保存的block信息匯報給namenode,namenode在接收到每個datanode的塊信息匯報后，將接收到的塊信息，以及其所在的datanode信息等保存在內存中。HDFS就是通過這種塊信息匯報的方式來完成?block -> datanodes list的對應表構建。Datanode向namenode匯報塊信息的過程叫做blockReport，而namenode將block -> datanodes list的對應表信息保存在一個叫BlocksMap的數據結構中。因此，我們可以得出一個非常重要的結論，NameNode不會定期的向各個DataNode去”索取“塊的信息，而是各個datanode定期向namenode匯報塊的信息。當組裝完NameNode組裝完BlockMap的信息后基本上整個HDFS的啟動就完成了，可以順利地離開安全模式了。分析到這里，我們就可以很清楚地知道整個HDFS的啟動速度是由上面決定的了，第一：執行各個edits文件，這個也是我這篇blog重點討論的。第二：各個DataNode向NameNode匯報塊信息的進度(當99.9%的block匯報完畢才會離開安全模式)。

四、Hadoop1.x中fsimage和edits的合并機制

當edits文件很多很大的時候，NameNode在啟動的時候需要逐一每條的執行這些edits文件，這就嚴重地影響了整個HDFS的啟動時間。這問題在hadoop1.x是通過SecondaryNamenode機制將edits文件合并到fsimage中，其之得到解決，SecondaryNamenode在第一代的Hadoop中算是一個非熱備的NameNode備份。整個SecondaryNamenode的工作流程簡單地畫了一下圖：

簡單描述一下具體流程：

步驟一：SSN在一個checkpoint時間點和NameNode進行通信，請求NameNode停止使用edits文件記錄相關操作而是暫時將新的Write操作寫到新的文件edit.new來。

步驟二：SSN通過HTTP GET的方式從NameNode中將fsimage和edits文件下載回來本地目錄中。

步驟三：SSN中合并edits和fsimage。SSN將從NameNode中下載回來的fsimage加載到內存中，然后逐條 執行edits文件中的各個操作項，使得加載到內存中的fsimage中包含edits中的操作，這個過程就是所謂的合并了。

步驟四：在SSN中合并完fsimage和edits文件后，需要將新的fsimage回傳到NameNode上，這個是通過HTTP POST方式進行的。

步驟五：NameNode將從SSN接收到的新的fsimage替換掉舊的fsimage。同時將edits.new文件轉換為通常的edits文件，這樣edits文件的大小就得到減少了。SSN整個合并以及和NameNode的交互過程到這里已經結束。

總結

以上是生活随笔為你收集整理的linux x和s 的区别,Hadoop1.x和2.X的HDFS fsimage和edits文件运行机制对比的全部內容，希望文章能夠幫你解決所遇到的問題。

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