hadoop相關

NameNode：

NameNode 在整個HDFS中處於關鍵的位置，它保存了全部文件系統的元數據信息用來監控每一個DataNode的健康狀態。只有NameNode知道數據從那裏來，將要分配到哪裏去，最後返回給誰。

DataNode會每3秒鐘一次經過TCP 9000端口發送心跳給NameNode。每10次心跳生成一個健康報告，心跳數據都會包含相關該DataNode所擁有的數據塊信息。該報告讓NameNode知道不一樣的機架上不一樣的DataNode上存在的數據塊副本，併爲此創建元數據信息。

Name Node的重要性不言而喻，沒有它，客戶端將不知道如何向HDFS寫入數據和讀取結果，就不可能執行 Map Reduce 工做，所以，Name Node 所在的服務器應當是一個比較牛逼的服務器（熱插拔風扇、冗餘網卡鏈接、雙電源等）。

若是 Name Node 沒有接收到 Data Node 發送過來的心跳，那麼它將會假定該 Data Node 已經死亡。由於有前面的心跳報告，所以 Name Node 知道該死亡的 Data Node 目前的工做內容以及進度，它將會將該 Data Node 所負責的內容分發給其餘的 Data Node去完成。（一樣根據機架意識來分發該任務）。

 

Secondary NameNode：

Secondary Name Node 在國內一般被稱爲輔助 Name Node 由於它並非一個完整備份， Secondary Name Node 的存在雖然是爲了確保 Name Node 在宕機後可以接手其職責，可是它與 Name Node 之間的元數據交互不是實時的。默認爲每隔 一小時，Secondary Name Node 會主動請求 Name Node，並從 Name Node 中拿到文件系統的元數據信息（同步）。這個間隔能夠經過配置項來設置。

所以，若是萬一 Name Node 宕機，雖然 Secondary Name Node 可以接手參加工做，可是依然會形成部分的數據丟失。所以，若是數據很是重要，默認的一小時同步一次可能遠遠不足以保護數據的計算進度，咱們能夠縮短其同步時間來增長數據的安全性例如： 每分鐘同步一次。

 

機架位感知：

因爲hadoop的HDFS對數據文件的分佈式存放是按照分塊block存儲，每一個block會有多個副本（默認是3），而且爲了數據的安全和高效，因此hadoop默認對3個副本的存放策略爲：

第一個block副本放在和client所在的node裏（若是client不在集羣範圍內，則這第一個node是隨機選取的）。

第二個副本放置在第一個節點不一樣的機架中的node中（隨機選擇）、

第三個副本彷佛放置在與第一個副本所在節點同一機架的另外一個節點上

 

NameNode：存儲元數據，元數據保存在內存中，保存文件block，DataNode之間的映射關係

DataNode：存儲文件內容，文件內容保存在磁盤，維護了block id 到DataNode本地文件的映射關係

 

NameNode掛了怎麼辦，持久化元數據，操做日誌（edit log）記錄文件建立，刪除，修改文件屬性等操做。Fsimage:包含完整的命名空間，file->Block的映射關係 ，文件的屬性（ACL，quota，修改時間等）

 

hadoop2.0的特性

支持CPU和內存兩種資源調度方式，容許配置每一個節點、  每一個任務可用的CPU和內存資源總量
• 能夠根據實際須要和CPU性能將每一個物理CPU劃分紅若干個  虛擬CPU。管理員可爲每一個節點單獨配置可用的虛擬CPU個數，用戶程序也可指定每一個任務須要的虛擬CPU個數
• 可爲每一個節點單獨配置可用內存，採用線程監控的方案控制內存使用，發現任務超過約定的資源量會將其殺死
• Mesos等資源管理軟件

基於zookeeper的HA原理和相關知識

非HA弊端
HDFS集羣的分佈式存儲是靠namenode節點（namenode負責響應客戶端請求）來實現。在非HA集羣中一旦namenode宕機，雖然元數據不會丟失，但整個集羣將沒法對外提供服務，致使HDFS服務的可靠性不高，這在實際應用場景中顯然是不可行的。
HA機制
已知致使服務可靠性不高的緣由是namenode節點宕機，那麼怎麼才能避免這個namenode節點宕機呢？一個容易想到的解決方案是部署兩臺namenode節點，造成主備模式（active/standby模式），這樣一旦active節點宕機，standby節點當即切換到active模式。事實上HA機制就是採起的這種方案。要想實現該機制，須要解決如下問題：
1.爲何選擇主備模式，而不是主主模式（active/active模式），也即讓兩個namenode節點都響應客戶端的請求
        一個顯然的前提是，兩臺namenode節點須要保存一致的元數據。
        咱們知道namenode節點是用來管理這些元數據的，響應客戶端請求時（上傳）須要增長元數據信息，若是使用主主模式，那麼兩個節點都將對元數據進行寫操做，怎麼同步是個很困難的問題。所以，只能有一臺機器響應請求，也即處在active狀態的節點（可稱爲主節點），而另外一臺namenode在主節點正常工做狀況下僅用來同步active節點的元數據信息，這個namenode稱爲備用節點（處在standby狀態），可見，要解決的問題主要是怎麼同步active節點的元數據信息。

2.怎麼同步兩個namenode節點的元數據
      響應客戶端請求的是active節點，所以只有active節點保存了最新的元數據。元數據分爲兩部分，一部分是剛寫入新的元數據（edits），另外一部分是合併後的較舊的（fsimage）。HA機制解決同步問題的方法是將active節點新寫入的edits元數據放在zookeeper集羣上（zookeeper集羣主要功能是實現少許數據的分佈式同步管理），standby節點在active節點正常狀況下只須要將zookeeper集羣上edits文件同步到本身的fsimage中就能夠。

       Hadoop框架爲這個集羣專門寫了個分佈式應用qjournal（依賴zookeeper實現），實現qjournal的節點稱爲journalnode。

3.怎麼感知active節點是否宕機，並將standby節點快速切換到active狀態？
        解決方案是專門在namenode節點上啓動一個監控進程，時刻監控namenode的狀態。對於處在active狀態的namenode，若是發現不正常就向zookeeper集羣中寫入一些數據。對於處在standby狀態的namenode，監控進程從zookeeper集羣中讀數據，從而感知到active節點是否正常。若是發現異常，監控進程負責將standby狀態切換到active狀態。這個監控進程在hadoop中叫作zkfc（依賴zookeeper實現）。

4.如何在狀態切換時避免brain split(腦裂)？
        腦裂：active namenode工做不正常後，zkfc在zookeeper中寫入一些數據，代表異常，這時standby namenode中的zkfc讀到異常信息，並將standby節點置爲active。可是，若是以前的active namenode並無真的死掉，出現了假死（死了一下子後又正常了，哈哈，是否是很搞笑），這樣，就有兩臺namenode同時工做了。這種現象稱爲腦裂。

        解決方案：standby namenode感知到主用節點出現異常後並不會當即切換狀態，zkfc會首先經過ssh遠程殺死active節點的 namenode進程（kill -9 進程號）。可是（這樣還不行，驚訝），若是kill指令沒有執行成功咋辦？？若是在一段時間內沒有收到執行成功的回執，standby節點會執行一個自定義腳本，儘可能保證不會出現腦裂問題！這個機制在hadoop中稱爲fencing（包括ssh發送kill指令，執行自定義腳本兩道保障）