吳平平，殷其雷

（四川大學(xué)計算機(jī)學(xué)院，成都　610064）

一種基于節(jié)點性能的Hadoop動態(tài)調(diào)度策略

吳平平，殷其雷

（四川大學(xué)計算機(jī)學(xué)院，成都610064）

0　引言

近年來，隨著互聯(lián)網(wǎng)應(yīng)用的飛速發(fā)展，越來越多的網(wǎng)絡(luò)服務(wù)和商業(yè)應(yīng)用被部署在云計算環(huán)境中，需處理的數(shù)據(jù)的規(guī)模越來越大，這導(dǎo)致了云計算［1］的迅速發(fā)展。云計算是一種新興的分布式的商業(yè)計算模型。其中，最出名的大規(guī)模數(shù)據(jù)處理解決方案是MapReduce［2］編程模型。MapReduce編程模型是Google公司在2004年提出的［3］，被廣泛應(yīng)用于分布式抓取、分布式排序、日志分析、構(gòu)建倒排索引、機(jī)器學(xué)習(xí)等應(yīng)用中。Hadoop［4］作為云計算的一種開源實現(xiàn)，也被廣泛應(yīng)用于Yahoo!、FaceBook、Amazon等公司［5］。Hadoop主要由MapReduce編程模型和HDFS分布式文件系統(tǒng)組成。

目前，Hadoop的MapReduce默認(rèn)的任務(wù)調(diào)度策略僅考慮同構(gòu)環(huán)境，這就導(dǎo)致目前的Hadoop在異構(gòu)環(huán)境下的不同硬件平臺時不能根據(jù)硬件性能和機(jī)器運(yùn)行時的性能動態(tài)調(diào)整各個節(jié)點的任務(wù)分配量。另外，Hadoop的參數(shù)在集群啟動之前在配置文件中進(jìn)行配置，這樣在集群在其啟動之后不能根據(jù)節(jié)點的運(yùn)行時性能動態(tài)的改變配置文件并使其生效［6］。本文就是在Hadoop默認(rèn)的任務(wù)策略之上，提出一種基于節(jié)點性能作為指標(biāo)的動態(tài)任務(wù)調(diào)度策略。該策略根據(jù)節(jié)點的CPU使用率和內(nèi)存使用率作為評價節(jié)點運(yùn)行時性能的依據(jù)，根據(jù)節(jié)點的運(yùn)行時性能好壞動態(tài)調(diào)整節(jié)點的任務(wù)分配數(shù)，從而達(dá)到集群中各節(jié)點運(yùn)行在較好狀態(tài)的效果，進(jìn)而縮短Hadoop集群的任務(wù)整體響應(yīng)時間。

1　Hadoop默認(rèn)的調(diào)度策略

1.1默認(rèn)調(diào)度策略

Hadoop的MapReduce采用了Master/Slave架構(gòu)，它由Client、JobTracker、TaskTracker和Task四部分組成［7］，在整個集群中，JobTracker只有一個，有多個Task-Tracker。應(yīng)用程序提交任務(wù)到JobTracker，由JobTracker進(jìn)行任務(wù)的分配與調(diào)度。在JobTracker中，會在offerservice方法中啟動調(diào)度器（默認(rèn)為FIFO調(diào)度器），調(diào)度器根據(jù)配置文件配置和集群的實時情況調(diào)度和分配任務(wù)。

TaskTracker會周期性地通過HeartBeat將本節(jié)點上資源的使用情況和任務(wù)運(yùn)行信息匯報給JobTracker，同時也接受來自JobTracker發(fā)來的命令并且執(zhí)行它們。TaskTracker使用slot等量劃分本節(jié)點上的資源量。一個Task只有獲取一個slot之后才有機(jī)會運(yùn)行，而Hadoop調(diào)度器的作用就是將各個TaskTracker上空閑的slot分配給Task使用。slot分為Map slot和Reduce slot兩種，分別給 Map Task和 Reduce Task使用。TaskTracker通過slot數(shù)目來限定Task的并發(fā)度。

圖1　

1.2默認(rèn)調(diào)度策略中存在的問題

Hadoop默認(rèn)的策略采用了靜態(tài)的任務(wù)分配策略，每個節(jié)點實現(xiàn)配置好可用的slot總數(shù)，這些slot數(shù)目一旦啟動后無法再動態(tài)修改。但是實際應(yīng)用場景中，不同作業(yè)對資源的需求具有較大的不同，靜態(tài)配置slot數(shù)目可能會導(dǎo)致節(jié)點上的負(fù)載過高或者過低。

從對MapReduce的Task分配過程的分析可知，Hadoop默認(rèn)的任務(wù)調(diào)度策略是建立在同構(gòu)的假設(shè)之上的，當(dāng)JobTracker分配相應(yīng)的任務(wù)時，并不考慮節(jié)點處理能力的高低，每個節(jié)點同時執(zhí)行的任務(wù)量不會因為性能的不同發(fā)生改變。因此在異構(gòu)環(huán)境下，節(jié)點硬件性能和運(yùn)行時性能有一定的差異，會出現(xiàn)以下不足：

（1）性能較差的TaskTracker負(fù)載過重，性能較好的節(jié)點的資源利用效率低下［8］。Hadoop原來的分配策略默認(rèn)地認(rèn)為各節(jié)點性能相同，在給各節(jié)點分配任務(wù)的時候并沒有考慮到各個節(jié)點的性能差異，相同的任務(wù)量對每個節(jié)點產(chǎn)生的負(fù)載因各個節(jié)點自身的性能高低而不同。造成性能較低的節(jié)點負(fù)載過重，從而一直處于過載狀態(tài)，使響應(yīng)時間延長，從而導(dǎo)致整個集群的響應(yīng)時間變長。

（2）不能考慮運(yùn)行時節(jié)點的性能。實際應(yīng)用中，有些任務(wù)在運(yùn)行時需要的CPU和內(nèi)存較多，因此同樣數(shù)目的任務(wù)可能使節(jié)點的負(fù)載過重，造成響應(yīng)時間延長。

2　基于節(jié)點性能的Hadoop集群動態(tài)調(diào)度算法

2.1算法的描述

基于以上分析，本文提出一種能夠根據(jù)節(jié)點性能動態(tài)改變TaskTracker的分配任務(wù)的改進(jìn)策略，該策略根據(jù)節(jié)點的性能動態(tài)調(diào)整分配給節(jié)點最大任務(wù)數(shù)，從而能夠讓性能較好的工作節(jié)點分配更多的任務(wù)，進(jìn)而加快響應(yīng)時間。算法流程如圖2所示。

圖2　

（1）TaskTracker每間隔一個心跳周期，通過Hadoop自帶的 LinuxResourceCalculatorPlugin采 集CPU利用率和內(nèi)存利用率信息并初始化一些數(shù)據(jù)。

（2）將CPU利用率和內(nèi)存利用率分別與各自的設(shè)定值進(jìn)行比較，判斷該節(jié)點在該心跳周期中是否為較好的狀態(tài)。

（3）判斷心跳計數(shù)，當(dāng)達(dá)到設(shè)定的值時則進(jìn)行（4）；否則進(jìn)入（5）。

（4）根據(jù)性能評估函數(shù)確定該節(jié)點的最大任務(wù)分配數(shù)的調(diào)整。

（5）計算AskForNew值，判斷是否可以向該節(jié)點分配任務(wù)。

2.2算法的實現(xiàn)

本算法采用Java語言實現(xiàn)，通過在TaskTracker類的transmitHeartBeat方法中加入算法并將修改的代碼與增加的代碼放入Hadoop工程源碼中，使用Eclipse平臺中集成的Ant進(jìn)行編譯生成jar包。算法的實現(xiàn)如下：

輸入：節(jié)點的CPU使用率、內(nèi)存使用率信息

MAX，MIN:分別表示最大和最小的任務(wù)數(shù)

MaxTasksNum:初始化為2

T:心跳計數(shù)間隔

a:判斷T次心跳中節(jié)點性能為較好的數(shù)目閾值

b:判斷T次心跳中節(jié)點性能為較差的數(shù)目閾值

Performance:數(shù)組記錄T次心跳中節(jié)點的性能信息

Cthre,Mthre:分別表示CPU閾值和內(nèi)存閾值并初始化

輸出：AskForNew,MaxTasksNum

S0：/*初始化節(jié)點和參數(shù)信息*/

S1：/*TaskTracker通過 Hadoop自帶的 LinuxResource-CalculatorPlugin得到節(jié)點CPU利用率CpuUsage、內(nèi)存利用率MemUsage信息；獲取 Performance、HeartBeatCount、Max-TasksNum、MinTasksNum，其中Performance為記錄性能狀態(tài)的數(shù)組，性能較好對應(yīng)的位置1，較差置為0*/

cpuUsage=getCpuUsageOnTT（）；

memUsage=1-getAvailablePhysicalMemoryOnTT（）*1.0/ getTotalPhysicalMemoryOnTT（）；

S2:/*將CPU利用率與設(shè)定的閾值Cthre比較，內(nèi)存利用率與設(shè)定的閾值Mthre比較，如果CpuUsage小于Cthre并且MemUsage小于Mthre則使Performance的對應(yīng)位置為1并且HeartBeatCount數(shù)加1，否則使Performance的對應(yīng)為置為0并且使HeartBeatCount數(shù)加1*/

/*如果CPU利用率和內(nèi)存利用率滿足一下條件，則認(rèn)為是性能較好的狀態(tài)*/

S4:/*根據(jù)Performance中記錄的歷史對節(jié)點進(jìn)行評估，如果Evaluate（Performance）等于1并且MaxTasksNum＜MAX，則另 MaxTasksNum加 1并且將Performance數(shù)據(jù)元素都置0，HeartBeatCount置0；

如果Check（Performance）等于false并且MaxTasksNum＞MIN，則另MaxTasksNum減1并且將Performance數(shù)據(jù)元素都置0，HeartBeatCount置0

*/

/*對前 T次心跳間隔中統(tǒng)計的節(jié)點信息進(jìn)行評估，并動態(tài)改變最大任務(wù)數(shù)*/

S5：/*將該節(jié)點正在運(yùn)行的任務(wù)數(shù) RunningTasks與MaxTasksNum進(jìn)行比較，如果 RunningTasks小于 Max-TasksNum則另AskForNew置為true，即可以向該節(jié)點分配任務(wù)；否則將AskForNew置為false*/

3　實驗與結(jié)果分析

3.1實驗平臺與參數(shù)

本文使用Hadoop-1.0.0進(jìn)行了實驗環(huán)境的搭建并對所提出的改進(jìn)策略進(jìn)行實現(xiàn)并仿真。將改進(jìn)的源代碼使用Eclipse集成的 Ant編譯生成jar包hadoopcore-1.0.0.jar并部署到Hadoop集群中的各個節(jié)點上，采用Hadoop自帶的WordCount基準(zhǔn)測試程序。實驗集群共有7臺機(jī)器，其中一臺用作JobTracker節(jié)點，另外6臺用作TaskTracker節(jié)點,每臺機(jī)器的網(wǎng)絡(luò)帶寬為100Mbps。具體配置如表1所示。

不同的參數(shù)對集群的響應(yīng)時間有一定的影響。本文中，對于Hadoop默認(rèn)策略的參數(shù)配置采用Hadoop的默認(rèn)的配置文件中的值。改進(jìn)的策略中的參數(shù)初始化配置如表2所示。

表1　集群配置

表2　改進(jìn)策略參數(shù)配置

3.2實驗與分析

實驗分別使用Hadoop默認(rèn)的任務(wù)分配調(diào)度策略和改進(jìn)分配調(diào)度策略對1.3GB、2.6GB、3.9GB、5.2GB的文件進(jìn)行WordCount基準(zhǔn)測試。WordCount在運(yùn)行時需要將數(shù)據(jù)裝入內(nèi)存和使用CPU計算，適用于測試本改進(jìn)策略。為了減少實驗結(jié)果的隨機(jī)性，本實驗每組分別測試了3組數(shù)據(jù)并取平均值作為最終的測試結(jié)果。實驗結(jié)果如表3所示。從表中可以看出，改進(jìn)的策略相對于原始分別縮減了7s、12.3s、14.7s、19.7s。

通過計算可知，隨著任務(wù)量的增大，改進(jìn)的策略相對于默認(rèn)的策略的響應(yīng)時間縮減得更多，如圖3所示。這說明隨著任務(wù)量的增大，改進(jìn)算法算法比較穩(wěn)定，能夠更好地提高集群的響應(yīng)效率。

表3　Hadoop默認(rèn)策略和改進(jìn)策略的響應(yīng)時間對比

圖3　不同任務(wù)量的響應(yīng)時間對比

4　結(jié)語

本文通過考慮節(jié)點影響性能的CPU和內(nèi)存等因素，分析了Hadoop默認(rèn)任務(wù)調(diào)度策略的局限性，提出了一種基于節(jié)點性能的動態(tài)調(diào)度策略。從實驗中可以看到，該策略能夠降低任務(wù)的響應(yīng)時間，并且隨著任務(wù)量的增大，能夠更好地減少響應(yīng)時間。

［1］劉鵬云.計算2版.北京電子工業(yè)出版社

［2］Jeffrey Dean,Sanjay and Ghemawat.MapReduce:Simplified Data Processing on Large Clusters.Communications of the ACM.Page 107～113,Volume 51,Issue 1,2008.1

［3］谷歌實驗室.http://labs.google.com/papers/mapreduce.htm

［4］Hadoop官網(wǎng).http://hadoop.apache.org

［5］雅虎開發(fā)者.https://developer.yahoo.com/hadoop

［6］欒亞建等.Hadoop平臺的性能優(yōu)化研究.計算機(jī)工程，2010（14）

［7］董西成.Hadoop技術(shù)內(nèi)幕.機(jī)械工業(yè)出版社

［8］鄭曉薇等.基于節(jié)點能力的Hadoop集群任務(wù)自適應(yīng)調(diào)度方法.計算機(jī)研究與發(fā)展，2014（03）

Hadoop；Node Performance；Scheduler Strategy

A Hadoop Dynamic Scheduling Strategy Based on the Node Performance

WU Ping-ping，YIN Qi-lei
（College of Computer Science，Sichuan University，Chengdu 610064）

1007-1423（2015）08-0042-05

10.3969/j.issn.1007-1423.2015.08.010

吳平平（1987-），男，湖北隨州人，研究生，研究方向為計算機(jī)網(wǎng)絡(luò)與信息安全

2015-02-10

2015-02-28

針對Hadoop默認(rèn)的任務(wù)調(diào)度分配算法不能根據(jù)集群中節(jié)點的性能進(jìn)行動態(tài)的調(diào)整任務(wù)的問題，提出一種基于節(jié)點性能的動態(tài)任務(wù)調(diào)度策略。該策略根據(jù)節(jié)點的CPU使用率和內(nèi)存使用率作為評價節(jié)點運(yùn)行時性能的依據(jù)，根據(jù)節(jié)點的運(yùn)行時性能好壞動態(tài)調(diào)整節(jié)點的任務(wù)分配數(shù)，從而達(dá)到集群中各節(jié)點運(yùn)行在較好狀態(tài)的效果。實驗顯示，該策略使集群的總?cè)蝿?wù)完成時間縮減，有效提高集群的性能。

Hadoop；節(jié)點性能；調(diào)度策略

殷其雷（1991-），男，碩士，研究方向為計算機(jī)網(wǎng)絡(luò)與信息安全

The default task scheduling algorithm of Hadoop can not adjust the assignment of task according to the performance.Proposes a dynamic task scheduling strategy based on the node performance.The strategy uses the node CPU utilization and memory utilization as the basis of evaluating the node's runtime performance,then adjust the task number dynamic according to the basis,so each node in a cluster can work in the good state.Experiments results indicate that the strategy makes the total completion time of task clusters reduced significantly and improve the performance of the cluster.