基于YARN資源調(diào)度器的MapReduce作業(yè)數(shù)調(diào)節(jié)方法①

廉 華,劉 瑜

(浙江理工大學(xué) 機(jī)械與自動控制學(xué)院,杭州 310018)

Apache Hadoop 是Apache 軟件基金會的頂級開源項(xiàng)目之一,它在分布式計(jì)算與存儲上具有先天的優(yōu)勢.隨著大數(shù)據(jù)時代的到來,Hadoop 成為了大數(shù)據(jù)的標(biāo)簽之一,在很多領(lǐng)域都得到了廣泛的應(yīng)用[1].當(dāng)前Hadoop 已然發(fā)展為擁有MapReduce(MR)、HDFS、YARN、Pig、Hive、Hbase 等系統(tǒng)的較為完整的大數(shù)據(jù)生態(tài)圈[2].YARN(Yet Another Resource Negotiator)資源管理系統(tǒng)是Hadoop 生態(tài)圈中的核心,很多計(jì)算框架都遷移到Y(jié)ARN 上,借助YARN 獲得了更好的資源調(diào)度、資源隔離、可擴(kuò)展性以及容災(zāi)容錯的特性,比如MR on YARN,Strom on YARN,Spark on YARN 等[3].但是,YARN 有上百個參數(shù)供用戶配置,而且大多數(shù)參數(shù)間有著密切聯(lián)系.對于生產(chǎn)集群來說,手動調(diào)節(jié)任何參數(shù)都需要用戶對集群管理機(jī)制有深入的理解以及集群性能長期的觀察,并且調(diào)節(jié)參數(shù)后還需用戶花費(fèi)很多時間來判斷集群性能是否達(dá)到預(yù)期的效果[4].對于開發(fā)者來說在面對上百個參數(shù)的情況下很難實(shí)現(xiàn)YARN的最佳性能,而YARN 性能對于MR 作業(yè)有很大影響[5].因此,設(shè)計(jì)一種自動調(diào)節(jié)YARN 配置參數(shù)的方法不僅有助于減少用戶在參數(shù)調(diào)節(jié)上所花費(fèi)的時間,同時適當(dāng)?shù)膮?shù)配置還可以減少作業(yè)的執(zhí)行時間,提高作業(yè)的吞吐量.近年來,研究人員開發(fā)了很多種算法來提高Hadoop 集群的性能.Bei ZD 等[6]提出了RFHOC 模型,利用隨機(jī)森林方法為map 和reduce 階段構(gòu)建性能模型集合,在這些模型的基礎(chǔ)上使用遺傳算法自動調(diào)整Hadoop 配置參數(shù).Chen CO 等[7]利用基于樹的回歸方法對集群的最優(yōu)參數(shù)進(jìn)行選取.這類利用機(jī)器學(xué)習(xí)構(gòu)建性能模型來尋找最優(yōu)參數(shù)的方法需要一個費(fèi)事的模型訓(xùn)練階段.同時,若作業(yè)的類型發(fā)生改變或出現(xiàn)集群中節(jié)點(diǎn)增加或減少等變化時,使用這類方法就需要重新訓(xùn)練模型.Zhang B 等[8]發(fā)現(xiàn)作業(yè)在運(yùn)行過程中會出現(xiàn)under-allocation 和over-allocation 兩種情況會降低集群性能.Under-allocation 表示MR 作業(yè)數(shù)被設(shè)置的過少,導(dǎo)致集群的資源利用率過低.Over-allocation 表示MR 作業(yè)過多,大部分資源分配給了AppMaster,導(dǎo)致分配給Container 計(jì)算任務(wù)的資源不足,甚至?xí)霈F(xiàn)AppMaster 只占用資源卻不進(jìn)行任何計(jì)算的情況,導(dǎo)致集群性能下降.為克服以上兩種情況,張博等人提出一種閉環(huán)反饋控制方法,以內(nèi)存使用狀況作為輸入,以最小化資源競爭和最大化資源利用率為目標(biāo)來調(diào)整MR 作業(yè)數(shù),但對內(nèi)存的使用狀況考慮不夠細(xì)膩,會出現(xiàn)無法跳出over-allocation 狀態(tài)的情況,例如當(dāng)集群中計(jì)算任務(wù)占用總內(nèi)存的比率小于T2 時集群處于over-allocation 狀態(tài),此時向集群提交大量M R 作業(yè)后,又會將集群認(rèn)定為u n d e rallocation 狀態(tài),導(dǎo)致控制量不發(fā)生變化,這時集群實(shí)際上處于MR 作業(yè)數(shù)被設(shè)置的過少,集群的資源利用率過低的over-allocation 狀態(tài).本文提出了一種對YARN 容量調(diào)度器和公平調(diào)度器參數(shù)調(diào)節(jié)的閉環(huán)反饋控制方法,該方法采用二分法原則,逐次縮小被控參數(shù)的調(diào)節(jié)步長,具有調(diào)節(jié)速度快,控制精度高的優(yōu)點(diǎn).相比于文獻(xiàn)8 本文將公平調(diào)度器參數(shù)也納入調(diào)節(jié)范圍,同時修改了集群狀態(tài)的判定條件防止無法跳出overallocation 狀態(tài).本文方法有效解決了MR 作業(yè)運(yùn)行過程中AppMaster 的under-allocation 與overallocation 的問題,相比于現(xiàn)有的參數(shù)自整定方法具有如下優(yōu)點(diǎn):1)當(dāng)集群中有節(jié)點(diǎn)增加減少或更換集群時,無需花費(fèi)任何時間調(diào)整方法模型;2)不必事先對YARN 框架或被提交的MR 作業(yè)進(jìn)行修改.

1 相關(guān)知識

1.1 YARN 體系架構(gòu)

YARN 主要依賴于3 個組件ResourceManager、NodeManager 和AppMaster 來實(shí)現(xiàn)所有的功能[9].組件ResourceManager 是集群的資源管理器,整個集群只有一個,負(fù)責(zé)集群整個資源的統(tǒng)一管理和調(diào)度分配,包含兩個部分:可插拔的資源調(diào)度器和ApplicationManager,用于管理集群資源和作業(yè).組件NodeManager位于集群中每個計(jì)算節(jié)點(diǎn)上,負(fù)責(zé)監(jiān)控節(jié)點(diǎn)的本地可用資源,故障報(bào)告以及管理節(jié)點(diǎn)上的作業(yè),它將節(jié)點(diǎn)上的資源信息上報(bào)給ResourceManager.組件AppMaster 是每個作業(yè)的主進(jìn)程,用于管理作業(yè)的生命周期.一個作業(yè)由一個AppMaster 及多個Container 組成,其中Container 是節(jié)點(diǎn)上的一組資源的組合,例如(1 GB,1 core),用于運(yùn)行作業(yè)中的計(jì)算任務(wù).當(dāng)客戶端有作業(yè)提交時,ResourceManager 會啟動一個AppMaster,之后再由AppMaster 根據(jù)當(dāng)前需要的資源向Application-Manager 請求一定量的Container.ApplicationManager基于調(diào)度策略,盡可能最優(yōu)的為AppMaster 分配Container 的資源,然后將資源請求的應(yīng)答發(fā)給AppMaster[10].上述作業(yè)提交流程如圖1 所示.

圖1 作業(yè)提交流程

1.2 YARN 的資源調(diào)度器

YARN 中自帶的可插拔資源調(diào)度器有先入先出調(diào)度器(FIFO scheduler)、容量調(diào)度器(capacity scheduler)和公平調(diào)度器(fair scheduler)[11].其中先入先出調(diào)度器以“先來先服務(wù)”的原則,按照作業(yè)提交的先后時間進(jìn)行調(diào)度,無需任何配置.但這種調(diào)度策略不考慮作業(yè)的優(yōu)先級,只適合低負(fù)載集群,當(dāng)使用大型共享集群時,大的作業(yè)可能會獨(dú)占集群資源,導(dǎo)致其他應(yīng)用阻塞.在大型共享集群中更適合容量調(diào)度器或公平調(diào)度器,這兩個調(diào)度器都允許大作業(yè)和小作業(yè)同時運(yùn)行并都獲得一定的系統(tǒng)資源[12].因此本文利用這兩種調(diào)度器調(diào)節(jié)MR 作業(yè)數(shù).在容量調(diào)度器中可設(shè)定參數(shù)yarn.scheduler.capacity.maximum-am-resource-percent(AMRP),來調(diào)節(jié)集群中可分配于AppMaster 的資源量,這個參數(shù)影響著集群中MapReduce 作業(yè)數(shù).在公平調(diào)度器中可設(shè)定參數(shù)maxAMShare,調(diào)節(jié)MapReduce 作業(yè)數(shù),它限制了AppMastter 可占用隊(duì)列資源的比例.

2 MapReduce 作業(yè)數(shù)控制方法

本文提出的MR 作業(yè)數(shù)控制方法是基于容量資源調(diào)度器和公平資源調(diào)度其實(shí)現(xiàn)的,是一種閉環(huán)反饋控制,控制系統(tǒng)的方框圖如圖2 所示.ysp為用戶所設(shè)定的域值T1、T2、T3,將監(jiān)控器得到的內(nèi)存使用情況與設(shè)定值ysp相比較,以此調(diào)節(jié)控制量A,防止Hadoop 集群中MR 作業(yè)出現(xiàn)under-allocation 和over-allocation 兩種狀態(tài),并使被控變量Hadoop 集群中MR 作業(yè)數(shù)保持在最佳值.閾值T1、T3 與集群中所有運(yùn)行作業(yè)的內(nèi)存使用率相比較,閾值T2 與集群中所有計(jì)算任務(wù)的內(nèi)存使用率相比較.

圖2 閉環(huán)反饋控制系統(tǒng)的方框圖

本文提出的閉環(huán)反饋控制方法主要分為3 個模塊:監(jiān)控器、控制器和執(zhí)行器:

(1)監(jiān)控器:在集群主節(jié)點(diǎn)中運(yùn)行,負(fù)責(zé)周期性監(jiān)控集群資源使用情況和MR 作業(yè)運(yùn)行情況,并將監(jiān)控到的數(shù)據(jù)傳輸至控制器中.YARN ResourceManager 有一個Web 端口,用這個端口可以查看YARN 監(jiān)控頁面,使用戶可以方便地了解集群的運(yùn)行情況和作業(yè)的運(yùn)行情況.監(jiān)控器得到的數(shù)據(jù)是由Python 腳本爬取YARN 監(jiān)控頁面獲得,而未使用YARN 自帶的用戶命令編寫shell 腳本.原因是由YARN 自帶的用戶命令獲取數(shù)據(jù)相較于使用Python 爬取較慢,且受集群運(yùn)行狀況影響較大.監(jiān)控器具體獲得的指標(biāo)有:隊(duì)列中等待提交的作業(yè)數(shù)、隊(duì)列中正在運(yùn)行的作業(yè)數(shù)、集群中所有運(yùn)行作業(yè)占用內(nèi)存、集群中所有從節(jié)點(diǎn)總內(nèi)存.

(2)控制器:負(fù)責(zé)根據(jù)從監(jiān)控器接收到的數(shù)據(jù)對資源調(diào)度器的參數(shù)進(jìn)行周期性地修改.本文調(diào)度器參數(shù)控制算法以集群內(nèi)存使用情況和隊(duì)列中的作業(yè)狀態(tài)作為判斷條件,對集群是否處于over-allocation 或underallocation 狀態(tài)做出判斷,若集群處于上述兩種狀態(tài)則采用二分法原則逐次調(diào)節(jié)被控參數(shù)直至集群從這兩種狀態(tài)中跳出.參數(shù)控制算法的流程描述如算法1.

?

算法1 中P、R、M_used、M_total的值由監(jiān)控器傳入,M_AMs、M_tasks由如下公式獲得:

其中,Unit為每個Container 的內(nèi)存大小.detect()通過讀取YARN 配置文件檢測調(diào)度器類型,隨后讀取相應(yīng)調(diào)度器配置文件得到變量A的值.A_min和A_max是調(diào)度器參數(shù)AMRP 或maxAMShare 允許達(dá)到的最小值和最大值.

當(dāng)M_used/M_total＜T1且集群中等待提交的作業(yè)在增加時(第11 行),可認(rèn)為沒有足夠的內(nèi)存分配給AppMaster,集群中并行的MR 作業(yè)數(shù)量較少,導(dǎo)致出現(xiàn)MR 作業(yè)占用內(nèi)存小于設(shè)定閾值T1的情況.此時集群處于under-allocation 狀態(tài),需增加A的值,提升MR 作業(yè)數(shù),充分利用集群的資源.

集群處于over-allocation 狀態(tài)可分為如下3 種情況:

① 隊(duì)列中無等待作業(yè)且隊(duì)列中正在運(yùn)行的作業(yè)數(shù)比上一時刻少,即P=0 且R(t)＜R(t-1),表示集群中并MR 作業(yè)數(shù)較低或正在降低,這種狀態(tài)判斷為overallocation.此時可減少分配到AppMaster 的資源,使計(jì)算任務(wù)可使用的資源增多,以此來減少M(fèi)R 作業(yè)總體完成時間.

②T3 ＜M_used/M_total＜T1且M_tasks/M_total＜T2(第13 行),當(dāng)集群中提交的任務(wù)較少時很容易滿足M_used/M_total＜T1和M_tasks/M_total＜T2條 件 設(shè)置閾值T3表示當(dāng)被使用的內(nèi)存足夠多時才會判斷集群是否為over-allocation 狀態(tài).若集群處于overallocation 狀態(tài),則需減小A的值,使集群跳出此狀態(tài).

③M_used/M_total＞T1且M_tasks/M_total＜T2(第17 行),表示MR 作業(yè)占用內(nèi)存大于設(shè)定閾值T1,但MR 作業(yè)中的計(jì)算任務(wù)占用內(nèi)存小于設(shè)定閾值T2.這種情況下集群MR 作業(yè)數(shù)過高,集群中計(jì)算任務(wù)得不到足夠的資源,此時需要減小A的值,降低MR 作業(yè)數(shù),使計(jì)算任務(wù)獲得更多的資源.

算法1 中調(diào)節(jié)變量A的方法increase_A()和decrease_A()分別如算法2 和算法3 所示.當(dāng)增加或減小變量A時,將確定 α /2n是否大于用戶設(shè)置的step,若大于則以 α/2n作為此次調(diào)節(jié)的步長,若小于則以step作為此次調(diào)節(jié)的步長.

(3)執(zhí)行器:負(fù)責(zé)將修改對應(yīng)調(diào)度器配置文件的AMRP 或maxAMShare 參數(shù),命令 Hadoop 集群重新加載調(diào)度器配置.

?

3 實(shí)驗(yàn)分析

3.1 實(shí)驗(yàn)環(huán)境

為了驗(yàn)證MR 作業(yè)數(shù)控制方法的效果,選取了5 臺普通PC 機(jī)來搭建測試集群.其中一臺作為主節(jié)點(diǎn),包含1 個NameNode 角色和1 個ResourceManager 角色.其余4 臺作為從節(jié)點(diǎn),每臺節(jié)點(diǎn)包含1 個DataNode角色和1 個NodeManager 角色.本文選取Grep,Terasort,Wordcount 這3 種常見的MR 作業(yè)用于測試,其中Terasort 為IO 密集型作業(yè),Grep 為計(jì)算密集型作業(yè),Wordcount 作業(yè)在Map 階段為計(jì)算密集型,Reduce 階段為IO 密集型,如表1 所示.

表1 實(shí)驗(yàn)作業(yè)類型

3.2 實(shí)驗(yàn)結(jié)果

本實(shí)驗(yàn)分別在將YARN 集群資源調(diào)度器配置為容量調(diào)度器和公平調(diào)度器的情況下進(jìn)行測試,將四組作業(yè)提交到集群中(第一組30 個Grep 作業(yè)、第二組30 個Terasort 作業(yè)、第三組30 個Wordcount 作業(yè)、第四組每種類型作業(yè)各10 個),對比在集群使用默認(rèn)配置、最優(yōu)配置和本文方法后作業(yè)的完成時間.實(shí)驗(yàn)中AMRP 和maxAMShare 的最優(yōu)值由窮舉法得到,窮舉范圍為{0,0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1},一組作業(yè)完成時間越短可認(rèn)為參數(shù)AMRP 或maxAMShare越優(yōu).圖3 中在使用容量調(diào)度器的情況下,每組作業(yè)完成時間最短時,AMRP 分別為0.6,0.5,0.3,0.5.圖4 中在使用公平調(diào)度器的情況下,每組作業(yè)完成時間最短時maxAMShare 分別0.8,0.9,0.6,0.8.實(shí)驗(yàn)中T1、T2、T3、step、A_ min、A_ max的值分別為1.0,0.5,0.8,0.05,0.05,0.95.

圖3 使用容量調(diào)度器時作業(yè)完成時間對比

圖4 使用公平調(diào)度器時作業(yè)完成時間對比

從圖3、圖4 中可以看出使用本文提出的方法調(diào)節(jié)MR 作業(yè)數(shù)相比于默認(rèn)的配置,MR 作業(yè)整體完成時間會明顯的減少,在使用容量調(diào)度器和公平調(diào)度器的情況下平均減少了53%和14%.同時在參數(shù)最優(yōu)的情況下,與使用本文提出的方法在作業(yè)完成時間上相差較小.兩者與默認(rèn)配置相比,作業(yè)完成時間最多有7%的差異.由于對于不同的作業(yè)組合,都需要做多組實(shí)驗(yàn)才能確定最優(yōu)的參數(shù),所以在實(shí)際使用集群時要達(dá)到明確的最優(yōu)參數(shù)并不現(xiàn)實(shí),因此本文提出的方法與最優(yōu)參數(shù)下的作業(yè)完成時間相比略有差異可以接受.

4 結(jié)論與展望

本文在現(xiàn)有調(diào)度器的基礎(chǔ)上提出了一種閉環(huán)反饋控制方法對MR 作業(yè)數(shù)進(jìn)行動態(tài)調(diào)節(jié).通過實(shí)驗(yàn)證明本文提出的方法能夠在省去人工調(diào)節(jié)參數(shù)的情況下有效的降低MR 作業(yè)完成時間,提升了集群的性能.下一步的工作是研究集群虛擬核使用率與集群CPU 使用率的關(guān)系,將節(jié)點(diǎn)虛擬核數(shù)也納入調(diào)節(jié)的范疇.