歡迎大家討論，我也是接觸時間不長，有問題歡迎大家指正。歡迎轉載，轉載請註明出處

Haddoop 1.0的不足與Hadoop2.0的產生

        學習和研究過Hadoop1.0的人都應該知道，在Hadoop1.0中，使用了Master\Slave的架構模式，jobTracker執行在單點的NameNode上，同時兼備了資源管理和作業控制兩個功能，使得它成為了系統的最大一個瓶頸，嚴重製約了Hadoop叢集的擴大；並且單點的NameNode一旦出現故障將導致整個叢集不可用；而且MRV1使用槽位slot作為資源分配模型，槽位是一種粗粒度的資源劃分單位，通常一個任務不會用完槽位對應的資源，且其他任務也無法使用這些空閒資源，資源之間無法共享，利用率低；最關鍵的是，它無法支援多重計算框架。基於以上原因，Hadoop2.0產生了。

       Hadoop2.0的核心是yarn，它是一個獨立的資源管理與分配的通用系統，yarn只負責資源管理與分配，在上面可以執行各種不同的框架。

Yarn的基本組成結構

      Yarn總體上仍然是master \ slave 結構，在整個叢集中，ResourceManager充當Master，NodeManager充當Slave，ResourceManager負責對各個NodeManager上的資源進行統一管理和排程。下圖為Yarn的基本結構，YARN主要有ResourceManager、NodeManager和ApplicationMaster和Container等幾個元件構成。

      ResourceManager是Master上一個獨立執行的程序，負責叢集統一的資源管理、排程、分配等等；NodeManager是Slave上一個獨立執行的程序，負責上報節點的狀態；App Master和Container是執行在Slave上的元件，Container是yarn中分配資源的一個單位，包涵記憶體、CPU等等資源，yarn以Container為單位分配資源。

      Client向ResourceManager提交的每一個應用程式都必須有一個Application Master，它經過ResourceManager分配資源後，運行於某一個Slave節點的Container中，具體做事情的Task，同樣也執行與某一個Slave節點的Container中。RM，NM，AM乃至普通的Container之間的通訊，都是用RPC機制。

Yarn詳細架構設計

     下面這個圖是我參考了一些資料之後，自己畫出的，請看：

分別進行介紹，所有的線條都是RPC協議，Client和Admin都是yarn系統外的，Client是使用者，他可以向yarn系統提交新的應用，Admin是yarn的管理員，它可以通過命令列來操作和管理yarn系統；RM(ResourceManager，以後的文章都簡稱RM)負責管理排程資源，NM(NodeManager，以後的文章都簡稱NM)負責管理Slave節點，並且定時向RM報告自己的狀態，叢集中有很多Slave節點。AMS(ApplicationMaste，以後的文章都簡稱AM)負責單個應用的資源再分配（從RM申請到資源以後，具體在分配給應用程式的任務）以及定時向RM彙報應用程式的狀態。AMS也是yarn系統外的，每個提交的應用程式都需要自己去實現一個AM。大家可能會迷惑為什麼ApplicationMasterProtocol和ContainerManagerProtocol在yarn系統中都已經實現了，為什麼是虛線？的確這兩個RPC協議都已經實現了，不過在AMS中需要自己去呼叫，比如ApplicationMasterProtocol協議，僅僅定義了register，stop和allocate介面，沒有實現任何心跳的程式碼，那就需要AM自己在程式碼裡重新開執行緒自己定期呼叫allocate去彙報自己的情況。RMClientProtocol和TaskUmbilicalProtocol是兩個在MRV2的應用程式中自己實現的RPC，所以嚴格的來說也是在yarn系統之外的，因為MRV2已經是一個執行在yarn平臺上的應用，從這點來看，yarn越來越像一個雲作業系統了。

程式碼目錄

        本系列文章，我們僅關注hadoop-yarn-project

hadoop-yarn-applications是兩個系統自帶的執行在yarn系統上的例子。具體的每個包是幹什麼用的，以後的文章會慢慢的講到。

今天的文章先到這裡。