Yarn應用程序運行流程剖析

Yarn（Yet Another Resource Negotiator）是一個Hadoop集羣資源管理系統，Hadoop2時被引入，旨在提升MapReduce的性能，但YARN已足夠通用，使得它能夠支持其它的分佈式應用。

 

Yarn自己提供了一系列API用於用戶應用程序與集羣資源進行交互，這些API複雜且晦澀難懂，用戶一般不會直接使用。用戶編制應用程序時，一般使用的是分佈式計算框架（MapReduce、Spark）提供的高層次API，這些API構建在Yarn之上且隱藏資源管理細節，以下圖所示：

 

 

MapReduce、Spark、Tez這樣的計算框架均以Yarn應用程序的形式運行於集羣計算層（Yarn）和集羣存儲層（HDFS或HBase）之上，而Pig、Hive、Crunch則運行於MapReduce、Spark或Tez之上，並無與Yarn直接交互。

 

Yarn的核心服務由兩個組件提供：

 

Resource Manager：每一個集羣一個實例，用於管理整個集羣的資源使用；

 

Node Manager：每一個集羣多個實例，用於自身Container的啓動和監測（每一個Node Manager上可能有多個Container）。

 

注：根據Yarn配置的不一樣，Container多是一個Unix進程或者一個Linux cgroup實例，在受限的資源範圍內（如內存、CPU等）執行特定應用程序的代碼。

 

運行流程

 

 

（1）Client請求Resource Manager運行一個Application Master實例（step 1）；

（2）Resource Manager選擇一個Node Manager，啓動一個Container並運行Application Master實例（step 2a、step 2b）；

（3）Application Master根據實際須要向Resource Manager請求更多的Container資源（step 3）；

（4）Application Master經過獲取到的Container資源執行分佈式計算（step 4a、step 4b）。

 

Application Master的具體邏輯與特定的應用相關，也許直接向Client返回計算結果，也可能請求更多的資源執行分佈式計算（如step 3）。此外，Yarn自己並無提供應用程序組件之間（Client、Master、Process）的通訊實現，須要特定的應用程序本身提供，如使用Hadoop RPC。

 

資源請求

 

Yarn在資源請求方面擁有一個可擴展的模型，亦便可表述複雜的請求信息，如某個Container須要的計算資源量（內存或CPU），並可帶有數據本地性約束需求。

 

數據本地性約束能夠很大程度上節約分佈式計算處理時的集羣帶寬消耗，能夠表現爲如下三種形式：

 

（1）請求位於集羣特定節點上的Container；

（2）請求位於集羣特定機架節點上的Container；

（3）請求位於集羣任意節點上的Container。

 

數據本地性約束並不必定可以剛好知足，若是指定的節點沒法啓動新的Container（正在運行的Container已將資源耗盡），則嘗試同一個機架的其它節點；若是也失敗，則嘗試集羣中的其它節點。MapReduce場景下Map Container的分配就是這樣的一種狀況，一般能夠粗略地認爲每個Map任務負責處理一個Block的數據，爲了不網絡傳輸數據，應該儘量的知足數據本地性約束，優先在存有Block Replica的節點上啓動Container，次之在存有Block Replica的機架節點上啓動Contaier，末之在集羣中的其他節點上啓動Container。

 

一個處於運行狀態的Yarn應用程序能夠在任什麼時候候發起資源請求，好比應用啓動時一次性請求全部資源（Spark），或者以動態的方式不斷請求更多的資源知足應用的須要（MapReduce，首先請求所有的Map資源，稍後請求Reduce資源，若是某些Task失敗，還會申請更多的資源用於失敗恢復）。

 

應用程序生存期

 

Yarn應用程序的生存期跨度比較大：從運行幾秒鐘的短任務應用到運行幾天甚至幾月的長任務應用。相對於運行時間而言，一種更有效的方式是根據Application與Job的映射關係劃分，常見如下三種狀況：

 

（1）一個Application對應一個Job（MapReduce）；

（2）一個Application對應一個Workflow（Session）的全部Jobs，這種方式能夠在多個Jobs之間重用Containers並有效緩存中間數據（Spark）；

（3）一個Long-Running  Application被多個用戶共享，這種應用多數充當「Coordination」角色（Slider、Impala）。

 

構建Yarn應用程序

 

咱們本身動手從頭至尾構建一個Yarn應用程序是比較複雜的，不少時候也是沒必要要的，能夠根據須要的不一樣選擇一個優秀的分佈式計算框架幫助咱們構建應用程序，如須要DAG計算，則選擇Spark、Tez；須要流式處理，則選擇Spark、Samza或Storm。

 

也有一些開源項目幫助咱們簡化Yarn應用程序的構建，如Slider、Twill，目前均處於孵化器狀態，暫時不討論。Yarn自己也自帶了一個例子「Distributed Shell Application」，向咱們展現了若是經過Yarn Client API完成Client、Application Master與Yarn Daemons之間的交互。