HDFS的namenode和datanode

一、概述

HDFS集羣以Master-Slave模式運行，主要有兩類節點：一個Namenode(即Master)和多個Datanode(即Slave)。

HDFS Architecture：

二、Namenode

Namenode 管理者文件系統的Namespace。它維護着文件系統樹(filesystem tree)以及文件樹中所有的文件和文件夾的元數據(metadata)。管理這些信息的文件有兩個，分別是Namespace 鏡像文件(Namespace image)和操作日誌文件(edit log)，這些信息被Cache在RAM中，當然，這兩個文件也會被持久化存儲在本地硬盤。Namenode記錄着每個文件中各個塊所在的數據節點的位置信息，但是他並不持久化存儲這些信息，因爲這些信息會在系統啓動時從數據節點重建。

Namenode結構圖課抽象爲如圖：

客戶端(client)代表用戶與namenode和datanode交互來訪問整個文件系統。客戶端提供了一些列的文件系統接口，因此我們在編程時，幾乎無須知道datanode和namenode，即可完成我們所需要的功能。

三、Namenode容錯機制

沒有Namenode，HDFS就不能工作。事實上，如果運行namenode的機器壞掉的話，系統中的文件將會完全丟失，因爲沒有其他方法能夠將位於不同datanode上的文件塊(blocks)重建文件。因此，namenode的容錯機制非常重要，Hadoop提供了兩種機制。

第一種方式是將持久化存儲在本地硬盤的文件系統元數據備份。Hadoop可以通過配置來讓Namenode將他的持久化狀態文件寫到不同的文件系統中。這種寫操作是同步並且是原子化的。比較常見的配置是在將持久化狀態寫到本地硬盤的同時，也寫入到一個遠程掛載的網絡文件系統。

第二種方式是運行一個輔助的Namenode(Secondary Namenode)。 事實上Secondary Namenode並不能被用作Namenode它的主要作用是定期的將Namespace鏡像與操作日誌文件(edit log)合併，以防止操作日誌文件(edit log)變得過大。通常，Secondary Namenode 運行在一個單獨的物理機上，因爲合併操作需要佔用大量的CPU時間以及和Namenode相當的內存。輔助Namenode保存着合併後的Namespace鏡像的一個備份，萬一哪天Namenode宕機了，這個備份就可以用上了。

但是輔助Namenode總是落後於主Namenode，所以在Namenode宕機時，數據丟失是不可避免的。在這種情況下，一般的，要結合第一種方式中提到的遠程掛載的網絡文件系統(NFS)中的Namenode的元數據文件來使用，把NFS中的Namenode元數據文件，拷貝到輔助Namenode，並把輔助Namenode作爲主Namenode來運行。

四、DataNode

Datanode是文件系統的工作節點，他們根據客戶端或者是namenode的調度存儲和檢索數據，並且定期向namenode發送他們所存儲的塊(block)的列表。

集羣中的每個服務器都運行一個DataNode後臺程序，這個後臺程序負責把HDFS數據塊讀寫到本地的文件系統。當需要通過客戶端讀/寫某個 數據時，先由NameNode告訴客戶端去哪個DataNode進行具體的讀/寫操作，然後，客戶端直接與這個DataNode服務器上的後臺程序進行通 信，並且對相關的數據塊進行讀/寫操作。

五、Secondary NameNode介紹

　Secondary  NameNode是一個用來監控HDFS狀態的輔助後臺程序。就想NameNode一樣，每個集羣都有一個Secondary  NameNode，並且部署在一個單獨的服務器上。Secondary  NameNode不同於NameNode，它不接受或者記錄任何實時的數據變化，但是，它會與NameNode進行通信，以便定期地保存HDFS元數據的 快照。由於NameNode是單點的，通過Secondary  NameNode的快照功能，可以將NameNode的宕機時間和數據損失降低到最小。同時，如果NameNode發生問題，Secondary  NameNode可以及時地作爲備用NameNode使用。

5.1NameNode的目錄結構如下：

${dfs.name.dir}/current/VERSION

                                         /edits

                                         /fsimage

                                         /fstime

5.2Secondary NameNode的目錄結構如下：

${fs.checkpoint.dir}/current/VERSION

                                                /edits

                                                /fsimage

                                                /fstime

                                /previous.checkpoint/VERSION

                                                                      /edits

                                                                      /fsimage

                                                                      /fstime

如上圖，Secondary NameNode主要是做Namespace image和Edit log合併的。

那麼這兩種文件是做什麼的？當客戶端執行寫操作，則NameNode會在edit log記錄下來，（我感覺這個文件有些像Oracle的online redo logo file）並在內存中保存一份文件系統的元數據。

Namespace image（fsimage）文件是文件系統元數據的持久化檢查點，不會在寫操作後馬上更新，因爲fsimage寫非常慢（這個有比較像datafile）。

由於Edit log不斷增長，在NameNode重啓時，會造成長時間NameNode處於安全模式，不可用狀態，是非常不符合Hadoop的設計初衷。所以要週期性合併Edit log，但是這個工作由NameNode來完成，會佔用大量資源，這樣就出現了Secondary NameNode，它可以進行image檢查點的處理工作。步驟如下：

（1）       Secondary NameNode請求NameNode進行edit log的滾動（即創建一個新的edit log），將新的編輯操作記錄到新生成的edit log文件；

（2）       通過http get方式，讀取NameNode上的fsimage和edits文件，到Secondary NameNode上；

（3）       讀取fsimage到內存中，即加載fsimage到內存，然後執行edits中所有操作（類似OracleDG，應用redo log），並生成一個新的fsimage文件，即這個檢查點被創建；

（4）       通過http post方式，將新的fsimage文件傳送到NameNode；

（5）       NameNode使用新的fsimage替換原來的fsimage文件，讓（1）創建的edits替代原來的edits文件；並且更新fsimage文件的檢查點時間。

整個處理過程完成。

Secondary NameNode的處理，是將fsimage和edites文件週期的合併，不會造成nameNode重啓時造成長時間不可訪問的情況。

NameNode，DataNode和Client之間的通信方式介紹：

在hadoop系統中，master/slaves/client的對應關係是：
master---namenode；
slaves---datanode；
client---dfsclient；
那究竟是通過什麼樣的方式進行通信的呢，在這裏從大體介紹一下：
簡單地講：
client和namenode之間是通過rpc通信；
datanode和namenode之間是通過rpc通信；
client和datanode之間是通過簡單的socket通信。