Hadoop深入學習：HDFS主要流程——SNN合并fsimage和編輯日志

本節我們主要寫Secondary NameNode是如何合并命名空間檔案和編輯日志檔案。 

//-------------------------------------------------------------------------------------------------------------------------------------

Namenode 是 HDFS 的中繼資料伺服器，管理并協調資料節點 Datanode 的工作，其記憶體中儲存整個分布式檔案系統的 2 類中繼資料：

(1)檔案系統的名字空間，即系統目錄樹（恢複這個需要FsImages和Edit logs）。

(2)資料塊副本與 Datanode 的映射，即副本的位置。

第(1)類中繼資料在 Namenode 上定期持久化，儲存為鏡像檔案。資料塊副本的位置資訊沒有實作持久化，而是在Namenode 啟動時，通過接收 Datanode 的 Blockreport 獲得。

//--------------------------------------------------------------------------------------------------------------------------------------

       用戶端對HDFS的檔案系統目錄樹進行的任何修改，都會被記錄到編輯日志（edits）檔案中，以保證系統出現故障後，能夠根據這些日志進行恢複，但是随着日志不斷地增加，這意味着系統重新開機後，需要進行恢複的時間也就越長。為了避免這一情況的發生，HDFS引入了檢查點（checkpoint）機制。 

       命名空間鏡像(FSImage)檔案是系統的持久性檢查點，和編輯日志不同，它不能在用戶端做的每次修改後都及時更新。故命名空間鏡像再加上編輯日志，NameNode節點的中繼資料提供了安全保障。 

        在NameNode啟動時，首先會将磁盤上（存在NameNode的磁盤上）的fsiamge命名空間鏡像檔案讀入記憶體，恢複到某個時間的檢查點，然後再讀取編輯日志，進行重建（也可以成為合并）。  

       Hadoop中引入了第二命名節點Secondary NameNode節點，就是為了解決編輯日志随時間不斷的增長，NameNode節點重新開機後要花很長時間來執行編輯日志中的每一個操作（來進行合并），這種情況。 

       Secondary NameNode節點的工作流程： 

       1）、定期的通過遠端方法擷取NameNode節點上編輯日志（edits）的大小； 

       2）、如果NameNode節點上編輯日很小，就不需要合并NameNode上的fsimage檔案和編輯日志；   

       3）、通過遠端接口啟動一次檢查點過程，這時名位元組點NameNode需要建立一個新的編輯日志檔案edits.new，後續對檔案系統的任何修改都記錄到這個新編輯日志裡； 

       4）、SecondNameNode點将Namenode上的fsimage檔案和原編輯日志下載下傳到本地，并在記憶體中合并，合并的結果輸出為fsimage.ckpt； 

       5）、再次發起請求通知NameNode節點資料(fsimage.ckpt)已準備好，然後NameNode節點會下載下傳fsimage.ckpt(并替換掉原來的fsimage)； 

       6）、NameNode下載下傳結束後，Secondary NameNode會通過遠端調用（NameNodeProtocol.rollFsImage()）完成這次檢查點，NameNode在響應該遠端調用時，會用fsimage.ckpt覆寫原來的fsimage檔案，形成新的命名空間鏡像，同時将新的編輯日志edits.new改名為edits。 

       整個流程如下圖示： 

原文位址：http://flyingdutchman.iteye.com/blog/1874824