[[323256]]

1、 YARN的產(chǎn)生

在之前文章中介紹過hadoop1與hadoop2架構(gòu)的區(qū)別是hadoop2將資源管理功能從MapReduce框架中獨(dú)立出來，也就是現(xiàn)在的YARN模塊。

在沒有 YARN 之前，是一個(gè)集群一個(gè)計(jì)算框架。比如：MapReduce 一個(gè)集群、Spark 一個(gè)集群、HBase 一個(gè)集群等。

造成各個(gè)集群管理復(fù)雜，資源的利用率很低;比如：在某個(gè)時(shí)間段內(nèi) Hadoop 集群忙而Spark 集群閑著，反之亦然，各個(gè)集群之間不能共享資源造成集群間資源并不能充分利用。

并且采用"一個(gè)框架一個(gè)集群"的模式，也需要多個(gè)管理員管理這些集群， 進(jìn)而增加運(yùn)維成本;而共享集群模式通常需要少數(shù)管理員即可完成多個(gè)框架的統(tǒng)一管理; 隨著數(shù)據(jù)量的暴增，跨集群間的數(shù)據(jù)移動(dòng)不僅需要花費(fèi)更長(zhǎng)的時(shí)間，且硬件成本也會(huì)大大增加;而共享集群模式可讓多種框架共享數(shù)據(jù)和硬件資源,將大大減少數(shù)據(jù)移動(dòng)帶來的成本。

解決辦法：

將所有的計(jì)算框架運(yùn)行在一個(gè)集群中，共享一個(gè)集群的資源，按需分配;Hadoop 需要資源就將資源分配給 Hadoop，Spark 需要資源就將資源分配給 Spark，進(jìn)而整個(gè)集群中的資源利用率就高于多個(gè)小集群的資源利用率;

2、 YARN的基本構(gòu)成

Master/Slave 結(jié)構(gòu)，1 個(gè)ResourceManager(RM)對(duì)應(yīng)多個(gè) NodeManager(NM);YARN 由 Client、ResourceManager、NodeManager、ApplicationMaster (AM)組成;Client 向 RM 提交任務(wù)、殺死任務(wù)等;

AM由對(duì)應(yīng)的應(yīng)用程序完成;

每個(gè)應(yīng)用程序?qū)?yīng)一個(gè) AM，AM向RM申請(qǐng)資源用于在NM上啟動(dòng)相應(yīng)的 Task;NM 向 RM通過心跳信息：匯報(bào) NM健康狀況、任務(wù)執(zhí)行狀況、領(lǐng)取任務(wù)等;

RM：整個(gè)集群只有一個(gè)，負(fù)責(zé)集群資源的統(tǒng)一管理和調(diào)度

1)處理來自客戶端的請(qǐng)求(啟動(dòng)/殺死應(yīng)用程序);

2)啟動(dòng)/監(jiān)控 AM;一旦某個(gè) AM 掛了之后，RM 將會(huì)在另外一個(gè)節(jié)點(diǎn)上啟動(dòng)該 AM;

3)監(jiān)控 NM，接收 NM的心跳匯報(bào)信息并分配任務(wù)到 NM去執(zhí)行;一旦某個(gè) NM掛了，標(biāo)志下該 NM 上的任務(wù)，來告訴對(duì)應(yīng)的 AM 如何處理;

4)負(fù)責(zé)整個(gè)集群的資源分配和調(diào)度;

NM：整個(gè)集群中有多個(gè)，負(fù)責(zé)單節(jié)點(diǎn)資源管理和使用

1)周期性向 RM匯報(bào)本節(jié)點(diǎn)上的資源使用情況和各個(gè) Container 的運(yùn)行狀;

2)接收并處理來自 RM 的 Container 啟動(dòng)/停止的各種命令;

3)處理來自 AM的命令;

4)負(fù)責(zé)單個(gè)節(jié)點(diǎn)上的資源管理和任務(wù)調(diào)度;

AM：每個(gè)應(yīng)用一個(gè)，負(fù)責(zé)應(yīng)用程序的管理

1)數(shù)據(jù)切分;

2)為應(yīng)用程序/作業(yè)向 RM 申請(qǐng)資源(Container)，并分配給內(nèi)部任務(wù);

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

4)任務(wù)監(jiān)控和容錯(cuò)(在任務(wù)執(zhí)行失敗時(shí)重新為該任務(wù)申請(qǐng)資源以重啟任務(wù));

5)處理 RM發(fā)過來的命令：殺死 Container、讓 NM重啟等;

Container：對(duì)任務(wù)運(yùn)行環(huán)境的抽象

1)任務(wù)運(yùn)行資源(節(jié)點(diǎn)、內(nèi)存、CPU);

2)任務(wù)啟動(dòng)命令;

3)任務(wù)運(yùn)行環(huán)境;任務(wù)是運(yùn)行在Container中，一個(gè)Container中既可以運(yùn)行AM也可以運(yùn)行具體的 Map/Reduce/MPI/Spark Task;

3、 YARN的工作原理

1)用戶向 YARN 中提交應(yīng)用程序/作業(yè)，其中包括 ApplicaitonMaster 程序、啟動(dòng)ApplicationMaster 的命令、用戶程序等;

2)ResourceManager 為作業(yè)分配第一個(gè) Container，并與對(duì)應(yīng)的 NodeManager 通信，要求它在這個(gè) Containter 中啟動(dòng)該作業(yè)的 ApplicationMaster;

3 )ApplicationMaster 首 先 向 ResourceManager 注 冊(cè) ， 這 樣 用 戶 可 以 直 接 通 過ResourceManager 查詢作業(yè)的運(yùn)行狀態(tài);然后它將為各個(gè)任務(wù)申請(qǐng)資源并監(jiān)控任務(wù)的運(yùn)行狀態(tài)，直到運(yùn)行結(jié)束。即重復(fù)步驟 4-7;

4)ApplicationMaster 采用輪詢的方式通過 RPC 請(qǐng)求向 ResourceManager 申請(qǐng)和領(lǐng)取資源;

5)一旦 ApplicationMaster 申請(qǐng)到資源后，便與對(duì)應(yīng)的 NodeManager 通信，要求它啟動(dòng)任務(wù);

6)NodeManager 啟動(dòng)任務(wù);

7)各個(gè)任務(wù)通過 RPC 協(xié)議向 ApplicationMaster 匯報(bào)自己的狀態(tài)和進(jìn)度，以讓ApplicaitonMaster 隨時(shí)掌握各個(gè)任務(wù)的運(yùn)行狀態(tài)，從而可以在任務(wù)失敗時(shí)重新啟動(dòng)任務(wù);在作業(yè)運(yùn)行過程中，用戶可隨時(shí)通過 RPC 向 ApplicationMaster 查詢作業(yè)當(dāng)前運(yùn)行狀態(tài);

8)作業(yè)完成后，ApplicationMaster 向 ResourceManager 注銷并關(guān)閉自己;

4、 YARN的容錯(cuò)性

ResourceMananger基于 ZooKeeper 實(shí)現(xiàn) HA 避免單點(diǎn)故障;

NodeManager執(zhí)行失敗后，ResourceManager 將失敗任務(wù)告訴對(duì)應(yīng)的 ApplicationMaster;

由 ApplicationMaster 決定如何處理失敗的任務(wù);

ApplicationMaster執(zhí)行失敗后，由 ResourceManager 負(fù)責(zé)重啟;

ApplicationMaster 需處理內(nèi)部任務(wù)的容錯(cuò)問題;

RMAppMaster 會(huì)保存已經(jīng)運(yùn)行完成的 Task，重啟后無需重新運(yùn)行。

5、 YARN的調(diào)度框架

1、雙層調(diào)度框架

1)ResourceManager 將資源分配給 ApplicationMaster;

2)ApplicationMaster 將資源進(jìn)一步分配給各個(gè) TASK;

2、基于資源預(yù)留的調(diào)度策略

1)資源不夠時(shí)，會(huì)為 Task 預(yù)留，直到資源充足;描述：當(dāng)一個(gè) Task 需要 10G 資源時(shí)，各個(gè)節(jié)點(diǎn)都不足 10G，那么就選擇一個(gè)節(jié)點(diǎn)，但是某個(gè) NodeManager上只有 2G， 那么就在這個(gè) NodeManager上預(yù)留， 當(dāng)這個(gè) NodeManager上釋放其他資源后，會(huì)將資源預(yù)留給 10G 的作業(yè)，直到攢夠 10G 時(shí)，啟動(dòng) Task;缺點(diǎn)：資源利用率不高，要先攢著，等到 10G 才利用，造成集群的資源利用率低;

2)與"all or nothing"策略不同(Apache Mesos)描述：當(dāng)一個(gè)作業(yè)需要 10G 資源時(shí)，節(jié)點(diǎn)都不足 10G，那就慢慢等，等到某個(gè)節(jié)點(diǎn)上有 10G 空閑資源時(shí)再運(yùn)行，很可能會(huì)導(dǎo)致該 Task 餓死。