在說Hadoop Yarn的原理之前，我們先來看看Yarn是怎樣出現的。在古老的Hadoop1.0中，MapReduce的JobTracker負責了太多的工作，包括資源調度，管理眾多的TaskTracker等工作。這自然就會產生一個問題，那就是JobTracker負載太多，有點“忙不過來”。於是Hadoop在1.0到2.0的升級過程中，便將JobTracker的資源調度工作獨立了出來，而這一改動，直接讓Hadoop成為大數據中最穩固的那一塊基石。，而這個獨立出來的資源管理框架，就是Hadoop Yarn框架 。
一. Hadoop Yarn是什么
在詳細介紹Yarn之前，我們先簡單聊聊Yarn，Yarn的全稱是Yet Another Resource Negotiator，意思是“另一種資源調度器”，這種命名和“有間客棧”這種可謂是異曲同工之妙。這里多說一句，以前Java有一個項目編譯工具，叫做Ant，他的命名也是類似的，叫做“Another Neat Tool”的縮寫，翻譯過來是”另一種整理工具“。
既然都叫做資源調度器了，那么自然，它的功能也是負責資源管理和調度的，接下來，我們就深入到Yarn框架內部一探究竟吧。
二. Hadoop Yarn架構原理剖析
這張圖可以說是Yarn的全景圖，我們主要圍繞上面這張圖展開，介紹圖中的每一個細節部分。首先，我們會介紹里面的Container的概念以及相關知識內容，然后會介紹圖中一個個組件，最后看看提交一個程序的流程。
2.1 Container
容器（Container）這個東西是Yarn對資源做的一層抽象。就像我們平時開發過程中，經常需要對底層一些東西進行封裝，只提供給上層一個調用接口一樣，Yarn對資源的管理也是用到了這種思想。
如上所示，Yarn將CPU核數，內存這些計算資源都封裝成為一個個的容器（Container）。需要注意兩點：
- 容器由NodeManager啟動和管理，並被它所監控。
- 容器被ResourceManager進行調度。
其中NodeManager和ResourceManager這兩個組件會在下面講到。
2.2 Yarn的三個主要組件
再看最上面的圖，我們能直觀發現的兩個主要的組件是ResourceManager和NodeManager，但其實還有一個ApplicationMaster在圖中沒有直觀顯示（其實就是圖中的App Mstr，圖里用了簡寫）。三個組件構成了Yarn的全景，這三個組件的主要工作是什么，Yarn 框架又是如何讓他們相互配合的呢，我們分別來看這三個組件。
ResourceManager
我們先來說說上圖中最中央的那個ResourceManager（RM）。從名字上我們就能知道這個組件是負責資源管理的，在運行過程中，整個系統有且只有一個RM，系統的資源正是由RM來負責調度管理的。RM包含了兩個主要的組件：定時調用器(Scheduler)以及應用管理器(ApplicationManager)，我們分別來看看它們的主要工作。
-
定時調度器(Scheduler)：從本質上來說，定時調度器就是一種策略，或者說一種算法。當Client提交一個任務的時候，它會根據所需要的資源以及當前集群的資源狀況進行分配。注意，它只負責向應用程序分配資源，並不做監控以及應用程序的狀態跟蹤。
-
應用管理器(ApplicationManager)：同樣，聽名字就能大概知道它是干嘛的。應用管理器就是負責管理Client用戶提交的應用。上面不是說到定時調度器（Scheduler）不對用戶提交的程序監控嘛，其實啊，監控應用的工作正是由應用管理器（ApplicationManager）完成的。
OK，明白了資源管理器ResourceManager，那么應用程序如何申請資源，用完如何釋放？這就是ApplicationMaster的責任了。
ApplicationMaster
每當Client（用戶）提交一個Application（應用程序）時候，就會新建一個ApplicationMaster。由這個ApplicationMaster去與ResourceManager申請容器資源，獲得資源后會將要運行的程序發送到容器上啟動，然后進行分布式計算。
這里可能有些難以理解，為什么是把運行程序發送到容器上去運行？如果以傳統的思路來看，是程序運行着不動，然后數據進進出出不停流轉。但當數據量大的時候就沒法這么玩了，因為海量數據移動成本太大，時間太長。但是中國有一句老話山不過來，我就過去。大數據分布式計算就是這種思想，既然大數據難以移動，那我就把容易移動的應用程序發布到各個節點進行計算唄，這就是大數據分布式計算的思路。
那么最后，資源有了，應用程序也有了，那么該怎么管理應用程序在每個節點上的計算呢？別急，我們還有一個NodeManager。
NodeManager
相比起上面兩個組件的掌控全局，NodeManager就顯得比較細微了。NodeManager是ResourceManager在每台機器的上代理，主要工作是負責容器的管理，並監控他們的資源使用情況（cpu，內存，磁盤及網絡等），並且它會定期向ResourceManager/Scheduler提供這些資源使用報告，再由ResourceManager決定對節點的資源進行何種操作（分配，回收等）。
三. 提交一個Application到Yarn的流程
這張圖簡單地標明了提交一個程序所經歷的流程，接下來我們來具體說說每一步的過程。
-
Client向Yarn提交Application，這里我們假設是一個MapReduce作業。
-
ResourceManager向NodeManager通信，為該Application分配第一個容器。並在這個容器中運行這個應用程序對應的ApplicationMaster。
-
ApplicationMaster啟動以后，對作業（也就是Application）進行拆分，拆分task出來，這些task可以運行在一個或多個容器中。然后向ResourceManager申請要運行程序的容器，並定時向ResourceManager發送心跳。
-
申請到容器后，ApplicationMaster會去和容器對應的NodeManager通信，而后將作業分發到對應的NodeManager中的容器去運行，這里會將拆分后的MapReduce進行分發，對應容器中運行的可能是Map任務，也可能是Reduce任務。
-
容器中運行的任務會向ApplicationMaster發送心跳，匯報自身情況。當程序運行完成后，ApplicationMaster再向ResourceManager注銷並釋放容器資源。
以上就是一個作業的大體運行流程。
小結：這次我們介紹了Hadoop yarn的主要架構原理以及yarn上任務的運行流程。我們說了yarn的幾個主要的組件，各自的責任，以及如何與其他組件協作調和。最后我們再來說說為什么會有Yarn這么個框架的出現吧~~
為什么會有Hadoop Yarn框架的出現？
上面說了這么多，最后我們來聊聊為什么會有Yarn吧。
直接的原因呢，就是因為Hadoop1.0中架構的缺陷，在MapReduce中，jobTracker擔負起了太多的責任了，接收任務是它，資源調度是它，監控TaskTracker運行情況還是它。這樣實現的好處是比較簡單，但相對的，就容易出現一些問題，比如常見的單點故障問題。
要解決這些問題，只能將jobTracker進行拆分，將其中部分功能拆解出來。彼時業內已經有了一部分的資源管理框架，比如mesos，於是照着這個思路，就開發出了Yarn。這里多說個冷知識，其實Spark早期是為了推廣mesos而產生的，這也是它名字的由來，不過后來反正是Spark火起來了。。。
閑話不多說，其實Hadoop能有今天這個地位，Yarn可以說是功不可沒。因為有了Yarn，更多計算框架可以接入到Hdfs中，而不單單是MapReduce，到現在我們都知道，MapReduce早已經被Spark等計算框架趕超，而Hdfs卻依然屹立不倒。究其原因，正式因為Yarn的包容，使得其他計算框架能專注於計算性能的提升。Hdfs可能不是最優秀的大數據存儲系統，但卻是應用最廣泛的大數據存儲系統，Yarn功不可沒。
推薦閱讀 ：
從分治算法到 MapReduce
一個故事告訴你什么才是好的程序員
大數據存儲的進化史 --從 RAID 到 Hadoop Hdfs