大數據小白系列——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快速大數據分析》紙質書一本！