6.3 YARN資源調(diào)度器的基本架構(gòu)
6.3.2 資源表示模型
NodeManager啟動(dòng)時(shí)會(huì)向ResourceManager注冊(cè)，注冊(cè)信息中包含該節(jié)點(diǎn)可分配的CPU和內(nèi)存總量，這兩個(gè)值均可通過配置選項(xiàng)設(shè)置，具體如下：
- ?yarn.nodemanager.resource.memory-mb∑餐蹋可分配的物理內(nèi)存總量，默認(rèn)是8MB×1024，即8GB怨咪。
- ?yarn.nodemanager.vmem-pmem-ratio。任務(wù)使用單位物理內(nèi)存量對(duì)應(yīng)最多可使用的虛擬內(nèi)存量润匙，默認(rèn)值是2.1诗眨，表示每使用1MB的物理內(nèi)存，最多可以使用2.1MB的虛擬內(nèi)存總量孕讳。
- ?yarn.nodemanager.resource.cpu-vcores匠楚。可分配的虛擬CPU個(gè)數(shù)厂财，默認(rèn)是8芋簿。為了更細(xì)粒度地劃分CPU資源和考慮到CPU性能異構(gòu)性，YARN允許管理員根據(jù)實(shí)際需要和CPU性能將每個(gè)物理CPU劃分成若干個(gè)虛擬CPU璃饱，而管理員可為每個(gè)節(jié)點(diǎn)單獨(dú)配置可用的虛擬CPU個(gè)數(shù)益咬，且用戶提交應(yīng)用程序時(shí)，也可指定每個(gè)任務(wù)需要的虛擬CPU個(gè)數(shù)帜平。比如node1節(jié)點(diǎn)上有8個(gè)CPU幽告，node2上有16個(gè)CPU，且node1CPU性能是node2的2倍裆甩，那么可為這兩個(gè)節(jié)點(diǎn)配置相同數(shù)目的虛擬CPU個(gè)數(shù)冗锁，比如均為32。由于用戶設(shè)置虛擬CPU個(gè)數(shù)必須是整數(shù)嗤栓，每個(gè)任務(wù)至少使用node2的半個(gè)CPU（不能更少了）冻河。
（2）不支持的調(diào)度語義當(dāng)前不支持的調(diào)度語義包括：
?請(qǐng)求任意節(jié)點(diǎn)上的特定資源量。比如茉帅，請(qǐng)求任意節(jié)點(diǎn)上5個(gè)這樣的Container：虛擬CPU個(gè)數(shù)為3叨叙，內(nèi)存量為1GB。
?請(qǐng)求任意機(jī)架上的特定資源量堪澎。
?請(qǐng)求一組或幾組符合某種特質(zhì)的資源擂错。比如，請(qǐng)求來自兩個(gè)機(jī)架上的4個(gè)Container樱蛤，其中钮呀，一個(gè)機(jī)架上2個(gè)這樣的Container：虛擬CPU個(gè)數(shù)為2剑鞍，內(nèi)存量為2GB；
?超細(xì)粒度資源爽醋。比如CPU性能要求蚁署、綁定CPU等。
?動(dòng)態(tài)調(diào)整Container資源蚂四，應(yīng)允許根據(jù)需要?jiǎng)討B(tài)調(diào)整Container資源量（對(duì)于長作業(yè)尤其有用）光戈。
6.3.3 資源調(diào)度模型
（1）雙層資源調(diào)度模型YARN采用了雙層資源調(diào)度模型：
在第一層中，ResourceManager中的資源調(diào)度器將資源分配給各個(gè)ApplicationMaster遂赠；
在第二層中久妆，ApplicationMaster再進(jìn)一步將資源分配給它內(nèi)部的各個(gè)任務(wù)。本章所介紹的資源調(diào)度器主要關(guān)注的是第一層的調(diào)度問題解愤，至于第二層的調(diào)度策略镇饺，完全由用戶應(yīng)用程序自己決定
步驟1 NodeManager通過周期性心跳匯報(bào)節(jié)點(diǎn)信息。
步驟2 ResourceManager為NodeManager返回一個(gè)心跳應(yīng)答送讲，包括需釋放的Container列表等信息奸笤。
步驟3 ResourceManager收到來自NodeManager的信息后，會(huì)觸發(fā)一個(gè)NODE_UPDATE事件哼鬓。
步驟4 ResourceScheduler收到NODE_UPDATE事件后监右，會(huì)按照一定的策略將該節(jié)點(diǎn)上的資源（步驟2中有釋放的資源）分配各應(yīng)用程序，并將分配結(jié)果放到一個(gè)內(nèi)存數(shù)據(jù)結(jié)構(gòu)中异希。
步驟5 應(yīng)用程序的ApplicationMaster向ResourceManager發(fā)送周期性的心跳健盒，以領(lǐng)取最新分配的Container。
步驟6 ResourceManager收到來自ApplicationMaster心跳信息后称簿，為它分配的container將以心跳應(yīng)答的形式返回給ApplicationMaster扣癣。
步驟7 ApplicationMaster收到新分配的container列表后，會(huì)將這些Container進(jìn)一步分配給它內(nèi)部的各個(gè)任務(wù)
資源調(diào)度器關(guān)注的是步驟4中采用的策略憨降，即如何將節(jié)點(diǎn)上空閑的資源分配給各個(gè)應(yīng)用程序父虑，至于步驟7中的策略材部，則完全由用戶應(yīng)用程序自己決定
（2）資源保證機(jī)制
YARN采用了增量資源分配機(jī)制舆逃，盡管這種機(jī)制會(huì)造成浪費(fèi)，但不會(huì)出現(xiàn)餓死現(xiàn)象
（3）資源分配算法
YARN資源調(diào)度器采用了主資源公平調(diào)度算法（Dominant ResourceFairness师倔，DRF）[插圖]悔叽，該算法擴(kuò)展了最大最小公平（max-min fairness）算法[插圖]莱衩，使其能夠支持多維資源的調(diào)度。由于DRF被證明非常適合應(yīng)用于多資源和復(fù)雜需求的環(huán)境中娇澎，因此被越來越多的系統(tǒng)采用笨蚁，包括Apache Mesos。
在DRF算法中，將所需份額（資源比例）最大的資源稱為主資源赚窃，而DRF的基本設(shè)計(jì)思想則是將最大最小公平算法應(yīng)用于主資源上册招，進(jìn)而將多維資源調(diào)度問題轉(zhuǎn)化為單資源調(diào)度問題岔激，即DRF總是最大化所有主資源中最小的勒极，其算法偽代碼如下
6.3.4 資源搶占模型
下面我們舉例說明。如圖6-5所示虑鼎，整個(gè)集群資源總量為100（為了簡便辱匿，沒有區(qū)分CPU或者內(nèi)存），且被分為三個(gè)隊(duì)列炫彩，分別是QueueA匾七、QueueB和QueueC。它們的最小資源量和最大資源量（由管理員配置）分別是(10,15)江兢、(20,35)和(60,65)昨忆。某一時(shí)刻，它們尚需的資源量和正在使用的資源量分別是(0,5)杉允、(10,30)和(60,65)邑贴，即隊(duì)列QueueA負(fù)載較輕，部分資源暫時(shí)不會(huì)使用叔磷，它將不會(huì)使用的5個(gè)資源共享給了其他兩個(gè)隊(duì)列（QueueB和QueueC分別得到2個(gè)和3個(gè)）拢驾，而隊(duì)列QueueB和QueueC除了使用來自隊(duì)列QueueA的資源外，還使用了整個(gè)系統(tǒng)共享的10個(gè)資源（100–10–20–60=10）改基。某一時(shí)刻繁疤，隊(duì)列QueueA突然增加了一批應(yīng)用程序，此時(shí)共需要20個(gè)資源秕狰，則資源調(diào)度器需要從QueueB和QueueC中搶占5個(gè)本該屬于QueueA的資源稠腊。需要注意的是，為了避免資源浪費(fèi)鸣哀，資源調(diào)度器通常會(huì)等待一段時(shí)間后才會(huì)強(qiáng)制回收資源架忌，而在這段等待時(shí)間內(nèi)，QueueB和QueueC可能已經(jīng)釋放了本該屬于QueueA的資源
在YARN中诺舔，資源搶占整個(gè)過程可概括為如下步驟：
步驟1 SchedulingEditPolicy探測(cè)到需要搶占的資源鳖昌，將需要搶占的資源通過事件DROP_RESERVATION和PREEMPT_CONTAINER發(fā)送給ResourceManager。
步驟2 ResourceManager調(diào)用ResourceScheduler的dropContainerReservation和preempt-Container函數(shù)低飒，標(biāo)注待搶占的Container许昨。
步驟3 ResourceManager收到來自ApplicationMaster的心跳信息，并通過心跳應(yīng)答將待釋放的資源總量和待搶占Container列表發(fā)返回給它褥赊。ApplicationMaster收到該列表后糕档，可選擇如下操作：
1）殺死這些Container。
2）選擇并殺死其他Container以湊夠總量。
3）不做任務(wù)處理速那，過段時(shí)間可能有Container自行釋放資源或者由ResourceManager殺死Container步驟4 SchedulingEditPolicy探測(cè)到一段時(shí)間內(nèi)俐银，ApplicationMaster未自行殺死約定的Container，則將這些Container封裝到KILL_CONTAINER事件中發(fā)送給ResourceManager端仰。
步驟5 ResourceManager調(diào)用ResourceScheduler的killContainer函數(shù)捶惜，而Resource-Scheduler則標(biāo)注這些待殺死的Container。
步驟6 ResourceManager收到來自NodeManager的心跳信息荔烧，并通過心跳應(yīng)答將待殺死的Container列表返回給它吱七，NodeManager收到該列表后，將這些Container殺死鹤竭，并通過心跳告知ResourceManager踊餐。
步驟7 ResourceManager收到來自ApplicationMaster的心跳信息，并通過心跳應(yīng)答將已經(jīng)殺死的Container列表發(fā)送給它（可能ApplicationMaster早已通過內(nèi)部通信機(jī)制知道了這些被殺死的Container）臀稚。
如何決定是否搶占某個(gè)隊(duì)列的資源吝岭？在YARN中，隊(duì)列是按照樹形結(jié)構(gòu)組織的吧寺，一個(gè)隊(duì)列當(dāng)前實(shí)際可以使用的資源量R取決于最小資源量A（由管理員配置）窜管、隊(duì)列資源需求量B（處于等待或者運(yùn)行狀態(tài)的應(yīng)用程序尚需的資源總量）和同父兄弟隊(duì)列的空閑資源量C（多余資源可共享給其他隊(duì)列），這意味著R在不同時(shí)間點(diǎn)的取值是不同的撮执，可以按照遞歸算法求出R=F(A,B,C)微峰，這樣，如果一個(gè)隊(duì)列當(dāng)前正在使用資源量U>R抒钱，則需從該隊(duì)列中搶占(U–R)資源蜓肆。
6.4 YARN層級(jí)隊(duì)列管理機(jī)制
6.4.1 層級(jí)隊(duì)列管理機(jī)制
該隊(duì)列組織方式具有以下特點(diǎn)：
?子隊(duì)列。具體包括如下兩點(diǎn)：
?隊(duì)列可以嵌套谋币，每個(gè)隊(duì)列均可以包含子隊(duì)列仗扬。
?用戶只能將應(yīng)用程序提交到最底層的隊(duì)列蕾额，即葉子隊(duì)列早芭。
?最少容量。具體包括如下四點(diǎn)：
?每個(gè)子隊(duì)列均有一個(gè)“最少容量比”屬性诅蝶，表示可以使用父隊(duì)列的容量的百分比退个。 ?調(diào)度器總是優(yōu)先選擇當(dāng)前資源使用率最低的隊(duì)列调炬，并為之分配資源语盈。比如同級(jí)的兩個(gè)隊(duì)列Q1和Q2，它們的最少容量均為30缰泡，而Q1已使用10刀荒，Q2已使用12，則調(diào)度器會(huì)優(yōu)先將資源分配給Q1〔瑁
?最少容量不是“總會(huì)保證的最低容量”干毅，也就是說，如果一個(gè)隊(duì)列的最少容量為20泼返，而該隊(duì)列中所有隊(duì)列僅使用了5硝逢，那么剩下的15可能會(huì)分配給其他需要的隊(duì)列》叮
?最少容量的值為不小于0的數(shù)趴捅，但也不能大于“最大容量”垫毙。
?最大容量霹疫。具體包括如下兩點(diǎn)：
?為了防止一個(gè)隊(duì)列超量使用資源，可以為隊(duì)列設(shè)置一個(gè)最大容量综芥，這是一個(gè)資源使用上限丽蝎，任何時(shí)刻使用的資源總量都不能超過該值；
?默認(rèn)情況下隊(duì)列的最大容量是無限大膀藐，這意味著屠阻，當(dāng)一個(gè)隊(duì)列只分配了20%的資源，所有其他隊(duì)列沒有應(yīng)用程序時(shí)额各，該隊(duì)列可能使用100%的資源国觉，當(dāng)其他隊(duì)列有應(yīng)用程序提交時(shí)，再逐步歸還虾啦。
6.4.2 隊(duì)列命名規(guī)則
為了防止隊(duì)列名稱沖突和便于識(shí)別隊(duì)列麻诀，YARN采用了自頂向下的路徑命名隊(duì)列，其中傲醉，父隊(duì)列與子隊(duì)列名稱采用“.”拼接蝇闭。下圖 是一個(gè)公司內(nèi)部的組織架構(gòu)，映射到Y(jié)ARN中硬毕，所有隊(duì)列命名如下：
圖6-8中有兩個(gè)同名的隊(duì)列C呻引，通過引入隊(duì)列路徑后，可以很容易區(qū)分出這兩個(gè)隊(duì)列吐咳，一個(gè)是"ROOT.C"逻悠，另外一個(gè)是"ROOT.C.C"
