本發(fā)明涉及分布式計(jì)算技術(shù)領(lǐng)域，特別是涉及一種Hadoop平臺(tái)下基于預(yù)釋放資源列表的任務(wù)調(diào)度算法。

背景技術(shù)：

互聯(lián)網(wǎng)技術(shù)催生了大數(shù)據(jù)時(shí)代的來臨。當(dāng)前，大數(shù)據(jù)已經(jīng)成為了炙手可熱的研究焦點(diǎn)。由于海量的數(shù)據(jù)使得單個(gè)的計(jì)算機(jī)已經(jīng)無法滿足存儲(chǔ)及計(jì)算的要求，各種大數(shù)據(jù)的計(jì)算模式及其對(duì)應(yīng)的分布式計(jì)算系統(tǒng)開始不斷涌現(xiàn)。MapReduce無疑是其中最為經(jīng)典的大數(shù)據(jù)計(jì)算模式，Apache Hadoop作為MapReduce的開源實(shí)現(xiàn)，得到了廣泛的使用。任務(wù)調(diào)度與資源分配一直以來都是大規(guī)模分布式集群研究的關(guān)鍵技術(shù)，這對(duì)提高大數(shù)據(jù)集群的計(jì)算效率尤其重要。

目前Hadoop中常用的任務(wù)調(diào)度器有FIFO調(diào)度器、公平(Fair)調(diào)度器[1]和計(jì)算能力(Capacity)調(diào)度器[2]。其中FIFO調(diào)度器主要適用于批處理作業(yè)的處理，并不適合于多用戶、復(fù)雜作業(yè)類型的環(huán)境。為了克服FIFO調(diào)度器的不足，多用戶多隊(duì)列調(diào)度器誕生了。這種調(diào)度器允許管理員按照應(yīng)用需求對(duì)用戶或者應(yīng)用程序分組，并為不同的分組分配不同的資源量，同時(shí)通過添加各種約束防止單個(gè)用戶或者應(yīng)用程序獨(dú)占資源，進(jìn)而能夠滿足各種QoS需求。

Hadoop的JobTracker與TaskTracker之間通過“pull”方式進(jìn)行通信。即JobTracker從不會(huì)主動(dòng)向TaskTracker發(fā)送任何信息，而是由TaskTracker主動(dòng)通過心跳“領(lǐng)取”屬于自己的信息。所以JobTracker只能通過心跳應(yīng)答的形式為各個(gè)TaskTracker分配任務(wù)。并且每個(gè)TaskTracker是在不同的時(shí)間向JobTracker發(fā)送心跳請(qǐng)求。所以即使當(dāng)前有一批存在空閑資源的TaskTracker，任務(wù)調(diào)度器也是逐個(gè)接收到它們的心跳請(qǐng)求的。現(xiàn)有的任務(wù)調(diào)度算法都只根據(jù)當(dāng)前請(qǐng)求任務(wù)的從節(jié)點(diǎn)狀況，來選擇任務(wù)進(jìn)行分配。而沒有將更多的資源與集群中各個(gè)作業(yè)的真實(shí)需求聯(lián)系起來，從而做出更優(yōu)的調(diào)度方案。公平調(diào)度器和計(jì)算能力調(diào)度器在選擇隊(duì)列和選擇作業(yè)的時(shí)候都遵循公平的原則或者是計(jì)算能力的原則，但在選擇任務(wù)的時(shí)候，為了滿足任務(wù)的本地性，采用了延遲調(diào)度算法[3]。在當(dāng)前作業(yè)沒有滿足本地性要求的任務(wù)時(shí)，需要將資源讓給下一個(gè)作業(yè)。所以公平調(diào)度器存在公平性和本地性之間的矛盾，計(jì)算能力調(diào)度器存在計(jì)算能力和本地性之間的矛盾。同時(shí)，延遲調(diào)度算法需要手動(dòng)設(shè)置node-local等待時(shí)間和rack-local等待時(shí)間兩個(gè)參數(shù)。而這兩個(gè)參數(shù)跟集群情況和作業(yè)情況密切相關(guān)，一般很難找到適合當(dāng)前集群中作業(yè)情況的參數(shù)設(shè)置，而且也不可能在作業(yè)情況改變的情況下，又重新去調(diào)度這兩個(gè)參數(shù)。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明的目的就是要克服現(xiàn)有技術(shù)的不足，提供一種Hadoop平臺(tái)下基于預(yù)釋放資源列表的任務(wù)調(diào)度算法，為每個(gè)作業(yè)分配更適合的資源。

為解決以上技術(shù)問題，本發(fā)明所采用的技術(shù)方案是：一種Hadoop平臺(tái)下基于預(yù)釋放資源列表的任務(wù)調(diào)度算法，所述方法包括以下步驟：

S101：空閑TaskTracker提交任務(wù)請(qǐng)求；

S102：初始化所有作業(yè)的預(yù)分配資源數(shù)；

S103：篩選出還需要資源的所有隊(duì)列needSlotPools；

S104：判斷needSlotPools是否為空；如果為空，則不為該TaskTracker分配任務(wù)，調(diào)度結(jié)束；如果不為空，繼續(xù)執(zhí)行下一步；

S105：通過公平原則從needSlotPools中選擇一個(gè)隊(duì)列chosedPool；

S106：從被選中的隊(duì)列chosedPool中篩選出還需要資源的所有作業(yè)needSlotJobs；

S107：通過公平原則或者FIFO原則，從needSlotJobs中選擇一個(gè)作業(yè)chosedJob；

S108：創(chuàng)建被選中作業(yè)chosedJob的預(yù)釋放資源列表；

S109：判斷生成的預(yù)釋放資源是否為空；如果為空，則從chosedJob中按照任務(wù)調(diào)度原則選擇一個(gè)任務(wù)，調(diào)度結(jié)束；否則，繼續(xù)執(zhí)行下一步；

S110：將預(yù)釋放資源列表中的第一個(gè)資源預(yù)分配給chosedJob；跳轉(zhuǎn)到S103繼續(xù)執(zhí)行。

進(jìn)一步的，所述步驟S103具體篩選過程包括：

比較隊(duì)列的資源需求量與隊(duì)列的預(yù)分配資源數(shù)，如果隊(duì)列的資源需求量大于隊(duì)列的預(yù)分配資源數(shù)，則隊(duì)列需要資源；否則，隊(duì)列不需要資源。

其中，一個(gè)隊(duì)列的資源需求量等于該隊(duì)列下所有作業(yè)的資源需求量的和；一個(gè)作業(yè)的資源需求量等于該作業(yè)尚未運(yùn)行的任務(wù)數(shù)；一個(gè)隊(duì)列的預(yù)分配資源數(shù)等于該隊(duì)列下所有作業(yè)的預(yù)分配資源數(shù)的和。

進(jìn)一步的，所述步驟S106具體篩選過程包括：

比較作業(yè)的資源需求量與作業(yè)的預(yù)分配資源數(shù)，如果作業(yè)的資源需求量大于作業(yè)的預(yù)分配資源數(shù)，則作業(yè)需要資源；否則，作業(yè)不需要資源。

進(jìn)一步的，所述步驟S108預(yù)釋放資源列表創(chuàng)建過程包括：

從當(dāng)前所有正在運(yùn)行的任務(wù)中挑選出來滿足一定條件的任務(wù)加入預(yù)釋放資源列表，再將滿足條件的任務(wù)按照作業(yè)在任務(wù)所在資源的任務(wù)完成時(shí)間由小到大排序，即生成本發(fā)明的預(yù)釋放資源列表；其中，該條件包括任務(wù)所在資源不能包含在預(yù)分配資源列表中，以及作業(yè)在任務(wù)所在資源的任務(wù)完成時(shí)間小于作業(yè)在當(dāng)前空閑資源的任務(wù)完成時(shí)間。

本發(fā)明提出一種基于預(yù)釋放資源列表的任務(wù)調(diào)度算法，充分利用了Hadoop記錄的歷史信息和集群當(dāng)前狀況監(jiān)控信息來更好地幫助資源調(diào)度。本算法無需手動(dòng)設(shè)置延遲等待時(shí)間。并通過對(duì)預(yù)釋放資源列表中的資源進(jìn)行預(yù)調(diào)度，解決了公平性和本地性之間的矛盾。另外，本發(fā)明提出的任務(wù)調(diào)度算法可以像延遲調(diào)度算法一樣，同時(shí)應(yīng)用于公平調(diào)度器和計(jì)算能力調(diào)度器。本發(fā)明的調(diào)度算法使用了預(yù)釋放資源列表，通過資源列表與任務(wù)列表的匹配調(diào)度，本發(fā)明的算法無論在Hadoop完成時(shí)間、任務(wù)本地性，還是平均作業(yè)響應(yīng)時(shí)間方面，都取得了更好的效果。

附圖說明

圖1為本發(fā)明算法基于預(yù)釋放資源列表的資源三級(jí)調(diào)度模型示意圖；

圖2為本發(fā)明算法的總體流程示意圖；

圖3為本發(fā)明算法基于預(yù)釋放資源列表的調(diào)度結(jié)果示意圖；

圖4為本發(fā)明算法的Hadoop完成時(shí)間比較示意圖；

圖5為本發(fā)明算法作業(yè)的任務(wù)本地性比較示意圖；

圖6為本發(fā)明算法的平均作業(yè)響應(yīng)時(shí)間比較示意圖。

具體實(shí)施方式

下面結(jié)合附圖及實(shí)施例對(duì)本發(fā)明的實(shí)施方式作進(jìn)一步描述。

如圖1所示，本發(fā)明遵循如圖所示的資源三級(jí)調(diào)度模型，包括：

步驟1：選擇隊(duì)列。按照公平原則選擇最優(yōu)先的隊(duì)列。

步驟2：選擇作業(yè)。從選中隊(duì)列中的作業(yè)，按照公平原則或FIFO原則選擇最優(yōu)先的作業(yè)。

步驟3：選擇任務(wù)。通過基于預(yù)釋放資源列表的任務(wù)調(diào)度算法選擇一個(gè)任務(wù)。

圖中，①Fair原則選擇隊(duì)列；②Fair或FIFO原則選擇作業(yè)；③基于作業(yè)的預(yù)釋放資源列表選擇任務(wù)。

圖1則為本發(fā)明實(shí)施例的流程示意圖，該方法包括：

S101、空閑TaskTracker提交任務(wù)請(qǐng)求；

S102、初始化所有作業(yè)的預(yù)分配資源數(shù)；

作業(yè)的預(yù)分配資源數(shù)用Job.preAssignNum表示。初始化所有作業(yè)：Job.preAssignNum＝0；

S103、篩選出還需要資源的所有隊(duì)列needSlotPools；

具體篩選過程是通過比較隊(duì)列的資源需求量與隊(duì)列的預(yù)分配資源數(shù)。如果隊(duì)列的資源需求量大于隊(duì)列的預(yù)分配資源數(shù)，說明隊(duì)列需要資源；否則就說明隊(duì)列不需要資源。其中一個(gè)隊(duì)列的資源需求量等于該隊(duì)列下所有作業(yè)的資源需求量的和。一個(gè)作業(yè)的資源需求量等于該作業(yè)尚未運(yùn)行的任務(wù)數(shù)。一個(gè)隊(duì)列的預(yù)分配資源數(shù)等于該隊(duì)列下所有作業(yè)的預(yù)分配資源數(shù)的和。

S104、判斷needSlotPools是否為空。如果為空，則不為該TaskTracker分配任務(wù)，調(diào)度結(jié)束；如果不為空，繼續(xù)執(zhí)行下一步。

needSlotPools為空，說明所有的隊(duì)列都不需要資源，因此不為TaskTracer分配任務(wù)，調(diào)度結(jié)束。

S105、通過公平原則從needSlotPools中選擇一個(gè)隊(duì)列chosedPool；

公平原則具體是指：當(dāng)存在資源使用量小于最小資源量的隊(duì)列時(shí)，優(yōu)先選擇資源使用率最低的隊(duì)列，即(runningTasks+poolPreAssignNum)/minShare最小的隊(duì)列。其中runningTasks是隊(duì)列當(dāng)前正在運(yùn)行的Task數(shù)目，poolPreAssignNum是已經(jīng)預(yù)分配給該隊(duì)列的資源量，minShare為隊(duì)列的最小資源量，它等于用戶配置的隊(duì)列最小資源量與該隊(duì)列當(dāng)前的真實(shí)資源需求量再減去poolPreAssignNum的最小值。否則選擇任務(wù)權(quán)重比最小的隊(duì)列，其中隊(duì)列的任務(wù)權(quán)重比為：tasksToWeightRatio＝(runningTasks+poolPreAssignNum)/poolWeight。其中poolWeight是管理員配置的隊(duì)列權(quán)重。

S106、從被選中的隊(duì)列chosedPool中篩選出還需要資源的所有作業(yè)needSlotJobs；

具體的篩選過程是通過比較作業(yè)的資源需求量與作業(yè)的預(yù)分配資源數(shù)。如果作業(yè)的資源需求量大于作業(yè)的預(yù)分配資源數(shù)，說明作業(yè)需要資源；否則就說明作業(yè)不需要資源。

S107、通過公平原則或者FIFO原則，從needSlotJobs中選擇一個(gè)作業(yè)chosedJob；

公平調(diào)度器允許管理員將隊(duì)列設(shè)置為公平隊(duì)列或FIFO隊(duì)列。公平隊(duì)列按照公平原則選擇作業(yè)，F(xiàn)IFO隊(duì)列則按照FIFO原則選擇作業(yè)。

其中，作業(yè)的公平原則是指：優(yōu)先將資源分配給資源池中任務(wù)權(quán)重比最小的作業(yè)，其中作業(yè)的任務(wù)權(quán)重比為：tasksToWeightRatio＝(runningTasks+jobPreAssignNum)/jobWeight。其中jobPreAssignNum是已經(jīng)預(yù)分配給該作業(yè)的資源量，jobWeight是管理員配置的作業(yè)權(quán)重；當(dāng)作業(yè)的任務(wù)權(quán)重比也一樣時(shí)，則優(yōu)先選擇提交時(shí)間較早的作業(yè)。

FIFO原則是指：優(yōu)先選擇優(yōu)先級(jí)最高的作業(yè)；優(yōu)先級(jí)相同的情況下，選擇作業(yè)提交時(shí)間最早的作業(yè)。

S108、創(chuàng)建被選中作業(yè)chosedJob的預(yù)釋放資源列表；

預(yù)釋放資源列表是從當(dāng)前所有正在運(yùn)行的任務(wù)中挑選出來的。將滿足如下條件的任務(wù)加入預(yù)釋放資源列表，再將滿足條件的任務(wù)按照作業(yè)在任務(wù)所在資源的任務(wù)完成時(shí)間由小到大排序，即生成本發(fā)明的預(yù)釋放資源列表。

條件1：任務(wù)所在資源不能包含在預(yù)分配資源列表中。

其中預(yù)分配資源列表是指一批已經(jīng)預(yù)分配給Job的資源。在下節(jié)的基于預(yù)釋放資源列表的任務(wù)調(diào)度算法中會(huì)進(jìn)行預(yù)分配。

條件2：作業(yè)在任務(wù)所在資源的任務(wù)完成時(shí)間小于作業(yè)在當(dāng)前空閑資源的任務(wù)完成時(shí)間。

其中作業(yè)在任務(wù)所在資源的任務(wù)完成時(shí)間是由三部分構(gòu)成的，該任務(wù)的剩余完成時(shí)間、當(dāng)前作業(yè)中的任務(wù)在該任務(wù)所在主機(jī)的完成所需時(shí)間和數(shù)據(jù)傳輸時(shí)間。作業(yè)中的任務(wù)在當(dāng)前空閑資源的完成時(shí)間由兩部分構(gòu)成，當(dāng)前作業(yè)中的任務(wù)在該任務(wù)所在主機(jī)的完成所需時(shí)間和數(shù)據(jù)傳輸時(shí)間。

任務(wù)的剩余完成時(shí)間和任務(wù)在指定主機(jī)的完成所需時(shí)間在Hadoop的任務(wù)推測(cè)執(zhí)行機(jī)制中均提供相應(yīng)實(shí)現(xiàn)。數(shù)據(jù)傳輸時(shí)間是由任務(wù)的本地性決定的。對(duì)node-local任務(wù)的數(shù)據(jù)傳輸時(shí)間為0，rack-local和non-local任務(wù)的數(shù)據(jù)傳輸時(shí)間取決于任務(wù)數(shù)據(jù)大小和機(jī)架內(nèi)的網(wǎng)絡(luò)帶寬及機(jī)架間的網(wǎng)絡(luò)帶寬。

在本發(fā)明的任務(wù)調(diào)度器中，不同作業(yè)會(huì)生成不同的預(yù)釋放資源列表。因?yàn)楝F(xiàn)在Hadoop集群的機(jī)器一般都是異構(gòu)的，導(dǎo)致這些機(jī)器的CPU運(yùn)算能力和I/O讀寫能力都是不同的。這樣，Hadoop中不同類型的作業(yè)，如CPU密集型或I/O密集型作業(yè)面對(duì)同一個(gè)資源時(shí)，任務(wù)的處理時(shí)間是不一樣的。所以需要針對(duì)不同作業(yè)生成不同的預(yù)釋放資源列表。

構(gòu)建預(yù)釋放資源列表的偽代碼如下所示：

輸入?yún)?shù)依次為：按照公平原則被選中的作業(yè)，當(dāng)前申請(qǐng)任務(wù)的空閑TaskTracker和預(yù)分配資源列表

S109、判斷生成的預(yù)釋放資源是否為空。如果為空，則從chosedJob中按照任務(wù)調(diào)度原則選擇一個(gè)任務(wù)，調(diào)度結(jié)束；否則繼續(xù)執(zhí)行下一步；

任務(wù)調(diào)度原則是指優(yōu)先選擇滿足node-local的任務(wù)，次優(yōu)選擇rack-local的任務(wù)，最后選擇non-local的x任務(wù)。

S110、將預(yù)釋放資源列表中的第一個(gè)資源預(yù)分配給chosedJob。跳轉(zhuǎn)到S103繼續(xù)執(zhí)行。

將chosedJob的預(yù)分配資源數(shù)加1，即chosedJob.preAssignNum+＝1；同時(shí)將預(yù)分配給chosedJob的資源加入到預(yù)分配資源列表中。

從上面的流程中可以看到，本發(fā)明的調(diào)度結(jié)果存在兩種可能，一種可能是不為TaskTracker分配任務(wù)。這種情況一般是所有的隊(duì)列都已經(jīng)預(yù)分配了足夠的預(yù)釋放資源，也就是說存在足夠多的能使任務(wù)更快完成的預(yù)釋放資源，所以就不為這個(gè)較慢的TaskTracker分配任務(wù)了。另外一種可能是從chosedJob中按照任務(wù)調(diào)度原則選擇一個(gè)任務(wù)。此時(shí)預(yù)釋放資源列表為空，說明該chosedJob已經(jīng)找不到比當(dāng)前TaskTracker更好的資源，所以直接從chosedJob中選擇一個(gè)任務(wù)進(jìn)行調(diào)度。

下面通過一個(gè)實(shí)例進(jìn)一步描述該備份任務(wù)選擇算法，并將直接調(diào)度算法、延遲調(diào)度算法和本發(fā)明的調(diào)度算法進(jìn)行對(duì)比。如圖3所示，假設(shè)當(dāng)前集群只有一個(gè)隊(duì)列，隊(duì)列中有3個(gè)作業(yè)。Job1、Job2和Job3分別在Slot1、Slot2和Slot3上有數(shù)據(jù)本地性。作業(yè)優(yōu)先級(jí)job1>job2>job3。Slot3、Slot1和Slot2將依次空閑。當(dāng)前Slot3是請(qǐng)求任務(wù)的空閑資源。

(1)首先Slot3空閑資源開始請(qǐng)求任務(wù)，按照公平原則首先讓Job1選擇資源。按照本算法Job1會(huì)選擇預(yù)釋放資源列表的第一個(gè)資源。于是將Slot1預(yù)調(diào)度給Job1；繼續(xù)按照公平原則讓Job2選擇資源，同樣選擇預(yù)釋放資源列表中的第一個(gè)資源。于是將Slot2預(yù)調(diào)度給Job2。最后按照公平的原則讓Job3選擇資源，Job3的預(yù)釋放資源列表為空，因?yàn)镴ob3的任務(wù)在Slot1和Slot2上的完成時(shí)間要小于在Slot3的完成時(shí)間，此時(shí)就將Slot3分配給Job3，同時(shí)因?yàn)镴ob3有node-local任務(wù)在Slot3上，所以Job3會(huì)選擇一個(gè)本地性的任務(wù)在Slot3上執(zhí)行。

(2)接著Slot2空閑出來，并請(qǐng)求任務(wù)。按照公平的原則首先讓Job1選擇資源，將Slot1預(yù)分配給Job1；接著Job2選擇資源，直接從Job2上選擇一個(gè)本地任務(wù)在Slot2上執(zhí)行。

(3)最后Slot1空閑出來，并請(qǐng)求任務(wù)。Job1選擇一個(gè)本地任務(wù)在Slot1上執(zhí)行。

通過我們本發(fā)明的任務(wù)調(diào)度算法，所有的作業(yè)都獲得滿足本地性的資源。

接下來再看看延遲調(diào)度算法的結(jié)果：

(1)Slot3空閑并請(qǐng)求資源：因?yàn)镾lot3不滿足Job1的本地性，Job1把Slot3讓給下一個(gè)Job；Slot3同樣不滿足Job2的本地性，Job2繼續(xù)把資源讓給下一個(gè)作業(yè)；Slot3滿足Job3的本地性，所以就將Slot3分配給Job3。

(2)Slot2空閑并請(qǐng)求資源：Slot2同樣不滿足Job1的本地性，但此時(shí)Job1是否會(huì)把資源讓給下一個(gè)作業(yè)，取決于延遲調(diào)度算法延遲等待時(shí)間值的設(shè)置。如果當(dāng)前等待時(shí)間小于W1，則讓給Job2；如果當(dāng)前等待時(shí)間大于W1且小于W1+W2，則看Slot2是否滿足rack-local，滿足的話，Slot2調(diào)度給Job1，否則讓給Job2。如果大于W1+W2，則直接將Slot2調(diào)度給Job1。其中W1和W2是延遲調(diào)度算法需要設(shè)置的兩個(gè)時(shí)間參數(shù)。

(3)Slot1空閑并請(qǐng)求資源。Slot1調(diào)度給剩下的那個(gè)作業(yè)。

另外，F(xiàn)IFO調(diào)度器采用了直接調(diào)度算法，即直接把當(dāng)前空閑的資源調(diào)度給當(dāng)前優(yōu)先級(jí)高的作業(yè)。所以調(diào)度結(jié)果就是Slot3分配給Job1，Slot2分配給Job2，Slot1分配給Job1。

通過下面的表格對(duì)比一下不同的調(diào)度算法的結(jié)果：

表1舉例場(chǎng)景下不同算法的調(diào)度結(jié)果對(duì)比

從上表可以看出，本發(fā)明的算法任務(wù)本地性的效果是最好的，而延遲調(diào)度算法的結(jié)果則取決于延遲等待時(shí)間的設(shè)置。而直接調(diào)度算法則是任務(wù)本地性最差的。

但本算法的原則并不是為了使更多任務(wù)滿足本地性，而是每次調(diào)度都讓被選中的作業(yè)選擇對(duì)該作業(yè)對(duì)說最快的資源。不同于延遲調(diào)度算法，在當(dāng)前作業(yè)滿足不了本地性的情況下，需要將調(diào)度機(jī)會(huì)讓給下一個(gè)作業(yè)。也就是說，公平性需要讓步于本地性。這就存在了公平性和本地性之間的矛盾。本發(fā)明提出的預(yù)釋放資源列表，保證了作業(yè)能夠從更多的資源中發(fā)現(xiàn)更快的資源。然后通過預(yù)調(diào)度，保證了每次選中的作業(yè)都可以選擇對(duì)該作業(yè)來說最好的資源。最好的資源不是指滿足本地性的資源，而是指能使作業(yè)中的任務(wù)更快完成的資源。因?yàn)榉潜镜匦匀蝿?wù)需要數(shù)據(jù)傳輸時(shí)間，所以，一般來說，滿足本地性的任務(wù)完成得更快。所以，這也保證了本算法能保持很高的任務(wù)本地性。

為了驗(yàn)證本發(fā)明的可行性和有效性，將本發(fā)明的基于預(yù)釋放資源列表的公平調(diào)度算法(Fair-PRRL，Pre-Release Resources List)和Hadoop的采用延遲調(diào)度的公平調(diào)度算法(Fair-DL，Delay Sheduling)以及FIFO調(diào)度算法進(jìn)行對(duì)比?？疾觳煌惴ㄟ\(yùn)行各種類型的作業(yè)的結(jié)果，然后對(duì)算法在整個(gè)Hadoop的完成時(shí)間、作業(yè)本地性任務(wù)的情況以及平均作業(yè)響應(yīng)時(shí)間等方面進(jìn)行評(píng)估。

考慮到將一個(gè)調(diào)度算法直接在實(shí)際工作集群系統(tǒng)進(jìn)行長(zhǎng)時(shí)間測(cè)試計(jì)算、評(píng)估耗時(shí)太長(zhǎng)，而且要找到集群規(guī)模、計(jì)算資源與計(jì)算場(chǎng)景完全滿足每一次實(shí)驗(yàn)要求的實(shí)際系統(tǒng)也是非常困難的。因此，本發(fā)明根據(jù)Hadoop底層原理，基于Java語言實(shí)現(xiàn)了一個(gè)Hadoop模擬器，用于驗(yàn)證和分析本調(diào)度算法的有效性。以下是一些相關(guān)實(shí)現(xiàn)細(xì)節(jié)：

(1)模擬的Hadoop硬件配置情況：3個(gè)機(jī)架，每個(gè)機(jī)架上分別有10個(gè)慢節(jié)點(diǎn)、10個(gè)普通節(jié)點(diǎn)和10個(gè)快節(jié)點(diǎn)。其中，慢節(jié)點(diǎn)的任務(wù)處理速率是普通節(jié)點(diǎn)的0.8倍，快節(jié)點(diǎn)的任務(wù)處理速率是普通節(jié)點(diǎn)的1.2倍。每個(gè)節(jié)點(diǎn)上都設(shè)置4個(gè)Slot。機(jī)架內(nèi)的網(wǎng)絡(luò)帶寬是20M/S，機(jī)架間的帶寬則是5M/S。

(2)HDFS的配置情況：每個(gè)數(shù)據(jù)塊的大小設(shè)置為128M。然后每個(gè)數(shù)據(jù)塊的備份數(shù)設(shè)置為3。其備份策略考慮了負(fù)載均衡，具體為：首先選擇當(dāng)前負(fù)載最小的節(jié)點(diǎn)保存第一份數(shù)據(jù)；第二份數(shù)據(jù)保存的節(jié)點(diǎn)要求與第一份數(shù)據(jù)所在節(jié)點(diǎn)同機(jī)架但不同節(jié)點(diǎn)，在滿足要求的情況下選擇負(fù)載最小的節(jié)點(diǎn)；第三份數(shù)據(jù)保存的節(jié)點(diǎn)與第一份數(shù)據(jù)不同機(jī)架，同時(shí)也選擇負(fù)載最小的節(jié)點(diǎn)。每個(gè)數(shù)據(jù)塊有3份備份，這表明每個(gè)任務(wù)在3個(gè)節(jié)點(diǎn)上會(huì)有節(jié)點(diǎn)本地性。

(3)延遲調(diào)度算法的兩個(gè)時(shí)間參數(shù)：W1設(shè)置為5秒，W2設(shè)置為20秒。這兩個(gè)時(shí)間參數(shù)的設(shè)置也是考慮了集群的網(wǎng)絡(luò)帶寬。因?yàn)樵谝粋€(gè)機(jī)架內(nèi)，一個(gè)任務(wù)的數(shù)據(jù)傳輸時(shí)間約為6.4秒，通過BlockSize除以機(jī)架內(nèi)網(wǎng)絡(luò)帶寬計(jì)算所得；而跨機(jī)架傳輸時(shí)，一個(gè)任務(wù)的數(shù)據(jù)傳輸時(shí)間約為25.6秒，通過BlockSize除以機(jī)架間網(wǎng)絡(luò)帶寬計(jì)算所得。保證了等待到本地性任務(wù)的收益要大于非本地性任務(wù)的數(shù)據(jù)傳輸時(shí)間。

(4)作業(yè)類型情況：根據(jù)作業(yè)大小，劃分了三種類型的作業(yè)。

表2不同作業(yè)類型的任務(wù)處理時(shí)間

一個(gè)作業(yè)數(shù)據(jù)量的大小決定了這個(gè)作業(yè)包含的任務(wù)數(shù)，比如大作業(yè)的數(shù)據(jù)量為800*128M，就表明大作業(yè)會(huì)被分成800個(gè)任務(wù)。

我們總共運(yùn)行了四組實(shí)驗(yàn)，具體如下：

(1)創(chuàng)建3個(gè)隊(duì)列，每個(gè)隊(duì)列提交100個(gè)小作業(yè)，同時(shí)運(yùn)行。

(2)創(chuàng)建3個(gè)隊(duì)列，每個(gè)隊(duì)列提交50個(gè)普通作業(yè)，同時(shí)運(yùn)行。

(3)創(chuàng)建3個(gè)隊(duì)列，每個(gè)隊(duì)列提交20個(gè)大作業(yè)，同時(shí)運(yùn)行。

(4)創(chuàng)建3個(gè)隊(duì)列，每個(gè)隊(duì)列提交100個(gè)小作業(yè)、50個(gè)普通作業(yè)和20個(gè)大作業(yè)，同時(shí)運(yùn)行。

圖4顯示了各個(gè)調(diào)度算法分別運(yùn)行完成Hadoop中所有作業(yè)所需要的時(shí)間。實(shí)驗(yàn)結(jié)果表明，F(xiàn)air-PRRL算法在Hadoop完成時(shí)間方面明顯好于Fair-DL算法。在運(yùn)行小作業(yè)時(shí)，F(xiàn)air-PRRL算法的Hadoop完成時(shí)間少于FIFO算法，而其它情況下，則略大于FIFO算法。這也說明，其實(shí)在執(zhí)行批處理作業(yè)的時(shí)候，F(xiàn)IFO算法反而是效果最好的。因?yàn)镕IFO算法只是按照作業(yè)提交時(shí)間逐個(gè)地執(zhí)行作業(yè)，這樣，作業(yè)執(zhí)行的時(shí)候就不會(huì)有別的作業(yè)搶占資源。而Fair-DL算法，會(huì)同時(shí)運(yùn)行很多作業(yè)，這樣就可能導(dǎo)致某個(gè)作業(yè)的本地性資源，正好有其它作業(yè)的任務(wù)在這個(gè)資源上面執(zhí)行。這就導(dǎo)致了這個(gè)作業(yè)只能選擇非本地性的資源了，這也導(dǎo)致了更多的運(yùn)行時(shí)間。Fair-PRRL算法也是同時(shí)運(yùn)行多個(gè)作業(yè)，所以也存在著這樣的問題。

Fari-DL算法和Fair-PRRL算法都考慮到了這個(gè)問題，所以Fari-DL算法通過延遲調(diào)度來解決作業(yè)的本地性資源已經(jīng)被別的作業(yè)占領(lǐng)的問題，F(xiàn)air-PRRL算法則通過基于預(yù)釋放資源列表的任務(wù)調(diào)度算法來解決這個(gè)問題。

圖5顯示了各個(gè)調(diào)度算法的任務(wù)本地性情況。圖中的nonLocalNum表示非本地性任務(wù)數(shù)，rackLocalNum表示rack-local的任務(wù)數(shù)，nodeLocalNum表示node-local的任務(wù)數(shù)。從結(jié)果來看，F(xiàn)ari-DL的本地性情況是最差的，F(xiàn)ari-DL算法和FIFO算法效果差不多。并且在小作業(yè)的情況下，F(xiàn)ari-DL算法的任務(wù)本地性效果更好。

Fari-DL算法都是在執(zhí)行小作業(yè)的情況下，Hadoop完成時(shí)間和任務(wù)本地性情況優(yōu)于FIFO算法，原因是當(dāng)小作業(yè)較多時(shí)，本發(fā)明算法可以構(gòu)建出足夠大的預(yù)釋放資源列表，從而有更多的選擇可以獲取到對(duì)當(dāng)前作業(yè)更好的資源。

FIFO算法雖然在Hadoop完成時(shí)間和任務(wù)本地性方面表現(xiàn)很好，但它并不是一個(gè)適用多用戶、多隊(duì)列的一個(gè)調(diào)度算法。因?yàn)樗饌€(gè)地按照作業(yè)提交時(shí)間執(zhí)行作業(yè)，會(huì)導(dǎo)致后面的作業(yè)長(zhǎng)時(shí)間處于等待狀態(tài)。所以如果是在多用戶、多隊(duì)列的情況下，那么后提交作業(yè)的用戶將會(huì)長(zhǎng)時(shí)間的得不到反饋，處于后面的隊(duì)列也是同樣的道理。

圖6展示了各個(gè)算法的平均作業(yè)響應(yīng)時(shí)間。平均作業(yè)響應(yīng)時(shí)間是指作業(yè)從提交到開始執(zhí)行所需要的時(shí)間。FIFO算法的平均作業(yè)響應(yīng)時(shí)間遠(yuǎn)遠(yuǎn)大于另外兩個(gè)算法。而Fari-PRRL算法和Fari-DL算法則相差不大。

綜合以上三個(gè)性能指標(biāo)，本發(fā)明的Fari-PRRL調(diào)度算法無疑是最好的。雖然FIFO算法在Hadoop完成時(shí)間和任務(wù)本地性方面效果都不錯(cuò)，但Fari-PRRL算法與之相差不大，甚至在小作業(yè)較多的情況下，F(xiàn)ari-PRRL算法還略好于FIFO算法。而且FIFO算法不適合于多用戶、多隊(duì)列的情形，也大大限制了它的使用場(chǎng)景。至于Fari-DL算法，F(xiàn)ari-PRRL算法在Hadoop完成時(shí)間和任務(wù)本地性方面都要明顯更好，作業(yè)的平均響應(yīng)時(shí)間因?yàn)槎际遣捎玫墓秸{(diào)度原則，所以相差不大。

以上各實(shí)施例僅用以說明本發(fā)明的技術(shù)方案，而非對(duì)其限制；盡管參照前述各實(shí)施例對(duì)本發(fā)明進(jìn)行了詳細(xì)的說明，本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解：其依然可以對(duì)前述各實(shí)施例所記載的技術(shù)方案進(jìn)行修改，或者對(duì)其中部分或者全部技術(shù)特征進(jìn)行等同替換；而這些修改或者替換，并不使相應(yīng)技術(shù)方案的本質(zhì)脫離本發(fā)明各實(shí)施例技術(shù)方案的范圍。

參考文獻(xiàn)：

[1]Hadoop:Capacity Scheduler.http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html

[2]Hadoop:Fair Scheduler.http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yar n-site/FairScheduler.html

[3]Zaharia M,Borthakur D,Sen Sarma J,et al.Delay scheduling:a simple technique for achieving locality and fairness in cluster scheduling.In:European Conference on Comp uter Systems.New York,2010,265-278.