了解Yarn的架構之前，先說說為什么會出現Yarn。在Hadoop v1版本中，存在最大的問題就是資源管理和任務管理耦合在一起，且整個集群的擴展性、可靠性(JobTracker的單節點故障問題)很差，以及最重要的一個問題，集群資源的利用率低。
隨着數據規模的膨脹，大家已經不滿足於僅僅能在Hadoop集群上運行MapReduce程序，更希望能夠有一套合理的管理機制來控制整個集群的資源調度，於是Yarn平台應運而生。先來看看Yarn平台的基本架構：
在Yarn的結構中，把原來JobTracker管的事兒(資源管理、任務調度)拆開了，資源調度讓ResourceManager干，任務調度讓 ApplicationMaster管，這樣的好處就是能夠讓各個模塊各司其職，專一干一件事，就好比一個大領導每天如果不專心管理管隊，老跑去敲代碼， 最后這個團隊必然存在問題。言歸正傳，既然要了解Yarn的架構，在這里有必要先解釋一下用戶提交一個任務都走了哪些流程：
知道了各模塊的“位置”后，下面着重對上圖中的各模塊作詳細介紹：
1. ResourceManager
ResourceManager(下文簡稱“RM”)是整個Yarn架構的核心部件，有且僅有一個，它負責整個集群的資源(內存、cpu等)管理，RM主要處理6中事件：
(1) NODE_REMOVED：事件NODE_REMOVED表示集群中被移除一個計算節點（可能是節點故障或者管理員主動移除），資源調度器收到該事件時需要從可分配資源總量中移除相應的資源量。
(2) NODE_ADDED：事件NODE_ADDED表示集群中增加了一個計算節點，資源調度器收到該事件時需要將新增的資源量添加到可分配資源總量中。
(3) APPLICATION_ADDED： 事件APPLICATION_ADDED 表示ResourceManager收到一個新的Application。通常而言，資源管理器需要為每個application維護一個獨立的數據結 構，以便於統一管理和資源分配。資源管理器需將該Application添加到相應的數據結構中。
(4) APPLICATION_REMOVED：事件APPLICATION_REMOVED表示一個Application運行結束（可能成功或者失敗），資源管理器需將該Application從相應的數據結構中清除。
(5) CONTAINER_EXPIRED：當資源調度器將一個container分配給某個ApplicationMaster后，如果該ApplicationMaster在一定時間間隔內沒有使用該container，則資源調度器會對該container進行再分配。
(6) NODE_UPDATE：NodeManager 通過心跳機制向ResourceManager匯報各個container運行情況，會觸發一個NODE_UDDATE事件，由於此時可能有新的 container得到釋放，因此該事件會觸發資源分配，也就是說，該事件是6個事件中最重要的事件，它會觸發資源調度器最核心的資源分配機制。
NodeManager啟動的時候，會向ResourceManager注冊自己的內存、CPU使用率等資源信息，供NodeManager調度。
2. ApplicationMaster
ApplicationMaster 負責管理應用程序的整個生命周期，每個應用程序都對應一個AM，主要功能有：
(1) 與RM的調度器通訊，協商管理資源分配。
(2) 與NM合作，在合適的容器中運行對應的task，並監控這些task執行。
(3) 如果container出現故障，AM會重新向調度器申請資源。
(4) 計算應用程序所需的資源量，並轉化成調度器可識別的協議。
(5) AM出現故障后，ASM會重啟它，而由AM自己從之前保存的應用程序執行狀態中恢復應用程序。
3. NodeManager
NodeManager替代了Hadoop v1版本中的TaskTracker，每個節點都會有一個NM，主要功能有：
(1) 為應用程序啟動容器，同時確保申請的容器使用的資源不會超過節點上的總資源。
(2) 為task構建容器環境，包括二進制可執行文件，jars等。
(3) 為所在的節點提供了一個管理本地存儲資源的簡單服務，應用程序可以繼續使用本地存儲資源即使他沒有從RM那申請。比如：MapReduce可以使用該服務程序存儲map task的中間輸出結果。
一個NodeManager上面可以運行多個Container，Container之間的資源互相隔離，類似於虛擬機的多個系統一樣，各 自使用自己分配的資源。NodeManager會啟動一個監控進行用來對運行在它上面的Container進行監控，當某個Container占用的資源 超過約定的閾值后，NodeManager就會將其殺死。
4. Container
Container可以說是一個對Application使用資源描述的集合(或容器)，可以看做一個可序列化的java對象，封裝了一些描述信息，例如：
message ContainerProto {
optional ContainerIdProto id = 1; //container id
optional NodeIdProto nodeId = 2; //container（資源）所在節點
optional string node_http_address = 3;
optional ResourceProto resource = 4; //container資源量
optional PriorityProto priority = 5; //container優先級
optional hadoop.common.TokenProto container_token = 6; //container token，用於安全認證
}
Container的一些基本概念和工作流程如下：
(1) Container是YARN中資源的抽象，它封裝了某個節點上一定量的資源（CPU和內存兩類資源）。它跟Linux Container沒有任何關系，僅僅是YARN提出的一個概念（從實現上看，可看做一個可序列化/反序列化的Java類）。
(2) Container由ApplicationMaster向ResourceManager申請的，由ResouceManager中的資源調度器異步分配給ApplicationMaster；
(3) Container的運行是由ApplicationMaster向資源所在的NodeManager發起的，Container運行時需提供內部執行的 任務命令（可以使任何命令，比如java、Python、C++進程啟動命令均可）以及該命令執行所需的環境變量和外部資源（比如詞典文件、可執行文件、 jar包等）。
另外，一個應用程序所需的Container分為兩大類，如下：
(1) 運行ApplicationMaster的Container：這是由ResourceManager（向內部的資源調度器）申請和啟動的，用戶提交應用程序時，可指定唯一的ApplicationMaster所需的資源；
(2) 運行各類任務的Container：這是由ApplicationMaster向ResourceManager申請的，並由ApplicationMaster與NodeManager通信以啟動之。
以上兩類Container可能在任意節點上，它們的位置通常而言是隨機的，即ApplicationMaster可能與它管理的任務運行在一個節點上。
5. YARN平台的資源管理方案
在YARN中，用戶以隊列的形式組織，每個用戶可屬於一個或多個隊列，且只能向這些隊列中提交application。每個隊列被划分了一定比例的資源。
YARN的資源分配過程是異步的，也就是說，資源調度器將資源分配給一個application后，不會立刻push給對應的 ApplicaitonMaster，而是暫時放到一個緩沖區中，等待ApplicationMaster通過周期性的RPC函數主動來取，也就是說，采 用了pull-based模型，而不是push-based模型，這個與MRv1是一致的。
相比於MRv1中的資源調度器，盡管YANR的調度器也是插拔式的，但由於YARN采用了事件驅動的模型，因此編寫起來更加復雜，難度也遠遠大於MRv1。
同MRv1一樣，YARN也自帶了三種常用的調度器，分別是FIFO，Capacity Scheduler和Fair Scheduler，其中，第一個是默認的調度器，它屬於批處理調度器，而后兩個屬於多租戶調度器，它采用樹形多隊列的形式組織資源，更適合公司應用場 景。需要注意的是，這三種調度器采用的算法與MRv1中的完全一致，只不過是根據YARN中資源調度器的對外接口重新實現了一遍，在此不再贅述。
轉自開源中國 @Circleblog http://my.oschina.net/circleblog/blog/715683