一. Hadoop Yarn 是什麼
在古老的 Hadoop1.0 中，MapReduce 的 JobTracker 負責了太多的工作，包括資源排程，管理衆多的 TaskTracker 等工作。這自然是不合理的，于是 Hadoop 在 1.0 到 2.0 的更新過程中，便将 JobTracker 的資源排程工作獨立了出來，而這一改動，直接讓 Hadoop 成為大資料中最穩固的那一塊基石。，而這個獨立出來的資源管理架構，就是 Yarn 。
在詳細介紹 Yarn 之前，我們先簡單聊聊 Yarn ，Yarn 的全稱是 Yet Another Resource Negotiator，意思是“另一種資源排程器”，這種命名和“有間客棧”這種可謂是異曲同工之妙。這裡多說一句，以前 Java 有一個項目編譯工具，叫做 Ant，他的命名也是類似的，叫做 “Another Neat Tool”的縮寫，翻譯過來是”另一種整理工具“。
既然都叫做資源排程器了，那麼自然，它的功能也是負責資源管理和排程的，接下來，我們就深入到 Yarn 這個東西内部一探究竟吧。
二. Yarn 架構
我們主要圍繞上面這張圖展開，不過在介紹圖中内容時，需要先了解 Yarn 中的 Container 的概念，然後會介紹圖中一個個元件，最後看看送出一個程式的流程。
2.1 Container
容器（Container）這個東西是 Yarn 對資源做的一層抽象。就像我們平時開發過程中，經常需要對底層一些東西進行封裝，隻提供給上層一個調用接口一樣，Yarn 對資源的管理也是用到了這種思想。
如上所示，Yarn 将CPU核數，記憶體這些計算資源都封裝成為一個個的容器（Container）。需要注意兩點：
- 容器由 NodeManager 啟動和管理，并被它所監控。
- 容器被 ResourceManager 進行排程。
NodeManager 和 ResourceManager 這兩個元件會在下面講到。
2.2 三個主要元件
再看最上面的圖，我們能直覺發現的兩個主要的元件是 ResourceManager 和 NodeManager ，但其實還有一個 ApplicationMaster 在圖中沒有直覺顯示。我們分别來看這三個元件。
ResourceManager
我們先來說說上圖中最中央的那個 ResourceManager（RM）。從名字上我們就能知道這個元件是負責資源管理的，整個系統有且隻有一個 RM ，來負責資源的排程。它也包含了兩個主要的元件：定時調用器(Scheduler)以及應用管理器(ApplicationManager)。
- 定時排程器(Scheduler)：從本質上來說，定時排程器就是一種政策，或者說一種算法。當 Client 送出一個任務的時候，它會根據所需要的資源以及目前叢集的資源狀況進行配置設定。注意，它隻負責向應用程式配置設定資源，并不做監控以及應用程式的狀态跟蹤。
- 應用管理器(ApplicationManager)：同樣，聽名字就能大概知道它是幹嘛的。應用管理器就是負責管理 Client 使用者送出的應用。上面不是說到定時排程器（Scheduler）不對使用者送出的程式監控嘛，其實啊，監控應用的工作正是由應用管理器（ApplicationManager）完成的。
ApplicationMaster
每當 Client 送出一個 Application 時候，就會建立一個 ApplicationMaster 。由這個 ApplicationMaster 去與 ResourceManager 申請容器資源，獲得資源後會将要運作的程式發送到容器上啟動，然後進行分布式計算。
這裡可能有些難以了解，為什麼是把運作程式發送到容器上去運作？如果以傳統的思路來看，是程式運作着不動，然後資料進進出出不停流轉。但當資料量大的時候就沒法這麼玩了，因為海量資料移動成本太大，時間太長。但是中國有一句老話山不過來，我就過去。大資料分布式計算就是這種思想，既然大資料難以移動，那我就把容易移動的應用程式釋出到各個節點進行計算呗，這就是大資料分布式計算的思路。
NodeManager
NodeManager 是 ResourceManager 在每台機器的上代理，負責容器的管理，并監控他們的資源使用情況（cpu，記憶體，磁盤及網絡等），以及向 ResourceManager/Scheduler 提供這些資源使用報告。
三. 送出一個 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 登出并釋放容器資源。
以上就是一個作業的大體運作流程。
為什麼會有 Yarn ？
上面說了這麼多，最後我們來聊聊為什麼會有 Yarn 吧。
直接的原因呢，就是因為 Hadoop1.0 中架構的缺陷，在 MapReduce 中，jobTracker 擔負起了太多的責任了，接收任務是它，資源排程是它，監控 TaskTracker 運作情況還是它。這樣實作的好處是比較簡單，但相對的，就容易出現一些問題，比如常見的單點故障問題。
要解決這些問題，隻能将 jobTracker 進行拆分，将其中部分功能拆解出來。彼時業内已經有了一部分的資源管理架構，比如 mesos，于是照着這個思路，就開發出了 Yarn。這裡多說個冷知識，其實 Spark 早期是為了推廣 mesos 而産生的，這也是它名字的由來，不過後來反正是 Spark 火起來了。。。
閑話不多說，其實 Hadoop 能有今天這個地位，Yarn 可以說是功不可沒。因為有了 Yarn ，更多計算架構可以接入到 Hdfs 中，而不單單是 MapReduce，到現在我們都知道，MapReduce 早已經被 Spark 等計算架構趕超，而 Hdfs 卻依然屹立不倒。究其原因，正式因為 Yarn 的包容，使得其他計算架構能專注于計算性能的提升。Hdfs 可能不是最優秀的大資料存儲系統，但卻是應用最廣泛的大資料存儲系統，Yarn 功不可沒。