經典 MapReduce 的局限性：

 經典 MapReduce 的最嚴重的限制主要關系到可伸縮性、資源利用和對與 MapReduce 不同的工作負載的支持。在 MapReduce 框架中，作業執行受兩種類型的進程控制：

• 一個稱為JobTracker的主要進程，它協調在集群上運行的所有作業，分配要在 TaskTracker 上運行的 map 和 reduce 任務。

• 許多稱為TaskTracker的下級進程，它們運行分配的任務并定期向 JobTracker 報告進度。

 大型的 Hadoop 集群顯現出了由單個 JobTracker 導致的可伸縮性瓶頸。依據 Yahoo!，在集群中有 5,000 個節點和 40,000 個任務同時運行時，這樣一種設計實際上就會受到限制。由于此限制，必須創建和維護更小的、功能更差的集群。

 此外，較小和較大的 Hadoop 集群都從未最高效地使用他們的計算資源。在 Hadoop MapReduce 中，每個從屬節點上的計算資源由集群管理員分解為固定數量的 map 和 reduce slot，這些 slot 不可替代。設定 map slot 和 reduce slot 的數量后，節點在任何時刻都不能運行比 map slot 更多的 map 任務，即使沒有 reduce 任務在運行。這影響了集群的利用率，因為在所有 map slot 都被使用（而且我們還需要更多）時，我們無法使用任何 reduce slot，即使它們可用，反之亦然。

 最后但同樣重要的是，Hadoop 設計為僅運行 MapReduce 作業。隨著替代性的編程模型（比如 Apache Giraph 所提供的圖形處理）的到來，除 MapReduce 外，越來越需要為可通過高效的、公平的方式在同一個集群上運行并共享資源的其他編程模型提供支持。

YARN與經典 MapReduce的變化：

YARN 是下一代 Hadoop 計算平臺，它進行了如下改變：

• ResourceManager 代替集群管理器

•  ApplicationMaster 代替一個專用且短暫的 JobTracker

•  NodeManager 代替 TaskTracker

•  一個分布式應用程序代替一個 MapReduce 作業

YARN主要架構解析：

1）全局管理的ResourceManager（RM）

 RM是一個全局的資源管理器，負責整個系統的資源管理和分配。它主要由兩個組件構成：調度器（Scheduler）和應用程序管理器（Applications Manager，ASM）。

• 調度器：調度器根據容量、隊列等限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個正在運行的應用程序。需要注意的是，該調度器是一個“純調度器”，它不再從事任何與具體應用程序相關的工作，比如不負責監控或者跟蹤應用的執行狀態等，也不負責重新啟動因應用執行失敗或者硬件故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念“資源容器”（Resource Container，簡稱Container）表示，Container是一個動態資源分配單位，它將內存、CPU、磁盤、網絡等資源封裝在一起，從而限定每個任務使用的資源量。此外，該調度器是一個可插拔的組件，用戶可根據自己的需要設計新的調度器，YARN提供了多種直接可用的調度器，比如Fair Scheduler和Capacity Scheduler等。

• 應用程序管理器：應用程序管理器負責管理整個系統中所有應用程序，包括應用程序提交、與調度器協商資源以啟動ApplicationMaster、監控ApplicationMaster運行狀態并在失敗時重新啟動它等。

2）表示每個應用的ApplicationMaster（AM）

用戶提交的每個應用程序均包含一個AM，主要功能包括：

•  與RM調度器協商以獲取資源（用Container表示）；

•  將得到的任務進一步分配給內部的任務(資源的二次分配)；

• 與NM通信以啟動/停止任務；

•  監控所有任務運行狀態，并在任務運行失敗時重新為任務申請資源以重啟任務。

3）資源管理器的節點代理NodeManager（NM）

 NM是每個節點上的資源和任務管理器，一方面，它會定時地向RM匯報本節點上的資源使用情況和各個Container的運行狀態；另一方面，它接收并處理來自AM的Container啟動/停止等各種請求。

4）運行在節點代理上的Container

 Container是YARN中的資源抽象，它封裝了某個節點上的多維度資源，如內存、CPU、磁盤、網絡等，當AM向RM申請資源時，RM為AM返回的資源便是用Container表示。YARN會為每個任務分配一個Container，且該任務只能使用該Container中描述的資源。

集群處理模型改變產生的意義

 ResourceManager、NodeManager 和容器都不關心應用程序或任務的類型。所有特定于應用程序框架的代碼都轉移到它的 ApplicationMaster，以便任何分布式框架都可以受 YARN 支持 — 只要有人為它實現了相應的 ApplicationMaster。

 得益于這個一般性的方法，Hadoop YARN 集群運行許多不同工作負載的夢想才得以實現。想像一下：您數據中心中的一個 Hadoop 集群可運行 MapReduce、Giraph、Storm、Spark、Tez/Impala、MPI 等。

單一集群方法明顯提供了大量優勢，其中包括：

•  更高的集群利用率，一個框架未使用的資源可由另一個框架使用

•  更低的操作成本，因為只有一個 “包辦一切的” 集群需要管理和調節

•  更少的數據移動，無需在 Hadoop YARN 與在不同機器集群上運行的系統之間移動數據

 管理單個集群還會得到一個更環保的數據處理解決方案。使用的數據中心空間更少，浪費的硅片更少，使用的電源更少，排放的碳更少，這只是因為我們在更小但更高效的 Hadoop 集群上運行同樣的計算。