本發(fā)明屬于云計算平臺優(yōu)化技術(shù)領(lǐng)域，涉及一種Hadoop大數(shù)據(jù)平臺中基于備份任務(wù)運行時間估計的調(diào)度方法。

背景技術(shù)：

隨著信息技術(shù)產(chǎn)業(yè)迅猛發(fā)展，企業(yè)、組織和個人所產(chǎn)生的數(shù)據(jù)量也與日俱增，我們生活在一個數(shù)據(jù)增長比以往任何時候都要快的時代。2012年，Google在世界范圍內(nèi)擁有數(shù)百萬臺服務(wù)器總量的數(shù)據(jù)中心，平均每天要處理33億次的搜索請求，每月要處理的用戶生成數(shù)據(jù)更是超過了400PB；同年，F(xiàn)aceBook公布其數(shù)據(jù)中心平均每天接收3億張用戶上傳的圖片，數(shù)據(jù)庫中新增數(shù)據(jù)也超過了500TB。在IDC的2014年度數(shù)據(jù)報告中預(yù)測2020年將有40億人接入網(wǎng)絡(luò)，全球數(shù)據(jù)量將達(dá)到44ZB，這一數(shù)據(jù)規(guī)模是2013年的10倍之多。這些海量數(shù)據(jù)所蘊含的4V特征，即體量大(volume)，模式多(variety)，速度快(velocity)，價值密度低(value)，正是大數(shù)據(jù)管理和信息提取的困難度和復(fù)雜性所在。隨著社會全面信息化，我們進入了“大數(shù)據(jù)時代”。傳統(tǒng)數(shù)據(jù)存儲能力和數(shù)據(jù)處理技術(shù)逐漸顯得乏力，云計算技術(shù)應(yīng)運而生。

面對這些海量的數(shù)據(jù)，對它們存儲、挖掘、實時處理等，都需要云計算作為技術(shù)支撐，所以云計算是讓大數(shù)據(jù)發(fā)揮價值的關(guān)鍵。云計算這個概念的直接起源來自Dell的數(shù)據(jù)中心解決方案、Google和IBM的分布式計算項目。但云計算的思想得益于網(wǎng)格計算、并行計算、分布式計算、資源虛擬化、網(wǎng)絡(luò)存儲等傳統(tǒng)計算機技術(shù)和網(wǎng)絡(luò)技術(shù)的聯(lián)合演進以及相互融合。云計算采取集群計算，將若干獨立計算實體通過網(wǎng)絡(luò)整合成一個具有強大計算能力的資源池，并借助基礎(chǔ)設(shè)施即服務(wù)(IaaS)、平臺即服務(wù)(PaaS)、軟件即服務(wù)(SaaS)和管理服務(wù)提供商(MSP)等先進的商業(yè)模式，把計算資源池中強大的計算能力按需分配到用戶手中。

2003年以來，Google以學(xué)術(shù)論文的形式陸續(xù)公開了其GFS、MapReduce、BigTable等分布式海量數(shù)據(jù)處理框架，同時證明了該框架的高可擴展、高性能等優(yōu)越性?；谶@些技術(shù)，Doug Cutting將其運用到了全網(wǎng)搜索引擎項目(Nutch)中。2006年年初，開發(fā)人員將這個開源實現(xiàn)移出了Nutch，成為Lucene的一個子項目，稱為Hadoop。開源的Apache Hadoop提供了成熟的“大數(shù)據(jù)處理工具”，得到了廣泛應(yīng)用和支持，是“大數(shù)據(jù)”計算的事實標(biāo)準(zhǔn)。Hadoop中的調(diào)度策略組件負(fù)責(zé)系統(tǒng)中所有作業(yè)與其子任務(wù)的整個調(diào)度過程，包括如何選擇作業(yè)和它的子任務(wù)，以及如何選擇適合的計算節(jié)點來執(zhí)行它們。調(diào)度結(jié)果會直接影響Hadoop系統(tǒng)的整體性能和集群資源利用率。所以衡量調(diào)度策略優(yōu)劣的主要指標(biāo)就是系統(tǒng)對作業(yè)任務(wù)的響應(yīng)時間(即周轉(zhuǎn)時間)，和集群資源(例如計算資源和帶寬資源)的利用率，而目前Hadoop系統(tǒng)中仍在廣泛使用的調(diào)度策略均存在許多不足之處。我們通過對Hadoop的研究，提升其性能，以改善“云”的處理能力。

在分布式計算領(lǐng)域中，調(diào)度策略的根本目標(biāo)是根據(jù)當(dāng)前集群中各個節(jié)點上的資源(包括CPU、內(nèi)存和網(wǎng)絡(luò)資源)剩余情況與各個用戶作業(yè)的服務(wù)質(zhì)量(QoS，Quality of Service)要求，在資源和作業(yè)/任務(wù)之間做出最優(yōu)的匹配。由于用戶對作業(yè)的服務(wù)質(zhì)量的要求是多樣化的，因此，分布式系統(tǒng)中的任務(wù)調(diào)度是一個多目標(biāo)優(yōu)化問題，更進一步說，它是一個典型的NP問題。

在當(dāng)前的Hadoop版本中，Hadoop通過備份任務(wù)推測執(zhí)行機制來加快一項作業(yè)中的某些慢任務(wù)來縮短作業(yè)周轉(zhuǎn)時間。然而，推測執(zhí)行機制在任務(wù)剩余時間估計精度以及備份任務(wù)調(diào)度有效率等方面表現(xiàn)不足，會導(dǎo)致大量備份任務(wù)的結(jié)束時間并不比原始慢任務(wù)早，造成這些備份任務(wù)的分配和運行無效。這些不足不僅造成了系統(tǒng)資源的浪費，而且這些失效的備份任務(wù)使得原本的備份任務(wù)推測執(zhí)行機制失去了意義。

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

有鑒于此，本發(fā)明的目的在于提供一種Hadoop大數(shù)據(jù)平臺中基于備份任務(wù)運行時間估計的調(diào)度方法，采用SDN帶寬感知能力，建立BWRE備份任務(wù)運行時間估計模型，對基于備份任務(wù)推測執(zhí)行機制的備份任務(wù)調(diào)度方法進行優(yōu)化。

為達(dá)到上述目的，本發(fā)明提供如下技術(shù)方案：

一種Hadoop大數(shù)據(jù)平臺中基于備份任務(wù)運行時間估計的調(diào)度方法，該方法包括以下步驟：

S1：判斷在JobTracker節(jié)點上的Job(作業(yè))中的任務(wù)進程實體TaskTracker，即任務(wù)請求者，是否為一個慢節(jié)點，通過該TaskTracker運行作業(yè)的其他任務(wù)的時候的性能表現(xiàn)對其評估；如果是，則不能啟動任何備份任務(wù)；

S2：檢查JobTracker節(jié)點上的Job(作業(yè))中已經(jīng)啟動的任務(wù)數(shù)是否超過閥值；一個任務(wù)一旦啟動了備份任務(wù)，則需要兩倍的計算資源處理同樣的數(shù)據(jù)，這樣可以防止推測執(zhí)行機制濫用；

S3：篩選出Job(作業(yè))中所有滿足條件的任務(wù)，并保存到candidates表中，其中條件為：該任務(wù)未在TaskTraker失敗過，該任務(wù)沒有其他正在運行的備份任務(wù)，該任務(wù)已經(jīng)運行超過60秒，該任務(wù)已經(jīng)出現(xiàn)“拖后腿跡象”；然后根據(jù)LATE(LongestApproximate Time to End)最長剩余時間估計算法計算出candidates表中任務(wù)的剩余時間，并選擇剩余時間最大的任務(wù)，即慢任務(wù)，為其預(yù)啟動備份任務(wù)；其中LATE算法采用基于“任務(wù)運行速度”和“任務(wù)剩余時間估計”的策略，根據(jù)leftTime_i＝(1-Progress_i)/ProgressRate_i來估算任務(wù)的剩余時間；在candidates中有多個待選任務(wù)的時候，Hadoop傾向于選擇剩余時間最長的任務(wù)，這樣的任務(wù)是的其備份任務(wù)替代自己的可能性最大；

S4：判斷預(yù)啟動備份任務(wù)是否是本地任務(wù)，如果是，備份任務(wù)估計運行時間等于執(zhí)行時間，即runTime＝executeTime；

S5：如果預(yù)啟動備份任務(wù)不是本地任務(wù)，那么任務(wù)的輸入數(shù)據(jù)則是從多個節(jié)點拷貝而來，調(diào)用OpenFlow的Floodlight的北向API獲得對應(yīng)鏈路實時帶寬Bw(src～des)；

S6：基于SDN帶寬感知的BWRE(備份任務(wù)運行時間估計模型)計算出步驟S5中預(yù)啟動備份任務(wù)的估計運行時間runTime＝copyTime+executeTime，即運行時間等于輸入數(shù)據(jù)網(wǎng)絡(luò)拷貝時間與執(zhí)行時間之和；BWRE(BandWidth-basedRun-time Estimate)模型加入了任務(wù)輸入數(shù)據(jù)的網(wǎng)路拷貝時間，運用了SDN的帶寬感知能力，取得此預(yù)啟動備份任務(wù)的輸入數(shù)據(jù)源節(jié)點(src)與任務(wù)執(zhí)行節(jié)點(des)之間的實時網(wǎng)絡(luò)帶寬，即Bw(src～des)，然后根據(jù)任務(wù)輸入數(shù)據(jù)分片大小/實時網(wǎng)絡(luò)帶寬，即InputSize_i/Bw(src～des)得到預(yù)啟動備份任務(wù)估計運行時間中的任務(wù)輸入數(shù)據(jù)的網(wǎng)絡(luò)拷貝時間部分；同時利用SDN帶寬保障，當(dāng)預(yù)啟動備份任務(wù)調(diào)度給TaskTracker(TT_i)后，保障TT_i所在的節(jié)點與備份任務(wù)輸入數(shù)據(jù)所在節(jié)點之間的網(wǎng)絡(luò)帶寬能夠達(dá)到SDN感知獲取的瞬時帶寬；

S7：用leftTime(SlowTask_i)和runTime(SpeculativeTask_i)分別表示步驟S3中計算出的慢任務(wù)剩余時間和步驟S4或者S6中計算出的預(yù)啟動備份任務(wù)的估計運行時間，并做對比，若符合leftTime(SlowTask_i)＞runTime(SpeculativeTask_i)，則將此預(yù)啟動備份任務(wù)(SpeculativeTask)調(diào)度給TaskTracker，正式啟動此備份任務(wù)，反之，則不調(diào)度。

進一步，在步驟S1中，需要判斷TaskTracker(TT_i)是否是慢節(jié)點，根據(jù)公式：

${\stackrel{\‾}{\mathrm{Pr}ogressRate\left({\mathrm{TT}}_i\right)}}_f-{\stackrel{\‾}{\mathrm{Pr}ogressRate(*)}}_f\≤\mathrm{\σ}\×slowNodeThreshold$

其中，表示一個TaskTracker(TT_i)上所有運行狀態(tài)為finished的任務(wù)的平均任務(wù)增長率；同時表示所有作業(yè)Job_j的任務(wù)中運行狀態(tài)為finished的任務(wù)的平均進度增長率；

如果滿足上述公式，則TaskTracker不是慢節(jié)點，有能力啟動一個備份任務(wù)；

其中，TT_i表示第i個進程實體TaskTracker；σ表示作業(yè)Job_j中所有任務(wù)進度增長率的標(biāo)準(zhǔn)方差；slowNodeThreshold是LATE設(shè)定的參數(shù)，表示TaskTracker上已運行完成任務(wù)的平均進度增長率與所有已完成任務(wù)的平均進度增長率的最大允許差距。

進一步，在步驟S2中，由于啟動備份任務(wù)消耗集群資源，Hadoop要求同時啟動的備份任務(wù)數(shù)占所有正在運行任務(wù)的比例不超過speculativeCap；根據(jù)下面的公式來判斷Job中已經(jīng)啟動的任務(wù)數(shù)是否超過閥值：

speculativeTaskCount/numRunningTask＜speculativeCap

其中，speculativeCap是在配置文件mapred-default.xml中由參數(shù)mapreduce.job.speculative.speculativecap設(shè)定的門限值，用于限定該作業(yè)允許啟動備份任務(wù)的任務(wù)數(shù)目占正在運行任務(wù)的百分比。

進一步，在步驟S3中，需要篩選出Job(作業(yè))中所有滿足條件的任務(wù)，其中一個要求就是該任務(wù)已經(jīng)出現(xiàn)“拖后腿跡象”，根據(jù)下面的公式來判斷該任務(wù)是否出現(xiàn)“拖后腿跡象”：

${\stackrel{\‾}{\mathrm{Pr}ogressRate(*)}}_f-{\stackrel{\‾}{\mathrm{Pr}ogressRate\left({\mathrm{Task}}_i\right)}}_f\≤\mathrm{\σ}\×slowTaskThreshold$

其中，表示所有作業(yè)Job_j的任務(wù)中運行狀態(tài)為finished的任務(wù)的平均進度增長率；表示一個任務(wù)Task_i的平均任務(wù)進度增長率；

根據(jù)LATE(最長剩余時間估計算法)算出在candidates表中的慢任務(wù)i的剩余時間leftTime(SlowTask_i)，公式如下：

leftTime(SlowTask_i)＝(1-Progress_i)/ProgressRate_i

其中，Progress_i表示任務(wù)進度；ProgressRate_i表示任務(wù)i的執(zhí)行速度；

ProgressRate_i＝Progress_i/Δt

選擇剩余時間最大的任務(wù)，即慢任務(wù)，為其預(yù)啟動備份任務(wù)。

進一步，在步驟S6中，預(yù)啟動備份任務(wù)的估計運行時間：

runTime＝copyTime+executeTime，即估計運行時間等于輸入數(shù)據(jù)網(wǎng)絡(luò)拷貝時間與執(zhí)行時間之和，計算需要用到基于SDN帶寬感知的BWRE(備份任務(wù)運行時間估算模型)，如下式：

$runTime\left({\mathrm{SpeculativeTime}}_i\right)=\frac{{\mathrm{inputSize}}_i}{Bw(src~des)}+\frac{1}{{\stackrel{\‾}{\mathrm{Pr}ogressRate\left({\mathrm{TT}}_k\right)}}_f}$

其中，Bw(src～des)表示當(dāng)前系統(tǒng)中此輸入數(shù)據(jù)分片所在的物理節(jié)點(src)與TaskTracker所在節(jié)點(des)之間的實時網(wǎng)絡(luò)帶寬，借助SDN的帶寬感知能力，調(diào)用OpenFlow的Floodlight的北向API獲得對應(yīng)鏈路實時帶寬來實現(xiàn)這個功能；表示此備份任務(wù)在該任務(wù)請求者TT_k上預(yù)估的任務(wù)執(zhí)行時間；其中，1代表任務(wù)進度，在Hadoop中無論是Map任務(wù)還是Reduce任務(wù)，任務(wù)進度表示一個比例值，取值范圍是[0,1]，所以總?cè)蝿?wù)進度就是1；而表示根據(jù)TT_k上所執(zhí)行過的該項作業(yè)所有任務(wù)的進度率的平均值，來預(yù)測它執(zhí)行該項備份任務(wù)的進度率；InputSize_i/Bw(src～des)表示備份任務(wù)的輸入數(shù)據(jù)的遠(yuǎn)程拷貝時間，如果是本地任務(wù)則為0，因為不需要遠(yuǎn)程拷貝；

1)如果備份任務(wù)是Map任務(wù)，那么InputSize_i表示任務(wù)i的輸入數(shù)據(jù)分片(InpuSplit)的大小，此數(shù)據(jù)分片大小與數(shù)據(jù)塊的大小相同，默認(rèn)為64MB；

2)如果備份任務(wù)是Reduce任務(wù)，那么InputSize_i表示Reduce任務(wù)從各個Map任務(wù)端拷貝的中間數(shù)據(jù)，根據(jù)節(jié)點匯報線程(Reporter)中向JobTracker匯報的該Reduce任務(wù)的輸入數(shù)據(jù)量取得；

表示此備份任務(wù)在該任務(wù)請求者TT_k上預(yù)估的任務(wù)執(zhí)行時間，其中，1代表任務(wù)進度，在Hadoop中無論是Map任務(wù)還是Reduce任務(wù)，任務(wù)進度表示一個比例值，取值范圍是[0,1]，所以總?cè)蝿?wù)進度就是1；而表示根據(jù)TT_k上所執(zhí)行過的該項作業(yè)所有任務(wù)的進度率的平均值，來預(yù)測它執(zhí)行該項備份任務(wù)的進度率。

其中，將Hadoop系統(tǒng)建立在SDN網(wǎng)絡(luò)層之上；SDN網(wǎng)絡(luò)層主要由OpenFlow控制器和OpenFlow交換機組成。OpenFlow控制器負(fù)責(zé)對整個SDN網(wǎng)絡(luò)的管控功能；使用Floodlight控制器作為OpenFlow控制器的實體軟件。在Floodlight控制器中加入服務(wù)質(zhì)量(QoS)程序模塊，可以實現(xiàn)流量監(jiān)控、接口限速、流量分類、擁塞管理等功能。而JobTracker通過Floodlight向上層提供的北向API接口調(diào)用QoS模塊提供的服務(wù)質(zhì)量保障功能。由此，利用帶有QoS模塊的Floodlight控制器提供了所需的兩個功能：

1)利用SDN帶寬感知：獲得任務(wù)請求者TT_k所在物理節(jié)點與備份任務(wù)的輸入數(shù)據(jù)所在物理節(jié)點之間的實時網(wǎng)絡(luò)帶寬；

2)利用SDN帶寬保障：當(dāng)備份任務(wù)調(diào)度給TT_k后，保障TT_k所在的節(jié)點與備份任務(wù)輸入數(shù)據(jù)所在節(jié)點之間的網(wǎng)絡(luò)帶寬能夠達(dá)到1)中獲取的瞬時帶寬。

進一步，在步驟S7中，用leftTime(SlowTask_i)和runTime(SpeculativeTask_i)分別表示原始慢任務(wù)的剩余時間和預(yù)啟動備份任務(wù)的估計運行時間；如果符合下式，則將此預(yù)啟動備份任務(wù)(SpeculativeTask_i)調(diào)度給任務(wù)請求者TT_i，正式啟動備份任務(wù)；

leftTime(SlowTask_i)＞runTime(SpeculativeTask_i)

這樣，在備份任務(wù)調(diào)度的關(guān)鍵處，通過添加對慢任務(wù)剩余時間與備份任務(wù)的運行時間之間做對比的方式，增加此備份任務(wù)的可信賴程度，即相信這個備份任務(wù)能夠比原始慢任務(wù)更早結(jié)束，從而提高備份任務(wù)的有效率。這不僅可以縮短作業(yè)周轉(zhuǎn)時間，還可以降低無效備份任務(wù)帶來的系統(tǒng)資源浪費。

本發(fā)明的有益效果在于：本發(fā)明結(jié)合了SDN的帶寬感知能力，提出了備份任務(wù)運行時間估計模型(BWRE)，通過為節(jié)點任務(wù)請求者TT_i分配備份任務(wù)時加入慢任務(wù)的剩余時間與預(yù)啟動備份任務(wù)在該TT_i上的估計運行時間之間的對比，增加此備份任務(wù)的可信賴程度，即相信這個備份任務(wù)能夠比原始慢任務(wù)更早結(jié)束，從而提高備份任務(wù)的有效率。這不僅可以縮短作業(yè)周轉(zhuǎn)時間，還可以降低無效備份任務(wù)帶來的系統(tǒng)資源浪費。

附圖說明

為了使本發(fā)明的目的、技術(shù)方案和有益效果更加清楚，本發(fā)明提供如下附圖進行說明：

圖1為本發(fā)明所述方案的宏觀流程圖；

圖2為本發(fā)明所述的基于備份任務(wù)運行時間估計的調(diào)度方法流程圖；

圖3為本發(fā)明的備份任務(wù)調(diào)度模塊圖；

圖4為本發(fā)明所述的基于備份任務(wù)運行時間估計的調(diào)度方法框架；

圖5為一個Hadoop集群網(wǎng)絡(luò)拓?fù)鋱D；

圖6為Hadoop框架中基于備份任務(wù)運行時間估計的調(diào)度方法的時序圖。

具體實施方式

下面將結(jié)合附圖，對本發(fā)明的優(yōu)選實施例進行詳細(xì)的描述。

圖1為本發(fā)明所述方案的宏觀流程圖，圖2為本發(fā)明所述的基于備份任務(wù)運行時間估計的調(diào)度方法流程圖，如圖所示，本發(fā)明所述的Hadoop大數(shù)據(jù)平臺中基于備份任務(wù)運行時間估計的調(diào)度方法主要包括以下七個步驟：步驟一：判斷在JobTracker節(jié)點上的Job(作業(yè))中的任務(wù)進程實體TaskTracker，即任務(wù)請求者，是否為一個慢節(jié)點；步驟二：檢查JobTracker節(jié)點上的Job(作業(yè))中已經(jīng)啟動的任務(wù)數(shù)是否超過閥值；步驟三：篩選出Job(作業(yè))中所有滿足條件的任務(wù)，并保存到candidates表中，根據(jù)LATE(最長剩余時間估計算法)計算出任務(wù)剩余時間leftTime，選擇剩余時間最大的任務(wù)，即慢任務(wù)，為其預(yù)啟動備份任務(wù)；步驟四：判斷預(yù)啟動備份任務(wù)是否是本地任務(wù)，如果是，備份任務(wù)運行時間即為備份任務(wù)執(zhí)行時間，即runTime＝executeTime；步驟五：如果步驟四中的預(yù)啟動備份任務(wù)不是本地任務(wù)，調(diào)用OpenFlow的Floodlight北向API獲得對應(yīng)鏈路實時帶寬Bw(src～des)；步驟六：基于SDN帶寬感知的BWRE(備份任務(wù)運行時間估計模型)計算出預(yù)啟動備份任務(wù)的估計運行時間runTime＝copyTime+executeTime，即估計運行時間等于輸入數(shù)據(jù)網(wǎng)絡(luò)拷貝時間與執(zhí)行時間之和；步驟七：用leftTime(SlowTask_i)和runTime(SpeculativeTask_i)分別表示步驟三計算得到的慢任務(wù)的剩余時間和步驟四或六中計算得到的預(yù)啟動備份任務(wù)的估計運行時間，并做對比，若符合leftTime(SlowTask_i)＞runTime(SpeculativeTask_i)，則將預(yù)啟動備份任務(wù)(SpeculativeTask)調(diào)度給TaskTracker正式啟動備份任務(wù)。

在Hadoop平臺中JobTracker以“三層多叉樹”的方式，描述和跟蹤每個作業(yè)的運行狀態(tài)，作業(yè)被抽象成三層，從上往下依次為：作業(yè)監(jiān)控層、任務(wù)監(jiān)控層和任務(wù)執(zhí)行層。在作業(yè)監(jiān)控層中，每個作業(yè)由一個JobInProgress(JIP)對象描述和跟蹤其整體運行狀態(tài)以及每個任務(wù)的運行情況；在任務(wù)監(jiān)控層中，每個任務(wù)由一個TaskInProgress(TIP)對象描述和跟蹤其運行狀態(tài)。

所以在步驟一中Hadoop通過該TaskTracker運行該作業(yè)i的其他任務(wù)時候的性能表現(xiàn)對其進行評估，判斷其是否是慢節(jié)點，也就是是否滿足下面的條件：

${\stackrel{\‾}{\mathrm{Pr}ogressRate\left({\mathrm{TT}}_i\right)}}_f-{\stackrel{\‾}{\mathrm{Pr}ogressRate(*)}}_f\≤\mathrm{\σ}\×slowNodeThreshold$

其中，表示一個TaskTracker(TT_i)上所有運行狀態(tài)為finished的任務(wù)的平均任務(wù)增長率；同時表示所有作業(yè)Job_j的任務(wù)中運行狀態(tài)為finished的任務(wù)的平均進度增長率。

如果滿足上述公式，則TaskTracker不是慢節(jié)點，有能力啟動一個備份任務(wù)。

在步驟二中檢查JobTracker節(jié)點上的Job(作業(yè))中已經(jīng)啟動的任務(wù)數(shù)是否超過閥值。Hadoop要求同時啟動的備份任務(wù)數(shù)目與所有正在運行任務(wù)的比例不能超過speculativeCap。滿足下面條件即可：

speculativeTaskCount/numRunningTask＜speculativeCap

其中，speculativeCap是在配置文件mapred-default.xml中由參數(shù)mapreduce.job.speculative.speculativecap設(shè)定的門限值，用于限定該作業(yè)允許啟動備份任務(wù)的任務(wù)數(shù)目占正在運行任務(wù)的百分比。

在步驟三中，Hadoop系統(tǒng)中的節(jié)點上的任務(wù)實例(Task)周期性的向TaskTracker匯報最新進度，它以線程的形式將任務(wù)進度信息封裝在Progress類的實例中，且每個Progress實例計算出任務(wù)進度值，最終被Reporter匯報給TaskTracker。而TaskTracker再以心跳信息的形式發(fā)送給JobTracker。JobTracker根據(jù)上述信息進行慢任務(wù)推測，篩選出Job(作業(yè))中所有滿足條件的任務(wù)，其中一個要求就是該任務(wù)已經(jīng)出現(xiàn)“拖后腿跡象”?？梢愿鶕?jù)下面的公式來判斷該任務(wù)是否出現(xiàn)“拖后腿跡象”：

${\stackrel{\‾}{\mathrm{Pr}ogressRate(*)}}_f-{\stackrel{\‾}{\mathrm{Pr}ogressRate\left({\mathrm{Task}}_i\right)}}_f\≤\mathrm{\σ}\×slowTaskThreshold$

其中，表示所有作業(yè)Job_j的任務(wù)中運行狀態(tài)為finished的任務(wù)的平均進度增長率；表示一個任務(wù)Task_i的平均任務(wù)進度增長率；

接下來根據(jù)LATE算法算出在candidates表中的慢任務(wù)i的剩余時間leftTime(SlowTask_i)，公式如下：

leftTime(SlowTask_i)＝(1-Progress_i)/ProgressRate_i

其中，Progress_i表示任務(wù)進度；ProgressRate_i表示任務(wù)i的執(zhí)行速度。

ProgressRate_i＝Progress_i/Δt

按照運行剩余時間由大到小對candidates表中任務(wù)進行排序，并選擇剩余時間最大的任務(wù)，即慢任務(wù)，作業(yè)調(diào)度器調(diào)度任務(wù)時調(diào)用JobInProgress的obtainNewTask()函數(shù)會獲取到慢任務(wù)，為其預(yù)啟動備份任務(wù)。即通過調(diào)用JobInProgress的findSpeculativeTask()函數(shù)選擇備份任務(wù)。為作業(yè)調(diào)度器(TaskScheduler)添加一個監(jiān)聽者，當(dāng)作業(yè)調(diào)度器中調(diào)度了findSpeculativeTask()函數(shù)，那么便開始啟動基于SDN帶寬感知的備份任務(wù)調(diào)度模塊(SDNScheduler)，如圖3備份任務(wù)調(diào)度模塊圖所示，SDNScheduler主要包含兩部分：LATE備份任務(wù)改進調(diào)度策略和BWRE計算模型，此模塊對作業(yè)調(diào)度器的備份任務(wù)分配做出最終決策。

在步驟四中，需要判斷預(yù)啟動備份任務(wù)是否是本地任務(wù)，如果是，備份任務(wù)估計運行時間等于執(zhí)行時間，即runTime＝executeTime；

在步驟五中，如果預(yù)啟動備份任務(wù)不是本地任務(wù)，那么任務(wù)的輸入數(shù)據(jù)則是從多個節(jié)點拷貝而來，如圖4所示，調(diào)用OpenFlow的Floodlight的北向API獲得對應(yīng)鏈路實時帶寬Bw(src～des)；

在步驟六中，預(yù)啟動備份任務(wù)的估計運行時間runTime＝copyTime+executeTime，即估計運行時間等于輸入數(shù)據(jù)網(wǎng)絡(luò)拷貝時間與執(zhí)行時間之和的計算需要用到基于SDN帶寬感知的BWRE(備份任務(wù)運行時間估算模型)，如下式：

$runTime\left({\mathrm{SpeculativeTime}}_i\right)=\frac{{\mathrm{inputSize}}_i}{Bw(src~des)}+\frac{1}{{\stackrel{\‾}{\mathrm{Pr}ogressRate\left({\mathrm{TT}}_k\right)}}_f}$

其中，Bw(src～des)表示當(dāng)前系統(tǒng)中此輸入數(shù)據(jù)分片所在的物理節(jié)點(src)與TaskTracker所在節(jié)點(des)之間的實時網(wǎng)絡(luò)帶寬，如圖4備份任務(wù)調(diào)度框架所示，借助SDN的帶寬感知能力，調(diào)用OpenFlow的Floodlight的北向API獲得對應(yīng)鏈路實時帶寬來實現(xiàn)這個功能；表示此備份任務(wù)在該任務(wù)請求者TT_k上預(yù)估的任務(wù)執(zhí)行時間。如果預(yù)啟動備份任務(wù)是本地任務(wù)，則備份任務(wù)估計運行時間等于執(zhí)行時間，即runTime＝executeTime，此時遠(yuǎn)程拷貝時間InputSize_i/Bw(src～des)為0；反之，如果預(yù)啟動備份任務(wù)不是本地任務(wù)，預(yù)啟動備份任務(wù)的估計運行時間runTime＝copyTime+executeTime，即估計運行時間等于輸入數(shù)據(jù)網(wǎng)絡(luò)拷貝時間與執(zhí)行時間之和，此時Bw(src～des)是建立在SDN網(wǎng)絡(luò)層之上的Hadoop系統(tǒng)中的JobTracker通過Floodlight向上層提供的北向API接口調(diào)用QoS模塊提供的服務(wù)質(zhì)量保障功能直接獲取到的鏈路的實時帶寬。而關(guān)于QoS模塊中鏈路帶寬保障的實現(xiàn)，主要是利用了Floodlight控制器對OpenFlow交換機中流表項的添加和修改功能。由此，利用帶有QoS模塊的Floodlight控制器提供的SDN帶寬感知和SDN帶寬保障功能，根據(jù)BWRE模型計算得到備份任務(wù)運行估計時間。圖5為一個Hadoop集群網(wǎng)絡(luò)拓?fù)鋱D，圖6為Hadoop框架中基于備份任務(wù)運行時間估計的調(diào)度方法的時序圖。

在步驟七中，將步驟三中計算得到的原始慢任務(wù)的剩余時間和步驟四或者六中計算得到的預(yù)啟動備份任務(wù)的估計運行時間進行對比，如果符合下式，則將此預(yù)啟動備份任務(wù)(SpeculativeTask_i)調(diào)度給任務(wù)請求者TaskTracker正式啟動備份任務(wù)。

leftTime(SlowTask_i)＞runTime(SpeculativeTask_i)

只有這樣為該TaskTracker調(diào)度這個備份任務(wù)才有意義。如果不滿足上式，則不進行調(diào)度，提高備份任務(wù)的有效率。

最后說明的是，以上優(yōu)選實施例僅用以說明本發(fā)明的技術(shù)方案而非限制，盡管通過上述優(yōu)選實施例已經(jīng)對本發(fā)明進行了詳細(xì)的描述，但本領(lǐng)域技術(shù)人員應(yīng)當(dāng)理解，可以在形式上和細(xì)節(jié)上對其作出各種各樣的改變，而不偏離本發(fā)明權(quán)利要求書所限定的范圍。