轉自：http://blog.csdn.net/gamer_gyt/article/details/51758881
參考博客：
http://dongxicheng.org/mapreduce-nextgen/nodemanager-architecture/
http://dongxicheng.org/mapreduce-nextgen/yarnmrv2-resource-manager-infrastructure/
http://www.aboutyun.com/thread-7778-1-1.html
Namenode 管理者文件系統的Namespace。它維護著文件系統樹(filesystem tree)以及文件樹中所有的文件和文件夾的元數據(metadata)。管理這些信息的文件有兩個，分別是Namespace 鏡像文件(Namespace image)和操作日志文件(edit log)，這些信息被Cache在RAM中，當然，這兩個文件也會被持久化存儲在本地硬盤。Namenode記錄著每個文件中各個塊所在的數據節點的位置信息，但是他并不持久化存儲這些信息，因為這些信息會在系統啟動時從數據節點重建。
Namenode結構圖課抽象為如圖：
客戶端(client)代表用戶與namenode和datanode交互來訪問整個文件系統。客戶端提供了一些列的文件系統接口，因此我們在編程時，幾乎無須知道datanode和namenode，即可完成我們所需要的功能。
1.1Namenode容錯機制
沒有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來運行。
當然在hadoop 2.x 中，已經有了新的解決方案，那就是NameNode HA(因為Hadoop還包括 ResourceManage HA)，hadoop聯邦， Hadoop HA是指同時啟動兩個NameNode，一個處于工作狀態，另外一個處于隨時待命狀態，這樣在處于工作狀態的NameNode所在的服務器宕機時，可在數據不丟失的情況下，手工或者自動切換到另外一個NameNode提供服務。
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使用。
3.1NameNode的目錄結構如下：
${dfs.name.dir}/current/VERSION
/edits
/fsimage
/fstime
3.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重啟時造成長時間不可訪問的情況。
ResourceManage 即資源管理，在YARN中，ResourceManager負責集群中所有資源的統一管理和分配，它接收來自各個節點（NodeManager）的資源匯報信息，并把這些信息按照一定的策略分配給各個應用程序（實際上是ApplicationManager）。
RM包括Scheduler（定時調度器）和ApplicationManager（應用管理器）。Schedular負責向應用程序分配資源，它不做監控以及應用程序的狀態跟蹤，并且不保證會重啟應用程序本身或者硬件出錯而執行失敗的應用程序。ApplicationManager負責接受新的任務，協調并提供在ApplicationMaster容器失敗時的重啟功能。
這里簡單介紹以下ApplicationMaster，每個應用程序的AM負責項Scheduler申請資源，以及跟蹤這些資源的使用情況和資源調度的監控
更多關于ResourceManager的介紹參考：點擊閱讀
NM是ResourceManager在每臺機器上的代理，負責容器管理，并監控它們的資源使用情況，以及向ResourceManager/Scheduler提供資源使用報告
