大數據技術棧速覽之：YARN

在Hadoop 2.0及後續版本中，MapReduce的調度部分被外部化並重新編寫爲名爲Yarn的新組件，但Yarn執行調度與Hadoop上運行的任務類型無關，Yarn可在Hadoop上執行除MapReduce以外的工作。

YARN生產背景

MapReduce1.x存在的問題:

​ 1.JobTracker單點故障&節點壓力大不易擴展&不支持mapreduce以外的計算框架（spark,storm)

​ 在MapReduce1.x下的架構：MapReduce：Master/Slave架構，1個JobTracker帶多個 TaskTracker

​ JobTracker：負責資源管理和作業調度，承受的訪問壓力大，影響系統擴展

​ TaskTracker:定期向JT彙報本節點的健康狀況、資源使用情況、作業執行情況

​ 接收來自JT的命令：啓動任務/殺死任務

​ 單點故障：整個集羣中只有一個JobTracker如果JT掛掉了全部TT都完蛋了

​ 2.資源利用率&運維成本

​ 由於在MapReduce1.x的架構加只能跑MapReduce，不支持MapReduce之外的計算框架，比如Storm,spark,flink，所以想要用其他的計算框架就必須在搭建支持其他計算框架的集羣。
 

所以由上面的圖產生了共享集羣的意願，同時催生了YARN：不同的計算框架可以共享同一個HDFS集羣上的數據。

YARN是一個資源管理系統，負責資源管理和調度
MapReduce只是運行在YARN上的一個應用程序
如果把YARN看作android，則mapreduce只是一個app
mapreduce1.0是一個獨立系統，直接運行在linux上
mapreduce2.0則是運行在YARN上的框架，且可以與多種框架一起運行在YARN上

YARN核心思想：
將MapReduce1中的JobTracker的資源管理和作業調度兩個功能分開，分別由
ResourceManager和ApplicationMaster進程來實現
ResourceManager：負責整個集羣的資源管理和調度
ApplicationMaster：負責應用程序相關的事務，比如任務調度，任務監控和容錯等

Yarn與MapReduce的關係

MapReduce是一個功能強大的分佈式框架和編程模型，允許在多節點集羣上執行基於批處理的並行化工作。儘管MapReduce功能強大，但它也有一些缺點，比如不適合實時甚至近實時的數據處理。但是，Yarn可以彌補MapReduce的不足，其核心是分佈式調度程序，負責兩項工作：

• 響應客戶端創建容器的請求——容器本質上可理解爲一個進程（也有人理解爲服務程序），其中包含允許使用的物理資源。

• 監視正在運行的容器，並在需要時終止。如果YARN調度程序想要釋放資源以便其他應用程序的容器運行，或者容器使用的資源多於其分配的資源，則可以選擇終止容器。

工作機制概述

Client向RM提交應用程序，應用程序提交到RM後，AM註冊到RM上，RM計算所需資源並向RM提出申請，RM返給AM資源信息，AM向NM發起啓動container的請求，container啓動後，NM將啓動成功和啓動失敗的container列表發送給AM，由AM重新向RM申請資源，期間AM和NM定期的向RM發送心跳。

1、連接運行器平臺
根據mapreduce.framework.name變量配置
如果等於yarn：則創建YARNRunner對象
如果等於Local：則創建LocalJobRunner對象

2、如果是yarn平臺，對resoucemanager提交作業審請
3、resourcemanager返回一個jobid和數據保存目錄（hdfs://xxx/staging/xxx）
4、客戶端根據返回數據保存目錄路徑，將job.split、job.xml、jar文件提交到hdfs://xxx/staging/xxx目錄
5、提交數據資源之後，客戶端對resouremanager提交任務運行
6、resourcemanager將任務存儲任務隊列
7、resourcemanager發送命令nodemanager處理從任務取出的任務
8、nodemanager往resourcemanageer審請我要創建一個app master
a、在nodemanager創建一個container，再啓動app master
9、app master讀取數據切片處理方案
10、app master往resourcemanager審請運行資源
11、resourcemanager往空閒的nodemanager主機發送指令，要創建Container
12、app master往nodemanger發送運行指令，container運行任務。

如下圖

YARN架構

YARN的出現可以使得多個計算框架運行在一個集羣當中,每個應用程序對應一個ApplicatonMaster
目前可以支持多種計算框架運行在YARN上，比如MapReduce，Strom，Spark，Flink

Yarn主要由ResourceManager、NodeManager、ApplicationMaster和Container等組件構成。Yarn框架執行主要功能，即在集羣中調度資源（上文提到的容器）。集羣中的應用程序與YARN框架通信，要求分配特定於應用程序的容器資源，Yarn框架會評估這些請求並嘗試實現。Yarn調度的一個重要部分是監視當前正在執行的容器，一旦容器完成，調度程序就可以釋放容量來安排其他工作。此外，每個容器都有一個協議，指定允許使用的系統資源，並在容器超出邊界的情況下終止容器，以避免惡意影響其他應用程序。

Yarn框架有意設計的儘可能簡單，它不知道或不關心正在運行的應用程序類型，不保留有關集羣上執行內容的任何歷史信息，這些設計是Yarn可以擴展到MapReduce之外的主要原因。

• ResourceManager——Hadoop集羣具有至少一個ResourceManager（RM）。

RM作爲一個獨立的守護進程運行在專有機器上，RM擁有集羣上所有資源的信息，是集羣所有資源的仲裁者，只負責給應用進行資源的劃分和資源的收回。這裏的資源主要指：內存，帶寬，內核數等。ResourceManager是Yarn的主進程，其唯一功能是仲裁Hadoop集羣上的資源，響應客戶端創建容器請求，調度程序根據特定的多租戶規則確定何人可以在何時何地創建容器，正如Hadoop 1.0版本，ResourceManager調度程序是可選擇的，這意味着你可以選擇最適合的調度程序，而實際創建的容器被委託給NodeManager。

整個集羣同一時間提供服務的RM只有一個，負責集羣資源的統一管理和調度

​ 處理客戶端的請求：提交一個作業、殺死一個作業

​ 監控我們的NM，一旦某個NM掛了，那麼該NM上運行的任務需要告訴我們的AM來如何處理

      RM是Master，仲裁集羣中所有的可用資源，從而幫助管理運行在yarn平臺上的分佈式應用程序，他和下面的組件一起工作：

    每個節點的NM。從RM中獲取指令，管理單個節點上的可用資源，並接收AM的資源請求。

    每個應用程序的AM，職責是向RM申請資源並且和NM一起工作、啓動、監控和停止Container。

• NodeManager——NodeManager是在集羣每個節點上運行的從屬進程。

NM是yarn在每個計算節點上的代理，他根據yarn應用程序的要求，使用每個節點上的物理資源來運行Container。NM本質上是YARN的工作守護進程。主要職責是：

保持與RM的同步

跟蹤節點的健康狀態

管理Container的生命週期，監控每個Container的資源使用情況（如內存，CPU等）

管理分佈式緩存（對container所需的JAR，庫等文件的本地文件系統緩存）

管理各個Container的日誌

不同的YARN應用可能需要的輔助服務

其中Container的管理是NodeManager的核心功能。NodeManager接受來自ApplicationMaster對Container啓動或者停止請求,對Container令牌進行鑑權(一種確保應用程序可以適當使用ResourceManager給定資源的安全機制),管理 Container執行依賴的庫,監控 Container的執行過程。管理員通過配置文件( yarn-default. xml或yarm- site.xml)來配置每個 NodeManager的資源,包括節點上的內存、CPU及其他可用資源。在向 ResourceManager成功註冊之後, NodeManager通過週期性的心跳彙報自己的狀態並接收 ResourceManager可能發來的指令。

在YARN中,包括 ApplicationMaster在內的所有 Container都通過 Container launch

Context(CLC)來描述。CLC包括環境變量,依賴的庫(可能存在遠程存儲中),下載庫文件以及 Container自身運行需要的安全令牌,用於 NodeManager輔助服務的 Container專用的載荷,以及啓動進程所需的命令。在驗證啓動 Container請求的有效性後, NodeManager會爲Container配置環境,從而使管理員指定的設置生效。

在真正拉起一個 Container之前, NodeManager會將所有需要的庫文件下載到本地,包括數據文件,可執行文件、 tarball、JAR文件,shel腳本等。這些下載好的庫文件可以通過本地應用級別緩存被同一應用的多個 Container共享,通過本地用戶級別緩存被相同用戶啓動的多個 Container共享,甚至通過公用緩存的方式被多個用戶共享,其共享方式是通過CLC來指定的。 NodeManager最終會回收不再被任何 Container使用的庫文件NodeManager也可能按照 ResourceManager的指令去殺死 Container。 Container可能在以下情況下被殺死：

• ResourceManager發送應用程序已經完成的信號
• 調度器作出要爲其他應用程序或者用戶搶佔該 Container的決策
• NodeMananger監控到這個 Container超出了 ContainerToken中指定的資源限制

Container退出時, Node Manager就會清理掉它的本地工作目錄。當應用程序完成時,其對應的 Container所有的資源都會被清理掉。

除了 Container的啓動和停止,完成 Container的清理,以及對本地資源的管理Node Manager還爲運行在本節點上的 Container提供了其他本地服務,例如:當應用程序 束時,日誌聚集服務可以將應用程序的 Container生成的日誌以及對 stdout和 stderr重定向的文件上傳到一個文件系統如 ResourceManager那一節所述,當有 NodeManager失敗時(這可能由很多原因引), ResourceManager通過超時機制監控到這種失敗,並將該失敗報告給所有運行中的應用程序。如果引發超時的故障或原因是瞬時的, NodeManager會與 ResourceManager重新同步,清理它的本地狀態,然後繼續服務。同樣的,當一個新的 NodeManager加入到集羣 ResourceManager會將這個用於運行 Container的新資源通知所有的 ApplicationMastser.

NM管理集羣中獨立的計算節點。

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

它的主要工作是創建、監視和殺死容器。它爲來自ResourceManager和ApplicationMaster的請求提供服務以創建容器，並向ResourceManager報告容器的狀態。ResourceManager使用這些狀態消息中包含的數據對請求做出調度決策。在非HA模式下，只存在ResourceManager單個實例。

整個集羣中有多個，負責自己本身節點資源管理和使用

​ 定時向RM彙報本節點的資源使用情況

​ 接受並處理來自RM的各種命令：啓動Container

​ 處理來自AM的命令

​ 單個節點的資源管理是由它自己管理，通過心跳機制告訴RM

• ApplicationMaster:AM

每個應用程序AM都是一個引導進程，一但應用程序的提交通過了，且自身加載完成，應用程序在RM中的代表將申請一個Container來啓動此引導程序，如果RM分配了Container，AM的啓動器將直接與NM進行通訊，以設置並啓動該container，AM的生命週期就開始了。與hadoop1中的架構相比，本質上AM是一個應用程序的JobTracker。

這個過程以應用程序提交一個請求到 ResourceManager開始。接着, ApplicationMaster啓動,向 ResourceManager註冊。 ApplicationMaster向 ResourceManager請求 Container執行實際的工作。將分配的 Container告知 NodeManager以便 ApplicationMaster使用。計算過程在 Container 中進行,這些 Container將與 Application Master(不是 ResourceManager)保持通信,並告知任務過程。當應用程序完成後, Container被停止, ApplicationMaster從 ResourceManager中註銷

一旦成功啓動, Application Master將負責以下任務：

• 初始化向 ResourceManager報告自己活躍信息的進程
• 計算應用程序的資源需求
• 將需求轉換成YARN調度器可以理解的 ReqsourceReques
• 與調度器協商申請資源
• 與 NodeManager合作使用分配的 Container
• 跟蹤正在運行的 Container的狀態,監控它們的進程
• 對 Container或節點失敗的情況進行處理,在必要的情況下重新申請資源

ApplicationMaster管理一個在YARN內運行的應用程序的每個實例，每個應用程序對應唯一一個AM。 負責管理作業的生命週期，包括動態的增加和減少資源使用，管理作業執行流程，處理故障和計算偏差，以及執行其本地優化。

​ 每個應用程序對應一個：MR、Spark,負責應用程序的管理

​ 爲應用程序向RM申請資源（core、memory），分配給內部task

​ 需要與NM進行通信：啓動/停止task的運行，task試運行在container裏面，AM也是運行在Container裏面

• Container

Container是YARN中的資源抽象，是單個節點上內存，CPU，磁盤，網絡等物理資源的集合，是一個任務運行環境的抽象。一個節點可以有一個或者多個container，當AM向RM申請資源時，RM爲AM返回的資源便是用Container表示的。其中AM可以看做是一種特殊的Container。

container由NM監控，RM調度。​

Application Master從 ResourceManager獲得 Container後,它就可以進行 Container的實際啓動工作。啓動 Container前,它首先根據需要構造 ContainerLaunchContext對象,該對象包括分配資源的大小、安全令牌(如果已啓用)、啓動 Container的執行命令、進程環境、必要的二進制文件/AR包/共享對象等。它可以通過與 NodeManager通信,逐一啓動Container,也可以批量運行單個節點上的所有Container,向 NodeManager在單個調用裏提供一系列Start ContainerRequest來啓動它們。

NodeManager通過 Start ContainerResponse迴應:該回應包含成功啓動的 Container列表、每個失敗的 Start ontainerRequest對應的 Container ID到異常的映射(記錄了每個 Container的異常)、 allServices Data映射(從附加服務的名字到它們相應的元數據)。

ApplicationMaster能獲取已經提交但未啓動的 Container以及已經啓動的 Container的更新狀態。

ApplicationMaster可以向 Node Manager發送 Stop ContainersRequest請求,停止在該節點上運行的一系列 Container,該請求包含待停止的 Container ID。 NodeManager通過Stop ContainersResponse迴應,它包含成功停止的 Container的列表以及每個失敗的請求中Container id到異常的映射(異常信息表示了每個特定 Container的錯誤)。當 ApplicationMaster退出時, ResourceManager將根據它提交的上下文殺死所有正在運行而沒有被 ApplicatMaster顯示終止的 Container

如上文所述,當 Container結束時, ResourceManager將以事件的形式通知 Application Master

ResourceManager並不解釋(也不關心) Container的狀態,只有 ApplicationMaster才能決定ResourceManager報告的 Container的退出狀態成功或失敗的含義。

處理 Container失敗是應用程序/框架的責任。YARN只負責爲應用程序/框架提供信息。

ResourceManager收集所有已完成的 Container的信息,把它們作爲 API allocate的迴應信息部分返回給相應的 Application. ApplicationMaster負責查看如下信息: Container的狀態、退出碼和診斷信息,並恰當地處理它。例如,當 MapReduce Application Master知道Container失敗時,它向 ResouceManager請求新的 Container,重新運行Map或 Reduce任務直到達到爲單個任務配置的最大的嘗試次數。

 

• Client

​ 提交作業

​ 查詢作業的運行進度

​ 殺死作業

小結：

Application Master需要在由於它自身原因重啓後恢復應用程序。當 Application Master失敗時, ResourceManager簡單地通過重新啓動一個新的 ApplicationMaster(更確切地說是運行 ApplicationMaster的 Container)來重啓應用程序(新的 ApplicationMaster將啓動新的Application Attempt,恢復應用程序的先前的狀態是新 Application.的責任。這個目標可以通過以下方法實現:前 ApplicationAttempt將當前狀態持久化到外部存儲供後面的ApplicationAttempt使用顯然 ApplicationMaster也可以從頭開始運行應用程序,而不是恢復其過去的狀態。例如,如本書所述不 Hadoop MapReduce框架的 Application Master會恢復已完成的任務,但會殺死正在運行的任務以及在 Application Master恢復時完成的任務,然後重新運行它們。

YARN的資源模型

在早期的 Hadoop版本中,集羣中的每個節點被靜態的分配好預先定義的Map槽位和Reduce槽位數,槽位不能在Map和 Reduce之間共享。槽位的這種靜態分配不是最優的,因爲對槽位的需求會在MapReduce應用程序的生命週期中變化。通常情況下,在作業剛啓動時,有Map槽位的需求,相對的,在作業快結束時,主要是 Reduce槽位的需求。

YARN的資源分配模型通過提供了更大的靈活性,解決了靜態分配的低效率問題。如先前所述,使用 Container的方式來請求資源,每個 Container都有一些非靜態屬性,YARN目前已經支持內存和CPU的動態屬性,還可以支持如帶寬和GPU等。在未來的資源管理模型中,每個屬性定義一個最小和最大值, ApplicationManager可以請求最小值整數倍的資源container。在應用運行的過程中，AM可以對資源進行增加或者回收，達到動態調整資源的目的。

5.1、客戶端資源請求

第一步：客戶發送一個即將要提交程序的請求

第二步：RM在應答中給出一個ApplicationID,以及有助於客戶端請求資源的就請你容量信息

5.2、Container分配

接下來,客戶端在第3步中使用“ Application Submission Context”發出響應, Application

Submission上下文中包含了 ApplicationID、用戶名、隊列以及其他啓動 Application Master所

需求(內存CPU)、作業文件、安全令牌以及在節點上啓動 Application Master 需要的其他信息。應用程序被提交之後,客戶端也可以向 ResourceManager請求殺死這個應用程序,或者提供該應用程序的狀態報告

當ResourceManager收到來自客戶端的應用程序提交上下文,它就會爲ApplicationMaster調度一個可用 Container,這個 Container通常稱爲“ Container0”",因爲它是ApplicationMaster,必須請求其他的 Container。如果沒有適用的 Container,這個請求必須等待。如果找到了合適的 Container, ResourceManager就會聯繫相應的 NodeManager並啓動 ApplicationMaster(圖第4步)。作爲此步驟的一部分,將建立 ApplicationMaster的RPC端口和用於跟蹤的URL,用來監控應用程序的狀態。

在註冊請求的響應中, ResourceManager會發送關於集羣的最小和最大容量信息(第5步)。在這一點上, ApplicationMaster須決定如何使用當前可用的資源。與一些客戶端請求硬限制的資源調度系統不同,YARN允許應用程序適應當前的集羣環境(如果可能的話)。基於來自 ResourceManager的可用資源報告, ApplicationMaster會請求一定量的Container(圖第6步)。該請求可以非常具體,包括最小資源整數倍的 Container(例如,額外的內存)。 ResourceManager會基於調度策略,儘可能最優的Application Master分配Container資源,作爲資源請求的應答發給 Application Master(圖第7步)。

隨着作業的執行, ApplicationMaster將心跳和進度信息通過心跳發給 ResourceManager。在這些心跳中, ApplicationMaster還可以請求和釋放 Container，當作業結束時, Application Master向 ResourceManager發出一個 Finish消息,然後退出。

5.4、ApplicationMaster與Container管理器的通信

在這一點上, ResourceManager已經將分配 NodeManager的控制權移交給ApplicationMaster

，AM將獨立聯繫其指定的節點管理器並提供 Container launch Context(CLC),CLC包括環境變量、遠程存儲依賴文件、安全令牌以及啓動實際進程所需的命令。當 Container啓動時,所有的數據文件,可執行文件以及必要的依賴文件都被拷貝到節點的本地存儲上了。依賴文件可以被運行中的應用程序的 Container之間共享。一旦所有的 Container都被啓動, ApplicationMaster就可以檢查它們的狀態， RM不參與應用程序的執行,只處理調度和監控其他資源。 RM可以命令NM殺死Container，在AM通知RM自己完成了,或者ResourceManager需要爲另一個應用程序搶佔資源,或者 Container超出資源限制時都可能發生殺死 Container事件。當 Container被殺死後, NodeManager會清理它的本地工作目錄。作業結束後, ApplicationMaster通知 ResourceManager該作業成功完成,然後ResourceManager通知 NodeManager聚集日誌並且清理 Container專用的文件。如果 Container還沒有退出NodeManager也可以接受指令去殺死剩餘的 Container(包括 ApplicationMaster)。

5.5、管理應用程序的依賴文件

在YARN中,應用程序通過運行 Container來執行它們的工作,這些 Container對應於運行在底層操作系統上的進程。 Container上有執行程序依賴的文件,這些文件在啓動時或者應用程序的執行過程中可能需要一次或者多次。例如,要在 Container中啓動一個簡單的Java進程,我們需要一組類文件或更多依賴的JAR文件。YARN沒有強迫每個應用程序每次都遠程訪問(大部分是讀)這些文件或者讓它們自己管理這些文件,而是爲應用程序提供了本地化這些文件的能力。

當啓動一個 Container時, Application Master可以指定該 Container需要的所有文件,因此,這些文件都應該被本地化。一且指定了這些文件,YARN就會負責本地化,並且隱藏所有安全拷貝、管理以及後續的刪除等引入的複雜性。

 

YARN執行流程

Yarn應用程序具備在Hadoop上運行的特定功能，MapReduce是YARN應用程序的一個示例，Hoya等項目允許多個HBase實例在單個集羣上運行，而Storm-yarn允許Storm在Hadoop集羣內運行。

                                        YARN應用程序典型交互

Yarn應用程序涉及三大組件 - 客戶端，ApplicationMaster（AM）和容器，如圖2.3所示。啓動新的Yarn應用程序需從Yarn客戶端開始，該客戶端與ResourceManager通信以創建新的Yarn ApplicationMaster實例，此過程Yarn客戶端會讓ResourceManager通知ApplicationMaster物理資源要求。

ApplicationMaster是Yarn應用程序主進程，不執行任何特定於應用程序的工作，因爲這些函數被委託給容器。但是，它負責管理特定於應用程序的容器：詢問ResourceManager其創建容器的意圖，然後與NodeManager聯繫以實際執行容器創建。作爲此過程的一部分，ApplicationMaster必須根據主機啓動容器，並確定容器的內存和CPU要求以指定容器所需資源。

ResourceManager根據資源要求安排工作，它使主機能夠運行混合容器，如圖2.4所示。ApplicationMaster負責應用程序的特定容錯，在容器失敗時從ResourceManager接收狀態消息，並基於具體事件採取操作（通過要求ResourceManager創建新容器解決）或忽略這些事件。

容器是由NodeManager代表ApplicationMaster創建的特定於應用程序的進程。ApplicationManager本身也是一個由ResourceManager創建的容器。由ApplicationManager創建的容器可以是任意進程——例如，容器進程可以是簡單的Linux命令，例如awk，Python應用程序或可由操作系統啓動的任何進程，這也是YARN強大功能的體現——可以在Hadoop集羣的任何節點啓動和管理任何進程。

Yarn配置

Yarn爲各組件帶來了強大的配置，例如UI、遠程進程調用（RPC）等。在選擇之前，你需要弄清楚想要訪問的正在運行的Hadoop集羣配置，你可以使用ResourceManager UI查看相關配置。

該功能的亮點在於UI不僅可以顯示屬性值，還可以顯示文件來源。如果未在<component> site.xml文件中定義該值，則將顯示默認值和文件名。該UI的另一功能是可顯示來自多個文件的配置，包括HDFS、Yarn和MapReduce等文件，可以從NodeManager UI以相同的方式導航到單個Hadoop從屬節點的配置。在使用由異構節點組成的Hadoop集羣時，這一功能非常有用，因爲這些集羣通常會有不同的配置來滿足不同的硬件資源。

Yarn開箱即用

Hadoop 2捆綁了兩個Yarn應用程序——MapReduce 2和DistributedShell。如果你不清楚集羣配置，則有兩個辦法可以解決：

1. 檢查yarn-site.xml的內容以查看屬性值。如果不存在自定義值，則默認值將生效。

2. 使用ResourceManager UI，它提供了有關運行配置的詳細信息，包括默認值以及是否生效。

如果希望在Hadoop集羣節點上運行Linux命令，可以使用與Hadoop捆綁在一起的DistributedShell示例應用程序。該應用程序也是在Hadoop集羣中並行運行命令的便捷實用程序。

更多實戰觀摩:http://blog.itpub.net/31077337/viewspace-2213602/

YARN 系統架構

ResourceManager
負責集羣中所有資源的統一管理和分配，它接受來自各個節點的NodeManager的資源彙報信息，並把這些信息按照一定的策略分配給各個應用程序，是整個YARN集羣中最重要的組件之一，他的設計直接決定了系統的可擴展性，可用性和容錯性，它的功能較多，包括ApplicationMaster管理，NodeManager管理，Application管理，狀態機管理等

主要有以下幾個功能：
1.與客戶端交互，處理來自客戶端的請求
2.啓動和管理ApplicationMaster，
並且在它失敗時重新啓動它
3.管理NodeManager，接受來自NodeManager的資源彙報信息，下達管理指令
4.資源管理和調度，接受來自ApplicationMaster的資源申請請求並向讓NodeManager爲之分配資源

 

Nodemanager
是運行在單個節點上的代理，管理hadoop集羣中單個計算節點，他需要與相應用程序的ApplicationMaster和集羣管理者ResourceManager交互
1.從ApplicationMaster上接收有關Contioner的命令並執行
2.向ResourceManager彙報各個container運行狀態和節點健康狀況，並領取有關的Container的命令並執行

ApplicationMaster
與應用程序相關的組件
1.負責數據切分，把每份數據分配給對應的Map Task
2.爲應用程序申請資源並進一步分配給內部的任務。比如從ResourceManager獲取分配的資源，然後分配給Task任務
3.任務的監控與容錯。一旦一個任務掛掉之後，他可以重新向ResourceManager申請資源

Container
Container是YARN中的資源抽象，它封裝了某個節點上的多維度資源，如內存，CPU，磁盤，網絡等。當AM向RM申請資源時，RM爲AM返回的資源便是用Container表示的。
YARN會爲每個任務分配一個Container，且該任務只能使用該Container中描述的資源。需要注意的是，Container不同於MR（mapreduce）v1中的slot（也是資源分配單位），他是一個動態資源劃分單位，是根據應用程序的需求動態生成的

MapReduce on YARN

運行在YARN上的應用程序分爲兩類：短應用程序和長應用程序
短應用程序：是指在一定時間內可以運行完成並正常退出的應用程序，不如MapReduce作業 離線計算
長應用程序：是指不出意外，永不停止的應用程序，通常是一些服務
比如Storm Service（主要包括Nimbus和Supervisor兩類服務）、HBase Service（包括Hmaste：和RegionServer兩類服務）等，而他們本身作爲一個框架提供了編程接口供用戶使用 spark 實時計算
當用戶向YARN中提交一個應用程序後，YARN將分爲兩個階段運行該應用程序：
第一個階段是啓動ApplicationMaster
第二個階段是由ApplicationMater創建應用程序，，爲它申請資源，並監控它的整個運行過程，直到運行完成

YARN中內存和CPU兩種資源的調度和隔離（轉載自董的博客）

YARN同時支持內存和CPU兩種資源的調度（默認只支持內存，如果想進一步調度CPU，需要自己進行一些配置）

【YARN中內存資源的調度和隔離】

基於以上考慮，YARN允許用戶配置每個節點上可用的物理內存資源，注意，這裏是“可用的”，因爲一個節點上的內存會被若干個服務共享，比如一部分給YARN，一部分給HDFS，一部分給HBase等，YARN配置的只是自己可以使用的，配置參數如下：

（1）yarn.nodemanager.resource.memory-mb

表示該節點上YARN可使用的物理內存總量，默認是8192（MB），注意，如果你的節點內存資源不夠8GB，則需要調減小這個值，而YARN不會智能的探測節點的物理內存總量。

（2）yarn.nodemanager.vmem-pmem-ratio

任務每使用1MB物理內存，最多可使用虛擬內存量，默認是2.1。

（3） yarn.nodemanager.pmem-check-enabled

是否啓動一個線程檢查每個任務正使用的物理內存量，如果任務超出分配值，則直接將其殺掉，默認是true。

（4） yarn.nodemanager.vmem-check-enabled

是否啓動一個線程檢查每個任務正使用的虛擬內存量，如果任務超出分配值，則直接將其殺掉，默認是true。

（5）yarn.scheduler.minimum-allocation-mb

單個任務可申請的最少物理內存量，默認是1024（MB），如果一個任務申請的物理內存量少於該值，則該對應的值改爲這個數。

（6）yarn.scheduler.maximum-allocation-mb

單個任務可申請的最多物理內存量，默認是8192（MB）。

默認情況下，YARN採用了線程監控的方法判斷任務是否超量使用內存，一旦發現超量，則直接將其殺死。由於Cgroups對內存的控制缺乏靈活性（即任務任何時刻不能超過內存上限，如果超過，則直接將其殺死或者報OOM），而Java進程在創建瞬間內存將翻倍，之後驟降到正常值，這種情況下，採用線程監控的方式更加靈活（當發現進程樹內存瞬間翻倍超過設定值時，可認爲是正常現象，不會將任務殺死），因此YARN未提供Cgroups內存隔離機制。

【YARN中CPU資源的調度和隔離】

在YARN中，CPU資源的組織方式仍在探索中，目前（2.2.0版本）只是一個初步的，非常粗粒度的實現方式，更細粒度的CPU劃分方式已經提出來了，正在完善和實現中。

目前的CPU被劃分成虛擬CPU（CPU virtual Core），這裏的虛擬CPU是YARN自己引入的概念，初衷是，考慮到不同節點的CPU性能可能不同，每個CPU具有的計算能力也是不一樣的，比如某個物理CPU的計算能力可能是另外一個物理CPU的2倍，這時候，你可以通過爲第一個物理CPU多配置幾個虛擬CPU彌補這種差異。用戶提交作業時，可以指定每個任務需要的虛擬CPU個數。在YARN中，CPU相關配置參數如下：

（1）yarn.nodemanager.resource.cpu-vcores

表示該節點上YARN可使用的虛擬CPU個數，默認是8，注意，目前推薦將該值設值爲與物理CPU核數數目相同。如果你的節點CPU核數不夠8個，則需要調減小這個值，而YARN不會智能的探測節點的物理CPU總數。

（2） yarn.scheduler.minimum-allocation-vcores

單個任務可申請的最小虛擬CPU個數，默認是1，如果一個任務申請的CPU個數少於該數，則該對應的值改爲這個數。

（3）yarn.scheduler.maximum-allocation-vcores

單個任務可申請的最多虛擬CPU個數，默認是32。

默認情況下，YARN是不會對CPU資源進行調度的，你需要配置相應的資源調度器讓你支持，具體可參考我的這兩篇文章：

（1）Hadoop YARN配置參數剖析（4）—Fair Scheduler相關參數

（2）Hadoop YARN配置參數剖析（5）—Capacity Scheduler相關參數

默認情況下，NodeManager不會對CPU資源進行任何隔離，你可以通過啓用Cgroups讓你支持CPU隔離。

由於CPU資源的獨特性，目前這種CPU分配方式仍然是粗粒度的。舉個例子，很多任務可能是IO密集型的，消耗的CPU資源非常少，如果此時你爲它分配一個CPU，則是一種嚴重浪費，你完全可以讓他與其他幾個任務公用一個CPU，也就是說，我們需要支持更粒度的CPU表達方式。

借鑑亞馬遜EC2中CPU資源的劃分方式，即提出了CPU最小單位爲EC2 Compute Unit（ECU），一個ECU代表相當於1.0-1.2 GHz 2007 Opteron or 2007 Xeon處理器的處理能力。YARN提出了CPU最小單位YARN Compute Unit（YCU），目前這個數是一個整數，默認是720，由參數yarn.nodemanager.resource.cpu-ycus-per-core設置，表示一個CPU core具備的計算能力（該feature在2.2.0版本中並不存在，可能增加到2.3.0版本中），這樣，用戶提交作業時，直接指定需要的YCU即可，比如指定值爲360，表示用1/2個CPU core，實際表現爲，只使用一個CPU core的1/2計算時間。注意，在操作系統層，CPU資源是按照時間片分配的，你可以說，一個進程使用1/3的CPU時間片，或者1/5的時間片。對於CPU資源劃分和調度的探討，可參考以下幾個鏈接：

https://issues.apache.org/jira/browse/YARN-1089

https://issues.apache.org/jira/browse/YARN-1024

Hadoop 新特性、改進、優化和Bug分析系列5：YARN-3

【總結】

目前，YARN 內存資源調度借鑑了Hadoop 1.0中的方式，比較合理，但CPU資源的調度方式仍在不斷改進中，目前只是一個初步的粗糙實現，相信在不久的將來，YARN 中CPU資源的調度將更加完善。

 

附：

yarn的搭建（參考：https://www.cnblogs.com/yuanyifei1/p/8474196.html）：

yarn是hadoop的一個子項目，在yarn上面搭建spark集羣需要配置好hadoop和spark。 yarn的包是包含在hadoop裏面的。

解壓hadoop壓縮包，配置環境變量,修改配置文件，node格式化……等後，直接啓動就ok了。

sbin/start-dfs.sh              #啓動dfs
sbin/start-yarn.sh              #啓動yarn

啓動成功後可以使用jps命令查看各個節點上是否啓動了對應進程。