毛韋　竹翠

摘 要：針對Hadoop集群節(jié)點性能差異大、資源分配隨機(jī)、執(zhí)行時間過長的問題，提出一種將節(jié)點性能標(biāo)簽（簡稱節(jié)點標(biāo)簽）和作業(yè)類別標(biāo)簽（簡稱作業(yè)標(biāo)簽）進(jìn)行動態(tài)匹配的調(diào)度器。節(jié)點初始分類并賦予原始節(jié)點標(biāo)簽，節(jié)點檢測自身性能指標(biāo)生成動態(tài)節(jié)點標(biāo)簽，作業(yè)根據(jù)部分運行信息進(jìn)行分類并生成作業(yè)標(biāo)簽，資源調(diào)度器將節(jié)點資源分配給對應(yīng)標(biāo)簽的作業(yè)。實驗結(jié)果表明，相對于YARN中自帶的調(diào)度器，其在作業(yè)執(zhí)行時間上有很大縮短。

關(guān)鍵詞：Hadoop；資源調(diào)度器；動態(tài)匹配；動態(tài)標(biāo)簽

DOI：10.11907/rjdk.171392

中圖分類號：TP319 文獻(xiàn)標(biāo)識碼：A 文章編號：1672-7800（2017）009-0095-05

Abstract：In order to solve the problem of big performance difference， random resource allocation， and long time execution in Hadoop cluster nodes，this paper propose a scheduler which allocates the Node Performance Label（NPL） and Job Category Label（JCL） dynamically.The node makes the classification of initialization and is assigned original node label. The node detects its own performance metrics to generate dynamic node labels. The job is classified based on part of the run information to generate the job label. The resource scheduler assigns the node resource to the corresponding label job. The experimental results shows that the scheduler has a certain degree of shorten in the time of job execution compared with one that comes with YARN.

Key Words：hadoop； scheduler； dynamic matching； dynamic label

0 引言

早期Hadoop版本由于將資源調(diào)度管理和MapReduce框架整合在一個模塊中，導(dǎo)致代碼的解耦性較差，不能較好地進(jìn)行擴(kuò)展，不支持多種框架。Hadoop開源社區(qū)設(shè)計實現(xiàn)了一種全新架構(gòu)的新一代Hadoop系統(tǒng)，該系統(tǒng)為Hadoop2.0版本，將資源調(diào)度抽取出來構(gòu)建了一個新的資源調(diào)度框架，即新一代的Hadoop系統(tǒng)YARN。眾所周知，在某一確定的環(huán)境下，合適的調(diào)度算法能夠在滿足用戶作業(yè)請求的同時，有效提升Hadoop作業(yè)平臺的整體性能和系統(tǒng)資源利用率。在YARN中默認(rèn)自帶3種調(diào)度器：先入先出（fifo）、公平調(diào)度器（Fair Scheduler）和計算能力調(diào)度器（Capacity Scheduler）。Hadoop默認(rèn)采用fifo調(diào)度器，該算法采用先進(jìn)先出的調(diào)度策略，簡單易實現(xiàn)，但是不利于短作業(yè)的執(zhí)行，不支持共享集群和多用戶管理；由Facebook提出的公平調(diào)度算法考慮了不同用戶與作業(yè)資源配置需求的差異，支持用戶公平共享集群的資源，但是作業(yè)資源的配置策略不夠靈活，容易造成資源浪費，并且不支持作業(yè)搶占；雅虎提出的計算能力調(diào)度算法支持多用戶共享多隊列，計算能力靈活，但是不支持作業(yè)搶占，易陷入局部最優(yōu)[1-2]。

然而在企業(yè)生產(chǎn)中，隨著企業(yè)數(shù)據(jù)量的加大，每年集群都會加入一些新節(jié)點，但是集群節(jié)點的性能差異很顯著，這種異構(gòu)集群在企業(yè)生產(chǎn)環(huán)境中很普遍。設(shè)想如果將一個計算量很大的機(jī)器學(xué)習(xí)任務(wù)分配在CPU計算能力很差的機(jī)器節(jié)點上，顯然會影響作業(yè)的整體執(zhí)行時間。Hadoop自帶的3種資源調(diào)度器并沒有很好地解決該問題。本文提出一種節(jié)點性能和作業(yè)類別標(biāo)簽動態(tài)匹配的資源調(diào)度算法（DLMS），將CPU性能較好的機(jī)器貼上CPU標(biāo)簽，將磁盤IO性能較好的機(jī)器貼上IO標(biāo)簽或者是兩者都一般的普通標(biāo)簽。作業(yè)根據(jù)分類可以貼上CPU標(biāo)簽、IO標(biāo)簽任務(wù)或者普通標(biāo)簽，然后進(jìn)入不同的標(biāo)簽隊列，調(diào)度器盡可能將相應(yīng)標(biāo)簽節(jié)點的資源分配給相應(yīng)的標(biāo)簽作業(yè)，從而減少作業(yè)運行時間，提高系統(tǒng)資源利用率，提高系統(tǒng)整體效率。

1 相關(guān)研究

Hadoop集群異構(gòu)調(diào)度相關(guān)研究已較多，Quan Chen等[3-4]提出動態(tài)MapReduce調(diào)度算法SAMR，能夠動態(tài)計算任務(wù)的進(jìn)展，自動適應(yīng)不斷變化的環(huán)境。但是該算法并沒有考慮到數(shù)據(jù)的本地化問題，同時也缺少一種動態(tài)參數(shù)調(diào)優(yōu)機(jī)制。Aysan Rasooli等[5]提出異構(gòu)環(huán)境中的動態(tài)調(diào)度算法，通過估計作業(yè)到達(dá)率和平均作業(yè)執(zhí)行時間決定調(diào)度策略。該文討論了不同作業(yè)的資源需求，把任務(wù)分配到不同的隊列中，設(shè)計了一個MapReduce負(fù)載預(yù)測機(jī)制來檢測MapReduce過程的負(fù)載類型，并對其分類后放入相應(yīng)的隊列中。針對需要頻繁IO的作業(yè)類型，HUI Kang等[6]提出MapReduce組調(diào)度算法，以降低上下文切換次數(shù)和解決IO阻塞問題。寧菲菲、鄭均輝等[7]探討了三隊列作業(yè)調(diào)度算法，提出節(jié)點分類的概念，基于Hadoop1.0框架，沒有考慮到節(jié)點運行作業(yè)時性能的變化等情況。以上這些算法都是針對異構(gòu)集群提出的優(yōu)化調(diào)度算法，都沒有將節(jié)點和作業(yè)進(jìn)行動態(tài)匹配的調(diào)度，缺少一種更加通用簡單高效的解決方法，增加了用戶的學(xué)習(xí)使用成本。endprint

2 調(diào)度算法

2.1 整體架構(gòu)

本文提出的調(diào)度框架將集群節(jié)點進(jìn)行初始分類并賦予相應(yīng)的標(biāo)簽。NodeManager發(fā)送心跳前作自我檢測并對原始標(biāo)簽進(jìn)行動態(tài)調(diào)整，并使用機(jī)器學(xué)習(xí)分類算法對作業(yè)進(jìn)行分類并賦予相應(yīng)的標(biāo)簽，根據(jù)用戶設(shè)定的作業(yè)優(yōu)先級、作業(yè)等待時間等屬性動態(tài)實現(xiàn)作業(yè)排序，并將相應(yīng)標(biāo)簽的資源分配給相應(yīng)標(biāo)簽隊列中的作業(yè)。YARN調(diào)度作業(yè)整體框架流程如圖1所示。

各步驟解釋如下：①用戶向YARN提交應(yīng)用程序，其中包括用戶程序、啟動ApplicationMaster命令等；②ResourceManager為該應(yīng)用程序分配第一個Container，并與對應(yīng)的NodeManager通信，要求它啟動應(yīng)用程序的ApplicationMaster；③ApplicationMaster向ResourceManager注冊后，為各任務(wù)申請資源，并監(jiān)控它們的運行狀態(tài)，直到運行結(jié)束；④NodeManager發(fā)送心跳前作自我檢測生成動態(tài)的節(jié)點標(biāo)簽，并向ResourceManager匯報資源；⑤作業(yè)分類進(jìn)入不同的標(biāo)簽隊列中，進(jìn)行優(yōu)先級排序等待分配資源；⑥ApplicationMaster通過RPC協(xié)議向ResourceManager申請和領(lǐng)取資源；⑦根據(jù)NodeManager匯報的節(jié)點標(biāo)簽和資源，調(diào)度器將此節(jié)點的資源分配給對應(yīng)標(biāo)簽隊列的作業(yè)；⑧ApplicationMaster申請到資源后，便與對應(yīng)的NodeManager通信，要求它啟動任務(wù)；⑨NodeManager為任務(wù)設(shè)置好運行環(huán)境（環(huán)境變量、JAR包、二進(jìn)制程序等）后，將任務(wù)啟動命令寫到腳本中，并通過運行該腳本啟動任務(wù)；⑩各任務(wù)通過某個RPC協(xié)議向ApplicationMaster匯報自己的狀態(tài)和進(jìn)度，可以在任務(wù)失敗時重新啟動任務(wù)；應(yīng)用程序運行完成后，ApplicationMaster向ResourceManager注銷并關(guān)閉自己。

該調(diào)度器主要模塊包括：①集群節(jié)點原始分類及其動態(tài)分類標(biāo)簽；②Map執(zhí)行信息的獲取與回傳；③多優(yōu)先級隊列；④作業(yè)分類；⑤數(shù)據(jù)本地性；⑥調(diào)度算法。

2.1.1 集群節(jié)點原始分類及其動態(tài)類別標(biāo)簽

根據(jù)節(jié)點運行單個任務(wù)的時間與集群中所有節(jié)點運行時間平均值的大小關(guān)系將節(jié)點大致分成CPU型節(jié)點、磁盤IO型節(jié)點、普通型節(jié)點。分類方法如下：

（1）設(shè)節(jié)點集為N={Ni|i∈[1，n]}，n為節(jié)點數(shù)量。

（2）在每臺節(jié)點上都執(zhí)行一個相同任務(wù)量的3種類型的作業(yè)并記錄作業(yè)執(zhí)行時間，Tcpu（i）表示在第Ni個節(jié)點上執(zhí)行CPU作業(yè)的花費時間，Tio（i）表示在第Ni個節(jié)點上執(zhí)行IO作業(yè)的花費時間，Tcom（i）表示在第Ni個節(jié)點上執(zhí)行普通作業(yè)的花費時間。

（3）計算每種作業(yè)的集群平均時間，計算公式如下：Avgj=∑n1Tj（i）n i∈[1，n]，j∈{cpu，io，com}

（1） 計算出每個節(jié)點在此種作業(yè)下與平均時間的時間差，如果Tcpu（i）Avgcpu，可以為此節(jié)點貼上普通型原始標(biāo)簽，通過比較后很可能每臺節(jié)點上的標(biāo)簽會有多個，選擇節(jié)省時間最多的標(biāo)簽為此節(jié)點的最后標(biāo)簽。

在集群節(jié)點運行過程中，如果一個節(jié)點的負(fù)載過大，即使該節(jié)點原始標(biāo)簽是CPU型標(biāo)簽，但在此環(huán)境下CPU性能優(yōu)勢已經(jīng)不能體現(xiàn)，因此采取動態(tài)標(biāo)簽的方法，在nodeManager向resourceManager發(fā)送心跳時動態(tài)檢測節(jié)點機(jī)器的CPU和IO使用率，如果超過了一定的閾值，將此節(jié)點標(biāo)簽貼上普通標(biāo)簽，由此實現(xiàn)動態(tài)標(biāo)簽。

2.1.2 Map信息回傳與獲取

Hadoop作業(yè)通常分成Map階段和Reduce階段，通常大作業(yè)的Map數(shù)量有上百個甚至更多，一個作業(yè)的時間主要消耗在Map階段計算上，但是每個Map又是完全相同的執(zhí)行內(nèi)容，因而會收集作業(yè)運行的第一個Map進(jìn)程的運行信息，這些信息在Nodemanage向ResourceManager發(fā)送心跳時傳遞到調(diào)度器中，由調(diào)度器進(jìn)行作業(yè)分類。當(dāng)生產(chǎn)環(huán)境中同一種類型作業(yè)每天都會運行，即用戶已經(jīng)知道作業(yè)所屬標(biāo)簽，可以在命令行或者代碼中為作業(yè)設(shè)置作業(yè)類型標(biāo)簽，在調(diào)度時調(diào)度器會進(jìn)行檢查，如果用戶已經(jīng)對作業(yè)貼上標(biāo)簽，就省去分類環(huán)節(jié)，直接進(jìn)行調(diào)度。設(shè)Map的運行信息為，M={Min，Mout，Rate，Acpu，Mcpu，Zcpu，Mrate}，它包括以下需要收集的信息：Min表示Map輸入數(shù)據(jù)量，Mout表示Map輸出數(shù)據(jù)量，Rate表示輸入數(shù)據(jù)量/輸出數(shù)據(jù)量，Acpu表示CPU平均使用率，Mcpu表示CPU中位數(shù)，Zcpu表示CPU使用率超過90%的平均數(shù)，MRate表示內(nèi)存使用量，這些數(shù)據(jù)將成為以后該作業(yè)分類的特征屬性。在實驗過程中發(fā)現(xiàn)，單純計算CPU的平均時間不能很好反映作業(yè)特征，CPU型作業(yè)的CPU使用率大于90%的次數(shù)較多，其類型作業(yè)的CPU使用率大于90%的次數(shù)相對較少。因此，將此信息也加入到Map回傳的信息中。

2.1.3 多級優(yōu)先級隊列

在調(diào)度器中新建5個隊列：原始隊列、等待優(yōu)先級隊列、CPU優(yōu)先級隊列、IO優(yōu)先級隊列、普通優(yōu)先級隊列。用戶提交的作業(yè)首先進(jìn)入原始隊列中，先運行作業(yè)部分Map并收集這部分Map運行信息，作業(yè)進(jìn)入等待優(yōu)先級隊列中根據(jù)作業(yè)的分類類別標(biāo)簽進(jìn)入到對應(yīng)標(biāo)簽的隊列中。在隊列優(yōu)先級方面采取用戶自定義雙層權(quán)重的設(shè)計方法，設(shè)作業(yè)的大小屬性所占權(quán)重為worthNum，該屬性可以分成3個等級Ni∈{long，mid，short}。作業(yè)的擁有者屬性所占權(quán)重為worthUser，該屬性可以分成兩個等級Ui∈{root，others}；作業(yè)的緊急程度所占權(quán)重為worthEmogence，該屬性可分成3個等級Ei∈{highPrority，midPrority，lowPrority}；作業(yè)的等待時間所占權(quán)重為worthWait，等待的計算公式為Jwait=nowTime-submitTime，賦予相應(yīng)權(quán)重，最后計算出每個任務(wù)的優(yōu)先級數(shù)，然后在相應(yīng)的隊列中進(jìn)行排序。上述5種任務(wù)屬性權(quán)重相加和為100%，具體公式如下：worthNum+worthUser+endprint

worthEmogence+worthWait=1

（2） 最后權(quán)重計算公式：finalWorth=worthNum*Ni+worthUser*Ui+

worthEmogence*Ei+worthWait*Jwait

（3）2.1.4 作業(yè)分類

在作業(yè)分類上，選擇簡單、使用比較普遍而且分類效果較好的樸素貝葉斯分類器進(jìn)行分類[8]。如果用戶在命令行和任務(wù)代碼中已經(jīng)添加作業(yè)類型，則此步驟會省掉，直接進(jìn)入相應(yīng)的隊列中等待分配資源。樸素貝葉斯分類器算法具體分類步驟如下：

（1）分別計算一個作業(yè)在某些條件下是CPU、IO還是普通型作業(yè)下的條件概率：P（job=cpuV1，V2…Vn）

P（job=ioV1，V2…Vn）

P（job=comV1，V2…Vn） 其中，job表示作業(yè)類別標(biāo)簽，為作業(yè)的屬性特征。

（2）根據(jù)貝葉斯公式P（BA）=P（AB）/P（A）得：P（job=cpuV1，V2…Vn）=

P（V1，V2…Vnjob=cpu）P（job=cpu）P（V1，V2…Vn）

（4） 假設(shè)V之間相對獨立，根據(jù)獨立假設(shè)：P（V1，V2…Vn|job=cpu）=∏n1P（Vi|job=cpu）（5） （3）實際計算中P（V1，V2…Vn）與作業(yè)無關(guān)可忽略不計，因此最終可得：P（job=cpuV1，V2…Vn）=

P（job=cpu）∏n1P（Vijob=cpu）

（6） 同理有：P（job=ioV1，V2…Vn）=

P（job=io）∏n1P（Vijob=io）

（7）

P（job=comV1，V2…Vn）=

P（job=com）∏n1P（Vijob=com）

（8） 作業(yè)是CPU型作業(yè)、IO型作業(yè)還是普通型作業(yè)取決于哪個概率值更大[9]。

2.1.5 數(shù)據(jù)本地性

Hadoop中遵循一個原則是“移動計算比移動數(shù)據(jù)更好”[9]，移動到放置數(shù)據(jù)的計算節(jié)點要比將數(shù)據(jù)移動到一個計算節(jié)點更加節(jié)省成本，性能更好。關(guān)于數(shù)據(jù)本地性，本文采取了延時降級調(diào)度策略。該策略具體思想如下：

為每個作業(yè)增加一個延時時間屬性，設(shè)Ti為第i個作業(yè)當(dāng)前的延時時間，i∈[1，n]，n為集群的節(jié)點數(shù)目，初始化為0，Tlocal表示本地節(jié)點延時時間閾值，Track表示機(jī)架節(jié)點延時時間閾值。當(dāng)調(diào)度器分配資源給作業(yè)時，如果作業(yè)的執(zhí)行節(jié)點和數(shù)據(jù)輸入節(jié)點不在一個節(jié)點上，此時自增1，表示該作業(yè)有一次延時調(diào)度，則可以將此資源分配給其它合適的作業(yè)，直到當(dāng)Ti>Tlocal時，作業(yè)的本地性就會降低為機(jī)架本地性，此時只要是本機(jī)架內(nèi)的節(jié)點都可以將資源分配給該作業(yè)；當(dāng)Ti>Track時，作業(yè)的本地性降低為隨機(jī)節(jié)點。其中Tlocal和Track都采用配置文件的方式由用戶根據(jù)集群情況自行配置。采用延時的調(diào)度策略可以保證在一定的延時時間內(nèi)獲得較好的本地性。

2.1.6 DLMS調(diào)度算法

DLMS調(diào)度算法的基本思想是預(yù)先分配部分作業(yè)執(zhí)行，根據(jù)作業(yè)回傳信息對作業(yè)進(jìn)行分類，然后將節(jié)點標(biāo)簽的資源分配給相應(yīng)隊列中的任務(wù)，基本流程：

步驟1：當(dāng)節(jié)點通過心跳向資源管理匯報資源時，如果原始隊列不為空，則遍歷原始隊列中的作業(yè)，將已經(jīng)在命令行或者程序中指定了作業(yè)類型標(biāo)簽的作業(yè)分配到相應(yīng)的標(biāo)簽優(yōu)先級隊列中，原始隊列移除此作業(yè)。

步驟2：如果原始隊列不為空，則將此節(jié)點上的資源分配給原始隊列，作業(yè)進(jìn)入等待隊列中等待下次分配資源，原始隊列移除此作業(yè)，此輪分配結(jié)束。

步驟3：如果等待優(yōu)先級隊列不為空，則對等待優(yōu)先級隊列中的作業(yè)進(jìn)行分類進(jìn)入相應(yīng)的標(biāo)簽優(yōu)先級隊列。

步驟4：如果節(jié)點性能標(biāo)簽相應(yīng)的作業(yè)類別隊列不為空，則將此節(jié)點的資源分配給此隊列，此輪分配結(jié)束。

步驟5：設(shè)置查看資源訪問次數(shù)變量，如果超過集群的數(shù)量，則將節(jié)點的資源按CPU、IO、普通、等待優(yōu)先級順序?qū)①Y源分配給相應(yīng)的隊列，此輪調(diào)度結(jié)束。此步驟可以防止出現(xiàn)如下情況：CPU隊列作業(yè)過多，導(dǎo)致CPU型節(jié)點資源已經(jīng)耗盡，而其它標(biāo)簽的節(jié)點還有資源，但是作業(yè)無法分配資源。

算法流程如圖2所示。

DMLS調(diào)度算法流程偽代碼如下：

算法1：

When a heartbeat is received from Node i to RM

If 初始隊列不為空

遍歷原始隊列中的作業(yè)將已經(jīng)貼上標(biāo)簽的作業(yè)放入相應(yīng)的標(biāo)簽隊列中

if applicats中有app不為空

為app分配ApplicationMaster

endif

endif

if 等待隊列不為空

分類得到app類型

根據(jù)app類型進(jìn)入不同的隊列中

在等待隊列中將app移除

Endif

根據(jù)節(jié)點標(biāo)簽的類型將節(jié)點資源分配給CPU、IO、COM優(yōu)先級隊列之一

if（調(diào)度次數(shù)變量 >= 總節(jié)點數(shù)目）

依次將資源分配給CPU、IO、COM隊列

調(diào)度次數(shù)變量=0；

endif

算法2：

assignContiners（applications，node）

for（app ： applications）

獲取app用戶、大小、緊急程度、等待時間對應(yīng)的權(quán)重

計算app最后的總權(quán)重

endforendprint

根據(jù)計算的權(quán)重值為app排序

for（app ： applications）

fifo為app分配資源

endfor

3 實驗驗證

本文通過實驗驗證DLMS調(diào)度器的實際效果。實驗環(huán)境為5臺PC機(jī)搭建而成的Hadoop完全分布式集群，集群的節(jié)點機(jī)器配置統(tǒng)一為操作系統(tǒng)Ubuntu-12.04.1，JDK1.6，Hadoop2.5.1，內(nèi)存2G，硬盤50G。其中NameNode的CPU核數(shù)為2，dataNode1的CPU核數(shù)為2，dataNode2的CPU核數(shù)為4，dataNode3的CPU核數(shù)為2，dataNode4的CPU核數(shù)為4。

3.1 節(jié)點原始標(biāo)簽分類

首先準(zhǔn)備數(shù)據(jù)量為128M的wordCount（IO型），kmeans（CPU型）作業(yè)各一個，分別在4臺節(jié)點上面運行6次，記錄作業(yè)運行時間。

表1中，s表示時間單位秒，avg表示該節(jié)點運行相應(yīng)標(biāo)簽任務(wù)的平均時間，allAvg表示所有節(jié)點運行相應(yīng)標(biāo)簽任務(wù)的總平均時間，rate的計算公式如下：rate=avg-allAvgallAvg×100%

（9） 其中，負(fù)號表示平均時間相對于總平均時間的減少，正號表示平均時間相對于總平均時間的增加。

由圖2可以看出，DataNode1運行兩個任務(wù)都是節(jié)省時間的。采取節(jié)省最多的CPU作業(yè)作為機(jī)器的原始標(biāo)簽，DataNode4為IO標(biāo)簽，DataNode2、DataNode3為普通機(jī)器。

3.2 實驗及結(jié)果分析

使用可以明顯區(qū)分作業(yè)類型的幾種作業(yè)，WordCount在Map階段需要大量地讀取數(shù)據(jù)和寫入中間數(shù)據(jù)，Map階段和Reduce階段基本上沒有算數(shù)計算，因此將這種作業(yè)定性為IO型作業(yè)，Kmeans在Map階段和Reduce階段都需要大量計算點和點之間的距離，并沒有太多中間數(shù)據(jù)的寫入，因此將這種作業(yè)定性為CPU型作業(yè)，TopK在Reduce階段沒有大量的數(shù)據(jù)寫入磁盤，也沒有大量的計算，只涉及簡單的比較，因此可認(rèn)為是普通型任務(wù)。

通過兩組實驗進(jìn)行驗證，第一組實驗設(shè)置調(diào)度器為fifo，在500M、1G和1.5G的數(shù)據(jù)量下分別運行WordCount、Kmeans、Topk作業(yè)各3次，記錄每個作業(yè)3次的平均時間作為最終時間，切換調(diào)度器為Capacity和DLMS調(diào)度器做同樣的實驗操作，實驗中記錄DLMS調(diào)度器下每種作業(yè)的Container在集群的分布，Container表示集群資源的劃分單位，記錄了作業(yè)分片在集群中運行的分布情況，YARN中每個Map和Reduce進(jìn)程都是以一個Container來表示。Container在集群中每個節(jié)點分布比例表明節(jié)點執(zhí)行作業(yè)任務(wù)量的比例。

圖3的橫坐標(biāo)是作業(yè)數(shù)據(jù)量，縱坐標(biāo)是WordCount、Kmeans、Topk這3種作業(yè)共同運行的總時間。在數(shù)據(jù)量增大的情況下，DLMS調(diào)度器相比于其它調(diào)度器節(jié)省約10%～20%的時間。

DLMS會將相應(yīng)節(jié)點標(biāo)簽的資源分配給相應(yīng)標(biāo)簽的作業(yè)。作業(yè)的Map和Reduce以Container的形式在節(jié)點上運行，圖4—圖6是在DMLS調(diào)度器下不同數(shù)據(jù)量作業(yè)的Container數(shù)量。原始分類Node1是CPU型的標(biāo)簽節(jié)點，Node2和Node3是普通標(biāo)簽節(jié)點，Node4是IO標(biāo)簽節(jié)點。WordCount是IO型作業(yè)，Topk是普通型作業(yè)，Kmeans是CPU型作業(yè)。從圖中可以看出，Container的分布規(guī)律為WordCount作業(yè)在Node4上分配的Container較多，Tokp在普通節(jié)點Node2和Node3上分布較多，Kmeans作業(yè)在Node1節(jié)點上分布較多。以上不同作業(yè)的Container在集群節(jié)點上的分布表明，DLMS調(diào)度器提高了相應(yīng)節(jié)點標(biāo)簽的資源分配給對應(yīng)標(biāo)簽作業(yè)的概率。

第二組實驗中，準(zhǔn)備了5個作業(yè)，分別是128M和500M數(shù)據(jù)量的WordCount作業(yè)，128M和500M數(shù)據(jù)量的Kmeans作業(yè)，500M的Topk作業(yè)組成一個作業(yè)組，5個作業(yè)同時提交運行。在不同調(diào)度器的集群中模擬連續(xù)作業(yè)執(zhí)行情況，記錄作業(yè)組執(zhí)行完的總時間。作業(yè)組在不同的調(diào)度器下運行3次，記錄作業(yè)組運行完的總時間。

具體結(jié)果如圖7所示，可以看出本文提出的DLMS調(diào)度器相比于Hadoop自帶調(diào)度器執(zhí)行相同作業(yè)組節(jié)省的時間較明顯，本文提出的DMLS調(diào)度器相比Hadoop自帶的Fifo調(diào)度器節(jié)省了大約20%的時間，比Capacity調(diào)度器節(jié)省了大約10%的運行時間。

4 結(jié)語

本文提出的DLMS調(diào)度器用兩個不同的實驗驗證該調(diào)度器的效率，從實驗數(shù)據(jù)上可以看出，無論是執(zhí)行不同數(shù)據(jù)量的單個作業(yè)，還是執(zhí)行由不同數(shù)據(jù)量組成的多個不同作業(yè)組成的作業(yè)組，相對于Hadoop自帶的其它調(diào)度器，其在執(zhí)行時間上都大大減少，集群資源利用率得以提高。后續(xù)研究的重點是在本文提出的調(diào)度器中考慮Reduce的數(shù)據(jù)本地性。

參考文獻(xiàn)：

[1] 朱潔，趙紅，李雯睿.基于Hadoop的三隊列作業(yè)調(diào)度算法[J].計算機(jī)應(yīng)用，2014，34（11）：3227-3230，3240.

[2] 鄧傳華，范通讓，高峰.Hadoop下基于統(tǒng)計最優(yōu)的資源調(diào)度算法[J].計算機(jī)應(yīng)用研究，2013，30（2）：417-419.

[3] CHEN Q， ZHANG D， GUO M， et al. SAMR： a self-adaptive mapreduce scheduling algorithm in heterogeneous environment[C]. IEEE， International Conference on Computer and Information Technology，2010：2736-2743.

[4] 陳全，鄧倩妮.異構(gòu)環(huán)境下的動態(tài)的Map-Reduce調(diào)度[J].計算機(jī)工程與科學(xué)，2009，31（S1）：168-171，175.

[5] RASOOLI A， DOWN D G. An adaptive scheduling algorithm for dynamic heterogeneous Hadoop systems[C]. Conference of the Center for Advanced Studies on Collaborative Research，2011：30-44.

[6] KANG H， CHEN Y， WONG J L， et al. Enhancement of Xen′s scheduler for MapReduce workloads[C]. ACM International Symposium on High PERFORMANCE Distributed Computing，2011：251-262.

[7] 寧菲菲，鄭均輝.基于Hadoop平臺的三隊列作業(yè)調(diào)度算法[J].微型電腦應(yīng)用，2015， 31（8）：19-21.

[8] 趙文濤，孟令軍，趙好好，等.樸素貝葉斯算法的改進(jìn)與應(yīng)用[J].測控技術(shù)，2016，35（2）：143-147.

[9] 楊洋.基于資源狀況的延時等待公平調(diào)度算法的研究[D].沈陽：東北大學(xué)，2014.

（責(zé)任編輯：孫 娟）endprint