基于YARN資源調度器的MapReduce作業數調節方法①

廉 華,劉 瑜

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

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

1 相關知識

1.1 YARN 體系架構

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

圖1 作業提交流程

1.2 YARN 的資源調度器

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

2 MapReduce 作業數控制方法

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

圖2 閉環反饋控制系統的方框圖

本文提出的閉環反饋控制方法主要分為3 個模塊:監控器、控制器和執行器:

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

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

?

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

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

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

集群處于over-allocation 狀態可分為如下3 種情況:

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

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

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

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

(3)執行器:負責將修改對應調度器配置文件的AMRP 或maxAMShare 參數,命令 Hadoop 集群重新加載調度器配置.

?

3 實驗分析

3.1 實驗環境

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

表1 實驗作業類型

3.2 實驗結果

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

圖3 使用容量調度器時作業完成時間對比

圖4 使用公平調度器時作業完成時間對比

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

4 結論與展望

本文在現有調度器的基礎上提出了一種閉環反饋控制方法對MR 作業數進行動態調節.通過實驗證明本文提出的方法能夠在省去人工調節參數的情況下有效的降低MR 作業完成時間,提升了集群的性能.下一步的工作是研究集群虛擬核使用率與集群CPU 使用率的關系,將節點虛擬核數也納入調節的范疇.