HDFS詳解（3）——HDFS檔案結構

標籤：des   blog   http   java   使用   檔案   

HDFS中的NameNode、DataNode、Secondery NameNode是如何在磁碟上組織和儲存持久化資料的？下面將分別進行介紹。

注意，這裡主要介紹的是Hadoop 2.0以前的版本，Hadoop 2.0以後版本檔案結構稍微有一些變化，因為目前我們還沒有使用hadoop 2.0，所以後面只是稍微說一下hadoop 2.0中NameNode目錄結構，其他有興趣的可以自己再去深入的研究。

NameNode的檔案結構

最新格式化的NameNode會建立以下目錄結構：

${dfs.name.dir}/current/VERSION

                                        /edits

                                        /fsimage

                                        /fstime

 

其中dfs.name.dir屬性是一個目錄列表，是每個目錄的鏡像。這個機制使系統具備了一定的複原能力，特別是當其中一個目錄位於NFS之上時。

VERSION檔案是Java屬性檔案，其中包括運行HDFS的版本資訊，下面是一個典型的VERSION檔案包括的內容:

#Tue Jun 17 16:55:18 CST 2014

namespaceID=1812798012

cTime=0

storageType=NAME_NODE

layoutVersion=-18

其中，namespaceID是檔案系統的唯一識別碼。在檔案系統第一次被格式化時便會創建立namespaceID。這個標識符也要求各DataNode節點和NameNode節點保持一致。NameNode會使用此標識符識別新的DataNode。DataNode只有在向NameNode註冊後才會獲得此namespaceID。cTime屬性標記了NameNode儲存空間建立的時間。對於新格式化的儲存空間，雖然這裡的cTime屬性值為0，但是只要檔案系統被更新，它就會更新到一個新的時間戳記。StorageType用於指出此儲存目錄包含一個NameNode的資料結構，在DataNode中它的屬性值為DataNode。

layoutVersion是一個負的整數，定義了HDFS持久資料結構（也稱布局）的版本。注意，該版本號碼和Hadoop的發行版本號碼無關。每次HDFS的布局發生變化，該版本號碼就會遞減（比如-18版本號碼之後是-19），在這種情況下，HDFS就需要更新升級，因為如果一個新的NameNode或DataNode還處於舊版本上，那麼系統就無法正常運行，各節點版本號碼要保持一致。

NameNode的儲存目錄包含edits、fsimage、fstime三個檔案。它們都是二進位的檔案，可以通過HadoopWritable對象進行序列化。下面將介紹NameNode的工作原理，以便讓大家更清晰的理解這三個檔案的作業。

編輯日誌（edit log）及檔案系統映像（filesystem image）

當用戶端執行寫操作時，NameNode會先在編輯日誌中寫下記錄，並在記憶體中儲存一個檔案系統中繼資料，中繼資料會在編輯日誌有所改動後進行更新。記憶體中的中繼資料用來提供讀資料請求服務。

編輯日誌會在每次成功操作之後、成功碼尚未返回給用戶端之前進行重新整理和同步。對於要寫入多個目錄操作，寫入流要重新整理和同步到所有的副本，這就保證了操作不會因故障而遺失資料。

fsimage檔案是檔案系統中繼資料的持久性檢查點。和編輯日誌不同，它不會在每個檔案系統的寫操作之後都進行更新，因為寫出fsimage檔案會非常慢（fsimage可能增長到GB大小。）這種設計並不影響系統的恢複力，因為如果NameNode失敗，那麼中繼資料的最新狀態可以通過將磁碟中讀出的fsimage檔案載入到記憶體中來進行重建恢複，然後重新執行編輯日誌中的操作。事實上，這也正是NameNode啟動時要做的事情。一個fsimage檔案包含以序列化格式儲存的檔案系統目錄和檔案inodes。每個inodes表示一個檔案或目錄的中繼資料資訊，以及檔案的副本數、修改和訪問時間等資訊。

正如上面所描述的，Hadoop檔案系統會出現編輯日誌不斷增長的情況。儘管在NameNode運行期間不會對系統造成影響，但是，如果NameNode重新啟動，它將會花費很多時間運行編輯日誌中的每個操作。在此期間（即安全模式時間），檔案系統還是停用，通常來說還是不符合應用需求。

為瞭解決這個問題，Hadoop在NameNode之外的節點上運行一個Secondary NameNode進程。它的任務就是為原NameNode記憶體中的檔案系統中繼資料產生檢查點。下面我們參照圖10對檢查點處理過程進行描述。

                                    圖 10 檢查點處理過程

1）Secondary NameNode首先請求原NameNode進行edits的滾動，這樣新的編輯操作就能夠進入新的檔案中。

2）Secondary NameNode通過HTTP方式讀取原NameNode中的fsimage及edits。

3）Secondary NameNode讀取fsimage到記憶體中，然後執行edits中的每個操作，並建立一個新的統一的fsimage檔案。

4）Secondary NameNode（通過HTTP方式）將新的fsimage發送到原NameNode。

5）原NameNode用新的fsimage替換舊的fsimage，舊的edits檔案通過步驟1）中的edits進行替換。同時系統會更新fsimage檔案到記錄檢查點記錄的時間。

在這個過程結束後，NameNode就有了最新的fsimage檔案和更小的edits檔案。事實上，對於NameNode在安全模式的這種情況，管理員可以通過以下命令運行這個過程：

Hadoop dfsadmin –saveNamespace

這個過程清晰的表明了Secondary NameNode要有和原NameNode一樣的記憶體需求的原因—要把fsimage載入到記憶體中，因此Secondary NameNode在叢集中也需要有專用機器。但hadoop的預設配置中讓snn進程預設運行在namenode的那台機器上，但我們並不建議這麼做。

有關檢查點的時間表由兩個配置參數決定。Secondary NameNode每個小時會插入一個檢查點（fs.checkpoint.period , 以秒為單位），如果編輯日誌達到64MB（fs.checkpoint.size,以位元組為單位），則間隔時間更短，每隔5分鐘會檢查一次。

 

Secondary NameNode的目錄結構

Secondary NameNode在每次處理過程結束後都會有個檢查點。這個檢查點可以在一個子目錄/previous.checkpoint中找到，可以作為NameNode的中繼資料備份源，目錄如下:

${fs.checkpoint.dir}/current/VERSION

                                        /edits

                                        /fsimage

                                        /fstime

                              /previous.checkpoint/VERSION

                                         /edits

                                         /fsimage

                                         /fstime

以上這個目錄和Secondary NameNode的/current目錄結構是完全相同的。這樣設計的目的是:萬一整個NameNode發生故障，並且沒有用於恢複的備份，甚至NFS中也沒有備份，就可以直接從Secondary NameNode恢複。具體方式有兩種，第一種是直接複製相關的目錄到新的NameNode中。第二種是在啟動NameNode守護進程時，Secondary NameNode可以使用-importCheckPoint選項，並作為新的NameNode繼續運行任務。-importCheckPoint選項將載入fs.checkpoint.dir屬性定義的目錄中的最新檢查點的NameNode資料，但這種操作只有在dfs.name.dir所指定的目錄下沒有中繼資料的情況下才進行，這樣就避免了重寫之前中繼資料的風險。

DataNode的目錄結構

DataNode不需要進行格式化，它會在啟動時自己建立儲存目錄，其中關鍵的檔案和目錄如下：

${dfs.data.dir}/current/VERSION

                                         /blk_<id_1>

                                         /blk_<id_1>.meta

　　　　　　　　　　　　　　/blk_<id_2>

　　　　　　　　　　　　　　/blk_<id_2>.meta

　　　　　　　　　　　　　　……

　　　　　　　　　　　　　　/subdir0/

　　　　　　　　　　　　　　/subdir1/

　　　　　　　　　　　　　　/…

　　　　　　　　　　　　　　/subdir63/

DataNode中的VERSION檔案跟NameNode類似，

#Wed Jun 18 19:32:42 CST 2014

namespaceID=1812798012

storageID=DS-1146216163-10.16.78.34-50010-1400812209946

cTime=0

storageType=DATA_NODE

layoutVersion=-18

其中namespaceID、cTime和layoutVersion值與NameNode中的都一樣，namespaceID在第一次串連NameNode時就會從中擷取。storageID相對於DataNode來說是唯一的，用於在NameNode處標識DataNode。storageType將這個目錄標誌位DataNode資料存放區目錄。

DataNode中current目錄下的其他檔案都有blk_首碼，它有兩種類型：

1)HDFS中的檔案塊本身，儲存的是原始檔案內容。

2)塊的中繼資料資訊（使用.meta尾碼標識）。一個檔案塊由儲存的原始檔案位元組組成，中繼資料檔案由一個包含版本和類型資訊的標頭檔和一系列塊的地區校正和組成。

當目錄中儲存的塊資料量增加到一定規模時，DataNode會建立一個新的目錄，用於儲存新的塊及中繼資料。當目錄中的塊資料量達到64（可由dfs.DataNode.numblocks屬性確定）時，便會建立一個子目錄，這樣就會形成一個更寬的檔案樹結構，避免了由於儲存大量資料區塊而導致目錄很深，使檢索效能免受影響。通過這樣的措施，資料節點可以確保每個目錄中的檔案塊都可控的，也避免了一個目錄中存在過多檔案。

Hadoop 2.x版本檔案結構

Hadoop 2.x版本檔案結構跟之前的版本差別不是很大，以下我大概列一下我知道的不同的地方：

NameNode中繼資料結構如下：

${dfs.name.dir}/current/VERSION

                                        /edits

                                        /fsimage

                                        /seen_txid

VERSION 內容如下：只是比版本1多了一個clusterID和blockpoolID.clusterID是系統產生或手動指定的叢集ID。blockpoolID是針對每一個Namespace所對應的blockpool的ID，這個ID包括了其對應的NameNode節點的ip地址。

#Tue Jun 17 16:55:18 CST 2014

namespaceID=1812798012

clusterID=cluster21

cTime=0

storageType=NAME_NODE

blockpoolID=BP-178902860-10.16.78.24-1400812199650

layoutVersion=-40

另外這個目錄下這個seen_txid檔案替換了fstime，seen_txid在hadoop2.x被用來是存放transactionId的檔案，format之後是，它代表的是namenode裡面的edits_*檔案的尾數，namenode重啟的時候，會按照seen_txid的數字，循序從頭跑edits_0000001~到seen_txid的數字。所以當你的hdfs發生異常重啟的時候，一定要比對seen_txid內的數字是不是你edits最後的尾數，不然會發生建置namenode時metaData的資料有缺少，導致誤刪Datanode上多餘Block的資訊。

其他的這裡就不再多說，有興趣的可以自己再去研究

 

參考資料：Hadoop實戰 第2版 陸嘉恒著