apReduce 的第一個(gè)版本既有優(yōu)點(diǎn)也有缺點(diǎn)。MRv1 是目前使用的標(biāo)準(zhǔn)的大數(shù)據(jù)處理系統(tǒng)。但是，這種架構(gòu)存在不足，主要表現(xiàn)在大型集群上。當(dāng)集群包含的節(jié)點(diǎn)超過 4,000 個(gè)時(shí)（其中每個(gè)節(jié)點(diǎn)可能是多核的），就會(huì)表現(xiàn)出一定的不可預(yù)測性。其中一個(gè)最大的問題是級(jí)聯(lián)故障，由于要嘗試復(fù)制數(shù)據(jù)和重載活動(dòng)的節(jié)點(diǎn)，所以一個(gè)故障會(huì)通過網(wǎng)絡(luò)泛洪形式導(dǎo)致整個(gè)集群嚴(yán)重惡化。
但 MRv1 的最大問題是多租戶。隨著集群規(guī)模的增加，一種可取的方式是為這些集群采用各種不同的模型。MRv1 的節(jié)點(diǎn)專用于 Hadoop，所以可以改變它們的用途以用于其他應(yīng)用程序和工作負(fù)載。當(dāng)大數(shù)據(jù)和 Hadoop 成為云部署中一個(gè)更重要的使用模型時(shí)，這種能力也會(huì)增強(qiáng)，因?yàn)樗试S在服務(wù)器上對(duì) Hadoop 進(jìn)行物理化，而無需虛擬化且不會(huì)增加管理、計(jì)算和輸入/輸出開銷。
我們現(xiàn)在看看 YARN 的新架構(gòu)，看看它如何支持 MRv2 和其他使用不同處理模型的應(yīng)用程序。
YARN (MRv2) 簡介
為了實(shí)現(xiàn)一個(gè) Hadoop 集群的集群共享、可伸縮性和可靠性。設(shè)計(jì)人員采用了一種分層的集群框架方法。具體來講，特定于 MapReduce 的功能已替換為一組新的守護(hù)程序，將該框架向新的處理模型開放。
回想一下，由于限制了擴(kuò)展以及網(wǎng)絡(luò)開銷所導(dǎo)致的某些故障模式，MRv1 JobTracker 和 TaskTracker 方法曾是一個(gè)重要的缺陷。這些守護(hù)程序也是 MapReduce 處理模型所獨(dú)有的。為了消除這一限制，JobTracker 和 TaskTracker 已從 YARN 中刪除，取而代之的是一組對(duì)應(yīng)用程序不可知的新守護(hù)程序。
圖 2. YARN 的新架構(gòu)
YARN 分層結(jié)構(gòu)的本質(zhì)是 ResourceManager。這個(gè)實(shí)體控制整個(gè)集群并管理應(yīng)用程序向基礎(chǔ)計(jì)算資源的分配。ResourceManager 將各個(gè)資源部分（計(jì)算、內(nèi)存、帶寬等）精心安排給基礎(chǔ) NodeManager（YARN 的每節(jié)點(diǎn)代理）。ResourceManager 還與 ApplicationMaster 一起分配資源，與 NodeManager 一起啟動(dòng)和監(jiān)視它們的基礎(chǔ)應(yīng)用程序。在此上下文中，ApplicationMaster 承擔(dān)了以前的 TaskTracker 的一些角色，ResourceManager 承擔(dān)了 JobTracker 的角色。
ApplicationMaster 管理一個(gè)在 YARN 內(nèi)運(yùn)行的應(yīng)用程序的每個(gè)實(shí)例。ApplicationMaster 負(fù)責(zé)協(xié)調(diào)來自 ResourceManager 的資源，并通過 NodeManager 監(jiān)視容器的執(zhí)行和資源使用（CPU、內(nèi)存等的資源分配）。請注意，盡管目前的資源更加傳統(tǒng)（CPU 核心、內(nèi)存），但未來會(huì)帶來基于手頭任務(wù)的新資源類型（比如圖形處理單元或?qū)Ｓ锰幚碓O(shè)備）。從 YARN 角度講，ApplicationMaster 是用戶代碼，因此存在潛在的安全問題。YARN 假設(shè) ApplicationMaster 存在錯(cuò)誤或者甚至是惡意的，因此將它們當(dāng)作無特權(quán)的代碼對(duì)待。