1. 程式人生 > >大資料小白系列——HDFS(2)

大資料小白系列——HDFS(2)

這裡是大資料小白系列,這是本系列的第二篇,介紹一下HDFS中SecondaryNameNode、單點失敗(SPOF)、以及高可用(HA)等概念。

 

上一篇我們說到了大資料、分散式儲存,以及HDFS中的一些基本概念,為了能更好的理解後續介紹的內容,這裡先補充介紹一下NameNode到底是怎麼儲存元資料的。

 

首先,在啟動的時候,將磁碟中的元資料檔案讀取到記憶體,後續所有變化將被直接寫入記憶體,同時被寫入一個叫Edit Log的磁碟檔案。(如果你熟悉關係型資料庫,這個Edit Log有點像Oracle Redo Log,這是題外話)。

Q: 為什麼不把這些變化直接寫到磁碟上的元資料中,使磁碟上的元資料保持最新呢?Edit Log是不是多此一舉?

A: 這個主要是基於效能考慮,由於對Edit Log的寫是“順序寫”(追加),對元資料的寫是“隨機寫”,兩者在磁碟上表現出來的效能有相當大的差異。有興趣的同學可以搜尋學習一下磁碟相關原理哦。

 

上面這個方案,帶來了一些明顯的副作用。

  • NameNode長期執行,不停地向Edit Log追加內容,導致它變得巨大無比。
  • NameNode在重啟時,需要使用Edit Log更新元資料檔案,當Edit Log太大時,這一步驟就會耗費很長的時間。

 為了消除這些副作用,HDFS中引入了另外一個角色,SecondaryNameNode。

它定期(比如每小時)從NameNode上抓取Edit Log,使用它更新元資料檔案,並把最新的元資料檔案寫回到NameNode。

說完了SecondaryNameNode的職責之後,大家應該明白,它並不是一個“備用NameNode”,其實這是典型的命名不當,它應該被命名成“Checkpoint NameNode”才比較恰當。

  

接下來我們來說說HDFS中的單點失敗問題(SPOF, Single Point Of Failure),即,當NameNode掉線之後,整個HDFS叢集就變得不可用了。為解決這個問題,Hadoop 2.0中真正引入了一個“備用NameNode”。

  •  對元資料的修改首先發生在NameNode,並被寫入某個“共享位置”,備用NameNode將從該位置獲取Edit Log。
  • DataNode節點們同時向兩臺NameNode彙報狀態。

由於這兩點,兩臺NameNode上的元資料將一直保持同步。這將保證當NameNode掉線後,使用者可以立即切換到備用NameNode,系統將保持可用。

由於備用NameNode比較空閒(不用處理使用者請求),系統又給它安排了另外一份工作——定期使用Edit Log更新元資料檔案,也就是說它接手了SecondaryNameNode的工作。

所以,在HA環境中,我們就不再需要SecondaryNameNode了。

 

今天就到這裡,下一篇準備介紹JournalNode、NameNode選舉等概念,Cheers!

 


公眾號“程式設計師雜書館”,專注大資料,歡迎關注,每位關注者將獲贈Spark快速大資料分析紙質書一本!