[[323256]]

1、 YARN的產(chǎn)生

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

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

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

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

解決辦法：

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

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

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

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

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

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

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

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

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

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

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

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

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

3)處理來自 AM的命令;

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

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

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

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

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

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

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

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

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

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

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

3、 YARN的工作原理

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

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

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

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

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

6)NodeManager 啟動任務(wù);

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

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

4、 YARN的容錯性

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

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

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

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

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

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

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

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

1)ResourceManager 將資源分配給 ApplicationMaster;

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

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

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

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