yarn 原理

 

產生背景

直接源於MRv1在幾個方面的缺陷

• 擴展性受限(NameNode,JobTracker設計爲單一節點，內存容量有限)
• 單點故障
• 難以支持MR以外的計算
• slot數目沒法動態修改，Map slot，Reduce slot不能共享

    

優勢：

• 將資源管理和做業控制分離，減少JobTracker壓力
• 可以支持不一樣的計算框架
• 資源管理更加合理

 

 

缺點：

• 各個應用沒法感知集羣總體資源的使用狀況，只能等待上層調度推送信息。
• 資源分配採用輪詢、ResourceOffer機制（mesos)，在分配過程當中使用悲觀鎖，併發粒度小。
• 缺少一種有效的競爭或優先搶佔的機制。

 

 

YARN容錯性

ResourceManager

        存在單點故障；

        正在基於ZooKeeper實現HA。

NodeManager

        失敗後，RM將失敗任務告訴對應的AM；

        AM決定如何處理失敗的任務。

ApplicationMaster

        失敗後，由RM負責重啓；

        AM需處理內部任務的容錯問題；

        RMAppMaster會保存已經運行完成的Task，重啓後無需從新運行。

YARN調度框架

    雙層調度框架

        RM將資源分配給AM

        AM將資源進一步分配給各個Task

 

 

YARN資源調度器

    多類型資源調度

        採用DRF算法（論文：「Dominant Resource Fairness: Fair Allocation of Multiple Resource Types」）

        目前支持CPU和內存兩種資源

    提供多種資源調度器

        FIFO

        Fair Scheduler

        Capacity Scheduler

    多租戶資源調度器

        支持資源按比例分配

        支持層級隊列劃分方式

        支持資源搶佔

 

YARN資源隔離方案

    支持內存和CPU兩種資源隔離

        內存是一種「決定生死」的資源

        CPU是一種「影響快慢」的資源

    內存隔離

        基於線程監控的方案

        基於Cgroups的方案

    CPU隔離

        默認不對CPU資源進行隔離

        基於Cgroups的方案

YARN支持的調度語義

    支持的語義

        請求某個特定節點/機架上的特定資源量

        將某些節點加入（或移除）黑名單，再也不爲本身分配這些節點上的資源

        請求歸還某些資源

    不支持的語義

        請求任意節點/機架上的特定資源量

        請求一組或幾組符合某種特質的資源

        超細粒度資源

        動態調整Container資源

 

運行在YARN上的計算框架 （還有別的）

        離線計算框架：MapReduce

        DAG計算框架： Tez

        流式計算框架：Storm

        內存計算框架：Spark

 

 

 

DAG計算框架：Apache Tez 

    DAG計算：多個做業之間存在數據依賴關係，並造成一個依賴關係有向圖（ Directed Acyclic Graph ），該圖的計算稱爲「DAG計算」

 

 

 

1.1 YARN 基本架構

YARN是Hadoop 2.0中的資源管理系統，它的基本設計思想是將MRv1中的JobTracker拆分紅了兩個獨立的服務：一個全局的資源管理器ResourceManager和每一個應用程序特有的ApplicationMaster。

其中ResourceManager負責整個系統的資源管理和分配，而ApplicationMaster負責單個應用程序的管理。

 

1.2 YARN基本組成結構

YARN整體上仍然是Master/Slave結構，在整個資源管理框架中，ResourceManager爲Master，NodeManager爲Slave，ResourceManager負責對各個NodeManager上的資源進行統一管理和調度。當用戶提交一個應用程序時，須要提供一個用以跟蹤和管理這個程序的ApplicationMaster，它負責向ResourceManager申請資源，並要求NodeManger啓動能夠佔用必定資源的任務。因爲不一樣的ApplicationMaster被分佈到不一樣的節點上，所以它們之間不會相互影響。在本小節中，咱們將對YARN的基本組成結構進行介紹。

圖2-9描述了YARN的基本組成結構，YARN主要由ResourceManager、NodeManager、ApplicationMaster（圖中給出了MapReduce和MPI兩種計算框架的ApplicationMaster，分別爲MR AppMstr和MPI AppMstr）和Container等幾個組件構成。

 

1.ResourceManager（RM）

RM是一個全局的資源管理器，負責整個系統的資源管理和分配。注：RM只負責監控AM，在AM運行失敗時候啓動它，RM並不負責AM內部任務的容錯，這由AM來完成。

它主要由兩個組件構成：調度器（Scheduler）和應用程序管理器（Applications Manager，ASM）。

（1）調度器

調度器根據容量、隊列等限制條件（如每一個隊列分配必定的資源，最多執行必定數量的做業等），將系統中的資源分配給各個正在運行的應用程序。

須要注意的是，該調度器是一個「純調度器」，它再也不從事任何與具體應用程序相關的工做，好比不負責監控或者跟蹤應用的執行狀態等，也不負責從新啓動因應用執行失敗或者硬件故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念「資源容器」（Resource Container，簡稱Container）表示，Container是一個動態資源分配單位，它將內存、CPU、磁盤、網絡等資源封裝在一塊兒，從而限定每一個任務使用的資源量。此外，該調度器是一個可插拔的組件，用戶可根據本身的須要設計新的調度器，YARN提供了多種直接可用的調度器，好比Fair Scheduler和Capacity Scheduler等。

 

（2） 應用程序管理器

應用程序管理器負責管理整個系統中全部應用程序，包括應用程序提交、與調度器協商資源以啓動ApplicationMaster、監控ApplicationMaster運行狀態並在失敗時從新啓動它等。

 

2. ApplicationMaster（AM）

用戶提交的每一個應用程序均包含1個AM，主要功能包括：

與RM調度器協商以獲取資源（用Container表示）；

將獲得的任務進一步分配給內部的任務；

與NM通訊以啓動/中止任務；

監控全部任務運行狀態，並在任務運行失敗時從新爲任務申請資源以重啓任務。

當前YARN自帶了兩個AM實現，一個是用於演示AM編寫方法的實例程序distributedshell，它能夠申請必定數目的Container以並行運行一個Shell命令或者Shell腳本；另外一個是運行MapReduce應用程序的AM—MRAppMaster

3. NodeManager（NM）

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

4. Container

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

須要注意的是，Container不一樣於MRv1中的slot，它是一個動態資源劃分單位，是根據應用程序的需求動態生成的。

截至本書完成時，YARN僅支持CPU和內存兩種資源，且使用了輕量級資源隔離機制Cgroups進行資源隔離。

 

1.3  YARN工做流程

當用戶向YARN中提交一個應用程序後，YARN將分兩個階段運行該應用程序：

第一個階段是啓動ApplicationMaster；

第二個階段是由ApplicationMaster建立應用程序，爲它申請資源，並監控它的整個運行過程，直到運行完成。

如圖2-11所示，YARN的工做流程分爲如下幾個步驟：

 

步驟1　用戶向YARN中提交應用程序，其中包括ApplicationMaster程序、啓動ApplicationMaster的命令、用戶程序等。

步驟2　ResourceManager爲該應用程序分配第一個Container，並與對應的Node-Manager通訊，要求它在這個Container中啓動應用程序的ApplicationMaster。

步驟3　ApplicationMaster首先向ResourceManager註冊，這樣用戶能夠直接經過ResourceManager查看應用程序的運行狀態，而後它將爲各個任務申請資源，並監控它的運行狀態，直到運行結束，即重複步驟4~7。

步驟4　ApplicationMaster採用輪詢的方式經過RPC協議向ResourceManager申請和領取資源。

步驟5　一旦ApplicationMaster申請到資源後，便與對應的NodeManager通訊，要求它啓動任務。

步驟6　NodeManager爲任務設置好運行環境（包括環境變量、JAR包、二進制程序等）後，將任務啓動命令寫到一個腳本中，並經過運行該腳本啓動任務。

步驟7　各個任務經過某個RPC協議向ApplicationMaster彙報本身的狀態和進度，以讓ApplicationMaster隨時掌握各個任務的運行狀態，從而能夠在任務失敗時從新啓動任務。

     在應用程序運行過程當中，用戶可隨時經過RPC向ApplicationMaster查詢應用程序的當前運行狀態。 

步驟8　應用程序運行完成後，ApplicationMaster向ResourceManager註銷並關閉本身。

 

1.4 多角度理解YARN

可將YARN看作一個雲操做系統，它負責爲應用程序啓動ApplicationMaster（至關於主線程），而後再由ApplicationMaster負責數據切分、任務分配、啓動和監控等工做，而由ApplicationMaster啓動的各個Task（至關於子線程）僅負責本身的計算任務。當全部任務計算完成後，ApplicationMaster認爲應用程序運行完成，而後退出。