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

背景技術(shù)：

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

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

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

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

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

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

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

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

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

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

S105：通過公平原則從needSlotPools中選擇一個隊列chosedPool；

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

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

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

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

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

進一步的，所述步驟S103具體篩選過程包括：

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

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

進一步的，所述步驟S106具體篩選過程包括：

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

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

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

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

附圖說明

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

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

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

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

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

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

具體實施方式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

S105、通過公平原則從needSlotPools中選擇一個隊列chosedPool；

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

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

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

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

公平調(diào)度器允許管理員將隊列設(shè)置為公平隊列或FIFO隊列。公平隊列按照公平原則選擇作業(yè)，F(xiàn)IFO隊列則按照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)重比也一樣時，則優(yōu)先選擇提交時間較早的作業(yè)。

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

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

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

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

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

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

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

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

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

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

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

S109、判斷生成的預(yù)釋放資源是否為空。如果為空，則從chosedJob中按照任務(wù)調(diào)度原則選擇一個任務(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ù)釋放資源列表中的第一個資源預(yù)分配給chosedJob。跳轉(zhuǎn)到S103繼續(xù)執(zhí)行。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們總共運行了四組實驗，具體如下：

(1)創(chuàng)建3個隊列，每個隊列提交100個小作業(yè)，同時運行。

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

(3)創(chuàng)建3個隊列，每個隊列提交20個大作業(yè)，同時運行。

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

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

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

圖5顯示了各個調(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完成時間和任務(wù)本地性情況優(yōu)于FIFO算法，原因是當(dāng)小作業(yè)較多時，本發(fā)明算法可以構(gòu)建出足夠大的預(yù)釋放資源列表，從而有更多的選擇可以獲取到對當(dāng)前作業(yè)更好的資源。

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

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

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

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

參考文獻：

[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.