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

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

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

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

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

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

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

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

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

• ResourceManager 代替集群管理器

• ApplicationMaster 代替一個(gè)專用且短暫的 JobTracker

• NodeManager 代替 TaskTracker

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

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

1）全局管理的ResourceManager（RM）

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

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

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

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

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

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

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

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

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

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

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

4）運(yùn)行在節(jié)點(diǎn)代理上的Container

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

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

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

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

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

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

• 更低的操作成本，因?yàn)橹挥幸粋€(gè) “包辦一切的” 集群需要管理和調(diào)節(jié)

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

管理單個(gè)集群還會(huì)得到一個(gè)更環(huán)保的數(shù)據(jù)處理解決方案。使用的數(shù)據(jù)中心空間更少，浪費(fèi)的硅片更少，使用的電源更少，排放的碳更少，這只是因?yàn)槲覀冊(cè)诟〉咝У?Hadoop 集群上運(yùn)行同樣的計(jì)算。