（1） YARN

下一代MapReduce框架的名稱，為了容易記憶，一般稱為MRv2（MapReduce version 2）。該框架已經不再是一個傳統的MapReduce框架，甚至與MapReduce無關，她是一個通用的運行時框架，用戶可以編寫自己的計算框架，在該運行環境中運行。用于自己編寫的框架作為客戶端的一個lib，在運用提交作業時打包即可。該框架為提供了以下幾個組件：

<1> 資源管理：包括應用程序管理和機器資源管理

<2> 資源雙層調度

<3> 容錯性：各個組件均有考慮容錯性

<4> 擴展性：可擴展到上萬個節點

2） ResourceManager

簡稱“RM”。

MRv2最基本的設計思想是將JobTracker的兩個主要功能，即資源管理和作業調度/監控分成兩個獨立的進程。在該解決方案中包含兩個組件：全局的ResourceManager（RM）和與每個應用相關的ApplicationMaster（AM）。這里的“應用”指一個單獨的MapReduce作業或者DAG作業。RM和與NodeManager（NM，每個節點一個）共同組成整個數據計算框架。RM是系統中將資源分配給各個應用的最終決策者。AM實際上是一個具體的框架庫，它的任務是【與RM協商獲取應用所需資源】和【與NM合作，以完成執行和監控task的任務】。

RM有兩個組件組成：

調度器（Scheduler）

應用管理器（ApplicationsManager，ASM）

調度器根據容量，隊列等限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個正在運行的應用。這里的調度器是一個“純調度器”，因為它不再負責監控或者跟蹤應用的執行狀態等，此外，他也不負責重新啟動因應用執行失敗或者硬件故障而產生的失敗任務。調度器僅根據各個應用的資源需求進行調度，這是通過抽象概念“資源容器”完成的，資源容器（Resource Container）將內存，CPU，磁盤，網絡等資源封裝在一起，從而限定每個任務使用的資源量。

調度器內嵌有策略可插拔的插件，主要負責將集群中得資源分配給多個隊列和應用。當前MapReduce的調度器，如Capacity Scheduler和Fair Scheduler，均可作為該插件。

（3）NodeManager

簡稱“NM”。

NM是每個節點上的框架代理，主要負責啟動應用所需的容器，監控資源（內存，CPU，磁盤，網絡等）的使用情況并將之匯報給調度器。

一句話：“NM主要用于管理某個節點上的task和資源”。

（4）ApplicationsManager

簡稱“ASM”。

ASM主要負責接收作業，協商獲取第一個容器用于執行AM和提供重啟失敗AM container的服務。

一句話：“ASM主要用于管理AM”。

（5）ApplicationMaster

簡稱“AM”。

AM主要負責同調度器協商以獲取合適的容器，并跟蹤這些容器的狀態和監控其進度。

一句話：“AM主要用于管理其對應的應用程序，如MapReduce作業，DAG作業等”。

（6） Container

容器中封裝了機器資源，如內存，CPU, 磁盤，網絡等，每個任務會被分配一個容器，該任務只能在該容器中執行，并使用該容器封裝的資源。

怎樣將某個計算框架（MapReduce，HAMA，Giraph）部署到YARN中？

答：需要編寫一個ApplicaionMaster。

MRv2最基本的設計思想是將JobTracker的兩個主要功能，即資源管理和作業調度/監控分成兩個獨立的進程。在該解決方案中包含兩個組件：全局的ResourceManager（RM）和與每個應用相關的ApplicationMaster（AM）。這里的“應用”指一個單獨的MapReduce作業或者DAG作業。RM和與NodeManager（NM，每個節點一個）共同組成整個數據計算框架。RM是系統中將資源分配給各個應用的最終決策者。AM實際上是一個具體的框架庫，它的任務是【與RM協商獲取應用所需資源】和【與NM合作，以完成執行和監控task的任務】。

RM有兩個組件組成：

調度器（Scheduler）

應用管理器（ApplicationsManager，ASM）

調度器根據容量，隊列等限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個正在運行的應用。這里的調度器是一個“純調度器”，因為它不再負責監控或者跟蹤應用的執行狀態等，此外，他也不負責重新啟動因應用執行失敗或者硬件故障而產生的失敗任務。調度器僅根據各個應用的資源需求進行調度，這是通過抽象概念“資源容器”完成的，資源容器（Resource Container）將內存，CPU，磁盤，網絡等資源封裝在一起，從而限定每個任務使用的資源量。（注：Hadoop-0.23.0【資料一， 資料二】中的Container采用了“監控linux進程”來限制每個任務的資源，即：有個監控線程周期性地從linux虛擬文件系統/proc/中讀取相應進程樹使用的資源總量，一旦檢測到超出限制，則直接kill該task，今后的版本想嚴格限制內存，CPU，網絡，磁盤等資源。

調度器是可插拔的組件，主要負責將集群中得資源分配給多個隊列和應用。YARN自帶了多個資源調度器，如Capacity Scheduler和Fair Scheduler等。

ASM主要負責接收作業，協商獲取第一個容器用于執行AM和提供重啟失敗AM container的服務。

NM是每個節點上的框架代理，主要負責啟動應用所需的容器，監控資源（內存，CPU，磁盤，網絡等）的使用情況并將之匯報給調度器。

AM主要負責同調度器協商以獲取合適的容器，并跟蹤這些容器的狀態和監控其進度。

【Resource Manager】資源模型在YARN 1.0中，調度器僅考慮了內存資源。 每個節點由多個固定內存大小（512MB或者1GB）的容器組成。AM可以申請該內存整數倍大小的容器。YARN最終會提供一個更加通用的資源模型，但在Yarn V1中，僅提供了一個相當直接的模型：“資源模型完全是基于內存的，且每個節點由若干個離散的內存塊（chunk of memory）組成”。與Hadoop MapReduce不同，MRv2并沒有人為的將集群資源分成map slot和reduce slot。MRv2中的每個內存塊是可互換的，這就提高了集群利用率—當前Hadoop MapReduce的一個最大問題是由于缺乏資源互換，作業會在reduce slot上存在瓶頸。（“互換”的意思是資源是對等的，所有資源形成一個資源池，任務可以從資源池中申請任意的資源，這就提高了資源利用率）對上一端進一步解釋：在當前Hadoop MapReduce中，集群資源會被切分成map slot和reduce slot。在每個TaskTracker上，管理員可配置若干個map slot和reduce slot，slot可看做是令牌，map task拿到一個map slot后才可以運行（對于reduce task類似）。而管理員一般只根據CPU個數配置slot個數時，如果CPU個數為12，則可配置8個map slot，4個reduce slot。這會導致兩個問題：（1）實際的計算資源不僅僅是CPU，還有內存，磁盤和網絡等，這些均需要考慮，只考慮某一種資源勢必會造成機器擁塞，這在共享集群環境下表現尤為顯著；（2）MapReduce計算流程是兩階段的，而這兩個階段存在依賴性：reduce task不會進入sort和reduce階段，直到全部map task計算完成，而實際計算時，map task完成一定的比例，便會啟動reduce task，此時啟動的reduce task全部處于shuffle階段，經常會走走停停，導致該map slot資源利用率非常低。在Yarn中，任何一個應用可申請任何內存大小合理（合理是指內存大小必須是memory chunck的整數倍）的容器，也可以申請各種類型的容器。資源協商每個AM使用資源描述來申請一系列容器，其中可能包括一些特殊需求的機器。它也可以申請同一個機器上的多個容器。所有的資源請求是受應用程序容量，隊列容量等限制的。AM負責計算應用程序所需的資源量，比如MapReduce的input-splits，并把他們轉化成調度器可以理解的協議。當前調度器可理解的協議是。以MapReduce為例，MapReduce AM分析input-splis，并將之轉化成以host為key的轉置表發送給RM。下圖為一個典型的AM資源請求：調度器會盡量匹配該表中的資源；如果某個特定機器上的資源是不可用的，調度器會提供同一個機架或者不同機架上的等量資源代替之。有些情況下，由于整個集群非常忙碌，AM獲取的資源可能不是最合適的，此時它可以拒絕這些資源并請求重新分配。調度調度器收集所有正在運行的應用程序的資源請求并構建一個全局規劃進行資源分配。調度器會根據應用程序相關的約束（如合適的機器）和全局約束（如隊列資源總量，用戶可提交作業總數等）分配資源。調度器使用與容量調度類似的概念，采用容量保證作為基本的策略在多個應用程序間分配資源。調度器的調度策略如下：選擇系統中“服務最低”的隊列（如何定義服務最低？可以是資源利用量最低的隊列，即：已使用的資源與總共可用資源比值最小）從該隊列中選擇優先級最高的作業盡量滿足該作業的資源請求調度器APIYarn 調度器與AM之間僅有一個API：Response allocate (Listask, Listrelease)

AM使用一個ResourceRequest列表請求特定資源，并同時可要求釋放一些調度器已經分配的容器。

Response包含三方面內容：新分配的容器列表，自從上次AM與RM交互以來已經計算完成的容器的狀態（包含該容器中運行task的詳細信息），當前集群中剩余資源量。 AM收集完成容器的信息并對失敗的任務作出反應。資源剩余量可用于AM調整接下來的資源請求，如MapReduce AM可使用該信息以合理調度maps和reduces從而防止產生死鎖。（何以“死鎖”？在MapReduce框架中，如果將所有資源分配給了map task，則可能會造成reduce? task饑餓，需要合理調整map資源和reduce 資源的比例）

資源監控

調度器周期性地收到NM所在節點的資源變化信息，同時，調度器會將已使用完的容器分配重新分給合適的AM。

AM的生命周期

ASM負責管理系統中所有應用程序的AM，正如上一節所述，ASM負責啟動AM，監控AM的運行狀態，在AM失敗時對其進行重啟等。

為了完成該功能，ASM主要有以下幾個組件：

（1） SchedulerNegotiator：與調度器協商容器資源，并返回給AM

（2）AMContainerManager：告知NM，啟動或者停止某個AM的容器

（3）? AMMonitor：查看AM是否活著，并在必要的時候重啟AM

【NodeManager】

每個節點上裝有一個NM，主要的職責有：

（1）為應用程序啟動容器，同時確保申請的容器使用的資源不會超過節點上的總資源。

（2）為task構建容器環境，包括二進制可執行文件，jars等

（3）為所在的節點提供了一個管理本地存儲資源的簡單服務，應用程序可以繼續使用本地存儲資源即使他沒有從RM那申請。比如：MapReduce可以使用該服務程序存儲map task的中間輸出結果。

【ApplicationMaster】

每個應用程序均會有一個AM，主要職責有：

（1）? 與調度器協商資源

（2）? 與NM合作，在合適的容器中運行對應的task，并監控這些task執行

（3） 如果container出現故障，AM會重新向調度器申請資源

（4）? 計算應用程序所需的資源量，并轉化成調度器可識別的格式（協議）

（5）? AM出現故障后，ASM會重啟它，而由AM自己從之前保存的應用程序執行狀態中恢復應用程序。

注：在MapReduce中，由于AM會定時的保存job的運行時狀態，因此，當AM重啟時可以恢復對應的job，按照粒度有三種策略：

<1>整個作業重新計算

<2> 保存已經完成的map task和reduce task，只重新計算未完成的task

YARN的資源管理器實際上是一個事件處理器，它需要處理來自外部的6種SchedulerEvent類型的事件，并根據事件的具體含義進行相應的處理。這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個事件中最重要的事件，它會觸發資源調度器最核心的資源分配機制。

YARN對內存資源和CPU資源采用了不同的資源隔離方案。對于內存資源，為了能夠更靈活的控制內存使用量，YARN采用了進程監控的方案控制內存使用，即每個NodeManager會啟動一個額外監控線程監控每個container內存資源使用量，一旦發現它超過約定的資源量，則會將其殺死。采用這種機制的另一個原因是Java中創建子進程采用了fork()+exec()的方案，子進程啟動瞬間，它使用的內存量與父進程一致，從外面看來，一個進程使用內存量可能瞬間翻倍，然后又降下來，采用線程監控的方法可防止這種情況下導致swap操作。對于CPU資源，則采用了Cgroups進行資源隔離。

資源分配模型

在YARN中，用戶以隊列的形式組織，每個用戶可屬于一個或多個隊列，且只能向這些隊列中提交application。每個隊列被劃分了一定比例的資源。

YARN的資源分配過程是異步的，也就是說，資源調度器將資源分配給一個application后，不會立刻push給對應的ApplicaitonMaster，而是暫時放到一個緩沖區中，等待ApplicationMaster通過周期性的RPC函數主動來取，也就是說，采用了pull-based模型，而不是push-based模型，這個與MRv1是一致的。

總結

相比于MRv1中的資源調度器，盡管YANR的調度器也是插拔式的，但由于YARN采用了事件驅動的模型，因此編寫起來更加復雜，難度也遠遠大于MRv1。

同MRv1一樣，YARN也自帶了三種常用的調度器，分別是FIFO，Capacity Scheduler和Fair Scheduler，其中，第一個是默認的調度器，它屬于批處理調度器，而后兩個屬于多租戶調度器，它采用樹形多隊列的形式組織資源，更適合公司應用場景。