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

吳平平，殷其雷

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

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

吳平平，殷其雷

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

0　引言

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

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

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

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

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

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

圖1　

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

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

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

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

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

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

2.1算法的描述

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

圖2　

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

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

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

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

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

2.2算法的實(shí)現(xiàn)

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

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

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

MaxTasksNum:初始化為2

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

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

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

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

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

輸出：AskForNew,MaxTasksNum

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

S1：/*TaskTracker通過(guò) Hadoop自帶的 LinuxResource-CalculatorPlugin得到節(jié)點(diǎn)CPU利用率CpuUsage、內(nèi)存利用率MemUsage信息；獲取 Performance、HeartBeatCount、Max-TasksNum、MinTasksNum，其中Performance為記錄性能狀態(tài)的數(shù)組，性能較好對(duì)應(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的對(duì)應(yīng)位置為1并且HeartBeatCount數(shù)加1，否則使Performance的對(duì)應(yīng)為置為0并且使HeartBeatCount數(shù)加1*/

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

S4:/*根據(jù)Performance中記錄的歷史對(duì)節(jié)點(diǎn)進(jìn)行評(píng)估，如果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

*/

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

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

3　實(shí)驗(yàn)與結(jié)果分析

3.1實(shí)驗(yàn)平臺(tái)與參數(shù)

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

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

表1　集群配置

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

3.2實(shí)驗(yàn)與分析

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

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

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

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

4　結(jié)語(yǔ)

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

［1］劉鵬云.計(jì)算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］谷歌實(shí)驗(yàn)室.http://labs.google.com/papers/mapreduce.htm

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

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

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

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

［8］鄭曉薇等.基于節(jié)點(diǎn)能力的Hadoop集群任務(wù)自適應(yīng)調(diào)度方法.計(jì)算機(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-），男，湖北隨州人，研究生，研究方向?yàn)橛?jì)算機(jī)網(wǎng)絡(luò)與信息安全

2015-02-10

2015-02-28

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

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

殷其雷（1991-），男，碩士，研究方向?yàn)橛?jì)算機(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.