基于節(jié)點(diǎn)性能的Hadoop作業(yè)調(diào)度算法改進(jìn)

馮興杰 賀 陽

(中國民航大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院 天津 300300)

基于節(jié)點(diǎn)性能的Hadoop作業(yè)調(diào)度算法改進(jìn)

馮興杰 賀 陽

(中國民航大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院 天津 300300)

由于構(gòu)成數(shù)據(jù)中心的計(jì)算設(shè)備一般都存在性能上的差異，但是Hadoop調(diào)度算法沒有考慮不同節(jié)點(diǎn)的性能差異，導(dǎo)致節(jié)點(diǎn)間出現(xiàn)“忙閑不均”的現(xiàn)象，影響作業(yè)的執(zhí)行效率。針對如上問題，在系統(tǒng)分析Hadoop資源管理機(jī)制(Yarn)源代碼的基礎(chǔ)上，提出了節(jié)點(diǎn)性能評價指標(biāo)，綜合考慮節(jié)點(diǎn)的硬件配置參數(shù)和運(yùn)行過程中的動態(tài)性能指標(biāo)。在此基礎(chǔ)上對Fair Scheduler調(diào)度算法進(jìn)行改進(jìn)，實(shí)現(xiàn)了基于節(jié)點(diǎn)性能的任務(wù)分配，整體上提高了所有節(jié)點(diǎn)的利用率。在Hadoop集群上的實(shí)驗(yàn)表明，所提出的節(jié)點(diǎn)性能評價指標(biāo)和對Fair Scheduler調(diào)度算法的改進(jìn)，有效解決了節(jié)點(diǎn)的負(fù)載均衡問題，整體上提高了作業(yè)執(zhí)行效率。

大數(shù)據(jù) Hadoop Yarn 負(fù)載均衡 Fair Scheduler算法

0 引 言

隨著互聯(lián)網(wǎng)技術(shù)在生產(chǎn)、生活中的廣泛應(yīng)用，以及各種移動設(shè)備和物聯(lián)網(wǎng)的快速發(fā)展，產(chǎn)生了數(shù)以P級的海量數(shù)據(jù)，并且數(shù)據(jù)還在以每兩年翻倍的速度快速增加。如此大的數(shù)據(jù)給存儲和計(jì)算帶來了巨大問題， 在大數(shù)據(jù)技術(shù)中，越來越多的企業(yè)開始使用Hadoop。Hadoop2.0引用Yarn框架，將原來的MapReduce中資源管理部分分離出來，減輕了MapReduce的壓力。Yarn由ResourceManager和NodeManager組成。

負(fù)載均衡技術(shù)是伴隨著集群的出現(xiàn)而產(chǎn)生的，它是集群系統(tǒng)實(shí)現(xiàn)技術(shù)中的關(guān)鍵部分，影響著集群的性能。隨著大數(shù)據(jù)技術(shù)的發(fā)展，大數(shù)據(jù)所具有的靈活性和用戶數(shù)量的龐大性等也給管理帶來很大問題，因此必須要采取合理而有效的資源調(diào)度策略和負(fù)載均衡措施來保證云計(jì)算的髙性能特性。

Hadoop的資源分配成為了決定運(yùn)行速度的主要因素，Hadoop主要是針對節(jié)點(diǎn)性能相同的集群而設(shè)計(jì)，然而在現(xiàn)實(shí)中，由于服務(wù)器的更新和添加，所購服務(wù)器沒有辦法做到性能完全一致。

現(xiàn)階段的主要研究有企業(yè)應(yīng)用型研究和學(xué)術(shù)型的研究：

在企業(yè)的應(yīng)用型研究中，Google的負(fù)載均衡是基于DNS(域名系統(tǒng))的，選擇與用戶在地理上接近的物理集群。Amazon從用戶的角度出發(fā)，把資源分配及每小時費(fèi)用分為8類，綜合的考慮集群的性能及成本。Facebook的調(diào)度算法Fire Scheduler有較強(qiáng)擴(kuò)展性，一般情況下是均衡資源量，使所有任務(wù)達(dá)到公平，但在只有一個任務(wù)的時候，會把所有資源分配給正在運(yùn)行的任務(wù)。

在學(xué)術(shù)型的研究中分為以下幾類：

(1) 提出算法的研究: Zhenhua Guo[1]等針對不均衡環(huán)境下的計(jì)算對節(jié)點(diǎn)的資源利用不充分問題提出了一種新的資源調(diào)度算法。該算法將任務(wù)分配給有多余資源的節(jié)點(diǎn)，以減輕部分節(jié)點(diǎn)的負(fù)擔(dān)，從而達(dá)到高資源利用率。Yuanquan Fan[2]等提出的一種LBVP算法,LBVP算法提出了一種虛擬Partition,在Map處理完成后,數(shù)據(jù)輸出使用虛擬的Partition進(jìn)行編號,ReduceTask在獲取數(shù)據(jù)時也根據(jù)這個編號進(jìn)行。儲雅[3]等對資源調(diào)度問題進(jìn)行深入剖析，根據(jù)現(xiàn)有云計(jì)算資源調(diào)度中的各種策略和算法歸納出4個熱點(diǎn)問題。

(2) MapReduce改進(jìn)的研究：Zhuo Tang[4]等引入了按等級劃分的MapReduce,將大任務(wù)分為小任務(wù)以作為新任務(wù)來運(yùn)行，從而減輕大任務(wù)帶來的負(fù)擔(dān)。VenkataSwamy[5]等人提出了h-MapReduce模型，用來評估Reduce任務(wù)過多的節(jié)點(diǎn)，以將重負(fù)載的任務(wù)進(jìn)行分割，再分配到其他節(jié)點(diǎn)上執(zhí)行。劉黨朋[6]等提出了基于MapReduce的負(fù)載均衡算法LBNP，以節(jié)點(diǎn)性能評價模型為核心，對Hadoop集群中各節(jié)點(diǎn)的計(jì)算能力進(jìn)行評估，并依據(jù)性能估值在Reduce階段對輸入數(shù)據(jù)進(jìn)行合理分配，從而達(dá)到均衡。

(3) 其他方面改進(jìn)的研究：Ramakrishnan[7]等提出了基于對象的集群采樣法，對 Reduce的負(fù)載均衡進(jìn)行研究，通過對Reduce的任務(wù)負(fù)載的評估，在其基礎(chǔ)上進(jìn)行調(diào)度。DongshengLi[8]等對迭代操作中的數(shù)據(jù)分布情況進(jìn)行收集，以此來引導(dǎo)下次任務(wù)迭代時對數(shù)據(jù)進(jìn)行分割，從而提高負(fù)載均衡。陳若飛[9]等對在非本地任務(wù)執(zhí)行前，對非本地性任務(wù)數(shù)據(jù)進(jìn)行數(shù)據(jù)塊間的預(yù)取，保證了Hadoop任務(wù)的本地性。林常航[10]等通過結(jié)合Hadoop中數(shù)據(jù)放置與任務(wù)執(zhí)行的關(guān)系，按不同節(jié)點(diǎn)對不同的任務(wù)的執(zhí)行能力進(jìn)行數(shù)據(jù)分配，該可以有效地縮短作業(yè)執(zhí)行時間，提高時效性。Daeho Kim[11]等根據(jù)Hadoop的CPU核數(shù)及可用內(nèi)存大小區(qū)分各節(jié)點(diǎn)能力來給每個任務(wù)分配內(nèi)存，從而達(dá)到均衡。

目前，閱讀Hadoop源碼的人不在少數(shù)，在源碼上進(jìn)行修改而達(dá)到相對性能均衡的論文很少，因?yàn)樵谠创a上進(jìn)行改動的難度較大、耗時更長，但是在源碼上的改進(jìn)是最直接、最能接近效果的方法。本文從Hadoop源碼入手，對Hadoop調(diào)度算法中的Fair Scheduler調(diào)度算法進(jìn)行了改進(jìn)，從而有效地緩解了Hadoop系統(tǒng)負(fù)載不均衡的情況，因此本文的出發(fā)點(diǎn)很有研究意義。

1 基于節(jié)點(diǎn)性能的Hadoop作業(yè)調(diào)度算法改進(jìn)

1.1 Fair Scheduler工作原理

資源調(diào)度器是Hadoop Yarn中最核心的組件之一，它直接決定著資源的分配，也決定著節(jié)點(diǎn)的負(fù)載情況，Hadoop自身所帶3種調(diào)度算法，分別是：FIFO Scheduler、Capacity Scheduler、Fair Scheduler。Hadoop2.0開始將默認(rèn)的調(diào)度算法FIFO Scheduler改為Capacity Scheduler，隨著Hadoop版本的演化，Capacity Scheduler 和Fair Scheduler的功能越來越完善，F(xiàn)air Scheduler調(diào)度算法幾乎包括了Capacity Scheduler的所有功能，并且Fair Scheduler支持多種調(diào)度策略[12]。因此，本文選中Fair Scheduler。

Hadoop整個系統(tǒng)相對龐大，通過對Hadoop任務(wù)運(yùn)行過程中的代碼追蹤，得到了詳細(xì)的Hadoop架構(gòu)。并且對重要的調(diào)度算法Fair Scheduler的追蹤進(jìn)行詳細(xì)分析得到如圖1所示的流程圖。

圖1 Fair Scheduler流程圖

Fair Scheduler調(diào)度算法同樣遵循Hadoop調(diào)度器的三級調(diào)度原則，即當(dāng)有空閑資源出現(xiàn)時，先從節(jié)點(diǎn)隊(duì)列中選擇一個節(jié)點(diǎn)，再從選中的節(jié)點(diǎn)中選擇一個優(yōu)先級高的任務(wù)，然后再選中空閑資源分配給任務(wù)。而節(jié)點(diǎn)的性能不均衡問題顯然應(yīng)當(dāng)從節(jié)點(diǎn)排序入手，節(jié)點(diǎn)的排序變化直接影響了任務(wù)在哪個節(jié)點(diǎn)上執(zhí)行，也是解決所出現(xiàn)的負(fù)載是否均衡問題的關(guān)鍵點(diǎn)，因此本文從節(jié)點(diǎn)的排序(圖中灰色)這一部分入手。

1.2 基于節(jié)點(diǎn)性能的Hadoop作業(yè)調(diào)度

算法的改進(jìn)過程分為兩部分。一部分為確定評價指標(biāo)，對于每個節(jié)點(diǎn)而言，服務(wù)器是其主要構(gòu)成設(shè)備，所以確定其指標(biāo)主要有兩大因素，即靜態(tài)指標(biāo)和動態(tài)指標(biāo)，靜態(tài)指標(biāo)即服務(wù)器本身的硬件參數(shù);動態(tài)指標(biāo)即在運(yùn)行過程中的各資源使用狀態(tài)。另一部分即對算法的改進(jìn)，主要是對Fair Schedule算法中對節(jié)點(diǎn)排序部分進(jìn)行改進(jìn)。

1.2.1 節(jié)點(diǎn)性能評價指標(biāo)

在性能不同的節(jié)點(diǎn)組成的集群中，節(jié)點(diǎn)性能并不能完全相同。如果作為相同性能的節(jié)點(diǎn)，會造成性能低的節(jié)點(diǎn)與性能高的節(jié)點(diǎn)可能接受同樣的任務(wù)，直接導(dǎo)致性能低節(jié)點(diǎn)運(yùn)行時間長，性能高節(jié)點(diǎn)運(yùn)行時間短，運(yùn)行過程中會發(fā)生性能高節(jié)點(diǎn)等待性能低節(jié)點(diǎn)運(yùn)行結(jié)果，從而浪費(fèi)性能高節(jié)點(diǎn)的資源，導(dǎo)致運(yùn)行時間變長。因此研究節(jié)點(diǎn)性能指標(biāo)有重要意義。

對節(jié)點(diǎn)性能進(jìn)行分析，總結(jié)出影響節(jié)點(diǎn)的性能指標(biāo)主要有兩大因素：靜態(tài)因素和動態(tài)因素。靜態(tài)因素為可控因素，其組成不會發(fā)生變化，也起到主要作用，靜態(tài)因素中起重要作用的兩個因素為：CPU和內(nèi)存。CPU和內(nèi)存容量大必然會運(yùn)行速度較快。因此主要從CPU和內(nèi)存來考慮其靜態(tài)性能指標(biāo)。

靜態(tài)性能指標(biāo)相對好處理，主要考慮節(jié)點(diǎn)的CPU容量在集群中所占的百分比以及內(nèi)存容量在集群中所占的百分比，所占百分比大的即為性能高節(jié)點(diǎn)。將每個節(jié)點(diǎn)的CPU所占百分比和內(nèi)存所占百分比做歸一化處理，得到CPU和內(nèi)存的綜合因素在集群中的所占比重。即得到節(jié)點(diǎn)的靜態(tài)性能指標(biāo)。

主要考慮CPU所占集群百分比和內(nèi)存所占集群百分比。單個節(jié)點(diǎn)CPU大小比上集群總的CPU大小，即為CPU所占集群百分比。同樣的方式求得內(nèi)存所占集群百分比，再將兩項(xiàng)綜合。

(1)

其中，i代表某節(jié)點(diǎn)，s代表整個集群，i.cpu代表i節(jié)點(diǎn)的cpu核數(shù)，i.memory代表i節(jié)點(diǎn)內(nèi)存的大小，h.index.i代表節(jié)點(diǎn)i在集群中的硬件指標(biāo)量。

根據(jù)上述所求得的單個節(jié)點(diǎn)性能所占集群百分比，求出所有結(jié)點(diǎn)性能百分比的和：

(2)

其中n代表節(jié)點(diǎn)個數(shù)，sum求出各節(jié)點(diǎn)的指標(biāo)量總合。

再針對單個節(jié)點(diǎn)求得單個節(jié)點(diǎn)的性能百分比在集群性能百分比中所占的百分比，即求得單個節(jié)點(diǎn)性能在集群總性能中的百分比：

(3)

動態(tài)因素主要由運(yùn)行過程中各項(xiàng)性能指標(biāo)的使用情況來判斷，因?yàn)檫\(yùn)行過程中每個節(jié)點(diǎn)的任務(wù)量不盡相同，加上每個節(jié)點(diǎn)的功能也不完全相同(主節(jié)點(diǎn)上要運(yùn)行Master任務(wù)，相對來說任務(wù)量會偏重)。還有一種情況是新節(jié)點(diǎn)和舊節(jié)點(diǎn)因?yàn)槭褂玫臅r間不同，導(dǎo)致新節(jié)點(diǎn)會性能比較高。因此動態(tài)因素也是檢測性能指標(biāo)的一個重要因素。

動態(tài)性能指標(biāo)：首先用相同的任務(wù)對單個節(jié)點(diǎn)進(jìn)行測試，用ganglia進(jìn)行單個節(jié)點(diǎn)運(yùn)行過程中的CPU和內(nèi)存的使用數(shù)據(jù)采集，再將單個節(jié)點(diǎn)采集到的CPU和內(nèi)存數(shù)據(jù)分別取得平均值，最后將各節(jié)點(diǎn)采集到的CPU和內(nèi)存使用率分別相加，以求得各節(jié)點(diǎn)的使用率在集群數(shù)據(jù)中所占的百分比。

在動態(tài)運(yùn)行過程中，用ganglia對節(jié)點(diǎn)運(yùn)行過程中的CPU使用率進(jìn)行10次采集，取平均值：

(4)

其中i.cpu為對節(jié)點(diǎn)i運(yùn)行過程中CPU的使用百分比的一次采集。

在動態(tài)運(yùn)行過程中，對單個節(jié)點(diǎn)運(yùn)行時的內(nèi)存使用率進(jìn)行10次采集，取得其平均值：

(5)

其中，i.memory為對節(jié)點(diǎn)i運(yùn)行過程中內(nèi)存的使用百分比的一次采集。

將單個節(jié)點(diǎn)的運(yùn)行時CPU平均使用率和運(yùn)行時內(nèi)存平均使用率進(jìn)行綜合，得到其單個節(jié)點(diǎn)運(yùn)行過程中的CPU和內(nèi)存的綜合使用率，因?yàn)橘Y源的未使用率與性能的高低是成正比的，所以在使用率的基礎(chǔ)上求得單個節(jié)點(diǎn)運(yùn)行過程中資源的未使用率：

(6)

其中，pro.index.i求得的是節(jié)點(diǎn)i內(nèi)存和CPU剩余量的指標(biāo)。

最后將所有節(jié)點(diǎn)的未使用率綜合考慮，求得單個節(jié)點(diǎn)對于集群的資源未使用率：

(7)

其中n為節(jié)點(diǎn)個數(shù)，pro.i即為節(jié)點(diǎn)i在運(yùn)行過程中未使用資源所占集群的百分比。

各節(jié)點(diǎn)綜合性能指標(biāo)的計(jì)算，要將動態(tài)指標(biāo)和靜態(tài)指標(biāo)全部考慮進(jìn)去，并且能達(dá)到希望的最佳效果，因此在動態(tài)指標(biāo)和靜態(tài)指標(biāo)前加參數(shù)以顯示兩項(xiàng)指標(biāo)對整體的權(quán)重。所以綜合考慮結(jié)果計(jì)算公式：

perf.index.i=a1×hard.i+a2×pro.i

(8)

其中，hard.i與pro.i由式(3)、式(7)計(jì)算得到，perf.index.i即為節(jié)點(diǎn)i的綜合性能指標(biāo)，各節(jié)點(diǎn)perf.index.i值的比值即為各節(jié)點(diǎn)的權(quán)重比，由a1和a2決定兩部分因素的權(quán)重。

1.2.2Hadoop作業(yè)調(diào)度算法改進(jìn)

Hadoop默認(rèn)的是所有節(jié)點(diǎn)性能相同，然而由于所構(gòu)成服務(wù)器的時間不同，使用情況不同以及每個節(jié)點(diǎn)的功能不同都會造成節(jié)點(diǎn)性能的不均衡。假設(shè)兩臺服務(wù)器，一臺服務(wù)器a內(nèi)存總量100，可用內(nèi)存量為40，另一臺服務(wù)器b內(nèi)存總量40，可用內(nèi)存30。這種情況下默認(rèn)的Hadoop系統(tǒng)會選擇a服務(wù)器來運(yùn)行下一個應(yīng)用程序，然而服務(wù)器a的可用內(nèi)存百分比為30%，而服務(wù)器b的可用內(nèi)存百分比為75%，可見服務(wù)器a比較緊張。因此會在運(yùn)行過程中發(fā)生資源不能很好利用，負(fù)載不均衡等情況。

根據(jù)這種情況，在考慮集群靜態(tài)性能指標(biāo)和動態(tài)性能指標(biāo)的情況下，加入了在任務(wù)執(zhí)行時考慮內(nèi)存使用率這一因素，對每個節(jié)點(diǎn)任務(wù)執(zhí)行時的內(nèi)存使用率作對比進(jìn)行排序，使得內(nèi)存未使用率高的節(jié)點(diǎn)優(yōu)先能安排到任務(wù)。并且事先對各節(jié)點(diǎn)進(jìn)行測試，根據(jù)上一小節(jié)的動態(tài)性能指標(biāo)的計(jì)算方法對各節(jié)點(diǎn)增加相應(yīng)的權(quán)重，運(yùn)行效率高的節(jié)點(diǎn)的權(quán)重增加，使其更容易分配到任務(wù)，從而提高效率，降低了上面這種情況發(fā)生的概率，從而達(dá)到了均衡的目的。

Compare(n1,n2)是FairScheduler算法中排序算法中的一個方法，作為排序的重要部分，Radio1和Radio2為兩個作比較的節(jié)點(diǎn)的未使用內(nèi)存資源百分比。在比率的基礎(chǔ)上加上兩個節(jié)點(diǎn)的權(quán)重，即上一小節(jié)的節(jié)點(diǎn)性能指標(biāo)所得出的各節(jié)點(diǎn)權(quán)重，再進(jìn)行比較。

算法偽代碼如下：

Sort(nodeIdList){

Compare(n1,n2){

//對比兩個節(jié)點(diǎn)

Radio1=n1.getAvailableMemory()/n1.getTotalMemory();

//可用節(jié)點(diǎn)百分比

Radio2=n2.getAvailableMemory()/n2.getTotalMemory();

R1=Radio1*n1.Weight;

//加上權(quán)重

R2=Radio1*n2.Weight;

If(R1

R2排在前面;

}else {

R1排在前面;

}

}

}

1.3 算法的實(shí)現(xiàn)過程

1.3.1 源碼改進(jìn)框架圖

Hadoop由Java實(shí)現(xiàn)，整個系統(tǒng)相對龐大，源碼改進(jìn)能最直接地達(dá)到效果。入手源碼會有點(diǎn)難度，入門后就會有一個整體的印象。只有在對Hadoop整體都了解的情況下才能去對源碼改進(jìn)，否則Hadoop不能啟動。對源碼改進(jìn)需要做多次實(shí)驗(yàn)驗(yàn)證其有效性。本研究把對Hadoop改動的類做了粗略整理，如圖2所示。

圖2 源碼改進(jìn)框架圖

主要更改的類為FairScheduler、DefaultResourceCalcultor、DominantResourceCalculator以及ResourceCalculator，其中最主要的更改在ResourceCalculator類中，這個類是根據(jù)節(jié)點(diǎn)未使用資源量進(jìn)行排序的關(guān)鍵類。

1.3.2 重新編譯源碼的過程

編譯過程如圖3所示。

圖3 源碼編譯過程圖

Hadoop的重新編譯過程以及啟動過程不像一些成熟的系統(tǒng)，過程比較復(fù)雜，在hadoop-src中有BUILDING.txt文檔對各插件版本要求做了介紹。在干凈的Hadoop環(huán)境下，嚴(yán)格按照流程圖中的步驟才可能成功，對Hadoop的重新編譯過程加深了對Hadoop整個系統(tǒng)的理解。

2 實(shí) 驗(yàn)

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

為了驗(yàn)證此想法的正確性，本研究用三臺服務(wù)器搭建了Hadoop集群，Hadoop版本為2.5.2，由3臺不同性能的服務(wù)器組成，三臺服務(wù)器都作為存儲和運(yùn)算節(jié)點(diǎn)。Name Node在Master節(jié)點(diǎn)上(即HDFS主節(jié)點(diǎn))，ResourceManager在Slave1節(jié)點(diǎn)上(即Yarn主節(jié)點(diǎn))，主節(jié)點(diǎn)分開，主要防止某一節(jié)點(diǎn)太過繁忙，服務(wù)器的各項(xiàng)參數(shù)如表1所示。

表1 節(jié)點(diǎn)性能參數(shù)表

由表1可以看出，集群的總CPU核數(shù)為18，內(nèi)存總量為17 GB,硬盤總量為1.7 TB。為了更方便看到直觀效果，用ganglia來進(jìn)行集群監(jiān)控(Slave1為ganglia主節(jié)點(diǎn))。ganglia主要用來監(jiān)控系統(tǒng)性能：CPU、內(nèi)存、硬盤利用率、I/O負(fù)載、網(wǎng)絡(luò)流量等。由曲線圖來展現(xiàn)各節(jié)點(diǎn)的當(dāng)前各資源使用狀態(tài)，對本實(shí)驗(yàn)進(jìn)程中調(diào)整、分配各項(xiàng)資源，提高集群的整體性能起到了非常重要的作用。

圖4為運(yùn)行過程中對每個節(jié)點(diǎn)的運(yùn)行情況的收集，圖中縱坐標(biāo)為每分鐘負(fù)載值，橫坐標(biāo)為運(yùn)行時間。由于Slave2配置最低，且Hadoop分配任務(wù)為平均分配，使得slave2過于繁忙，運(yùn)行過程中狀態(tài)呈現(xiàn)紅色(即圖中Slave2為深灰色)，1 GB數(shù)據(jù)大約運(yùn)行時間為9分鐘(運(yùn)行時間從08:57:21到09:06:19)，而Slave2節(jié)點(diǎn)每分鐘負(fù)載最高達(dá)到了10。高性能的Master節(jié)點(diǎn)每分鐘負(fù)載最高達(dá)到了5。Slave1節(jié)點(diǎn)的每分鐘負(fù)載最高只達(dá)到了2。圖4能清楚地表明Master和Slave1節(jié)點(diǎn)資源沒有能夠有效利用。

圖4 改進(jìn)前各節(jié)點(diǎn)運(yùn)行狀態(tài)圖

2.2 節(jié)點(diǎn)性能指標(biāo)計(jì)算

節(jié)點(diǎn)性能指標(biāo)計(jì)算的兩部分中，硬件參數(shù)根據(jù)節(jié)點(diǎn)性能參數(shù)表由1.2.1節(jié)所示式(1)-式(3)計(jì)算得到。

而動態(tài)指標(biāo)中用到的的數(shù)據(jù)在任務(wù)執(zhí)行之前采集，先用wordcount對每個節(jié)點(diǎn)單獨(dú)進(jìn)行測試，測試過程中對每個節(jié)點(diǎn)進(jìn)行采集資源信息，每個節(jié)點(diǎn)同一時間的CPU和內(nèi)存使用量為一組數(shù)據(jù)，共采集10組。利用1.2.1節(jié)中節(jié)點(diǎn)性能評價指標(biāo)方法來進(jìn)行各節(jié)點(diǎn)的性能評定，從而確定各節(jié)點(diǎn)的權(quán)重，其中所采集的運(yùn)行過程中CPU及內(nèi)存的使用情況數(shù)據(jù)如表2、表3所示。

表2 運(yùn)行中cpu使用情況表

表3 運(yùn)行中memory使用情況表

T1到T10分別表示10個時間段，最右列為名節(jié)點(diǎn)的名字，中間為單個時間段在單個節(jié)點(diǎn)上的資源使用率。利用這些數(shù)據(jù)，根據(jù)式(4)-式(7)計(jì)算得到各節(jié)點(diǎn)運(yùn)行過程中CPU和內(nèi)存的使用情況，即動態(tài)性能指標(biāo)。式(8)中的a1和a2，由于硬件的性能指標(biāo)占主要地位，而動態(tài)性能會因運(yùn)行的時間、運(yùn)行的任務(wù)不同而發(fā)生不穩(wěn)定變化，因此將硬件性能指標(biāo)的比率設(shè)置為0.6，而動態(tài)性能指標(biāo)的比率設(shè)置為0.4，即a1=0.6，a2=0.4。根據(jù)前面計(jì)算得到的靜態(tài)性能與動態(tài)性能相結(jié)合，得到三個節(jié)點(diǎn)的性能比約為3∶3∶1。因此將Master和Slave1的初始權(quán)重設(shè)置為3，Slave2的初始權(quán)重設(shè)置為1。

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

根據(jù)權(quán)重計(jì)算方法算得的結(jié)果，將Master和Slave1的初始權(quán)重設(shè)為3，Slave2的初始權(quán)重設(shè)為1。對改進(jìn)后的Yarn的源碼用maven進(jìn)行重新編譯，重新啟動Hadoop后再次用同樣的1GB數(shù)據(jù)進(jìn)行實(shí)驗(yàn)，實(shí)驗(yàn)結(jié)果如圖5所示。

圖5 改進(jìn)后各節(jié)點(diǎn)運(yùn)行狀態(tài)圖

由圖5可看到相對于改進(jìn)前得到了很大的改善，每分鐘負(fù)載最大的節(jié)點(diǎn)為Slave1，負(fù)載值為6，Slave1節(jié)點(diǎn)為高性能節(jié)點(diǎn)，所以相對于改進(jìn)前的負(fù)載最大的是Slave2的低性能節(jié)點(diǎn)這種情況，已經(jīng)得到了改善。改進(jìn)后，1GB數(shù)據(jù)的任務(wù)大約運(yùn)行時間為5分鐘(運(yùn)行時間從13:44:24到13:49:31)，相比較改進(jìn)前的運(yùn)行時間得到了很大的提高，同時緩解了Slave2的運(yùn)行壓力，每分鐘最大的負(fù)載為2。整體來看運(yùn)行時間有很大減少，大概節(jié)約了44%。Slave2節(jié)點(diǎn)也從之前的最大的每分鐘負(fù)載10降到了2。

從結(jié)論分析，由于改進(jìn)前給不同性能的節(jié)點(diǎn)分配了相同的任務(wù)，導(dǎo)致性能最差的Slave2節(jié)點(diǎn)太過繁忙，且其他節(jié)點(diǎn)中間結(jié)果出來后要等待Slave2而拖延整體的運(yùn)行時間。改進(jìn)后Slave2的任務(wù)明顯減少，性能高的節(jié)點(diǎn)Slave1充分發(fā)揮了其性能，從而使運(yùn)行時間大大減少，因此證明了結(jié)論的正確性。

3 結(jié) 語

本文對Hadoop2.0的資源調(diào)度器Yarn進(jìn)行了研究，結(jié)合服務(wù)器靜態(tài)指標(biāo)和動態(tài)指標(biāo)確定了節(jié)點(diǎn)的性能評價指標(biāo)，且從源碼的角度討論了負(fù)載均衡問題，給出了源碼中FairScheduler的流程，提出了對FairScheduler的改進(jìn)算法，并且在搭建的集群上進(jìn)行了實(shí)驗(yàn)，結(jié)果證明在Hadoop系統(tǒng)中加入此改進(jìn)算法，對負(fù)載均衡有很好的效果，同時提高了利用率。負(fù)載均衡問題是集群運(yùn)行效率的一個重要問題，改進(jìn)后對Hadoop集群的負(fù)載不均衡問題確實(shí)有很大的改善，然而現(xiàn)實(shí)情況中影響負(fù)載均衡的因素眾多，例如：數(shù)據(jù)在集群上的分布，任務(wù)提交節(jié)點(diǎn)以及主節(jié)點(diǎn)要有一部分資源的占用等問題。下一步的研究要在本研究方法的基礎(chǔ)上加入更多的考慮因素，結(jié)合hdfs的分布情況使集群的負(fù)載更加均衡。

[1]GuoZ,FoxG.ImprovingMapReduceperformanceinheterogeneousnetworkenvironmentsandresourceutilization[C]//Proceedingsofthe2012 12thIEEE/ACMInternationalSymposiumonCluster,CloudandGridComputing(CCGrid2012).IEEEComputerSociety,2012:714-716.

[2]FanY,WuW,CaoH,etal.LBVP:aloadbalancealgorithmbasedonvirtualpartitioninHadoopcluster[C]//2012IEEEAsiaPacificCloudComputingCongress,2012:37-41.

[3] 儲雅,馬廷淮,趙立成.云計(jì)算資源調(diào)度：策略與算法[J].計(jì)算機(jī)科學(xué),2013,40(11):8-13.

[4]TangZ,ZhouJ,LiK,etal.AMapReducetaskschedulingalgorithmfordeadlineconstraints[J].ClusterComputing,2013,16(4):651-662.

[5]MarthaVS,ZhaoW,XuX.h-MapReduce:aframeworkforworkloadbalancinginMapReduce[C]//Proceedingsofthe2013IEEE27thInternationalConferenceonAdvancedInformationNetworkingandApplications.IEEEComputerSociety,2013:637-644.

[6] 劉黨朋.不均衡環(huán)境下面向Hadoop的負(fù)載均衡算法研究[D].北京:北京郵電大學(xué),2015.

[7]RamakrishnanSR,SwartG,UrmanovA.BalancingreducerskewinMapReduceworkloadsusingprogressivesampling[C]//ProceedingsoftheThirdACMSymposiumonCloudComputing,2012:1-14.

[8]LiD,ChenY,HaiRH.Skew-awaretaskschedulinginclouds[C]//Proceedingsofthe2013IEEESeventhInternationalSymposiumonServiceOrientedSystemEngineering.IEEEComputerSociety,2013:341-346.

[9] 陳若飛.Hadoop作業(yè)調(diào)度本地性的研究與優(yōu)化[D].北京:北京交通大學(xué),2015.

[10] 林常航,郭文忠,陳煌寧.針對Hadoop異構(gòu)集群節(jié)點(diǎn)性能的數(shù)據(jù)分配策略[J].小型微型計(jì)算機(jī)系統(tǒng),2015,36(1):83-88.

[11]KimD,ChoiE,HongJ.Systeminformation-basedHadooploadbalancingforheterogeneousclusters[C]//Proceedingsofthe2015ConferenceonResearchinAdaptiveandConvergentSystems.ACM,2015:465-467.

[12] 董西成.Hadoop技術(shù)內(nèi)幕：深入解析YARN架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)原理[M].北京:機(jī)械工業(yè)出版社,2014.

IMPROVEMENT OF SCHEDULING ALGORITHM ON HADOOP BASED ON NODE PERFORMANCE

Feng Xingjie He Yang

(SchoolofComputerScienceandTechnology,CivilAviationUniversityofChina,Tianjin300300,China)

Because the computing devices that make up the data center generally have different performance, Hadoop scheduling algorithm does not consider the performance difference of different nodes, resulting in the phenomenon of “busy and idle inhomogeneous” between nodes, affecting the efficiency of job execution. In view of the above problem, based on the analysis of the source code of Hadoop resource management mechanism (Yarn), the node performance evaluation index is proposed. Considering the hardware configuration parameters and the dynamic performance indexes, the Fair Scheduler scheduling algorithm is improved, and the task allocation based on node performance is realized, and the utilization rate of all the nodes is improved as a whole. The experiments on Hadoop cluster show that the proposed node performance evaluation index and the improvement of Fair Scheduler scheduling algorithm effectively solve the problem of node load balancing and improve the efficiency of job execution as a whole.

Big data Hadoop Yarn Load balancing Fair Scheduler algorithm

2016-04-01。國家自然科學(xué)基金委員會與中國民用航空局聯(lián)合基金項(xiàng)目(U1233113)；國家自然科學(xué)基金項(xiàng)目(61301245，61201414)。馮興杰，教授，主研領(lǐng)域：智能算法，智能信息處理理論與技術(shù)。賀陽，碩士生。

TP302.7

A

10.3969/j.issn.1000-386x.2017.05.039