白話聊聊Hadoop的Namenode是怎麼管理中繼資料的？

      什麼是中繼資料呢。百度百科的解釋是這樣的，描述資料的資料（data about data），主要是描述資料屬性（property）的資訊，用來支援如指示儲存位置、曆史資料、資源尋找、檔案記錄等功能。中繼資料算是一種電子式目錄，為了達到編製目錄的目的，必須在描述並收藏資料的內容或特色，進而達成協助資料檢索的目的。說了這麼了多，簡單地說，就是管理資料的資料。

      在hadoop中有兩個角色，namenode(一個主節點),datanode（多個從節點），datanode主要是儲存資料的，namenode一是管理檔案系統檔案的中繼資料資訊（包括檔案名稱、大小、位置、屬性、建立時間、修改時間等等），二是維護檔案到塊的對應關係和塊到節點的對應關係，三是維護使用者對檔案的操作資訊（檔案的增刪改查）。

      現在我們假設一下，如果中繼資料僅以檔案的形式儲存在namenode本地硬碟，這樣行不行。因為大批量的用戶端同時在進行上傳、下載等各種操作時，都要對中繼資料進行讀寫及修改操作，僅僅以檔案的形式來儲存中繼資料顯然不行，因為無法做到對各種操作的快速響應，把中繼資料放在記憶體中呢，確實能夠提高系統響應速度，但是一旦斷電就完全丟失了，這肯定也不行，那麼如果把記憶體的資料定期flush到磁碟檔案的方法行不行呢。一旦斷電，沒來得及的刷到磁碟的記憶體資料肯定也是要丟失的，顯然也不行，那麼在實際環境中，hadoop是怎麼管理中繼資料的呢。

      首先，磁碟確實有塊空間，對中繼資料進行持久化儲存的，名為fsimage,如果直接讀取磁碟檔案，速度肯定跟不上，記憶體中也要放一些中繼資料資訊，雖然很容易丟失，但可以提供查詢服務，實際上就是讀寫分離，由讀寫分離就有了資料一致性的問題，因為寫入資料，沒有寫入記憶體中，最新的中繼資料記錄在哪呢。實際上是記錄在一個很小的檔案中，這個檔案不提供修改，只提供追加，以日誌的形式記錄，一直都保持著幾十兆大小，名為edits***.log，比如在上傳一個檔案時，先對NAMENODE進行詢問，往哪裡寫，NAMENODE一邊分配一邊記錄，將空間分配資訊記錄edits**.log，當完成一個副本的寫入工作後，通知NAMENODE,被認為是寫入成功，這時，將edits**.log的資料更新至記憶體，此時，記憶體中的資料是最新的，即使現在斷電，最新的中繼資料在edits**.log也有儲存。

      回顧一下這個過程

      1、  用戶端寫入檔案時，NAMENODE首先往edits**.log檔案中記錄中繼資料操作

      2、  用戶端開始上傳檔案，完成後成功資訊給NAMENODE,NAMENODE就在記憶體中寫入這次上傳操作的新產生的中繼資料資訊，edits**.log檔案大小有一定的範圍，比較小， fsimage檔案就是記憶體的鏡像檔案，fsimage是最全的，edits**.log是最新的，更新的順序是先edits**.log,其次是記憶體，最後是fsimage，那fsimage什麼時候更新呢，記憶體和fsimage如何保持一致性。只要edits**.log在沒有寫滿時不需要同步，這裡提一下check point操作，是指每當edits**.log寫滿時，需要將這一段時間的新的中繼資料刷進fsimage，將edits**.log與fsimage合并

      3、  為防止影響響應速度，由SecondaryNamenode來做edit**.log與fsimage的合并工作，當edits**.log寫滿時，通知SecondaryNamenode進行checkpoint操作，停止往edits檔案中寫資料，SecondaryNamenode下載fsimage和edits檔案，合并產生新的fsimage,將新的記憶體鏡像上傳給Namenode,替換老的fsimage,刪除老的edit**.log,將edits new檔案命名為edits**.log       通過上述操作，可以看出在任務進行時，在任務時間點斷電，都不會遺失資料了。