Yarn資源調度系統入門

1. yarn介紹

 

Apache Hadoop YARN 是 apache Software Foundation Hadoop的子項目，爲分離Hadoop2.0資源管理和計算組件而引入。YARN的誕生緣於存儲於HDFS的數據需要更多的交互模式，不單單是MapReduce模式。Hadoop2.0 的YARN 架構提供了更多的處理框架，不再強迫使用MapReduce框架。

當企業的數據在HDFS中是可用的，有多種數據處理方式是非常重要的。有了Hadoop2.0和YARN,機構可以採用流處理、互動數據處理方式以及其他的基於Hadoop的應用程序。

2. yarn架構

YARN還是經典的主從（master/slave）結構，如下圖所示。大體上看，YARN服務由一個ResourceManager（RM）和多個NodeManager（NM）構成，ResourceManager爲主節點（master），NodeManager爲從節點（slave）。

ApplicationMaster可以在容器內運行任何類型的任務。例如，MapReduce ApplicationMaster請求容器啓動map或reduce任務，而Giraph ApplicationMaster請求容器運行Giraph任務。

核心組件

組件名	作用
ResourceManager	是Master上一個獨立運行的進程，負責集羣統一的資源管理、調度、分配等等；
ApplicationManager	相當於這個Application的監護人和管理者，負責監控、管理這個Application的所有Attempt在cluster中各個節點上的具體運行，同時負責向Yarn ResourceManager申請資源、返還資源等；
NodeManager	是Slave上一個獨立運行的進程，負責上報節點的狀態(磁盤，內存，cpu等使用信息)；
Container	是yarn中分配資源的一個單位，包涵內存、CPU等等資源，YARN以Container爲單位分配資源；

ResourceManager 負責對各個 NadeManager 上資源進行統一管理和調度。當用戶提交一個應用程序時，需要提供一個用以跟蹤和管理這個程序的 ApplicationMaster，它負責向 ResourceManager 申請資源，並要求 NodeManger 啓動可以佔用一定資源的任務。由於不同的 ApplicationMaster 被分佈到不同的節點上，因此它們之間不會相互影響。

Client 向 ResourceManager 提交的每一個應用程序都必須有一個 ApplicationMaster，它經過 ResourceManager 分配資源後，運行於某一個 Slave 節點的 Container 中，具體做事情的 Task，同樣也運行與某一個 Slave 節點的 Container 中。

2.1 ResourceManager

RM是一個全局的資源管理器，集羣只有一個，負責整個系統的資源管理和分配，包括處理客戶端請求、啓動/監控 ApplicationMaster、監控 NodeManager、資源的分配與調度。它主要由兩個組件構成：調度器（Scheduler）和應用程序管理器（Applications Manager，ASM）。

（1） 調度器

調度器根據容量、隊列等限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個正在運行的應用程序。需要注意的是，該調度器是一個“純調度器”，它從事任何與具體應用程序相關的工作，比如不負責監控或者跟蹤應用的執行狀態等，也不負責重新啓動因應用執行失敗或者硬件故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。

調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念“資源容器”（Resource Container，簡稱Container）表示，Container是一個動態資源分配單位，它將內存、CPU、磁盤、網絡等資源封裝在一起，從而限定每個任務使用的資源量。

（2） 應用程序管理器

應用程序管理器主要負責管理整個系統中所有應用程序，接收job的提交請求，爲應用分配第一個 Container 來運行 ApplicationMaster，包括應用程序提交、與調度器協商資源以啓動 ApplicationMaster、監控 ApplicationMaster 運行狀態並在失敗時重新啓動它等。

2.2 ApplicationMaster

管理 YARN 內運行的一個應用程序的每個實例。關於 job 或應用的管理都是由 ApplicationMaster 進程負責的，Yarn 允許我們以爲自己的應用開發 ApplicationMaster。

功能：

• 數據切分；

• 爲應用程序申請資源並進一步分配給內部任務（TASK）；

• 任務監控與容錯；

• 負責協調來自ResourceManager的資源，並通過NodeManager監視容易的執行和資源使用情況。

可以說，ApplicationMaster 與 ResourceManager 之間的通信是整個 Yarn 應用從提交到運行的最核心部分，是 Yarn 對整個集羣進行動態資源管理的根本步驟，Yarn 的動態性，就是來源於多個Application 的 ApplicationMaster 動態地和 ResourceManager 進行溝通，不斷地申請、釋放、再申請、再釋放資源的過程。

2.3 NodeManager

NodeManager 整個集羣有多個，負責每個節點上的資源和使用。

NodeManager 是一個 slave 服務：它負責接收 ResourceManager 的資源分配請求，分配具體的 Container 給應用。同時，它還負責監控並報告 Container 使用信息給 ResourceManager。通過和ResourceManager 配合，NodeManager 負責整個 Hadoop 集羣中的資源分配工作。

功能：NodeManager 本節點上的資源使用情況和各個 Container 的運行狀態（cpu和內存等資源）

• 接收及處理來自 ResourceManager 的命令請求，分配 Container 給應用的某個任務；

• 定時地向RM彙報以確保整個集羣平穩運行，RM 通過收集每個 NodeManager 的報告信息來追蹤整個集羣健康狀態的，而 NodeManager 負責監控自身的健康狀態；

• 處理來自 ApplicationMaster 的請求；

• 管理着所在節點每個 Container 的生命週期；

• 管理每個節點上的日誌；

• 執行 Yarn 上面應用的一些額外的服務，比如 MapReduce 的 shuffle 過程；

當一個節點啓動時，它會向 ResourceManager 進行註冊並告知 ResourceManager 自己有多少資源可用。在運行期，通過 NodeManager 和 ResourceManager 協同工作，這些信息會不斷被更新並保障整個集羣發揮出最佳狀態。

NodeManager 只負責管理自身的 Container，它並不知道運行在它上面應用的信息。負責管理應用信息的組件是 ApplicationMaster

2.4 Container

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

Container 和集羣節點的關係是：一個節點會運行多個 Container，但一個 Container 不會跨節點。任何一個 job 或 application 必須運行在一個或多個 Container 中，在 Yarn 框架中，ResourceManager 只負責告訴 ApplicationMaster 哪些 Containers 可以用，ApplicationMaster 還需要去找 NodeManager 請求分配具體的 Container。

需要注意的是，Container 是一個動態資源劃分單位，是根據應用程序的需求動態生成的。目前爲止，YARN 僅支持 CPU 和內存兩種資源，且使用了輕量級資源隔離機制 Cgroups 進行資源隔離。

功能：

• 對task環境的抽象；

• 描述一系列信息；

• 任務運行資源的集合（cpu、內存、io等）；

• 任務運行環境

2.5 Resource Request 及 Container

引用連接

Yarn的設計目標就是允許我們的各種應用以共享、安全、多租戶的形式使用整個集羣。並且，爲了保證集羣資源調度和數據訪問的高效性，Yarn還必須能夠感知整個集羣拓撲結構。

爲了實現這些目標，ResourceManager的調度器Scheduler爲應用程序的資源請求定義了一些靈活的協議，通過它就可以對運行在集羣中的各個應用做更好的調度，因此，這就誕生了Resource Request和Container。

一個應用先向ApplicationMaster發送一個滿足自己需求的資源請求，然後ApplicationMaster把這個資源請求以resource-request的形式發送給ResourceManager的Scheduler，Scheduler再在這個原始的resource-request中返回分配到的資源描述Container。

每個ResourceRequest可看做一個可序列化Java對象，包含的字段信息如下：

<!--
- resource-name：資源名稱，現階段指的是資源所在的host和rack，後期可能還會支持虛擬機或者更復雜的網絡結構
- priority：資源的優先級
- resource-requirement：資源的具體需求，現階段指內存和cpu需求的數量
- number-of-containers：滿足需求的Container的集合
-->
<resource-name, priority, resource-requirement, number-of-containers>

2.6 JobHistoryServer

作業歷史服務,記錄在yarn中調度的作業歷史運行情況情況 , 通過mr-jobhistory-daemon.sh start historyserver命令在集羣中的數據節點機器上不需要做任何配置,單獨使用命令啓動直接啓動即可, 啓動成功後會出現JobHistoryServer進程(使用jps命令查看，下面會有介紹) , 並且可以從19888端口進行查看日誌詳細信息

2.6.1 如果我們沒有啓動jobhistoryserver時我們運行一個mapreduce程序在yarn上看到什麼呢？

打開如下圖界面，在下圖中點擊History，頁面會進行一次跳轉

此時我們在三個節點把jobhistoryserver啓動後，在此運行wordcount程序(記得啓動前把輸出目錄刪除掉)

點擊History連接會跳轉一個全新的頁面，在頁面下方會看到TaskType中列舉的map和reduce，Total表示此次運行的mapreduce程序執行所需要的map和reduce的任務數據.

在TaskType列中點擊Map連接

如下圖我們可以看到map任務的相關信息比如執行狀態,啓動時間，完成時間。

可以使用同樣的方式我們查看reduce任務執行的詳細信息，這裏不再贅述.

從以上操作中我們可以看到jobhistoryserver就是進行作業運行過程中歷史運行信息的記錄，方便我們對作業進行分析.

2.7 Timeline Server

用來寫日誌服務數據 , 一般來寫與第三方結合的日誌服務數據(比如spark等),從官網的介紹看，它是對jobhistoryserver功能的有效補充，jobhistoryserver只能對mapreduce類型的作業信息進行記錄，除了jobhistoryserver能夠進行對作業運行過程中信息進行記錄之外還有更細粒度的信息記錄，比如任務在哪個隊列中運行，運行任務時設置的用戶是哪個用戶。

根據官網的解釋jobhistoryserver只能記錄mapreduce應用程序的記錄，timelineserver功能更強大,但不是替代jobhistory兩者是功能間的互補關係.

3. yarn應用運行原理

YARN 是如何工作的？YARN的基本理念是將JobTracker/TaskTracker 兩大職能分割爲以下幾個實體：

1. 一個全局的資源管理ResourceManager

2. 每個應用程序一個ApplicationMaster

3. 每個從節點一個NodeManager

4. 每個應用程序一個運行在NodeManager上的Container

ResouceManager 和 NodeManager 組成了一個新的、通用的、用分佈式管理應用程序的系統。ResourceManager 對系統中的應用程序資源有終極仲裁的權限。ApplicationMaster 是一個特定於框架的實體，它的責任是同ResourceManager 談判資源 ，同時爲NodeManager(s)執行和監控組件任務。RessourceManager 有一個調度器，根據不同的約束條件，例如隊列容量、用戶限制等，將資源進行分配給各類運行着的應用程序。調度器執行調度功能是基於應用程序的資源申請。NodeManager 負責發佈應用程序容器，監控資源的使用並向ResourceManager進行彙報。每個ApplicationMaster都有職責從調度器那談判得到適當的資源容器，追蹤它們的狀態，並監控他們的進程。從系統的視圖看，ApplicationMaster 作爲一個普通的容器運行着。

3.1 yarn應用提交過程

Application在Yarn中的執行過程，整個執行過程可以總結爲三步：

1. 應用程序提交

2. 啓動應用的ApplicationMaster實例

3. ApplicationMaster 實例管理應用程序的執行

具體提交過程爲：

1. 客戶端程序向 ResourceManager 提交應用並請求一個 ApplicationMaster 實例；

2. ResourceManager 找到一個可以運行一個 Container 的 NodeManager，並在這個 Container 中啓動 ApplicationMaster 實例；

3. ApplicationMaster 向 ResourceManager 進行註冊，註冊之後客戶端就可以查詢 ResourceManager 獲得自己 ApplicationMaster 的詳細信息，以後就可以和自己的 ApplicationMaster 直接交互了（這個時候，客戶端主動和 ApplicationMaster 交流，應用先向 ApplicationMaster 發送一個滿足自己需求的資源請求）；

4. 在平常的操作過程中，ApplicationMaster 根據 resource-request協議 向 ResourceManager 發送 resource-request請求；

5. 當 Container 被成功分配後，ApplicationMaster 通過向 NodeManager 發送 container-launch-specification信息 來啓動Container，container-launch-specification信息包含了能夠讓Container 和 ApplicationMaster 交流所需要的資料；

6. 應用程序的代碼以 task 形式在啓動的 Container 中運行，並把運行的進度、狀態等信息通過 application-specific協議 發送給ApplicationMaster；

7. 在應用程序運行期間，提交應用的客戶端主動和 ApplicationMaster 交流獲得應用的運行狀態、進度更新等信息，交流協議也是 application-specific協議；

8. 一旦應用程序執行完成並且所有相關工作也已經完成，ApplicationMaster 向 ResourceManager 取消註冊然後關閉，用到所有的 Container 也歸還給系統。

精簡版： 步驟1：用戶將應用程序提交到 ResourceManager 上； 步驟2：ResourceManager 爲應用程序 ApplicationMaster 申請資源，並與某個 NodeManager 通信啓動第一個 Container，以啓動ApplicationMaster； 步驟3：ApplicationMaster 與 ResourceManager 註冊進行通信，爲內部要執行的任務申請資源，一旦得到資源後，將於 NodeManager 通信，以啓動對應的 Task； 步驟4：所有任務運行完成後，ApplicationMaster 向 ResourceManager 註銷，整個應用程序運行結束。

3.2 mapreduce on yarn

MapReduce基於yarn的工作原理：我們通過提交jar包，進行MapReduce處理，那麼整個運行過程分爲五個環節：　　1、向client端提交MapReduce job.　　2、隨後yarn的ResourceManager進行資源的分配.　　3、由NodeManager進行加載與監控containers.　　4、通過applicationMaster與ResourceManager進行資源的申請及狀態的交互，由NodeManagers進行MapReduce運行時job的管理. 5、通過hdfs進行job配置文件、jar包的各節點分發。

Job 初始化過程　　1、當resourceManager收到了submitApplication()方法的調用通知後，scheduler開始分配container,隨之ResouceManager發送applicationMaster進程，告知每個nodeManager管理器。　　2、由applicationMaster決定如何運行tasks,如果job數據量比較小，applicationMaster便選擇將tasks運行在一個JVM中。那麼如何判別這個job是大是小呢？當一個job的mappers數量小於10個，只有一個reducer或者讀取的文件大小要小於一個HDFS block時，（可通過修改配置項mapreduce.job.ubertask.maxmaps,mapreduce.job.ubertask.maxreduces以及mapreduce.job.ubertask.maxbytes 進行調整)　　3、在運行tasks之前，applicationMaster將會調用setupJob()方法，隨之創建output的輸出路徑(這就能夠解釋，不管你的mapreduce一開始是否報錯，輸出路徑都會創建)Task 任務分配　　1、接下來applicationMaster向ResourceManager請求containers用於執行map與reduce的tasks（step 8),這裏map task的優先級要高於reduce task，當所有的map tasks結束後，隨之進行sort(這裏是shuffle過程後面再說）,最後進行reduce task的開始。(這裏有一點，當map tasks執行了百分之5%的時候，將會請求reduce，具體下面再總結)　　2、運行tasks的是需要消耗內存與CPU資源的，默認情況下，map和reduce的task資源分配爲1024MB與一個核，（可修改運行的最小與最大參數配置,mapreduce.map.memory.mb,mapreduce.reduce.memory.mb,mapreduce.map.cpu.vcores,mapreduce.reduce.reduce.cpu.vcores.)Task 任務執行　　1、這時一個task已經被ResourceManager分配到一個container中，由applicationMaster告知nodemanager啓動container，這個task將會被一個主函數爲YarnChild的java application運行，但在運行task之前，首先定位task需要的jar包、配置文件以及加載在緩存中的文件。　　2、YarnChild運行於一個專屬的JVM中，所以任何一個map或reduce任務出現問題，都不會影響整個nodemanager的crash或者hang。　　3、每個task都可以在相同的JVM task中完成，隨之將完成的處理數據寫入臨時文件中。Mapreduce數據流運行進度與狀態更新　　1、MapReduce是一個較長運行時間的批處理過程，可以是一小時、幾小時甚至幾天，那麼Job的運行狀態監控就非常重要。每個job以及每個task都有一個包含job（running,successfully completed,failed）的狀態，以及value的計數器，狀態信息及描述信息（描述信息一般都是在代碼中加的打印信息），那麼，這些信息是如何與客戶端進行通信的呢？　　2、當一個task開始執行，它將會保持運行記錄，記錄task完成的比例，對於map的任務，將會記錄其運行的百分比，對於reduce來說可能複雜點，但系統依舊會估計reduce的完成比例。當一個map或reduce任務執行時，子進程會持續每三秒鐘與applicationMaster進行交互。Job 完成

3.3 yarn應用生命週期

• RM: Resource Manager

• AM: Application Master

• NM: Node Manager

1. Client向RM提交應用，包括AM程序及啓動AM的命令。

2. RM爲AM分配第一個容器，並與對應的NM通信，令其在容器上啓動應用的AM。

3. AM啓動時向RM註冊，允許Client向RM獲取AM信息然後直接和AM通信。

4. AM通過資源請求協議，爲應用協商容器資源。

5. 如容器分配成功，AM要求NM在容器中啓動應用，應用啓動後可以和AM獨立通信。

6. 應用程序在容器中執行，並向AM彙報。

7. 在應用執行期間，Client和AM通信獲取應用狀態。

8. 應用執行完成，AM向RM註銷並關閉，釋放資源。

   申請資源->啓動appMaster->申請運行任務的container->分發Task->運行Task->Task結束->回收container