在說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吧。
直接的原因呢，就是因為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