論文閱讀筆記 - YARN : Architecture of Next Generation Apache Hadoop MapReduceFramework

做者：劉旭暉 Raymond 轉載請註明出處

Email：colorant at 163.com

BLOG：http://blog.csdn.net/colorant/

更多論文閱讀筆記 http://blog.csdn.net/colorant/article/details/8256145

 

== 目標問題 ==

 

下一代的Hadoop框架，支持10,000+節點規模的Hadoop集羣，支持更靈活的編程模型

 

== 核心思想 ==

 

固定的編程模型，單點的資源調度和任務管理方式，使得Hadoop 1.0的應用在模式上和規模上都日益表現出它的侷限性。

 

YARN的核心思想是採用兩級分佈式的資源調度和任務管理框架，支持模塊化的任務調度組件和自定義的任務管理模塊，以適應多樣化的編程模式和日益增大的集羣規模。

 

YARN以container爲單位調度資源和任務，可調度的資源類型爲Memory（長期目標包括CPU/DISK/IO等），經過在各個任務管理框架間分配和共享資源來提升集羣利用率，總體思想和Mesos十分接近。

 

== 實現 ==

 

YARN的主要組成部分包括：

 

一個全局的RM(ResourceManager)，每一個Job一個的AM(ApplicationMaster) 和每一個節點一個的NM(NodeManager)

 

 

RM內部又進一步分爲調度模塊(scheduler)和應用管理模塊(Applications Manager)，調度模塊負責在各個Job間調度分配資源，而應用管理模塊則負責監聽客戶端建立Job的請求和啓動Per Job的AM

 

在應用管理模塊啓動AM之後，AM就接管了自身Job以後的管理工做，AM負責與調度模塊協商獲取任務運行所需的資源，經過NM建立獲得所需資源的任務進程，並監控任務的完成狀況。

 

從AM和RM的通信協議上看，對資源的調度接口已經簡化爲一個AM所需Container的配置，數量和位置的列表，所以具備很大的通用性，固然，因爲調度模塊只是簡單的根據Job的需求和優先級等調度資源，而不考慮任何任務具體細節和執行狀況的相關信息，也就會損失一些能夠做爲調度依據的信息。以MapReduce爲例，MapSplit相關的信息是調度模塊所沒法得知的。Locality等要求就須要由AM來保證。

 

== 相關研究，項目等 ==

 

Mesos所要解決的問題和總體思路和YARN十分類似。一樣的兩級資源調度，可模塊化的調度策略，由具體的運算框架負責第二級資源調度，隔離的資源管理方式和類似的任務執行方式。不過在資源的一級調度方式上，Mesos採用Push的方式，而YARN採用Pull的方式，Mesos號稱是爲了使接口更加簡單和通用化，YARN採用Pull的方式看起來則彷佛更靈活一些。可是光從API上看，我的理解AM在作調度請求前還須要獲取全局資源的狀態，可能須要付出更大的通信代價？

 

Facebook的Corona一樣是爲Hadoop開發的，基本上也是將MapReduce1.0中的Job tracker以Job爲單位進行拆分。一樣採用Pull的方式向中央調度模塊Cluster manager請求資源。不過Scope大概比YARN要小，目測純粹是經過分佈是調度的方是解決集羣規模問題，而YARN同時還但願能靈活適配不一樣的運算框架。