（1） YARN

下一代MapReduce框架的名稱赶促，為了容易記憶愕秫，一般稱為MRv2（MapReduce version 2）慨菱。該框架已經(jīng)不再是一個(gè)傳統(tǒng)的MapReduce框架，甚至與MapReduce無關(guān)戴甩，她是一個(gè)通用的運(yùn)行時(shí)框架符喝，用戶可以編寫自己的計(jì)算框架，在該運(yùn)行環(huán)境中運(yùn)行甜孤。用于自己編寫的框架作為客戶端的一個(gè)lib协饲，在運(yùn)用提交作業(yè)時(shí)打包即可。該框架為提供了以下幾個(gè)組件：

<1> 資源管理：包括應(yīng)用程序管理和機(jī)器資源管理

<2> 資源雙層調(diào)度

<3> 容錯(cuò)性：各個(gè)組件均有考慮容錯(cuò)性

<4> 擴(kuò)展性：可擴(kuò)展到上萬個(gè)節(jié)點(diǎn)

2） ResourceManager

簡稱“RM”缴川。

MRv2最基本的設(shè)計(jì)思想是將JobTracker的兩個(gè)主要功能茉稠，即資源管理和作業(yè)調(diào)度/監(jiān)控分成兩個(gè)獨(dú)立的進(jìn)程。在該解決方案中包含兩個(gè)組件：全局的ResourceManager（RM）和與每個(gè)應(yīng)用相關(guān)的ApplicationMaster（AM）二跋。這里的“應(yīng)用”指一個(gè)單獨(dú)的MapReduce作業(yè)或者DAG作業(yè)战惊。RM和與NodeManager（NM，每個(gè)節(jié)點(diǎn)一個(gè)）共同組成整個(gè)數(shù)據(jù)計(jì)算框架扎即。RM是系統(tǒng)中將資源分配給各個(gè)應(yīng)用的最終決策者。AM實(shí)際上是一個(gè)具體的框架庫况凉，它的任務(wù)是【與RM協(xié)商獲取應(yīng)用所需資源】和【與NM合作谚鄙，以完成執(zhí)行和監(jiān)控task的任務(wù)】。

RM有兩個(gè)組件組成：

調(diào)度器（Scheduler）

應(yīng)用管理器（ApplicationsManager刁绒，ASM）

調(diào)度器根據(jù)容量闷营，隊(duì)列等限制條件（如每個(gè)隊(duì)列分配一定的資源，最多執(zhí)行一定數(shù)量的作業(yè)等）知市，將系統(tǒng)中的資源分配給各個(gè)正在運(yùn)行的應(yīng)用傻盟。這里的調(diào)度器是一個(gè)“純調(diào)度器”，因?yàn)樗辉儇?fù)責(zé)監(jiān)控或者跟蹤應(yīng)用的執(zhí)行狀態(tài)等嫂丙，此外娘赴，他也不負(fù)責(zé)重新啟動(dòng)因應(yīng)用執(zhí)行失敗或者硬件故障而產(chǎn)生的失敗任務(wù)。調(diào)度器僅根據(jù)各個(gè)應(yīng)用的資源需求進(jìn)行調(diào)度跟啤，這是通過抽象概念“資源容器”完成的诽表，資源容器（Resource Container）將內(nèi)存唉锌，CPU，磁盤竿奏，網(wǎng)絡(luò)等資源封裝在一起袄简，從而限定每個(gè)任務(wù)使用的資源量。

調(diào)度器內(nèi)嵌有策略可插拔的插件泛啸，主要負(fù)責(zé)將集群中得資源分配給多個(gè)隊(duì)列和應(yīng)用绿语。當(dāng)前MapReduce的調(diào)度器，如Capacity Scheduler和Fair Scheduler候址，均可作為該插件吕粹。

（3）NodeManager

簡稱“NM”。

NM是每個(gè)節(jié)點(diǎn)上的框架代理宗雇，主要負(fù)責(zé)啟動(dòng)應(yīng)用所需的容器昂芜，監(jiān)控資源（內(nèi)存，CPU赔蒲，磁盤泌神，網(wǎng)絡(luò)等）的使用情況并將之匯報(bào)給調(diào)度器。

一句話：“NM主要用于管理某個(gè)節(jié)點(diǎn)上的task和資源”舞虱。

（4）ApplicationsManager

簡稱“ASM”欢际。

ASM主要負(fù)責(zé)接收作業(yè)，協(xié)商獲取第一個(gè)容器用于執(zhí)行AM和提供重啟失敗AM container的服務(wù)矾兜。

一句話：“ASM主要用于管理AM”损趋。

（5）ApplicationMaster

簡稱“AM”。

AM主要負(fù)責(zé)同調(diào)度器協(xié)商以獲取合適的容器椅寺，并跟蹤這些容器的狀態(tài)和監(jiān)控其進(jìn)度浑槽。

一句話：“AM主要用于管理其對應(yīng)的應(yīng)用程序，如MapReduce作業(yè)返帕，DAG作業(yè)等”桐玻。

（6） Container

容器中封裝了機(jī)器資源，如內(nèi)存荆萤，CPU, 磁盤镊靴，網(wǎng)絡(luò)等，每個(gè)任務(wù)會(huì)被分配一個(gè)容器链韭，該任務(wù)只能在該容器中執(zhí)行偏竟，并使用該容器封裝的資源。

怎樣將某個(gè)計(jì)算框架（MapReduce敞峭，HAMA踊谋，Giraph）部署到Y(jié)ARN中？

答：需要編寫一個(gè)ApplicaionMaster儡陨。

MRv2最基本的設(shè)計(jì)思想是將JobTracker的兩個(gè)主要功能褪子，即資源管理和作業(yè)調(diào)度/監(jiān)控分成兩個(gè)獨(dú)立的進(jìn)程量淌。在該解決方案中包含兩個(gè)組件：全局的ResourceManager（RM）和與每個(gè)應(yīng)用相關(guān)的ApplicationMaster（AM）。這里的“應(yīng)用”指一個(gè)單獨(dú)的MapReduce作業(yè)或者DAG作業(yè)嫌褪。RM和與NodeManager（NM呀枢，每個(gè)節(jié)點(diǎn)一個(gè)）共同組成整個(gè)數(shù)據(jù)計(jì)算框架。RM是系統(tǒng)中將資源分配給各個(gè)應(yīng)用的最終決策者笼痛。AM實(shí)際上是一個(gè)具體的框架庫裙秋，它的任務(wù)是【與RM協(xié)商獲取應(yīng)用所需資源】和【與NM合作，以完成執(zhí)行和監(jiān)控task的任務(wù)】缨伊。

RM有兩個(gè)組件組成：

調(diào)度器（Scheduler）

應(yīng)用管理器（ApplicationsManager摘刑，ASM）

調(diào)度器根據(jù)容量，隊(duì)列等限制條件（如每個(gè)隊(duì)列分配一定的資源刻坊，最多執(zhí)行一定數(shù)量的作業(yè)等）枷恕，將系統(tǒng)中的資源分配給各個(gè)正在運(yùn)行的應(yīng)用。這里的調(diào)度器是一個(gè)“純調(diào)度器”谭胚，因?yàn)樗辉儇?fù)責(zé)監(jiān)控或者跟蹤應(yīng)用的執(zhí)行狀態(tài)等徐块，此外，他也不負(fù)責(zé)重新啟動(dòng)因應(yīng)用執(zhí)行失敗或者硬件故障而產(chǎn)生的失敗任務(wù)灾而。調(diào)度器僅根據(jù)各個(gè)應(yīng)用的資源需求進(jìn)行調(diào)度胡控，這是通過抽象概念“資源容器”完成的，資源容器（Resource Container）將內(nèi)存旁趟，CPU昼激，磁盤，網(wǎng)絡(luò)等資源封裝在一起锡搜，從而限定每個(gè)任務(wù)使用的資源量橙困。（注：Hadoop-0.23.0【資料一， 資料二】中的Container采用了“監(jiān)控linux進(jìn)程”來限制每個(gè)任務(wù)的資源耕餐，即：有個(gè)監(jiān)控線程周期性地從linux虛擬文件系統(tǒng)/proc/中讀取相應(yīng)進(jìn)程樹使用的資源總量纷宇，一旦檢測到超出限制，則直接kill該task蛾方，今后的版本想嚴(yán)格限制內(nèi)存，CPU上陕，網(wǎng)絡(luò)桩砰，磁盤等資源。

調(diào)度器是可插拔的組件释簿，主要負(fù)責(zé)將集群中得資源分配給多個(gè)隊(duì)列和應(yīng)用亚隅。YARN自帶了多個(gè)資源調(diào)度器，如Capacity Scheduler和Fair Scheduler等庶溶。

ASM主要負(fù)責(zé)接收作業(yè)煮纵，協(xié)商獲取第一個(gè)容器用于執(zhí)行AM和提供重啟失敗AM container的服務(wù)懂鸵。

NM是每個(gè)節(jié)點(diǎn)上的框架代理，主要負(fù)責(zé)啟動(dòng)應(yīng)用所需的容器行疏，監(jiān)控資源（內(nèi)存匆光，CPU，磁盤酿联，網(wǎng)絡(luò)等）的使用情況并將之匯報(bào)給調(diào)度器终息。

AM主要負(fù)責(zé)同調(diào)度器協(xié)商以獲取合適的容器，并跟蹤這些容器的狀態(tài)和監(jiān)控其進(jìn)度贞让。

【Resource Manager】資源模型在YARN 1.0中周崭，調(diào)度器僅考慮了內(nèi)存資源。 每個(gè)節(jié)點(diǎn)由多個(gè)固定內(nèi)存大性拧（512MB或者1GB）的容器組成续镇。AM可以申請?jiān)搩?nèi)存整數(shù)倍大小的容器。YARN最終會(huì)提供一個(gè)更加通用的資源模型销部，但在Yarn V1中摸航，僅提供了一個(gè)相當(dāng)直接的模型：“資源模型完全是基于內(nèi)存的，且每個(gè)節(jié)點(diǎn)由若干個(gè)離散的內(nèi)存塊（chunk of memory）組成”柴墩。與Hadoop MapReduce不同忙厌，MRv2并沒有人為的將集群資源分成map slot和reduce slot。MRv2中的每個(gè)內(nèi)存塊是可互換的江咳，這就提高了集群利用率—當(dāng)前Hadoop MapReduce的一個(gè)最大問題是由于缺乏資源互換逢净，作業(yè)會(huì)在reduce slot上存在瓶頸。（“互換”的意思是資源是對等的歼指，所有資源形成一個(gè)資源池爹土，任務(wù)可以從資源池中申請任意的資源，這就提高了資源利用率）對上一端進(jìn)一步解釋：在當(dāng)前Hadoop MapReduce中踩身，集群資源會(huì)被切分成map slot和reduce slot胀茵。在每個(gè)TaskTracker上，管理員可配置若干個(gè)map slot和reduce slot挟阻，slot可看做是令牌琼娘，map task拿到一個(gè)map slot后才可以運(yùn)行（對于reduce task類似）。而管理員一般只根據(jù)CPU個(gè)數(shù)配置slot個(gè)數(shù)時(shí)附鸽，如果CPU個(gè)數(shù)為12脱拼，則可配置8個(gè)map slot，4個(gè)reduce slot坷备。這會(huì)導(dǎo)致兩個(gè)問題：（1）實(shí)際的計(jì)算資源不僅僅是CPU熄浓，還有內(nèi)存，磁盤和網(wǎng)絡(luò)等省撑，這些均需要考慮赌蔑，只考慮某一種資源勢必會(huì)造成機(jī)器擁塞俯在，這在共享集群環(huán)境下表現(xiàn)尤為顯著；（2）MapReduce計(jì)算流程是兩階段的娃惯，而這兩個(gè)階段存在依賴性：reduce task不會(huì)進(jìn)入sort和reduce階段跷乐，直到全部map task計(jì)算完成，而實(shí)際計(jì)算時(shí)石景，map task完成一定的比例劈猿，便會(huì)啟動(dòng)reduce task，此時(shí)啟動(dòng)的reduce task全部處于shuffle階段潮孽，經(jīng)常會(huì)走走停停揪荣，導(dǎo)致該map slot資源利用率非常低。在Yarn中往史，任何一個(gè)應(yīng)用可申請任何內(nèi)存大小合理（合理是指內(nèi)存大小必須是memory chunck的整數(shù)倍）的容器仗颈，也可以申請各種類型的容器。資源協(xié)商每個(gè)AM使用資源描述來申請一系列容器椎例，其中可能包括一些特殊需求的機(jī)器挨决。它也可以申請同一個(gè)機(jī)器上的多個(gè)容器。所有的資源請求是受應(yīng)用程序容量订歪，隊(duì)列容量等限制的脖祈。AM負(fù)責(zé)計(jì)算應(yīng)用程序所需的資源量，比如MapReduce的input-splits刷晋，并把他們轉(zhuǎn)化成調(diào)度器可以理解的協(xié)議盖高。當(dāng)前調(diào)度器可理解的協(xié)議是。以MapReduce為例眼虱，MapReduce AM分析input-splis喻奥，并將之轉(zhuǎn)化成以host為key的轉(zhuǎn)置表發(fā)送給RM。下圖為一個(gè)典型的AM資源請求：調(diào)度器會(huì)盡量匹配該表中的資源捏悬；如果某個(gè)特定機(jī)器上的資源是不可用的撞蚕，調(diào)度器會(huì)提供同一個(gè)機(jī)架或者不同機(jī)架上的等量資源代替之。有些情況下过牙，由于整個(gè)集群非常忙碌甥厦，AM獲取的資源可能不是最合適的，此時(shí)它可以拒絕這些資源并請求重新分配寇钉。調(diào)度調(diào)度器收集所有正在運(yùn)行的應(yīng)用程序的資源請求并構(gòu)建一個(gè)全局規(guī)劃進(jìn)行資源分配矫渔。調(diào)度器會(huì)根據(jù)應(yīng)用程序相關(guān)的約束（如合適的機(jī)器）和全局約束（如隊(duì)列資源總量，用戶可提交作業(yè)總數(shù)等）分配資源摧莽。調(diào)度器使用與容量調(diào)度類似的概念陨溅，采用容量保證作為基本的策略在多個(gè)應(yīng)用程序間分配資源仅炊。調(diào)度器的調(diào)度策略如下：選擇系統(tǒng)中“服務(wù)最低”的隊(duì)列（如何定義服務(wù)最低？可以是資源利用量最低的隊(duì)列，即：已使用的資源與總共可用資源比值最械倘纭）從該隊(duì)列中選擇優(yōu)先級最高的作業(yè)盡量滿足該作業(yè)的資源請求調(diào)度器APIYarn 調(diào)度器與AM之間僅有一個(gè)API：Response allocate (Listask, Listrelease)

AM使用一個(gè)ResourceRequest列表請求特定資源，并同時(shí)可要求釋放一些調(diào)度器已經(jīng)分配的容器鸣剪。

Response包含三方面內(nèi)容：新分配的容器列表俏扩，自從上次AM與RM交互以來已經(jīng)計(jì)算完成的容器的狀態(tài)（包含該容器中運(yùn)行task的詳細(xì)信息），當(dāng)前集群中剩余資源量卖哎。 AM收集完成容器的信息并對失敗的任務(wù)作出反應(yīng)鬼悠。資源剩余量可用于AM調(diào)整接下來的資源請求，如MapReduce AM可使用該信息以合理調(diào)度maps和reduces從而防止產(chǎn)生死鎖亏娜。（何以“死鎖”焕窝？在MapReduce框架中，如果將所有資源分配給了map task维贺，則可能會(huì)造成reduce? task饑餓它掂，需要合理調(diào)整map資源和reduce 資源的比例）

資源監(jiān)控

調(diào)度器周期性地收到NM所在節(jié)點(diǎn)的資源變化信息，同時(shí)溯泣，調(diào)度器會(huì)將已使用完的容器分配重新分給合適的AM虐秋。

AM的生命周期

ASM負(fù)責(zé)管理系統(tǒng)中所有應(yīng)用程序的AM，正如上一節(jié)所述垃沦，ASM負(fù)責(zé)啟動(dòng)AM客给，監(jiān)控AM的運(yùn)行狀態(tài)，在AM失敗時(shí)對其進(jìn)行重啟等肢簿。

為了完成該功能靶剑，ASM主要有以下幾個(gè)組件：

（1） SchedulerNegotiator：與調(diào)度器協(xié)商容器資源，并返回給AM

（2）AMContainerManager：告知NM译仗，啟動(dòng)或者停止某個(gè)AM的容器

（3）? AMMonitor：查看AM是否活著抬虽，并在必要的時(shí)候重啟AM

【NodeManager】

每個(gè)節(jié)點(diǎn)上裝有一個(gè)NM，主要的職責(zé)有：

（1）為應(yīng)用程序啟動(dòng)容器纵菌，同時(shí)確保申請的容器使用的資源不會(huì)超過節(jié)點(diǎn)上的總資源阐污。

（2）為task構(gòu)建容器環(huán)境，包括二進(jìn)制可執(zhí)行文件咱圆，jars等

（3）為所在的節(jié)點(diǎn)提供了一個(gè)管理本地存儲(chǔ)資源的簡單服務(wù)笛辟，應(yīng)用程序可以繼續(xù)使用本地存儲(chǔ)資源即使他沒有從RM那申請。比如：MapReduce可以使用該服務(wù)程序存儲(chǔ)map task的中間輸出結(jié)果序苏。

【ApplicationMaster】

每個(gè)應(yīng)用程序均會(huì)有一個(gè)AM手幢，主要職責(zé)有：

（1）? 與調(diào)度器協(xié)商資源

（2）? 與NM合作，在合適的容器中運(yùn)行對應(yīng)的task忱详，并監(jiān)控這些task執(zhí)行

（3） 如果container出現(xiàn)故障围来，AM會(huì)重新向調(diào)度器申請資源

（4）? 計(jì)算應(yīng)用程序所需的資源量，并轉(zhuǎn)化成調(diào)度器可識別的格式（協(xié)議）

（5）? AM出現(xiàn)故障后，ASM會(huì)重啟它监透，而由AM自己從之前保存的應(yīng)用程序執(zhí)行狀態(tài)中恢復(fù)應(yīng)用程序桶错。

注：在MapReduce中，由于AM會(huì)定時(shí)的保存job的運(yùn)行時(shí)狀態(tài)胀蛮，因此院刁，當(dāng)AM重啟時(shí)可以恢復(fù)對應(yīng)的job，按照粒度有三種策略：

<1>整個(gè)作業(yè)重新計(jì)算

<2> 保存已經(jīng)完成的map task和reduce task粪狼，只重新計(jì)算未完成的task

YARN的資源管理器實(shí)際上是一個(gè)事件處理器退腥，它需要處理來自外部的6種SchedulerEvent類型的事件，并根據(jù)事件的具體含義進(jìn)行相應(yīng)的處理再榄。這6種事件含義如下：

（1）? NODE_REMOVED

事件NODE_REMOVED表示集群中被移除一個(gè)計(jì)算節(jié)點(diǎn)（可能是節(jié)點(diǎn)故障或者管理員主動(dòng)移除）狡刘，資源調(diào)度器收到該事件時(shí)需要從可分配資源總量中移除相應(yīng)的資源量。

（2） NODE_ADDED

事件NODE_ADDED表示集群中增加了一個(gè)計(jì)算節(jié)點(diǎn)不跟，資源調(diào)度器收到該事件時(shí)需要將新增的資源量添加到可分配資源總量中颓帝。

（3）APPLICATION_ADDED

事件APPLICATION_ADDED 表示ResourceManager收到一個(gè)新的Application。通常而言窝革，資源管理器需要為每個(gè)application維護(hù)一個(gè)獨(dú)立的數(shù)據(jù)結(jié)構(gòu)购城，以便于統(tǒng)一管理和資源分配。資源管理器需將該Application添加到相應(yīng)的數(shù)據(jù)結(jié)構(gòu)中虐译。

（4）APPLICATION_REMOVED

事件APPLICATION_REMOVED表示一個(gè)Application運(yùn)行結(jié)束（可能成功或者失敱癜濉），資源管理器需將該Application從相應(yīng)的數(shù)據(jù)結(jié)構(gòu)中清除漆诽。

（5） CONTAINER_EXPIRED

當(dāng)資源調(diào)度器將一個(gè)container分配給某個(gè)ApplicationMaster后侮攀，如果該ApplicationMaster在一定時(shí)間間隔內(nèi)沒有使用該container，則資源調(diào)度器會(huì)對該container進(jìn)行再分配厢拭。

（6）NODE_UPDATE

NodeManager通過心跳機(jī)制向ResourceManager匯報(bào)各個(gè)container運(yùn)行情況兰英，會(huì)觸發(fā)一個(gè)NODE_UDDATE事件，由于此時(shí)可能有新的container得到釋放供鸠，因此該事件會(huì)觸發(fā)資源分配畦贸，也就是說，該事件是6個(gè)事件中最重要的事件楞捂，它會(huì)觸發(fā)資源調(diào)度器最核心的資源分配機(jī)制薄坏。

YARN對內(nèi)存資源和CPU資源采用了不同的資源隔離方案。對于內(nèi)存資源寨闹，為了能夠更靈活的控制內(nèi)存使用量胶坠，YARN采用了進(jìn)程監(jiān)控的方案控制內(nèi)存使用，即每個(gè)NodeManager會(huì)啟動(dòng)一個(gè)額外監(jiān)控線程監(jiān)控每個(gè)container內(nèi)存資源使用量繁堡，一旦發(fā)現(xiàn)它超過約定的資源量沈善，則會(huì)將其殺死乡数。采用這種機(jī)制的另一個(gè)原因是Java中創(chuàng)建子進(jìn)程采用了fork()+exec()的方案，子進(jìn)程啟動(dòng)瞬間矮瘟，它使用的內(nèi)存量與父進(jìn)程一致瞳脓，從外面看來，一個(gè)進(jìn)程使用內(nèi)存量可能瞬間翻倍澈侠，然后又降下來，采用線程監(jiān)控的方法可防止這種情況下導(dǎo)致swap操作埋酬。對于CPU資源哨啃，則采用了Cgroups進(jìn)行資源隔離。

資源分配模型

在YARN中写妥，用戶以隊(duì)列的形式組織拳球，每個(gè)用戶可屬于一個(gè)或多個(gè)隊(duì)列，且只能向這些隊(duì)列中提交application珍特。每個(gè)隊(duì)列被劃分了一定比例的資源祝峻。

YARN的資源分配過程是異步的，也就是說扎筒，資源調(diào)度器將資源分配給一個(gè)application后莱找，不會(huì)立刻push給對應(yīng)的ApplicaitonMaster，而是暫時(shí)放到一個(gè)緩沖區(qū)中嗜桌，等待ApplicationMaster通過周期性的RPC函數(shù)主動(dòng)來取奥溺，也就是說，采用了pull-based模型骨宠，而不是push-based模型浮定，這個(gè)與MRv1是一致的。

總結(jié)

相比于MRv1中的資源調(diào)度器层亿，盡管YANR的調(diào)度器也是插拔式的桦卒，但由于YARN采用了事件驅(qū)動(dòng)的模型，因此編寫起來更加復(fù)雜匿又，難度也遠(yuǎn)遠(yuǎn)大于MRv1方灾。

同MRv1一樣，YARN也自帶了三種常用的調(diào)度器琳省，分別是FIFO迎吵，Capacity Scheduler和Fair Scheduler，其中针贬，第一個(gè)是默認(rèn)的調(diào)度器击费，它屬于批處理調(diào)度器，而后兩個(gè)屬于多租戶調(diào)度器桦他，它采用樹形多隊(duì)列的形式組織資源蔫巩，更適合公司應(yīng)用場景谆棱。