本節書摘來自華章計算機《深入了解hadoop（原書第2版）》一書中的第2章，第2.4節，作者 [美]薩米爾·瓦德卡（sameer wadkar），馬杜·西德林埃（madhu siddalingaiah），傑森·文納（jason venner），譯 于博，馮傲風，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
mapreduce已經進行了全新更新，即hadoop 2.0，更新後的版本經常被稱為mapreduce 2.0（mr v2）或者yarn。本書中常常提到其版本号2.x，雖然發行版本小數點後面的數字有變化，但是系統架構或者其運作方式并不會發生根本的變化。
mr v2是一套應用程式設計接口（api），該接口相容mr v1，根據mr v1接口編寫的程式僅需重新編譯即可。hadoop 2.x系統的底層架構已經完全改變了，hadoop 1.x中的作業排程器承擔兩個主要功能：
資源管理（resource management）
作業排程/作業監控（job scheduling/job monitoring）
yarn把這兩個功能分為兩個守護程序來分别承擔。這樣的設計使得系統有一個全局的資料總管以及每個程式有一個應用程式管理器（application master）。注意，我們這裡提到了程式（application），而不是作業（job）。在新的hadoop 2.x系統中，一個程式（application）既可以指傳統概念上的一個單獨的mapreduce作業，也可以指一系列作業組成的有向無環圖（directed acyclic graph，dag）。dag是一個由許多節點相連構成的圖，圖中沒有循環。也就是說，無論使用什麼樣的方法來周遊這張圖，你都不可能遇到已經在周遊過程中經過的節點。用簡單明了的話說就是，多個作業組成了有向無環圖就意味着這些作業之間存在着層屬關系（hierarchical relationship）。
yarn還使得hadoop的功用不僅僅局限于mapreduce。在後續章節中，我們會發現mapreduce架構存在着諸多局限。新的架構已經開始突破這些局限。舉個例子，apache hive給hadoop系統帶來了sql特性，apache pig可以讓使用者使用基于腳本的資料流方式在hadoop系統中處理資料。像hama這樣的新架構使得hadoop系統更加适合疊代計算，這在機器學習這樣的應用場景中非常有用。
來自berkley的spark/shark架構是hive 和 hama的結合，提供了低延時的sql通路和一些記憶體計算能力。這些架構都是運作在hdfs之上的，hadoop系統不能僅僅隻支援其中的某一種。對架構重新設計是非常必需的，以使得基于海量資料批處理計算架構（不僅限于mapreduce模型），基于hama的資料整體同步并行計算（bsp）架構或者基于shark/spark的記憶體緩存和計算架構都能運作在統一的hadoop系統之上。
經過重新設計的新架構可以使得整個hadoop系統對其提供一緻的原生支援。這會使得關于安全和資源管理的系統級政策能以一緻的方式應用，所有系統都共享相同的底層hdfs。
yarn系統由以下幾個組成部分：
全局資料總管（global resource manager）
節點管理器（node manager）
針對每種應用程式的應用程式管理器（application-specific application master）
排程器（scheduler）
容器（container）
一部分cpu核心和一部分記憶體構成了一個容器。一個應用程式（application）運作在一組容器中。應用程式管理器的一個執行個體會向全局資料總管請求擷取資源。排程器會通過每個節點的節點管理器（node manager）來配置設定資源（容器）。節點管理器會向全局資料總管彙報每個容器的使用情況。
全局資料總管和每個節點的節點管理器構成了新mapreduce架構的管理系統。全局資料總管全權負責系統資源的配置設定。每種應用程式都有一個應用程式管理器。（比如，mapreduce是一種應用程式，每個mapreduce作業是mapreduce類型程式的一個執行個體，就像面向對象程式設計中的類和對象之間的關系一樣）。針對同一應用程式類型的所有應用程式，一個應用程式管理器執行個體被初始化。應用程式管理器執行個體（instance）向全局資料總管協商獲得容器來運作作業。全局資料總管利用排程器（全局元件）與每個節點的節點管理器的溝通結果來配置設定資源。從系統角度來看，應用程式管理器也是運作在一個容器之中的。
yarn全局架構如圖2-6所示。
為了確定對已經存在的mapreduce程式的向後相容，對mapreduce v1架構進行了重用，并沒有做任何重大的修改。
我們來更詳細地講解yarn中的每個元件。從整體上來說，我們在一群商用伺服器上搭建了hadoop叢集，每台伺服器稱為一個節點。
容器（container）是yarn架構中的計算單元。它是一個任務進行工作的單元子系統。也可以這麼認為，yarn架構中的容器相當于mapreduce v1中的一個任務（task）執行器。叢集節點與容器之間的關系是：一個節點可以運作多個容器，但一個容器隻能運作在一個節點之内。
一個容器就是已配置設定的一組系統資源。目前支援兩種類型的系統資源：
中央處理器核心（cpu core）
記憶體（機關為mb）
擁有系統資源的容器在某一節點上執行，是以一個容器中隐含了“資源名稱”的概念，這個“資源名稱”就是容器所在的機架和節點的名稱。請求一個容器的時候，就會向一個節點送出請求。容器使得程式可以在某個節點上獲得指定數量的cpu核心和一定數量的記憶體。
實際上，任何任務或者程式（單個任務或者多個任務組成的有向無環圖）都運作在一個或者多個容器中。在yarn架構中全權負責配置設定容器的元件叫做節點管理器。
節點管理器（node manager）運作在叢集中的一個節點上，叢集中每個節點都會運作一個自己的節點管理器。它是作為一個從屬服務（slave service）：它接受來自另外一個稱為資料總管的元件的請求，然後配置設定容器給應用程式。它還負責監控和彙報資源使用情況給資料總管。在hadoop叢集中，節點管理器與資料總管一起協同工作，負責管理配置設定hadoop系統資源。資料總管是一個hadoop叢集的全局元件，節點管理器作為各個節點的代理來負責管理叢集中每個節點的健康情況。節點管理器的任務如下：
接受來自資料總管的請求，為作業的執行配置設定容器。
與資料總管交換資訊，確定整個叢集的穩定運作。資料總管依靠各個節點管理器的彙報來跟蹤整個叢集的健康狀況，節點管理器作為代理任務來監控和管理本節點的健康狀況。
管理每個已啟動的容器的整個生命周期。
每個節點的日志管理。
運作各種yarn應用程式使用的輔助服務（auxiliary service）。舉個例子，在目前的hadoop系統實作中，mapreduce程式中的shuffle服務就是一個輔助服務。
當一個節點啟動，它會向資料總管注冊，并且告訴資料總管有多少資源（最終可配置設定給容器使用的資源）可用。在節點運作期間，節點管理器和資料總管會協同工作，不停地更新系統資源狀态，保證叢集資源有效地、優化地利用。
節點管理器僅對抽象出來的容器進行管理，而對單個應用程式或者應用程式類型的情況一無所知。負責管理這部分内容的是一個被稱為應用程式管理器（application master）的元件。在我們介紹應用程式管理器之前，先簡單介紹一下資料總管。
資料總管的核心是一個排程器：當多個應用程式競争使用叢集資源的時候，它來負責資源的配置設定排程，確定叢集資源的優化合理使用。資料總管有一個插件化的排程器，該排程器按照程式隊列和叢集的處理能力，負責為正在運作的多個應用程式配置設定其所需的叢集資源。hadoop自帶了計算能力排程器和公平排程器，在後面的章節中我們會詳細地介紹這兩種排程器。
一個任務的啟動、配置及其資源的監控都由計算節點上的節點管理器（node manager）來負責。這種職責的分離使得資料總管相比傳統的作業排程器（jobscheduler）具備更好的系統擴充性。
應用程式管理器（application master）是老的mapreduce v1 架構和yarn之間的關鍵差別之處。應用程式管理器是一個特定的架構函數庫（framework-specific library）執行個體。它同資料總管協調溝通資源，并通過節點管理器來擷取這些系統資源，然後執行任務。應用程式管理器就是與資料總管溝通以擷取擁有系統資源的容器的元件。
應用程式管理器為yarn架構主要帶來了以下好處：
提高了可擴充性。
架構更加通用。
在mapreduce v1中，負責處理任務失敗的責任由作業跟蹤器承擔。作業跟蹤器還要負責給要執行的任務配置設定系統資源。資料總管（作業跟蹤器的替代者）現在僅僅負責系統資源的調配，使得mapreduce v1系統架構的可擴充性獲得了提升。管理作業或應用程式的工作就交給了應用程式管理器。如果一個任務失敗了，應用程式管理器會同資料總管協調溝通以擷取系統資源，并嘗試着重新執行該任務。
在mapreduce v1中，hadoop系統架構僅僅支援mapreduce類型的作業，是以它并不是一個通用的架構。其主要原因就是因為系統中比如作業跟蹤器和任務跟蹤器這樣的關鍵元件，它們的設計開發過于局限于map和reduce概念。随着mapreduce使用的越來越廣泛，人們發現某些類型的資料計算是不适用mapreduce架構的。由此新架構被開發出來，比如基于apache hama和apache giraph的bsp架構。這些新架構适合圖計算，在hdfs系統上運作得很好。本書成稿之際，像shark/spark這樣的記憶體架構越來越引起人們的注意。雖然它們在hdfs上運作得很好，但是卻無法運作在hadoop 1.x之中，因為他們對計算架構的設計思路完全不同。
在hadoop 2.x中把應用程式管理器作為yarn的一部分引入進來，改變了這一切。使用不同的應用程式管理器來管理基于不同設計思想的計算架構，使得多種計算架構可以共存于一個統一的管理系統之中。在hadoop 1.x中，hadoop/hama/shark雖然運作于相同的hdfs系統，但是隻能分别運作在不同的管理系統之中，這樣就造成了系統不一緻和系統資源沖突，現在他們可以運作在同一個hadoop2.x系統之中了。它們都通過資料總管來公平地申請使用系統資源。yarn使得hadoop系統的使用變得更加廣泛。hadoop系統現在不僅支援mapreduce類型的計算，它變得更加插件化：如果系統要增加某種類型的計算架構，就開發一個對應的應用程式管理器，并把這個程式管理器以插件的形式整合到hadoop系統之中。應用程式管理器的概念使得hadoop系統突破了mapreduce的限制，使得mapreduce可以與其他類型的計算架構共存并互相協作。
當一個使用者向hadoop2.x架構送出了一份作業，yarn架構背景處理該請求（如圖2-7所示）。
步驟如下：
1）一個用戶端送出作業程式。該應用程式的類型确定了，就決定了使用何種應用程式管理器。
2）資料總管協調資源，在一個節點上擷取一個用于運作應用程式管理器執行個體的容器。
3）應用程式管理器在資料總管中注冊。注冊之後，用戶端就可以向資料總管查詢該應用程式管理器的詳細資訊了。用戶端将會與應用程式管理器通信，應用程式管理器已經通過自己的資料總管啟動了。
4）在這個操作過程中，應用程式管理器通過資源請求與資料總管協商資源。除了其他内容，一個資源請求包括被請求的容器所在的節點和該容器的詳細說明（cpu核數量和記憶體大小）。
5）在啟動的容器中運作的應用程式會通過該應用程式特定的協定向應用程式管理器彙報它的執行進度（有可能是遠端的）。
6）通過應用程式特定的協定，用戶端與應用程式管理器通信。用戶端通過查詢在步驟3中注冊的資料總管的資訊就可以找到對應的應用程式管理器。
上面的步驟如圖2-8所示：
當應用程式執行完畢，應用程式管理器就會從資料總管中取消注冊，作業占用的容器将會被釋放回系統中。