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 註銷其容器，執行週期就完成了。 ^[1] 

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

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

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

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

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

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

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

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

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

b.ResourceManager的每個節點代理 NodeManager

c. 表示每個應用的 ApplicationMaster

d. 每一個ApplicationMaster擁有多個Container在NodeManager上運行 ^[2] 

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

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

應用程序管理器負責管理整個系統中所有應用程序，包括應用程序提交、與調度器協商資源以啓動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不同服務組件的通信方式採用了事件驅動的異步併發機制，這樣可以簡化系統的設計。

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

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

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