（1） YARN
下一代MapReduce框架的名稱(chēng)，為了容易記憶，一般稱(chēng)為MRv2（MapReduce version 2）。該框架已經(jīng)不再是一個(gè)傳統(tǒng)的MapReduce框架，甚至與MapReduce無(wú)關(guān)，她是一個(gè)通用的運(yùn)行時(shí)框架，用戶(hù)可以編寫(xiě)自己的計(jì)算框架，在該運(yùn)行環(huán)境中運(yùn)行。用于自己編寫(xiě)的框架作為客戶(hù)端的一個(gè)lib，在運(yùn)用提交作業(yè)時(shí)打包即可。該框架為提供了以下幾個(gè)組件：
<1> 資源管理：包括應(yīng)用程序管理和機(jī)器資源管理
<2> 資源雙層調(diào)度
<3> 容錯(cuò)性：各個(gè)組件均有考慮容錯(cuò)性
<4> 擴(kuò)展性：可擴(kuò)展到上萬(wàn)個(gè)節(jié)點(diǎn)
2） ResourceManager
簡(jiǎn)稱(chēng)“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è)具體的框架庫(kù)，它的任務(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)度，這是通過(guò)抽象概念“資源容器”完成的，資源容器（Resource Container）將內(nèi)存，CPU，磁盤(pán)，網(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
簡(jiǎn)稱(chēng)“NM”。
NM是每個(gè)節(jié)點(diǎn)上的框架代理，主要負(fù)責(zé)啟動(dòng)應(yīng)用所需的容器，監(jiān)控資源（內(nèi)存，CPU，磁盤(pán)，網(wǎng)絡(luò)等）的使用情況并將之匯報(bào)給調(diào)度器。
一句話(huà)：“NM主要用于管理某個(gè)節(jié)點(diǎn)上的task和資源”。
（4）ApplicationsManager
簡(jiǎn)稱(chēng)“ASM”。
ASM主要負(fù)責(zé)接收作業(yè)，協(xié)商獲取第一個(gè)容器用于執(zhí)行AM和提供重啟失敗AM container的服務(wù)。
一句話(huà)：“ASM主要用于管理AM”。
（5）ApplicationMaster
簡(jiǎn)稱(chēng)“AM”。
AM主要負(fù)責(zé)同調(diào)度器協(xié)商以獲取合適的容器，并跟蹤這些容器的狀態(tài)和監(jiān)控其進(jìn)度。
一句話(huà)：“AM主要用于管理其對(duì)應(yīng)的應(yīng)用程序，如MapReduce作業(yè)，DAG作業(yè)等”。
（6） Container
容器中封裝了機(jī)器資源，如內(nèi)存，CPU, 磁盤(pán)，網(wǎng)絡(luò)等，每個(gè)任務(wù)會(huì)被分配一個(gè)容器，該任務(wù)只能在該容器中執(zhí)行，并使用該容器封裝的資源。
怎樣將某個(gè)計(jì)算框架（MapReduce，HAMA，Giraph）部署到Y(jié)ARN中？
答：需要編寫(xiě)一個(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è)具體的框架庫(kù)，它的任務(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)度，這是通過(guò)抽象概念“資源容器”完成的，資源容器（Resource Container）將內(nèi)存，CPU，磁盤(pán)，網(wǎng)絡(luò)等資源封裝在一起，從而限定每個(gè)任務(wù)使用的資源量。（注：Hadoop-0.23.0【資料一， 資料二】中的Container采用了“監(jiān)控linux進(jìn)程”來(lái)限制每個(gè)任務(wù)的資源，即：有個(gè)監(jiān)控線程周期性地從linux虛擬文件系統(tǒng)/proc/中讀取相應(yīng)進(jìn)程樹(shù)使用的資源總量，一旦檢測(cè)到超出限制，則直接kill該task，今后的版本想嚴(yán)格限制內(nèi)存，CPU，網(wǎng)絡(luò)，磁盤(pán)等資源。
調(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，磁盤(pán)，網(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可以申請(qǐng)?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并沒(méi)有人為的將集群資源分成map slot和reduce slot。MRv2中的每個(gè)內(nèi)存塊是可互換的，這就提高了集群利用率—當(dāng)前Hadoop MapReduce的一個(gè)最大問(wèn)題是由于缺乏資源互換，作業(yè)會(huì)在reduce slot上存在瓶頸。（“互換”的意思是資源是對(duì)等的，所有資源形成一個(gè)資源池，任務(wù)可以從資源池中申請(qǐng)任意的資源，這就提高了資源利用率）對(duì)上一端進(jìn)一步解釋?zhuā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)行（對(duì)于reduce task類(lèi)似）。而管理員一般只根據(jù)CPU個(gè)數(shù)配置slot個(gè)數(shù)時(shí)，如果CPU個(gè)數(shù)為12，則可配置8個(gè)map slot，4個(gè)reduce slot。這會(huì)導(dǎo)致兩個(gè)問(wèn)題：（1）實(shí)際的計(jì)算資源不僅僅是CPU，還有內(nèi)存，磁盤(pán)和網(wǎng)絡(luò)等，這些均需要考慮，只考慮某一種資源勢(shì)必會(huì)造成機(jī)器擁塞，這在共享集群環(huán)境下表現(xiàn)尤為顯著；（2）MapReduce計(jì)算流程是兩階段的，而這兩個(gè)階段存在依賴(lài)性：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)用可申請(qǐng)任何內(nèi)存大小合理（合理是指內(nèi)存大小必須是memory chunck的整數(shù)倍）的容器，也可以申請(qǐng)各種類(lèi)型的容器。資源協(xié)商每個(gè)AM使用資源描述來(lái)申請(qǐng)一系列容器，其中可能包括一些特殊需求的機(jī)器。它也可以申請(qǐng)同一個(gè)機(jī)器上的多個(gè)容器。所有的資源請(qǐng)求是受應(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資源請(qǐng)求：調(diào)度器會(huì)盡量匹配該表中的資源；如果某個(gè)特定機(jī)器上的資源是不可用的，調(diào)度器會(huì)提供同一個(gè)機(jī)架或者不同機(jī)架上的等量資源代替之。有些情況下，由于整個(gè)集群非常忙碌，AM獲取的資源可能不是最合適的，此時(shí)它可以拒絕這些資源并請(qǐng)求重新分配。調(diào)度調(diào)度器收集所有正在運(yùn)行的應(yīng)用程序的資源請(qǐng)求并構(gòu)建一個(gè)全局規(guī)劃進(jìn)行資源分配。調(diào)度器會(huì)根據(jù)應(yīng)用程序相關(guān)的約束（如合適的機(jī)器）和全局約束（如隊(duì)列資源總量，用戶(hù)可提交作業(yè)總數(shù)等）分配資源。調(diào)度器使用與容量調(diào)度類(lèi)似的概念，采用容量保證作為基本的策略在多個(gè)應(yīng)用程序間分配資源。調(diào)度器的調(diào)度策略如下：選擇系統(tǒng)中“服務(wù)最低”的隊(duì)列（如何定義服務(wù)最低？可以是資源利用量最低的隊(duì)列，即：已使用的資源與總共可用資源比值最?。脑撽?duì)列中選擇優(yōu)先級(jí)最高的作業(yè)盡量滿(mǎn)足該作業(yè)的資源請(qǐng)求調(diào)度器APIYarn 調(diào)度器與AM之間僅有一個(gè)API：Response allocate (Listask, Listrelease)
AM使用一個(gè)ResourceRequest列表請(qǐng)求特定資源，并同時(shí)可要求釋放一些調(diào)度器已經(jīng)分配的容器。
Response包含三方面內(nèi)容：新分配的容器列表，自從上次AM與RM交互以來(lái)已經(jīng)計(jì)算完成的容器的狀態(tài)（包含該容器中運(yùn)行task的詳細(xì)信息），當(dāng)前集群中剩余資源量。 AM收集完成容器的信息并對(duì)失敗的任務(wù)作出反應(yīng)。資源剩余量可用于AM調(diào)整接下來(lái)的資源請(qǐng)求，如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í)對(duì)其進(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í)確保申請(qǐng)的容器使用的資源不會(huì)超過(guò)節(jié)點(diǎn)上的總資源。
（2）為task構(gòu)建容器環(huán)境，包括二進(jìn)制可執(zhí)行文件，jars等
（3）為所在的節(jié)點(diǎn)提供了一個(gè)管理本地存儲(chǔ)資源的簡(jiǎn)單服務(wù)，應(yīng)用程序可以繼續(xù)使用本地存儲(chǔ)資源即使他沒(méi)有從RM那申請(qǐng)。比如：MapReduce可以使用該服務(wù)程序存儲(chǔ)map task的中間輸出結(jié)果。
【ApplicationMaster】
每個(gè)應(yīng)用程序均會(huì)有一個(gè)AM，主要職責(zé)有：
（1）? 與調(diào)度器協(xié)商資源
（2）? 與NM合作，在合適的容器中運(yùn)行對(duì)應(yīng)的task，并監(jiān)控這些task執(zhí)行
（3） 如果container出現(xiàn)故障，AM會(huì)重新向調(diào)度器申請(qǐng)資源
（4）? 計(jì)算應(yīng)用程序所需的資源量，并轉(zhuǎn)化成調(diào)度器可識(shí)別的格式（協(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ù)對(duì)應(yīng)的job，按照粒度有三種策略：
<1>整個(gè)作業(yè)重新計(jì)算
<2> 保存已經(jīng)完成的map task和reduce task，只重新計(jì)算未完成的task
YARN的資源管理器實(shí)際上是一個(gè)事件處理器，它需要處理來(lái)自外部的6種SchedulerEvent類(lèi)型的事件，并根據(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)沒(méi)有使用該container，則資源調(diào)度器會(huì)對(duì)該container進(jìn)行再分配。
（6）NODE_UPDATE
NodeManager通過(guò)心跳機(jī)制向ResourceManager匯報(bào)各個(gè)container運(yùn)行情況，會(huì)觸發(fā)一個(gè)NODE_UDDATE事件，由于此時(shí)可能有新的container得到釋放，因此該事件會(huì)觸發(fā)資源分配，也就是說(shuō)，該事件是6個(gè)事件中最重要的事件，它會(huì)觸發(fā)資源調(diào)度器最核心的資源分配機(jī)制。
YARN對(duì)內(nèi)存資源和CPU資源采用了不同的資源隔離方案。對(duì)于內(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)它超過(guò)約定的資源量，則會(huì)將其殺死。采用這種機(jī)制的另一個(gè)原因是Java中創(chuàng)建子進(jìn)程采用了fork()+exec()的方案，子進(jìn)程啟動(dòng)瞬間，它使用的內(nèi)存量與父進(jìn)程一致，從外面看來(lái)，一個(gè)進(jìn)程使用內(nèi)存量可能瞬間翻倍，然后又降下來(lái)，采用線程監(jiān)控的方法可防止這種情況下導(dǎo)致swap操作。對(duì)于CPU資源，則采用了Cgroups進(jìn)行資源隔離。
資源分配模型
在YARN中，用戶(hù)以隊(duì)列的形式組織，每個(gè)用戶(hù)可屬于一個(gè)或多個(gè)隊(duì)列，且只能向這些隊(duì)列中提交application。每個(gè)隊(duì)列被劃分了一定比例的資源。
YARN的資源分配過(guò)程是異步的，也就是說(shuō)，資源調(diào)度器將資源分配給一個(gè)application后，不會(huì)立刻push給對(duì)應(yīng)的ApplicaitonMaster，而是暫時(shí)放到一個(gè)緩沖區(qū)中，等待ApplicationMaster通過(guò)周期性的RPC函數(shù)主動(dòng)來(lái)取，也就是說(shuō)，采用了pull-based模型，而不是push-based模型，這個(gè)與MRv1是一致的。
總結(jié)
相比于MRv1中的資源調(diào)度器，盡管YANR的調(diào)度器也是插拔式的，但由于YARN采用了事件驅(qū)動(dòng)的模型，因此編寫(xiě)起來(lái)更加復(fù)雜，難度也遠(yuǎn)遠(yuǎn)大于MRv1。
同MRv1一樣，YARN也自帶了三種常用的調(diào)度器，分別是FIFO，Capacity Scheduler和Fair Scheduler，其中，第一個(gè)是默認(rèn)的調(diào)度器，它屬于批處理調(diào)度器，而后兩個(gè)屬于多租戶(hù)調(diào)度器，它采用樹(shù)形多隊(duì)列的形式組織資源，更適合公司應(yīng)用場(chǎng)景。
