Hadoop Yarn

摘自：https://yq.aliyun.com/articles/5896

1、Yarn簡介

Yarn是Hadoop集羣的資源管理系統。Hadoop2.0對MapReduce框架作了完全的設計重構，咱們稱Hadoop2.0中的MapReduce爲MRv2或者Yarn。在介紹Yarn以前，咱們先回頭看一下Hadoop1.x對MapReduce job的調度管理方式，它主要包括兩部分功能：

1. ResourceManagement 資源管理
2. JobScheduling/JobMonitoring 任務調度監控

 到了Hadoop2.x也就是Yarn，它的目標是將這兩部分功能分開，也就是分別用兩個進程來管理這兩個任務：

1. ResourceManger
2. ApplicationMaster

  須要注意的是，在Yarn中咱們把job的概念換成了application，由於在新的Hadoop2.x中，運行的應用不僅是MapReduce了，還有多是其它應用如一個DAG（有向無環圖Directed Acyclic Graph，例如storm應用）。Yarn的另外一個目標就是拓展Hadoop，使得它不只僅能夠支持MapReduce計算，還能很方便的管理諸如Hive、Hbase、Pig、Spark/Shark等應用。這種新的架構設計可以使得各類類型的應用運行在Hadoop上面，並經過Yarn從系統層面進行統一的管理，也就是說，有了Yarn，各類應用就能夠互不干擾的運行在同一個Hadoop系統中，共享整個集羣資源，以下圖所示：

 

2、Yarn的組件及架構

 Yarn主要由如下幾個組件組成：

1. ResourceManager：Global（全局）的進程 
2. NodeManager：運行在每一個節點上的進程
3. ApplicationMaster：Application-specific（應用級別）的進程
   - *Scheduler：是ResourceManager的一個組件*
   - *Container：節點上一組CPU和內存資源*

 　　ApplicationMaster是對運行在Yarn中某個應用的抽象，它其實就是某個類型應用的實例，ApplicationMaster是應用級別的，它的主要功能就是向ResourceManager（全局的）申請計算資源（Containers）而且和NodeManager交互來執行和監控具體的task。Scheduler是ResourceManager專門進行資源管理的一個組件，負責分配NodeManager上的Container資源，NodeManager也會不斷髮送本身Container使用狀況給ResourceManager。Container是Yarn對計算機計算資源的抽象，它其實就是一組CPU和內存資源，全部的應用都會運行在Container中。

   ResourceManager和NodeManager兩個進程主要負責系統管理方面的任務。ResourceManager有一個Scheduler，負責各個集羣中應用的資源分配。對於每種類型的每一個應用，都會對應一個ApplicationMaster實例，ApplicationMaster經過和ResourceManager溝通得到Container資源來運行具體的job，並跟蹤這個job的運行狀態、監控運行進度。

Yarn的架構圖

 

3、Yarn的組件詳解

    3.1 Container Container是Yarn框架的計算單元，是具體執行應用task（如map task、reduce task）的基本單位。Container和集羣節點的關係是：一個節點會運行多個Container，但一個Container不會跨節點。一個Container就是一組分配的系統資源，現階段只包含兩種系統資源（以後可能會增長磁盤、網絡等資源）：

1. CPU core
2. Memory in MB

 　　既然一個Container指的是具體節點上的計算資源，這就意味着Container中一定含有計算資源的位置信息：計算資源位於哪一個機架的哪臺機器上。因此咱們在請求某個Container時，實際上是向某臺機器發起的請求，請求的是這臺機器上的CPU和內存資源。任何一個job或application必須運行在一個或多個Container中，在Yarn框架中，ResourceManager只負責告訴ApplicationMaster哪些Containers能夠用，ApplicationMaster還須要去找NodeManager請求分配具體的Container。

     3.2 Node Manager  NodeManager進程運行在集羣中的節點上，每一個節點都會有本身的NodeManager。NodeManager是一個slave服務：它負責接收ResourceManager的資源分配請求，分配具體的Container給應用。同時，它還負責監控並報告Container使用信息給ResourceManager。經過和ResourceManager配合，NodeManager負責整個Hadoop集羣中的資源分配工做。ResourceManager是一個全局的進程，而NodeManager只是每一個節點上的進程，管理這個節點上的資源分配和監控運行節點的健康狀態。下面是NodeManager的具體任務列表：

- 接收ResourceManager的請求，分配Container給應用的某個任務
- 和ResourceManager交換信息以確保整個集羣平穩運行。ResourceManager就是經過收集每一個NodeManager的報告信息來追蹤整個集羣健康狀態的，而NodeManager負責監控自身的健康狀態。
- 管理每一個Container的生命週期
- 管理每一個節點上的日誌
- 執行Yarn上面應用的一些額外的服務，好比MapReduce的shuffle過程

 　　當一個節點啓動時，它會向ResourceManager進行註冊並告知ResourceManager本身有多少資源可用。在運行期，經過NodeManager和ResourceManager協同工做，這些信息會不斷被更新並保障整個集羣發揮出最佳狀態。NodeManager只負責管理自身的Container，它並不知道運行在它上面應用的信息。負責管理應用信息的組件是ApplicationMaster。

   3.3 Resource Manager ResourceManager主要有兩個組件：Scheduler和ApplicationManager。Scheduler是一個資源調度器，它主要負責協調集羣中各個應用的資源分配，保障整個集羣的運行效率。Scheduler的角色是一個純調度器，它只負責調度Containers，不會關心應用程序監控及其運行狀態等信息。一樣，它也不能重啓因應用失敗或者硬件錯誤而運行失敗的任務。Scheduler是一個可插拔的插件，它能夠調度集羣中的各類隊列、應用等。在Hadoop的MapReduce框架中主要有兩種Scheduler：Capacity Scheduler和Fair Scheduler。另外一個組件ApplicationManager主要負責接收job的提交請求，爲應用分配第一個Container來運行ApplicationMaster，還有就是負責監控ApplicationMaster，在遇到失敗時重啓ApplicationMaster運行的Container。 

   3.4 Application Master ApplicationMaster的主要做用是向ResourceManager申請資源並和NodeManager協同工做來運行應用的各個任務而後跟蹤它們狀態及監控各個任務的執行，遇到失敗的任務還負責重啓它。在MR1中，JobTracker即負責job的監控，又負責系統資源的分配。而在MR2中，資源的調度分配由ResourceManager專門進行管理，而每一個job或應用的管理、監控交由相應的分佈在集羣中的ApplicationMaster，若是某個ApplicationMaster失敗，ResourceManager還能夠重啓它，這大大提升了集羣的拓展性。在MR1中，Hadoop架構只支持MapReduce類型的job，因此它不是一個通用的框架，由於Hadoop的JobTracker和TaskTracker組件都是專門針對MapReduce開發的，它們之間是深度耦合的。Yarn的出現解決了這個問題，關於Job或應用的管理都是由ApplicationMaster進程負責的，Yarn容許咱們本身開發ApplicationMaster，咱們能夠爲本身的應用開發本身的ApplicationMaster。這樣每個類型的應用都會對應一個ApplicationMaster，一個ApplicationMaster其實就是一個類庫。這裏要區分ApplicationMaster*類庫和ApplicationMaster實例*，一個ApplicationMaster類庫何以對應多個實例，就行java語言中的類和類的實例關係同樣。總結來講就是，每種類型的應用都會對應着一個ApplicationMaster，每一個類型的應用均可以啓動多個ApplicationMaster實例。因此，在yarn中，是每一個job都會對應一個ApplicationMaster而不是每類。 

4、Yarn request分析

4.1 應用提交過程分析

   瞭解了上面介紹的這些概念，咱們有必要看一下Application在Yarn中的執行過程，整個執行過程能夠總結爲三步：

1. 應用程序提交
2. 啓動應用的ApplicationMaster實例
3. ApplicationMaster實例管理應用程序的執行

  　執行過程

1- 客戶端程序向ResourceManager提交應用並請求一個ApplicationMaster實例
2- ResourceManager找到能夠運行一個Container的NodeManager，並在這個Container中啓動ApplicationMaster實例
3-ApplicationMaster向ResourceManager進行註冊，註冊以後客戶端就能夠查詢ResourceManager得到本身ApplicationMaster的詳細信息，之後就能夠和本身的ApplicationMaster直接交互了
4-在日常的操做過程當中，ApplicationMaster根據resource-request協議向ResourceManager發送resource-request請求
5-當Container被成功分配以後，ApplicationMaster經過向NodeManager發送container-launch-specification信息來啓動Container， container-launch-specification信息包含了可以讓Container和ApplicationMaster交流所須要的資料
6-應用程序的代碼在啓動的Container中運行，並把運行的進度、狀態等信息經過application-specific協議發送給ApplicationMaster
7-在應用程序運行期間，提交應用的客戶端主動和ApplicationMaster交流得到應用的運行狀態、進度更新等信息，交流的協議也是application-specific協議
8- 一但應用程序執行完成而且全部相關工做也已經完成，ApplicationMaster向ResourceManager取消註冊而後關閉，用到全部的Container也歸還給系統

  實例：在YARN上運行MapReduce程序(運行其餘程序也相似Spark);

   1- 提交MR請求前的Hadoop進程：

    

   2- 提交MR後的進程：啓動RunJar進程，將提交的內容存放在：HDFS的 /tmp/xx/xx/yarn-staging/jobID/ ：

    

   3- 啓動RunJar進程後，提交給ResourceManager，ResourceManager啓動ApplicationMaster(二者保持聯繫,爲了接收ApplicationMaster註冊和請求信息等)：

    

   4- ApplicationMaster向ResourceManager註冊，並提交資源請求，ResourceManager安排NodeManager分配Container，以後ApplicationMaster運行Map(進程6801):  

         

 5- Map運行完以後，運行Reduce(進程：6859)：

   

6- 運行結束MR以後，ApplicationMaster在回收資源：

      

7- 資源回收完成：
    　

4.2 Resource Request和Container

　 Yarn的設計目標就是容許咱們的各類應用以共享、安全、多租戶的形式使用整個集羣。而且，爲了保證集羣資源調度和數據訪問的高效性，Yarn還必須可以感知整個集羣拓撲結構。爲了實現這些目標，ResourceManager的調度器Scheduler爲應用程序的資源請求定義了一些靈活的協議，經過它就能夠對運行在集羣中的各個應用作更好的調度，所以，這就誕生了Resource Request和Container。具體來說，一個應用先向ApplicationMaster發送一個知足本身需求的資源請求，而後ApplicationMaster把這個資源請求以resource-request的形式發送給ResourceManager的Scheduler，Scheduler再在這個原始的resource-request中返回分配到的資源描述Container。每一個ResourceRequest可看作一個可序列化Java對象，包含的字段信息以下：

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

  　number-of-containers中的Containers就是ResourceManager給ApplicationMaster分配資源的結果。Container就是受權給應用程序可使用某個節點機器上CPU和內存的數量。ApplicationMaster在獲得這些Containers後，還須要與分配Container所在機器上的NodeManager交互來啓動Container並運行相關任務。固然Container的分配是須要認證的，以防止ApplicationMaster本身去請求集羣資源。