yarn

YARN的基本思想是將JobTracker的兩個主要功能（資源管理和作業調度/監控）分離，主要方法是創建一個全局的ResourceManager（RM）和若干個針對應用程序的ApplicationMaster（AM）。這裡的應用程序是指傳統的MapReduce作業或作業的DAG（有向無環圖）。

YARN分層結構的本質是ResourceManager。這個實體控制整個集群並管理應用程序向基礎計算資源的分配。ResourceManager將各個資源部分（計算、內存、帶寬等）精心安排給基礎NodeManager（YARN的每節點代理）。ResourceManager還與ApplicationMaster一起分配資源，與NodeManager一起啟動和監視它們的基礎應用程序。在此上下文中，ApplicationMaster承擔了以前的TaskTracker的一些角色，ResourceManager承擔了JobTracker的角色。

ApplicationMaster管理一個在YARN內運行的應用程序的每個實例。ApplicationMaster負責協調來自ResourceManager的資源，並通過NodeManager監視容器的執行和資源使用（CPU、內存等的資源分配）。請注意，儘管目前的資源更加傳統（CPU核心、內存），但未來會帶來基於手頭任務的新資源類型（比如圖形處理單元或專用處理設備）。從YARN角度講，ApplicationMaster是用戶代碼，因此存在潛在的安全問題。YARN假設ApplicationMaster存在錯誤或者甚至是惡意的，因此將它們當作無特權的代碼對待。

NodeManager管理一個YARN集群中的每個節點。NodeManager提供針對集群中每個節點的服務，從監督對一個容器的終生管理到監視資源和跟蹤節點健康。MRv1通過插槽管理Map和Reduce任務的執行，而NodeManager管理抽象容器，這些容器代表著可供一個特定應用程序使用的針對每個節點的資源。YARN繼續使用HDFS層。它的主要NameNode用於元數據服務，而DataNode用於分散在一個集群中的複製存儲服務。

要使用一個YARN集群，首先需要來自包含一個應用程序的客戶的請求。ResourceManager協商一個容器的必要資源，啟動一個ApplicationMaster來表示已提交的應用程序。通過使用一個資源請求協議，ApplicationMaster協商每個節點上供應用程序使用的資源容器。執行應用程序時，ApplicationMaster監視容器直到完成。當應用程序完成時，ApplicationMaster從ResourceManager註銷其容器，執行周期就完成了。

MapReduce的第一個版本既有優點也有缺點。MRv1是目前使用的標準的大數據處理系統。但是，這種架構存在不足，主要表現在大型集群上。當集群包含的節點超過4,000個時（其中每個節點可能是多核的），就會表現出一定的不可預測性。其中一個最大的問題是級聯故障，由於要嘗試複製數據和重載活動的節點，所以一個故障會通過網路泛洪形式導致整個集群嚴重惡化。

但MRv1的最大問題是多租戶。隨著集群規模的增加，一種可取的方式是為這些集群採用各種不同的模型。MRv1的節點專用於Hadoop，所以可以改變它們的用途以用於其他應用程序和工作負載。當大數據和Hadoop成為雲部署中一個更重要的使用模型時，這種能力也會增強，因為它允許在伺服器上對Hadoop進行物理化，而無需虛擬化且不會增加管理、計算和輸入/輸出開銷。

大大減小了JobTracker（也就是現在的ResourceManager）的資源消耗，並且讓監測每一個Job子任務(tasks)狀態的程序分散式化了，更安全、更優美。

在新的Yarn中，ApplicationMaster是一個可變更的部分，用戶可以對不同的編程模型寫自己的AppMst，讓更多類型的編程模型能夠跑在Hadoop集群中，可以參考hadoopYarn官方配置模板中的mapred-site.xml配置。

對於資源的表示以內存為單位(在目前版本的Yarn中，沒有考慮cpu的佔用)，比之前以剩餘slot數目更合理。

老的框架中，JobTracker一個很大的負擔就是監控job下的tasks的運行狀況，現在，這個部分就扔給ApplicationMaster做了，而ResourceManager中有一個模塊叫做ApplicationsMasters(注意不是ApplicationMaster)，它是監測ApplicationMaster的運行狀況，如果出問題，會將其在其他機器上重啟。

Container是Yarn為了將來作資源隔離而提出的一個框架。這一點應該借鑒了Mesos的工作，目前是一個框架，僅僅提供java虛擬機內存的隔離,hadoop團隊的設計思路應該後續能支持更多的資源調度和控制，既然資源表示成內存量，那就沒有了之前的mapslot/reduceslot分開造成集群資源閑置的尷尬情況。

將JobTracker和TaskTracker進行分離，它由下面幾大構成組件：

a.一個全局的資源管理器ResourceManager

b.ResourceManager的每個節點代理NodeManager

c.表示每個應用的ApplicationMaster

d.每一個ApplicationMaster擁有多個Container在NodeManager上運行

ResourceManager（RM）：RM是一個全局的資源管理器，負責整個系統的資源管理和分配。它主要由兩個組件構成：調度器（Scheduler）和應用程序管理器（ApplicationsManager，ASM）。

調度器調度器根據容量、隊列等限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個正在運行的應用程序。需要注意的是，該調度器是一個“純調度器”，它不再從事任何與具體應用程序相關的工作，比如不負責監控或者跟蹤應用的執行狀態等，也不負責重新啟動因應用執行失敗或者硬體故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念“資源容器”（ResourceContainer，簡稱Container）表示，Container是一個動態資源分配單位，它將內存、CPU、磁碟、網路等資源封裝在一起，從而限定每個任務使用的資源量。此外，該調度器是一個可插拔的組件，用戶可根據自己的需要設計新的調度器，YARN提供了多種直接可用的調度器，比如FairScheduler和CapacityScheduler等。

應用程序管理器負責管理整個系統中所有應用程序，包括應用程序提交、與調度器協商資源以啟動ApplicationMaster、監控ApplicationMaster運行狀態並在失敗時重新啟動它等。

ApplicationMaster（AM）：用戶提交的每個應用程序均包含一個AM，主要功能包括：

與RM調度器協商以獲取資源（用Container表示）；

將得到的任務進一步分配給內部的任務(資源的二次分配)；

與NM通信以啟動/停止任務；

徠監控所有任務運行狀態，並在任務運行失敗時重新為任務申請資源以重啟任務。

當前YARN自帶了兩個AM實現，一個是用於演示AM編寫方法的實常式序distributedshell，它可以申請一定數目的Container以并行運行一個Shell命令或者Shell腳本；另一個是運行MapReduce應用程序的AM—MRAppMaster。

註：RM只負責監控AM，在AM運行失敗時候啟動它，RM並不負責AM內部任務的容錯，這由AM來完成。

NodeManager（NM）：NM是每個節點上的資源和任務管理器，一方面，它會定時地向RM彙報本節點上的資源使用情況和各個Container的運行狀態；另一方面，它接收並處理來自AM的Container啟動/停止等各種請求。

Container：Container是YARN中的資源抽象，它封裝了某個節點上的多維度資源，如內存、CPU、磁碟、網路等，當AM向RM申請資源時，RM為AM返回的資源便是用Container表示。YARN會為每個任務分配一個Container，且該任務只能使用該Container中描述的資源。

註：1.Container不同於MRv1中的slot，它是一個動態資源劃分單位，是根據應用程序的需求動態生成的。

2.現在YARN僅支持CPU和內存兩種資源，且使用了輕量級資源隔離機制Cgroups進行資源隔離。

YARN的資源管理和執行框架都是按主/從範例實現的——Slave---節點管理器（NM）運行、監控每個節點，並向集群的Master---資源管理器(RM)報告資源的可用性狀態，資源管理器最終為系統里所有應用分配資源。

特定應用的執行由ApplicationMaster控制，ApplicationMaster負責將一個應用分割成多個任務，並和資源管理器協調執行所需的資源，資源一旦分配好，ApplicationMaster就和節點管理器一起安排、執行、監控獨立的應用任務。

需要說明的是，YARN不同服務組件的通信方式採用了事件驅動的非同步併發機制，這樣可以簡化系統的設計。

集中式調度器(MonolithicScheduler)的特點是，資源的調度和應用程序的管理功能全部放到一個進程中完成，開源界典型的代表是MRv1JobTracker的實現。這樣設計的缺點很明顯，擴展性差：首先，集群規模受限；其次，新的調度策略難以融入到現有代碼中，比如之前僅支持MapReduce作業，現在要支持流式作業，而將流式作業的調度策略嵌入到中央調度其中是一項很難的工作。

為了克服集中式調度器的不足，雙層調度器是一種很容易被想到的解決之道，它可看作是一種分而治之的機制或者是策略下放機制：雙層調度器仍保留一個經簡化的集中式資源調度器，但具體任務相關的調度策略則下放到各個應用程序調度器完成。這種調度器的典型代表是Mesos。Mesos調度器由兩部分組成，分別是資源調度器和框架(應用程序)調度器，其中，資源調度器負責將集群中的資源分配給各個框架(應用程序),而框架(應用程序)調度器負責將資源進一步分配給內部的各個任務，用戶很容易將一種框架或者系統接入Mesos.

雙層調度器的特點是：各個框架調度器並不知道整個集群資源使用情況，只是被動地接受資源；資源調度器僅將可用的資源推送給各個框架，而由框架自己選擇是使用還是拒絕這些資源；一旦框架接受到新資源，再進一步將資源分配給其內部的任務，進而實現雙層調度。然而這種調度器也是有缺點，主要表現在以下兩個方面:1.各個框架無法知道整個集群的實時資源使用情況；採用悲觀鎖，併發粒度小。