《Hadoop技術詳解》一2.5 管理檔案系統中繼資料

本節書摘來異步社群《hadoop技術詳解》一書中的第2章，第2.5節，作者： 【美】eric sammer 譯者： 劉敏 , 麥耀鋒 , 李冀蕾 , 等，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

namenode将檔案系統的中繼資料以不同的檔案儲存在本地磁盤中，其中最重要的兩個檔案是fsimage和edits。和資料庫一樣，fsimage包含檔案系統中繼資料的完整快照，而edits僅包含中繼資料的增量修改。對高吞吐率的資料存儲而言，一個常用方法是使用預寫日志（wal），如edits檔案，實作順序增加操作來減少i/o操作（在namenode中，所有操作都在ram中完成），進而避免高消耗的查找操作，擷取更好的整體性能。namenode啟動後，直接加載fsimage到ram，再通過回放引入edits的增量變化，最終在記憶體中建立擁有最新資訊的檔案系統視圖。

在hadoop較新的幾個版本中（具體地說，就是apache hadoop 2.0和cdh4；有關hadoop更多版本資訊，請參見4.1節“挑選hadoop的發行版本”），底層中繼資料的存儲擁有更好的可恢複性和支援namenode的高可用性。在概念上，中繼資料的存儲和以前的版本是類似的，除了事務不再儲存在單一的edits檔案中以外。在新版本中，namenode周期性輪換edits檔案（關閉一個檔案，然後打開一個新檔案），用事務id号來辨別。這樣就提供了一種可能：namenode可以保留舊的fsimage和edits檔案備份，進而可以更好地支援資料的復原功能。大部分的這類改變對使用者幾乎沒有什麼影響。之是以在這裡提起是為了讓讀者能更好地了解磁盤上這些檔案的用途，同時提醒讀者不要輕易改動這些檔案，除非你十厘清楚你在幹什麼。本書接下來的章節提到這些檔案的時候會使用它們的名字，分别用fsimage和edits來表明它們的功能。

namenode隻将改動内容寫入wal，即edits。随着時間的推移，edits檔案會像其他的日志系統檔案一樣變得越來越大，當伺服器發生故障時就需要很長的時間來回放。是以像傳統的關系資料庫那樣，需要定期将edits檔案引入到fsimage檔案中。這樣就帶來了新的問題，namenode在為叢集提供服務時可能無法提供足夠的資源——cpu或ram來支援此運算。為了解決這一問題，引入了次namenode。

namenode和次namenode之間的互動如圖2-4所示。[1]

1． 次namenode引導namenode滾動更新edits檔案，并開始将新的内容寫入edits.new。

2．次namenode将namenode的fsimage和edits檔案複制到本地的檢查點目錄。

3．次namenode載入fsimage檔案，回放edits内容，将其合并到fsimage，将新的fsimage檔案壓縮後寫入磁盤。

4．次namenode将新的fsimage檔案送回namenode，namenode在接收新的fsimage檔案後，直接加載和應用該檔案。

5．namenode将edits.new更名為edits。

預設情況下，該過程每小時發生一次，或者當namenode的edits檔案大小達到預設的64mb時也會被觸發。盡管後面我們會研究如何改變這些配置，但通常來說無需改變。在新版本的hadoop中，通過使用預定義的事務次數而不是檔案大小來觸發該過程。