Hadoop Yarn詳解

摘要： 一、Yarn簡介 Yarn是Hadoop集群的資源管理系統。Hadoop2.0對MapReduce框架做了徹底的設計重構，我們稱Hadoop2.0中的MapReduce為MRv2或者Yarn。

一、Yarn簡介

Yarn是Hadoop集群的資源管理系統。Hadoop2.0對MapReduce框架做了徹底的設計重構，我們稱Hadoop2.0中的MapReduce為MRv2或者Yarn。在介紹Yarn之前，我們先回頭看一下Hadoop1.x對MapReduce job的調度管理方式（可參考：Hadoop核心之MapReduce架構設計），它主要包括兩部分功能：

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系統中，共享整個集群資源，如下圖所示：

二、Yarn的組件及架構

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

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

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

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

下面我們看一下整個Yarn的架構圖：

三、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而不是每類。

Yarn 框架相對於老的 MapReduce 框架什么優勢呢？

- 這個設計大大減小了 ResourceManager 的資源消耗，並且讓監測每一個 Job 子任務 (tasks) 狀態的程序分布式化了，更安全、更優美。 - 在新的 Yarn 中，ApplicationMaster 是一個可變更的部分，用戶可以對不同的編程模型寫自己的 AppMst，讓更多類型的編程模型能夠跑在 Hadoop 集群中，可以參考 hadoop Yarn 官方配置模板中的 ``mapred-site.xml`` 配置。 - 對於資源的表示以內存為單位 ( 在目前版本的 Yarn 中，沒有考慮 cpu 的占用 )，比之前以剩余 slot 數目更合理。 - 老的框架中，JobTracker 一個很大的負擔就是監控 job 下的 tasks 的運行狀況，現在，這個部分就扔給 ApplicationMaster 做了，而 ResourceManager 中有一個模塊叫做 ApplicationsManager，它是監測 ApplicationMaster 的運行狀況，如果出問題，會將其在其他機器上重啟。 - Container 是 Yarn 為了將來作資源隔離而提出的一個框架。這一點應該借鑒了 Mesos 的工作，目前是一個框架，僅僅提供 java 虛擬機內存的隔離 ,hadoop 團隊的設計思路應該后續能支持更多的資源調度和控制 , 既然資源表示成內存量，那就沒有了之前的 map slot/reduce slot 分開造成集群資源閑置的尷尬情況。 

四、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也歸還給系統

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自己去請求集群資源。