Hadoop YARN架構解讀

原Mapreduce架構

原理
架構圖如下：

原 MapReduce 程序的流程：
首先用戶程序 (JobClient) 提交了一個 job，job 的信息會發送到 Job Tracker 中，Job Tracker需要與集群中的機器定時通信 (heartbeat), 需要管理哪些程序應該跑在哪些機器上，需要管理所有 job 失敗、重啟等操作。
TaskTracker 是 Map-reduce 集群中每臺機器都有的一個部分，它的職責有兩個：一是監視自己所在機器的資源情況，二是監視當前機器的 tasks 運行狀況。TaskTracker 需要把這些信息通過 heartbeat 發送給 JobTracker，JobTracker 會搜集這些信息以給新提交的 job 分配運行在哪些機器上。上圖虛線箭頭就是表示消息的發送 - 接收的過程。

存在的問題

1. JobTracker單點故障。
2. JobTracker的管理負荷過大，業界普遍認可的並行節點上限是4000。
3. TaskTracker 端，以 map/reduce task 的數目作為資源的表示過於簡單，沒有考慮到 cpu/ 內存的占用情況，如果兩個大內存消耗的 task 被調度到了一塊，很容易出現資源枯竭。

   其他問題摘抄如下：
   在 TaskTracker 端，把資源強制劃分為 map task slot 和 reduce task slot, 如果當系統中只有 map task 或者只有 reduce task 的時候，會造成資源的浪費，也就是前面提過的集群資源利用的問題。
   源代碼層面分析的時候，會發現代碼非常的難讀，常常因為一個 class 做了太多的事情，代碼量達 3000 多行，，造成 class 的任務不清晰，增加 bug 修復和版本維護的難度。
   從 操作的角度來看，現在的 Hadoop MapReduce 框架在有任何重要的或者不重要的變化 ( 例如 bug 修復，性能提升和特性化 ) 時，都會強制進行系統級別的升級更新。更糟的是，它不管用戶的喜好，強制讓分布式集群系統的每一個用戶端同時更新。這些更新會讓用戶為了驗證他們之前的應 用程序是不是適用新的 Hadoop 版本而浪費大量時間。

一句話總結：JobTracker幹的事兒太多了。

YARN架構

架構圖如下：

基本思想是將 JobTracker 兩個主要的功能分離成單獨的組件，這兩個功能是資源管理和任務調度 / 監控。
ResourceManager 管理所有應用程序計算資源的分配，每一個應用的 ApplicationMaster 負責相應的調度和協調。一個應用程序無非是一個單獨的傳統的 MapReduce 任務或者是一個 DAG( 有向無環圖 ) 任務。ResourceManager 和每一臺機器的節點管理服務器能夠管理用戶在那臺機器上的進程並能對計算進行組織。NodeManager 是每一臺機器框架的代理，是執行應用程序的容器，監控應用程序的資源使用情況 (CPU，內存，硬盤，網絡 ) 並且向調度器匯報。

架構變化的總結
原來的JobTracker和TaskTracker是從物理節點的角度來設置，但每個 節點內部還包括資源監控、任務調度的功能。改版之後，從邏輯上進行功能模塊設計，ResourceManager專門負責管理和分配資 源，NodeManager是RM在各節點上的代理，每個應用有一個ApplicationMaster，但不放在RM節點上，而是分布式存放，用來管理 應用在各節點上的運行、向RM申請資源。這樣，原來JobTracker被分解為兩個功能模塊，並且不在同一個節點上運行，自然降低了RM節點（原 JobTracker節點）的管理負荷。

摘自：http://www.jianshu.com/p/3b9179534127

yarn架構——本質上是在做解耦 將資源分配和應用程序狀態監控兩個功能職責分離為RM和AM