MapReduce V2---Yarn的架構及其執行原理

1.MRv1的侷限性

   1)：擴充套件性差

           MRv1中，Jobracker同事兼備了資源管理和作業控制（job的生命週期管理(task排程，跟蹤task過程狀態，task處理容錯）兩個功能。

    單個的jobtracker無論在記憶體還是其他資源方面總存在瓶頸，在伸縮性、資源利用率、執行除mapreduce的其他任務等方面都會有限制。

MRv2 Yarn框架把資源排程和task管理監控分離開來，由資源管理器NodeManager負責資源排程，每一個application(job)由一個AppMaster負責對task進行排程管理監控，並且可以監控AppMaster的狀態，有問題可以在其他節點重啟。

   2)：資源利用率低

     MRv1 mapreduce框架使用slot做資源表示單位，並且map slot和reduce slot分離的，這樣資源不能共享，資源利用率不高，yarn使用節點的cpu、記憶體等資源作為資源表示單位，大大提高了資源利用率。

   

2.Yarn的組成

ResourceManager（RM）

RM是全域性資源管理器，負責整個系統的資源管理和分配。

主要由兩個元件組成：排程器和應用程式管理器（ASM）

排程器：根據容量，佇列等限制條件，將系統中的資源分配給各個正在執行的應用程式，不負責具體應用程式的相關工作，比如監控或跟蹤狀態

應用程式管理器：負責管理整個系統中所有應用程式

ApplicationMaster(AM)

使用者提交的每個應用程式均包含一個AM

AM的主要功能：

     (1)與RM排程器協商以獲取資源（用Container表示）

     (2)將得到的任務進一步分配給內部的任務

     (3)與NM通訊以自動/停止任務

     (4)監控所有任務執行狀態，並在任務執行失敗時重新為任務申請資源以重啟任務

當前YARN自帶了兩個AM實現

     一個用於演示AM編寫方法的例項程式distributedshell

     一個用於Mapreduce程式---MRAppMaster

其他的計算框架對應的AM正在開發中，比如spark等。

Nodemanager（NM）和Container

NM是每個節點上的資源和工作管理員

      (1)定時向RM彙報本節點上的資源使用情況和各個Container的執行狀態

      (2)接收並處理來自AM的Container啟動/停止等各種要求

Container是YARN中的資源抽象，它封裝了某個節點上的多維度資源

     YARN會為每個任務分配一個Container，且該任務只能使用該Container中描述的資源

3.Yarn的執行流程

   

(1)：由客戶端提交一個應用，由RM的ASM接受應用請求

提交過來的應用程式包括哪些內容：

a:ApplicationMaster

b:啟動Applicationmaster的命令

c:本身應用程式的內容

(2):提交了三部分內容給RM，然後RM找NodeManager,然後

Nodemanager就啟用Applicationmaster，並分配Container

 

接下來我們就要執行這個任務了，

(3):但是執行任務需要資源，所以我們得向RM的ASM申請執行任務的資源（它會在ＲＭ這兒註冊一下，說我已經啟動了，註冊了以後就可以通過RM的來管理，我們使用者也可以通過ＲＭ的ｗｅｂ客戶端來監控任務的狀態）ＡＳＭ只是負責APplicationMaster的啟用

(4)我們註冊好了後，得申請資源，申請資源是通過第四步，向ResourceScheduler申請的

(5)申請並領取資源後，它會找Nodemanager，告訴他我應經申請到了，然後Nodemanager判斷一下，

(6)知道他申請到了以後就會啟動任務，當前啟動之前會準備好環境，

(7)任務啟動以後會跟APplicationmaster進行通訊，不斷的心跳進行任務的彙報。

(8)完成以後會給ＲＭ進行彙報，讓RSM撤銷註冊。然後RSM就會回收資源。當然了，我們是分散式的，所以我們不會只跟自己的Nodemanager通訊。也會跟其他的節點通訊。