yarn

Apache Hadoop YARN （Yet Another Resource Negotiator，另一種資源協調者）是一種新的 Hadoop 資源管理器，它是一個通用資源管理系統，可為上層套用提供統一的資源管理和調度，它的引入為集群在利用率、資源統一管理和數據共享等方面帶來了巨大好處。

基本介紹

• 中文名：YARN
• 外文名：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 集群中，可以參考 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上運行

主要架構

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.各個框架無法知道整個集群的實時資源使用情況；採用悲觀鎖，並發粒度小。