我們都知道在如今的Hadoop中主要有三個重要的執行管理器。一個HDFS,一個MapReduce,還有就是我們今天要看的 YARN。
2.0以前的Hadoop
在2.0以前的hadoop中是沒有Yarn這個模式管理的。大部分都是獨自作戰。Hbase做自己的，Spark也是做自己的,等等。這樣的話就會造成資源的浪費，不能充分的把資源給利用上。特别是在1.x的版本上容易出現單點故障，不容易擴充的情況。
在這裡Client的請求都會通過1個JobTracker來分發任務，如果我們的這個JobTracker出現異常。整個叢集就沒法參與正常工作。
在JobTracker 過多的TaskScheduler 集中過來，容易造成記憶體,cpu不夠用的情況。增加了任務執行失敗的風險。
因為這些情況，随着發展，Hadoop需要更新的一代管理引擎來幫助我們管理叢集-YARN引擎
在2.0的YARN
在新的業務驅動下，發展起來的YARN替代原先的模式。将原先浪費的資源進行合并，共同管理建立在一個模式管理下
- 從圖中我們可以看到 原先的JobTracker 被拆分成 資源管理和任務排程監控。
- 我們來看下如今的架構
ResourceManager : 在叢集中提供資源的統一管理和排程。并且接收來自用戶端的請求。同時不停的接收來自 DataNode上的心跳資訊。并且對叢集進行管理。
NodeManager ：
在整個叢集中會有多個該節點。主要用來維護自己節點上資源的管理和使用。
定時向ResourceManager 彙報自己資源的使用情況。并且 接收來自ResourceManager 各種指令
啟動我們在圖中看到的ApplicationMaster.
ApplicationMaster :
該ApplicationMaster 對應我們送出的程式，該程式可以來自Spark,Hbase , MapReduce.該master向管理器YARN申請資源。然後供應用程式使用。
配置設定任務給接下來的Container 。包含啟動，停止任務。
Container
封裝了CPU ，Memory 等資源的容器。
Client
通過client來送出任務，進行任務的開始與結束。并且查詢任務的執行進度等情況。
了解了這幾個功能名稱的作用，我們來看下整個任務執行流程是怎麼樣的。
從Client端發送一個 請求到我們的ResourceManager 上。其中内容應該包含ApplicationMaster,ApplicationMaster的啟動指令。本身應用程式的内容。
ResourceManager 配置設定任務到NodeManager上
NodeManager根據配置資訊進行處理啟動ApplicationMaster 。
注冊到ResourceManager，并且申請到資源傳回到我們的ApplicationMaster 上。
根據申請到的資源注冊到NodeManger上。
NodeManager 啟動對應的Container上。在這之間會通過心跳進行任務彙報。然後任務彙報後。進行任務管理。
總結
整個yarn的流程和新的結構大概就是如此。新模式解決了原先的單點問題。并且挺高了高可用性和擴充性。一套叢集環境就能供多個應用程式使用。YARN模式幫助我們解決掉了資源管理的問題，程式員關注業務開發即可。
原文釋出時間為：2018-06-22
本文作者：mengrui LuckQI
本文來自雲栖社群合作夥伴“
LuckQI”，了解相關資訊可以關注“
”。