Hadoop Yarn框架原理解析

在說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)，咱們分別來看看它們的主要工做。

1. 定時調度器(Scheduler)：從本質上來講，定時調度器就是一種策略，或者說一種算法。當Client提交一個任務的時候，它會根據所須要的資源以及當前集羣的資源情況進行分配。注意，它只負責嚮應用程序分配資源，並不作監控以及應用程序的狀態跟蹤。

2. 應用管理器(ApplicationManager)：一樣，聽名字就能大概知道它是幹嗎的。應用管理器就是負責管理Client用戶提交的應用。上面不是說到定時調度器（Scheduler）不對用戶提交的程序監控嘛，其實啊，監控應用的工做正是由應用管理器（ApplicationManager）完成的。

OK，明白了資源管理器ResourceManager，那麼應用程序如何申請資源，用完如何釋放？這就是ApplicationMaster的責任了。

ApplicationMaster

每當Client（用戶）提交一個Application（應用程序）時候，就會新建一個ApplicationMaster。由這個ApplicationMaster去與ResourceManager申請容器資源，得到資源後會將要運行的程序發送到容器上啓動，而後進行分佈式計算。

這裏可能有些難以理解，爲何是把運行程序發送到容器上去運行？若是以傳統的思路來看，是程序運行着不動，而後數據進進出出不停流轉。但當數據量大的時候就無法這麼玩了，由於海量數據移動成本太大，時間太長。可是中國有一句老話山不過來，我就過去。大數據分佈式計算就是這種思想，既然大數據難以移動，那我就把容易移動的應用程序發佈到各個節點進行計算唄，這就是大數據分佈式計算的思路。

那麼最後，資源有了，應用程序也有了，那麼該怎麼管理應用程序在每一個節點上的計算呢？別急，咱們還有一個NodeManager。

NodeManager

相比起上面兩個組件的掌控全局，NodeManager就顯得比較細微了。NodeManager是ResourceManager在每臺機器的上代理，主要工做是負責容器的管理，並監控他們的資源使用狀況（cpu，內存，磁盤及網絡等），而且它會按期向ResourceManager/Scheduler提供這些資源使用報告，再由ResourceManager決定對節點的資源進行何種操做（分配，回收等）。

三. 提交一個Application到Yarn的流程

這張圖簡單地標明瞭提交一個程序所經歷的流程，接下來咱們來具體說說每一步的過程。

1. Client向Yarn提交Application，這裏咱們假設是一個MapReduce做業。

2. ResourceManager向NodeManager通訊，爲該Application分配第一個容器。並在這個容器中運行這個應用程序對應的ApplicationMaster。

3. ApplicationMaster啓動之後，對做業（也就是Application）進行拆分，拆分task出來，這些task能夠運行在一個或多個容器中。而後向ResourceManager申請要運行程序的容器，並定時向ResourceManager發送心跳。

4. 申請到容器後，ApplicationMaster會去和容器對應的NodeManager通訊，然後將做業分發到對應的NodeManager中的容器去運行，這裏會將拆分後的MapReduce進行分發，對應容器中運行的多是Map任務，也多是Reduce任務。

5. 容器中運行的任務會向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