資源調度系統-Yarn

系列文章：

MapReduce編程模型和計算框架架構原理

分佈式文件系統-HDFS

YARN產生背景

爲何會產生YRAN？這個與MapReduce1.x的架構有關，正是由於MapReduce1.x存在許多的問題，纔會產生 YARN。

MapReduce1.x的架構以下：

MapReduce1.x的架構

Hadoop1.x時，MapReduce的架構仍然是主從架構。一個JobTracker帶多個TaskTracker，主節點爲JobTracker，只有一個，從節點爲TaskTracker，能夠有多個，從節點經過向主節點發送心跳信息（heartbeat）來告訴它本身的運行狀況，而主節點則是負責管理調度的工做。

JobTracker(JT)：負責資源管理和做業調度。

TaskTracker(TT)：按期向JT彙報本節點的健康情況、資源使用狀況、做業執行狀況。接收來自JT的命令，從而啓動任務或殺死任務。

那麼這個架構存在什麼樣的問題呢？

首先是單點故障的問題，全部的從節點(TT)都是跟主節點(JT)直接關聯的，若是主節點不當心掛了，那麼整個系統就崩潰了，就沒有辦法運行了。

其次，JT的壓力大且不易擴展，他要接收全部從節點(TT)的心跳信息(heartbeat)和客戶端的請求，JT承擔的職責特別多，隨着集羣擴展後，那麼JT的壓力就會愈來愈大。

最後，最大的問題就是兼容性問題，它不兼容除了MapReduce外的其餘框架，好比Spark是不能跑在這個系統上的。

而有了YARN以後，基於YARN之上能夠運行不少其餘的計算框架，不一樣計算框架能夠共享同一個HDFS集羣上數據，享受總體的資源調度。它至關於操做系統，起着調度管理的工做。

YARN概述

• YARN的全稱是Yet Another Resource Negotiator。

• 通用的資源管理系統，要申請資源統一通過YARN進行申請就好了。

• 爲上層應用提供統一的資源管理和調度。

YARN的架構以下圖所示：

YARN的架構由這幾個部分構成：

1. ResourceManager（RM）：資源管理器

• 整個集羣同一時間提供服務的RM只有一個，負責集羣資源的統一管理和調度。通常來講RM只有一個，多了的話很差協調容易混亂，可是若是隻有一個的話，若是RM出問題了整個系統就崩潰了，因此生產中儘可能會再加一個做爲備用，這樣就算主RM掛了，備用的RM也能夠繼續工做，可是在同一時間提供服務的只有一個，要麼是主RM，要麼是備用RM。

• 處理客戶端的請求：提交做業、殺死做業。

• 監控NM，一旦某個NM掛了，那麼該NM上運行的任務須要告訴AM來如何進行處理。

2. NodeManager（NM）：節點管理器

• 整個集羣中有多個NM，負責本身自己節點資源管理使用。管理自身節點的資源，好比某一時刻還剩多少資源，NM是能知道的。

• 定時向RM彙報本節點的資源使用狀況，RM只有知道全部NM上的資源使用狀況，才能合理的進行調度。對於一個特定的做業，他才知道該分配到哪一個NM上去。

• 接受並處理來自RM的各類命令，好比啓動Container。NM既然做爲主從結構的從節點，那麼就應該聽老大的話，老大給你分配了任務，讓你去執行你就去執行，讓你別幹了你就別幹了。

• 處理來自AM的命令，AM告訴NM須要在節點上啓動多少container跑task，NM才能運行。

• 單個節點的資源管理，在跑做業的過程當中，對本身節點上資源的使用和剩餘多少資源必需要有數。

3. ApplicationMaster（AM）：應用程序主控程序

• 每一個應用程序對應一個，好比一個Spark或者一個MapReduce做業對應一個AM。負責應用程序的管理，爲應用程序向RM申請資源，好比須要多少內存和計算量。拿到資源後再分配給內部的task進行處理。

• 須要與NM進行通訊，啓動或者中止task，task是運行在container裏面，AM也是運行在container裏面。

4. Container：容器

• 封裝了CPU、Memory等資源的一個容器，至關於一個任務運行環境的抽象。

5. Client：客戶端：

• 提交做業、查看做業的運行進度、殺死做業

關於這個架構我是這麼理解的，能夠將它與企業或者公司的管理進行對比：

Client，很簡單天然就是跟公司合做的客戶。提交一個做業就至關於客戶跟公司一筆生意談成了，客戶提要求，公司負責幫客戶去完成項目，只是這裏沒有金錢交易而已。

RM，至關於公司的管事的boss，權力很大，全部公司的事都要聽他的。咱們對照則RM的做用一條一條來理解，首先，一個公司同一時間只能有一個拍板的，不能你說你的他說他的，最後整個公司也不知道聽誰的，那就完全亂套了。若是某天老闆生病了，那就只能委託一個代理暫時幫他行使管理的責任，這個代理就是備用的RM。其次，老闆能夠決定項目什麼時候終止，什麼時候開始，這個很好理解。NM至關於公司下面分設的許多部門，AM至關於某個具體項目的負責人，具體的咱們待會再說，暫時先這麼理解。最後，老闆能夠隨時知道部門的狀況，若是某個部門集體度假了，或者出了什麼重大事故，那麼天然這個部門所牽涉的項目就要被擱置，這時候對於這個項目該怎麼處理，是等他們回來再繼續，仍是直接把項目給其餘的部門，這就要問這個項目的負責人了，怎麼決斷就要聽他的意見，畢竟這個項目是他負責的。

NM所在的整個節點，至關於公司的各個部門，惟一的區別就是，在公司中，每每不會設立兩個財務部門或三我的力部門，公司的部門每每是惟一的。而YARN 的結構中，每一個節點並不具備惟一性，因此咱們爲了類比方便，能夠假設這個公司有3個開發部門，4個測試部門這樣。這樣RM就能夠理解成這個部門的負責人，顯然RM對於本部門的狀況是十分了解的，包括哪一個人今天有沒有來上班，部門如今的工做能力如何，是否是有人還處於空閒沒事作的狀態等等。負責人須要按期向老闆遞交工做記錄（心跳信息）從而讓老闆知道這個部門的工做能力如何啊等等這些信息，這樣下次有新任務的時候，老闆就知道能不能分配給這個部門。做爲部門負責人，天然得聽老闆的話，老闆給你個任務，讓你立馬在部門中給我組個小組(container)完成，你就要執行老闆的命令。同時對於項目負責人的要求，他也要儘可能可能知足，好比項目負責人說我這個項目須要大家部門哪些哪些人幫我去作，那部門負責人就按照他的要求把那些人組成一個小組去執行任務。

AM，項目負責人或團隊，一個公司可能有多個項目，天然每一個項目須要有一個項目負責人。項目負責人在作項目的時候一定會用到公司中的資源，好比開會須要會議室、打印機啊，那天然得跟老闆去申請說，我這個項目須要利用公司的會議室、打印機等等，老闆說能夠啊沒問題，那麼他拿到這些資源後就會給每一個小組說，我已經幫大家申請到這些東西了，之後大家要用的話就直接能夠用了。最後，他能夠跟某個部門的負責人說，我須要大家部門的幾我的組成一個小組（container）來幫我作這個項目，或者大家部門的這個小組作的不行，我不要他們了。

container就是一個小組，小組內有你們能夠共用的一些資源，每一個項目分紅一個個小的任務也是在各個小組中完成的，每一個小組都屬於某個部門，一個部門能夠有若干個小組。

不知道這樣說會不會對理解YARN的架構有所幫助，這只是我在看到這個架構時的一些理解。

YRAN執行流程

YARN的執行流程

1. 客戶端提交一個做業請求給RM，能夠是MapReduce做業，也能夠Spark做業。

2. RM會爲做業分配第一個container，假設這個container運行在第二個節點上，這樣RM就會與對應的NM進行通訊，也就是跟第二個節點的NM說，我要在你上面啓動一個container。

3. NM在接到了RM的指令後，在NM上啓動了一個container，而application master就運行在這個container之中。

4. AM啓動完了以後，會在RM中進行註冊，註冊了用戶就能夠經過RM看到做業執行的進度了。而且AM會將須要使用的資源，好比須要多少memory，向RM進行申請，若是申請到資源就美滋滋，接着進行下面的步驟。

5. 申請到資源後，AM就在對應的NM上開始啓動任務。假設須要在第一個NM啓動2個task，在第三個NM上啓動1個task，那麼把這些通知發送給對應的NM。

6. NM在接受到這些通知後，就知道本身須要建立幾個task，因而在NM上啓動相應的container，並把task放到container中去運行。

其實這個流程並非很複雜，能夠對照着以前舉的公司的例子，把相應的角色帶入進去理解一下流程。

咱們再來思考一個問題，爲何說在1.x版本不能支持其餘計算框架的運行，而使用了YARN後就能夠了呢？關鍵在於這個流程是個通用的流程，AM做爲應用程序的主控程序，若是咱們對於相應的框架都作出對應的AM的實現，也就是說，若是是MapReduce，那麼這裏的AM就是MapReduce對應的AM，對於spark也是一樣的道理。那麼在YARN之上就能夠運行不少計算框架了。其實能夠把YARN的做用理解成能夠跑各類計算框架的操做系統，就跟使用Windows操做系統，你就能夠在這個操做系統上運行各類軟件同樣。