一、第一代資源管理器爲什麼會被淘汰掉
我們知道，hadoop 主要是由三部分組成，HDFS （hadoop 分佈式文件系統），MapReduce（分佈式計算框架），還有一個就是分佈式集羣資源調度框架 YARN。
但是 YARN 並不是隨 HADOOP 的推出一開始就有的。
YARN 是在 Mapreduce 基礎上演化而來的，它克服了 MapReduce 架構中的各種侷限性，主要可概括爲以下幾個方面：
-
可靠性差
MRv1採用了master/slave結構，其中，master存在單點故障問題，一旦它出現故障將導致整個集羣不可用。
-
擴展性差
在MRv1中，JobTracker（master）同時兼備了資源管理和作業控制兩個功能，這成爲系統的一個最大瓶頸，嚴重製約了Hadoop集羣擴展性。
-
資源利用率低
MRv1採用了基於槽位的資源分配模型，槽位是一種粗粒度的資源劃分單位，通常一個任務不會用完槽位對應的資源，且其他任務也無法使用這些的空閒資源。
此外，Hadoop將槽位分爲Map Slot和Reduce Slot兩種，且不允許它們之間共享，常常會導致一種槽位資源緊張而另外一種閒置（比如一個作業剛剛提交時，只會運行Map Task，此時Reduce Slot閒置）。
-
無法支持多種計算框架
隨着互聯網高速發展，MapReduce這種基於磁盤的離線計算框架已經不能滿足應用要求，從而出現了一些新的計算框架，包括內存計算框架、流式計算框架和迭代式計算框架等，而MRv1不能支持多種計算框架並存。
在 Hadoop 早期的時候，大數據技術就只有 Hadoop 一家，這個缺點並不明顯。
但隨着大數據技術的發展，各種新的計算框架不斷出現，我們不可能爲每一種計算框架部署一個服務器集羣，而且就算能部署新集羣，數據還是在原來集羣的 HDFS 上。
所以我們需要把 MapReduce 的資源管理和計算框架分開，這也是 Hadoop 2 最主要的變化，就是將 Yarn 從 MapReduce 中分離出來，成爲一個獨立的資源調度框架。
二、Yarn 的設計思想
基本設計思想是將 JobTracker 的兩個主要功能，即資源管理和作業控制（包括作業監控、容錯等），分拆成兩個獨立的進程。
資源管理進程和具體的應用程序無關，它負責整個集羣的資源（內存，CPU，磁盤等）管理，而作業控制進程則是直接與應用程序相關的模塊，且每個作業控制進程只負責管理一個作業。
這樣，通過將原有JobTracker中與應用程序相關和無關的模塊分開，不僅減輕了JobTracker的負載，也使得Hadoop支持更多的計算框架。
從資源管理的角度看，下一代MapReduce框架衍生出了一個資源統一管理平臺，它使得Hadoop不再侷限於僅支持MapReduce一種計算模型，而是可無限融入多種計算框架，並且對這些框架進行統一管理和調度。
三、Yarn 的架構
從圖上看，Yarn 包括兩個部分：一個是資源管理器（ResourceManager），一個是節點管理器（NodeManager）。
ResourceManager 進程負責整個集羣的資源調度管理，通常部署在獨立的服務器上；
NodeManager 進程負責具體服務器上的資源和任務管理，在集羣的每一臺計算服務器上都會啓動。基本上跟 HDFS 的 DataNode 進程一起出現。
資源管理器
調度器
調度器主要功能是根據資源容量，隊列等方面的限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個應用程序。
YARN中的調度器是一個“純調度器”，它不再從事任何與具體應用程序相關的工作，比如不負責監控或者跟蹤應用的執行狀態等，也不負責重新啓動因應用執行失敗或者硬件故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。
調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念“資源容器”（ResourceContainer，簡稱Container）表示，Container是一個動態資源分配單位，它將內存、CPU、磁盤、網絡等資源封裝在一起，從而限定每個任務使用的資源量。
在YARN中，資源調度器是一個可插拔的組件，用戶可根據自己的需要設計新的調度器，YARN提供了多種直接可用的調度器，比如 Fair Scheduler 和 Capacity Scheduler 。
應用程序管理器
應用程序管理器負責應用程序的提交、監控應用程序運行狀態等。
應用程序啓動後需要在集羣中運行一個 ApplicationMaster，ApplicationMaster 也需要運行在容器裏面。
每個應用程序啓動後都會先啓動自己的 ApplicationMaster，由 ApplicationMaster 根據應用程序的資源需求進一步向 ResourceManager 進程申請容器資源，得到容器以後就會分發自己的應用程序代碼到容器上啓動，進而開始分佈式計算。
四、以一個 MapReduce 爲例介紹 Yarn 的工作流程
當用戶向YARN中提交一個應用程序後，YARN將分兩個階段運行該應用程序：第一個階段是啓動ApplicationMaster；第二個階段是由ApplicationMaster創建應用程序，爲它申請資源，並監控它的整個運行過程，直到運行完成。
YARN的工作流程分爲以下幾個步驟：
步驟1 用戶向YARN中提交應用程序，其中包括ApplicationMaster程序、啓動ApplicationMaster的命令、用戶程序等。
步驟2 ResourceManager爲該應用程序分配第一個Container，並與對應的Node-Manager通信，要求它在這個Container中啓動應用程序的ApplicationMaster。
步驟3 ApplicationMaster首先向ResourceManager註冊，這樣用戶可以直接通過ResourceManage查看應用程序的運行狀態，然後它將爲各個任務申請資源，並監控它的運行狀態，直到運行結束，即重複步驟4~7。
步驟4 ApplicationMaster採用輪詢的方式通過RPC協議向ResourceManager申請和領取資源。
步驟5 一旦ApplicationMaster申請到資源後，便與對應的NodeManager通信，要求它啓動任務。
步驟6 NodeManager爲任務設置好運行環境（包括環境變量、JAR包、二進制程序等）後，將任務啓動命令寫到一個腳本中，並通過運行該腳本啓動任務。
步驟7 各個任務通過某個RPC協議向ApplicationMaster彙報自己的狀態和進度，以讓ApplicationMaster隨時掌握各個任務的運行狀態，從而可以在任務失敗時重新啓動任務。在應用程序運行過程中，用戶可隨時通過RPC向ApplicationMaster查詢應用程序的當前運行狀態。
步驟8 應用程序運行完成後，ApplicationMaster向ResourceManager註銷並關閉自己。
五、總結
我認爲理解 Yarn 的工作原理和架構，對於正確使用大數據技術，排查任務運行錯誤原因，是非常重要的。
在雲計算的時代，一切資源都是動態管理的，理解這種動態管理的原理對於理解雲計算也非常重要。
Yarn 作爲一個大數據平臺的資源管理框架，簡化了應用場景，對於幫助我們理解雲計算的資源管理很有幫助。
掃一掃，我們的故事就開始了。
如果這篇文章對你有所啓發，點贊、轉發都是一種支持！
另外公衆號改變了推送規則，大家看文章不要忘記點擊最下方的在看，點贊按鈕，這樣微信自動識別爲常看公衆號，否則很可能推送的文章可能淹沒在別的文章找不到，謝謝大家
讓我知道你在看
本文分享自微信公衆號 - 大數據實戰演練（gh_f942bfc92d26）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。