經(jīng)典 MapReduce 的局限性：

 經(jīng)典 MapReduce 的最嚴(yán)重的限制主要關(guān)系到可伸縮性、資源利用和對與 MapReduce 不同的工作負(fù)載的支持。在 MapReduce 框架中，作業(yè)執(zhí)行受兩種類型的進(jìn)程控制：

• 一個稱為JobTracker的主要進(jìn)程，它協(xié)調(diào)在集群上運行的所有作業(yè)，分配要在 TaskTracker 上運行的 map 和 reduce 任務(wù)。

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

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

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

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

YARN與經(jīng)典 MapReduce的變化：

YARN 是下一代 Hadoop 計算平臺，它進(jìn)行了如下改變：

• ResourceManager 代替集群管理器

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

•  NodeManager 代替 TaskTracker

•  一個分布式應(yīng)用程序代替一個 MapReduce 作業(yè)

YARN主要架構(gòu)解析：

1）全局管理的ResourceManager（RM）

 RM是一個全局的資源管理器，負(fù)責(zé)整個系統(tǒng)的資源管理和分配。它主要由兩個組件構(gòu)成：調(diào)度器（Scheduler）和應(yīng)用程序管理器（Applications Manager，ASM）。

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

• 應(yīng)用程序管理器：應(yīng)用程序管理器負(fù)責(zé)管理整個系統(tǒng)中所有應(yīng)用程序，包括應(yīng)用程序提交、與調(diào)度器協(xié)商資源以啟動ApplicationMaster、監(jiān)控ApplicationMaster運行狀態(tài)并在失敗時重新啟動它等。

2）表示每個應(yīng)用的ApplicationMaster（AM）

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

•  與RM調(diào)度器協(xié)商以獲取資源（用Container表示）；

•  將得到的任務(wù)進(jìn)一步分配給內(nèi)部的任務(wù)(資源的二次分配)；

• 與NM通信以啟動/停止任務(wù)；

•  監(jiān)控所有任務(wù)運行狀態(tài)，并在任務(wù)運行失敗時重新為任務(wù)申請資源以重啟任務(wù)。

3）資源管理器的節(jié)點代理NodeManager（NM）

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

4）運行在節(jié)點代理上的Container

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

集群處理模型改變產(chǎn)生的意義

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

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

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

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

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

•  更少的數(shù)據(jù)移動，無需在 Hadoop YARN 與在不同機(jī)器集群上運行的系統(tǒng)之間移動數(shù)據(jù)

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