吳 岳

(國家林業(yè)和草原局 林產(chǎn)工業(yè)規(guī)劃設(shè)計院,北京 100010)

基于MapReduce的程序被越來越多地應(yīng)用于大型數(shù)據(jù)分析的應(yīng)用中.程序運行時間的縮短對于MapReduce 程序以及所有數(shù)據(jù)處理應(yīng)用而言至關(guān)重要,而能夠準確估算MapReduce 程序的執(zhí)行時間是優(yōu)化程序的重要環(huán)節(jié).因此,作者需要建立基于MapReduce程序數(shù)據(jù)處理應(yīng)用的性能模型.分析基于MapReduce程序性能模型的實驗成本遠低于在真實數(shù)據(jù)分析系統(tǒng)中設(shè)置模擬實驗,也可以得到準確的系統(tǒng)作業(yè)響應(yīng)時間,準確了解不同狀況下的系統(tǒng)作業(yè)響應(yīng)時間是對MapReduce 作業(yè)負載管理和資源分配規(guī)劃做出決策的重要依據(jù).

基于MapReduce 程序編寫需要將算法調(diào)整為兩階段的處理模型,即Map 模型和Reduce 模型.以這種方式編寫的程序會自動在計算集群上并行執(zhí)行.Apache Hadoop是最常用的開源MapReduce 模型之一.在Hadoop1.x 版本中,MapReduce 程序模型與資源管理是整合在一起的.為了達到更高的集群利用率、可靠性和可用性,支持編程模型多樣性、向后兼容性以及彈性資源模型,Hadoop2.x 版本的體系結(jié)構(gòu)進行了重大改進,引入了YARN 框架(Yet Another Resource Negotiator)——獨立的資源管理模塊.Hadoop2.x 版本的體系結(jié)構(gòu)發(fā)生了明顯改變,YARN 框架將MapReduce 編程模型從資源管理結(jié)構(gòu)中分離出來,集群資源被認為是一個整體,沒有被靜態(tài)地劃分給每個Map和Reduce 作業(yè).

本文定義了一個在Hadoop2.x 版本中能夠準確估算MapReduce 作業(yè)負載執(zhí)行時間的性能模型.該模型包括一個優(yōu)先級樹模型與一個排隊網(wǎng)絡(luò)模型,優(yōu)先級樹模型可以展示一個MapReduce 作業(yè)中不同任務(wù)之間的依賴關(guān)系,排隊網(wǎng)絡(luò)模型可以展示MapReduce 作業(yè)內(nèi)的同步約束.

通過分析Hadoop2.x的體系結(jié)構(gòu),作者確定了可能影響MapReduce 作業(yè)執(zhí)行開銷的因素,為Hadoop2.x定義了理論上的MapReduce 開銷模型,該模型展示了不同MapReduce 作業(yè)的優(yōu)先級以及由于共享資源導(dǎo)致的同步延遲.通過比較開銷模型的估算數(shù)據(jù)與MapReduce的實際執(zhí)行數(shù)據(jù)來評估開銷模型的準確性.

1 適用于Hadoop1.x的性能評估模型

有兩種方法可以分析Hadoop1.x 中MapReduce作業(yè)的性能,分別為靜態(tài)MapReduce 性能模型和動態(tài)MapReduce 性能模型.靜態(tài)MapReduce 性能模型中不考慮由于爭用共享資源導(dǎo)致的排隊延遲與不同Map-Reduce 作業(yè)之間的同步延遲.動態(tài)MapReduce 性能模型中考慮了并發(fā)MapReduce 程序執(zhí)行與排隊延遲.

1.1 靜態(tài)MapReduce 性能模型

靜態(tài)MapReduce 性能模型可以描述Hadoop1.x 中MapReduce 作業(yè)的執(zhí)行情況.性能模型以細粒度的方式描述MapReduce 作業(yè)內(nèi)各個階段的數(shù)據(jù)流和開銷情況.Map 作業(yè)可分為:Read,Map,Collect,Spill、Merge五個階段.Reduce 作業(yè)的Shuffle、Merge、Reduce、write 階段均有獨立的公式.整個工作的執(zhí)行時間可以認為是Map和Reduce 作業(yè)所有階段執(zhí)行時間的總和.

該模型為MapReduce 作業(yè)完成時間與MapReduce作業(yè)資源分配定義上限值和下限值,在給定的作業(yè)完成期限內(nèi)分配滿足該MapReduce 作業(yè)所需的資源,以便MapReduce 操作在要求的期限內(nèi)完成.該框架由3 個相關(guān)聯(lián)的部分組成.(1)作業(yè)配置文件,其中該應(yīng)用程序Map和Reduce 階段的性能特征.(2)構(gòu)建一個MapReduce 性能模型,該模型根據(jù)給定作業(yè)截止期限來估算在截止期限內(nèi)完成作業(yè)所需的資源量.(3)調(diào)度程序本身,它確定MapReduce作業(yè)順序以及在截止日期之內(nèi)完成MapReduce 作業(yè)所需的資源量.

MapReduce 作業(yè)完成時間與輸入數(shù)據(jù)集的規(guī)模及分配資源的數(shù)量有關(guān),定義作業(yè)完成時間的上限TJUp,作業(yè)完成時間下限為TJLow,平均完成時間TJAvg.假設(shè)TJAvg=(TJUp+TJLow)/2,由于誤差等原因,作業(yè)平均完成時間會比作業(yè)實際完成時間少15%左右,因此基于作業(yè)平均完成時間的預(yù)測很適合確保作業(yè)在截止日期之前完成,是最接近實際作業(yè)完成時間的.在Hadoop1.x 中,用于Map和Reduce 作業(yè)的資源數(shù)量是預(yù)先確定的并不會更改.在Hadoop2.x 中,YARN 完全將靜態(tài)資源分配從MapReduce 作業(yè)中分離出來,并且不能忽略作業(yè)之間的依賴關(guān)系,因此靜態(tài)MapReduce 性能模型不再適用.

1.2 動態(tài)MapReduce 性能模型

研究MapReduce 性能模型的最大難點是,必須精準地捕獲到MapReduce 作業(yè)執(zhí)行過程中不同原因造成的延遲.特別是,屬于某個MapReduce 作業(yè)的任務(wù)可能會發(fā)生兩種類型的延遲:由于爭用共享資源產(chǎn)生的排隊延遲,在同一MapReduce 作業(yè)中進行協(xié)作的任務(wù)之間由于優(yōu)先級約束而導(dǎo)致的同步延遲.在不考慮同步延遲的條件下,主要有兩種方法可以評估并行應(yīng)用程序的MapReduce 作業(yè)負載性能.第一種方法是平均值分析(MVA).MVA 僅考慮任務(wù)由于共享公共資源而導(dǎo)致的排隊延遲.因此,MVA 無法直接應(yīng)用于具有優(yōu)先級約束的工作負載,例如同一個MapReduce 作業(yè)中Map和Reduce 任務(wù)的同步.另一種典型的解決方案是利用馬爾可夫鏈來表示系統(tǒng)的狀態(tài),并對網(wǎng)絡(luò)模型進行排隊,以計算系統(tǒng)不同狀態(tài)之間的轉(zhuǎn)換率.但是,在MapReduce 作業(yè)中,系統(tǒng)狀態(tài)的數(shù)量會隨著任務(wù)數(shù)量的增加呈指數(shù)增長,所以此種方法無法應(yīng)用于具有多個任務(wù)的MapReduce 作業(yè)模型中[1].

2 Hadoop2.x的體系結(jié)構(gòu)

2.1 YARN 框架的構(gòu)成

Hadoop2.x 中的最大變化就是出現(xiàn)了YARN 框架,它主要負責(zé)管理集群資源與作業(yè)調(diào)度.在Hadoop1.x中,這個功能是集成在MapReduce 框架中,由JobTracker組件實現(xiàn).YARN 框架的基本思想是接替JobTracker的兩個主要功能,即資源管理和任務(wù)調(diào)度/監(jiān)控,所以YARN 擁有面向全局的ResourceManager和面向每一個應(yīng)用程序的ApplicationMaster.通過將資源管理與編程模型分離,YARN 將集群資源認為是一個整體,沒有被靜態(tài)地劃分給每個Map和Reduce 作業(yè),顯著提高了集群資源利用率.

YARN 模塊包含3 個主要組件:

(1)ResourceManager(RM):RM 負責(zé)整個集群的資源管理和分配,是一個全局的資源管理系統(tǒng).

(2)NodeManager(NM):NM是每個節(jié)點上的資源和任務(wù)管理器,它是管理這臺機器的代理,負責(zé)該節(jié)點程序的運行,以及該節(jié)點資源的管理和監(jiān)控.YARN 中每個節(jié)點都運行一個NodeManager.

(3)ApplicationMaster(AM):用戶提交的每個應(yīng)用程序均包含一個AM,AM 負責(zé)與RM 協(xié)商以獲取資源(用Container 表示)[2].

2.2 Hadoop2.x 中的資源管理

了解資源請求過程是構(gòu)建Hadoop2.x 性能模型的關(guān)鍵.在Hadoop2.x 中,AM 可以以靜態(tài)模式或者動態(tài)模式提出它需要的資源請求.如果對資源的要求是在應(yīng)用程序提交時確定的,并且在AM 開始運行時該資源請求沒有變化,那么可以使用靜態(tài)方式請求資源.例如在MapReduce 作業(yè)中,通過輸入拆分產(chǎn)生的Map 任務(wù)數(shù)量與通過用戶定義參數(shù)產(chǎn)生的Reduce 數(shù)量總和是固定不變的.動態(tài)資源請求方式是指在應(yīng)用程序提交時無法確定,而需要AM 根據(jù)用戶指定、集群資源的可用性、業(yè)務(wù)邏輯等條件,在運行時選擇需要請求多少資源.無論使用哪種資源請求模式,RM 都不會立即分配Container 給AM.AM 發(fā)送分配的請求后RM最終將根據(jù)集群容量,優(yōu)先級和調(diào)度策略分配容器.當(dāng)且僅當(dāng)其原始估算值發(fā)生變化并且需要其他容器時,AM 才應(yīng)再次向RM 請求容器.

2.3 Hadoop2.x 中的作業(yè)調(diào)度

構(gòu)建性能模型需要了解在不同節(jié)點中為任務(wù)分配容器的方式.通過分析MapReduce的源代碼Package(org.apache.hadoop.mapreduce.v2.app.rm)和JavaClass(RMContainerAllocator),可以得到Map和Reduce 任務(wù)具有不同的生命周期.Map 任務(wù)的生命周期分為3 個過程:Scheduled、Assigned和Completed.Reduce 任務(wù)的生命周期分為4 個過程:Pending、Scheduled、Assigned和Completed.在Pending 過程中,資源請求尚未發(fā)送給RM.在Scheduled 過程,資源請求已經(jīng)發(fā)送給RM但是并未被分配.在Assigned 過程,資源請求被分配到一個容器中.在Completed 過程,被請求的容器已經(jīng)完成執(zhí)行.

此外,AM 可以進行第二級的調(diào)度,并將其獲得的容器分配給作業(yè)執(zhí)行計劃中的任何任務(wù).因此,YARN中的資源分配是后期綁定.AM 僅負責(zé)使用容器提供的資源,而不會一定將該資源分配給最初請求資源的邏輯任務(wù).當(dāng)AM 接收到一個容器時,它將使該容器與待處理任務(wù)集進行匹配,選擇一個輸入數(shù)據(jù)最接近該容器的任務(wù),首先嘗試執(zhí)行本地數(shù)據(jù)任務(wù),然后后退到本地機架[3,4].

3 算法設(shè)計

在本文中,作者以Hadoop1.x 中MapReduce 作業(yè)性能模型為基礎(chǔ)加以改進,使它能夠適應(yīng)Hadoop2.x的體系結(jié)構(gòu).需要改進方面主要有以下兩處:

(1)與Hadoop1.0 中為每個Map和Reduce 任務(wù)預(yù)先配置資源不同,考慮到Hadoop2.x 中資源的動態(tài)分配,需要構(gòu)建一個優(yōu)先級樹.

(2)在Map 任務(wù)和Reduce 任務(wù)的Shuffle 階段因為引入管線會發(fā)生同步延遲,需要在性能模型中及時捕獲到這種延遲.

3.1 輸入?yún)?shù)

為了簡單起見,作者設(shè)計了一組數(shù)量為numNodes的計算節(jié)點,所有計算節(jié)點都具有相同的技術(shù)特征.工作負載由系統(tǒng)中同時執(zhí)行的N個MapReduce 作業(yè)組成.每個作業(yè)都有mi個Map 任務(wù)和ri個Reduce 任務(wù).由于每次Shuffle 操作后都會執(zhí)行部分Sort 操作,所以將每對Shuffle 操作與Sort 操作進行分組,形成一個單獨的子任務(wù),這個子任務(wù)稱為Shuffle-Sort 任務(wù).在Reduce 任務(wù)的最后階段,在完成所有的部分Sort 操作后,將執(zhí)行最終Sort 操作,將最終Sort 操作和Reduce函數(shù)分組到一個子任務(wù)中,這個子任務(wù)稱為Merge 任務(wù).因此,Reduce 任務(wù)分為兩個子任務(wù):Shuffle-Sort 任務(wù)和Merge 任務(wù).表1列出了性能模型的輸入?yún)?shù).共有兩種類型的服務(wù)資源:CPU-內(nèi)存和網(wǎng)絡(luò).用常量C 表示任務(wù)類別的總數(shù),它的取值為3 (即Map 任務(wù)、Shuffle-Sort 任務(wù)和Merge 任務(wù)).

表1 輸入?yún)?shù)表

3.2 改進后的均值分析(MVA)算法

作者使用了改進的均值分析算法來解決排隊網(wǎng)絡(luò)模型問題.假設(shè)一個系統(tǒng)有C種任務(wù)類型和K個服務(wù)資源.有一個向量,其中第i個分量表示系統(tǒng)中第i類任務(wù)的數(shù)量.Sjk表示服務(wù)資源k中任務(wù)類型j的平均資源需求(j∈C,k∈K).

這個算法主要分為6 個步驟,如圖1所示①～⑥.

圖1 改進后的均值算法的主要步驟

在①階段,初始化每個服務(wù)資源中每類任務(wù)的平均停留時間和系統(tǒng)中每個任務(wù)的平均響應(yīng)時間.在②階段,基于每個獨立任務(wù)的平均響應(yīng)時間構(gòu)建優(yōu)先級樹.在③至⑤階段,相同作業(yè)任務(wù)和不同作業(yè)任務(wù)在執(zhí)行時間上的疊加會產(chǎn)生排隊延遲,考慮到排隊延遲因素帶來的影響,需要重新估算任務(wù)平均響應(yīng)時間.在⑥階段,在新估算出的任務(wù)平均響應(yīng)時間上進行融合測試.如果融合測試失敗了,使用③至⑤階段得到的任務(wù)響應(yīng)時間,回到②階段重新構(gòu)建優(yōu)先級樹,這個優(yōu)先級樹會比之前構(gòu)建的更加準確.如果當(dāng)前的估算值足夠接近先前的估算值,算法將結(jié)束,由此產(chǎn)生最終的作業(yè)平均響應(yīng)時間.

(1)初始化任務(wù)響應(yīng)時間

初始化過程包含可以并發(fā)執(zhí)行的兩個子過程:初始化每個服務(wù)資源中每類任務(wù)的平均停留時間和初始化系統(tǒng)中每個任務(wù)的平均響應(yīng)時間.要初始化任務(wù)駐留時間,可以從相應(yīng)的實際Hadoop 作業(yè)執(zhí)行歷史中獲取了駐留時間的平均值.要初始化任務(wù)響應(yīng)時間,可以假設(shè)優(yōu)先執(zhí)行所有的Map 任務(wù),然后執(zhí)行Reduce 任務(wù),于是將所有可用資源先提供給Map 任務(wù),再提供給Reduce 任務(wù).這種方法可以通過較少的算法迭代產(chǎn)生更多準確的響應(yīng)時間初始化.

(2)構(gòu)建優(yōu)先級樹

在優(yōu)先級樹中,每個葉子代表一個任務(wù),每個內(nèi)部節(jié)點都是一個運算符,描述了任務(wù)執(zhí)行過程中的約束.使用串行(S)和并行(P)兩種基本操作符號構(gòu)建的優(yōu)先級二叉樹.串行(S)運算符用于連接順序執(zhí)行的任務(wù),并行(P)運算符用于連接并發(fā)執(zhí)行的任務(wù).優(yōu)先級樹的示例如圖2所示.

圖2 優(yōu)先級樹示例

構(gòu)建優(yōu)先級樹的主要目標是捕獲作業(yè)的執(zhí)行流程,確定各個任務(wù)的執(zhí)行順序是串行還是并行,以及各個任務(wù)之間的依賴性.在算法的每次迭代時會重新構(gòu)建優(yōu)先級樹,用于重新估計任務(wù)響應(yīng)時間[5].

優(yōu)先級樹取決于各個任務(wù)的響應(yīng)時間,使用任務(wù)響應(yīng)時間線構(gòu)建.基于獲得的時間線,可以構(gòu)造唯一的優(yōu)先級樹.將所有同時執(zhí)行的任務(wù)中耗時最長的稱為一個階段,為了能夠區(qū)分任務(wù)是順序執(zhí)行還是并發(fā)執(zhí)行,必須確定時間線中新階段的開始點.將時間線劃分為多個階段.同一階段內(nèi)的所有任務(wù)并發(fā)執(zhí)行,而屬于不同階段的任務(wù)則順序執(zhí)行.這意味著每個任務(wù)的開始或結(jié)束都會有一個新階段開始.時間線構(gòu)造算法如算法1 所示.

算法1.時間線構(gòu)造算法輸入:Map 任務(wù)集合M,Reduce 任務(wù)集合R,集群節(jié)點集合N,Map任務(wù)所需的容器數(shù)m,Reduce 任務(wù)所需的容器數(shù)r輸出:時間線TL{st:開始時間;et:結(jié)束時間;d:持續(xù)時間;sd:Shuffle 階段持續(xù)時間;an:被委派節(jié)點;}1.當(dāng)i 從1 到N 時,循環(huán)執(zhí)行2.時間線集合TL[i]為空集?;3.循環(huán)結(jié)束4.當(dāng)m 屬于M 時,循環(huán)執(zhí)行5:i為TL 中的最小值;m 中被委派節(jié)點m.an 等于i;m的開始時間m.st 等于TL[i]中最小值;m的結(jié)束時間m.et 等于m的開始時間m.st 加上m的持續(xù)時間m.d;TL[i]等于TL[i]與{m}的并集;6.循環(huán)結(jié)束7.如果設(shè)置為slow_start,那么8.邊界值border 等于TL[TLmin]的結(jié)束時間;9.否則10.邊界值border 等于TL[TLmax]的結(jié)束時間;11.條件判斷結(jié)束12.當(dāng)r 屬于R的時候,循環(huán)執(zhí)行13.i為TL 中的最小值;r 中被委派節(jié)點r.an 等于 i;r的開始時間r.st 等于TL[i]的結(jié)束時間與邊界值border 中的較大值;14.當(dāng)m 屬于M 時,循環(huán)執(zhí)行15.如果m.an 不等于i,那么16.r.d 等于r.d 加上m.sd 除以|R|;17.條件判斷結(jié)束18.循環(huán)結(jié)束

19.r的結(jié)束時間r.et 等于r的開始時間r.st 加上r的持續(xù)時間r.d;20.TL[i]等于TL[i]與{r}的并集;21.循環(huán)結(jié)束22.返回值TL;?

由于Map 任務(wù)比Reduce 任務(wù)具有更高的優(yōu)先級,算法從1～6 行開始為Map 任務(wù)分配容器.如果設(shè)置為slow_start 時,則Reduce 任務(wù)Shuffle 階段的開始將與占用率最低的節(jié)點上的第一個Map 任務(wù)的結(jié)束重合.因此,Shuffle 階段盡將會可能早地開始.如果沒有設(shè)置為slow_start 時,Reduce 任務(wù)的Shuffle 階段將會盡可能晚地開始,如同算法的第7～11 行.算法在第12～21行為Reduce 任務(wù)分發(fā)了容器.

得到時間線后,可以基于時間線構(gòu)建一個二進制優(yōu)先級樹,為了減少二進制優(yōu)先級樹的最大深度對其每一個P 子樹應(yīng)用平衡處理.時間線與優(yōu)先級樹分別如圖3和圖4所示.

圖3 時間線

圖4 優(yōu)先級樹

(3)計算作業(yè)內(nèi)與作業(yè)間重疊因子

對于具有多個任務(wù)類型的系統(tǒng),由于j類任務(wù)所導(dǎo)致i類任務(wù)的排隊延遲與它們的重疊成正比.主要有兩種類型的重疊因子:作業(yè)內(nèi)重疊因子 αij,?i,j表示來自同一工作的表示任務(wù)的ID;工作間重疊因子βkr,?k,r表示來自不同工作的任務(wù)ID.工作內(nèi)和工作間重疊因素的示例如圖5所示.

(4)計算平均作業(yè)響應(yīng)時間

使用基于Fork/Join 框架的算法來估算作業(yè)響應(yīng)時間,將并行階段的作業(yè)執(zhí)行看作Fork/Join 塊,估算Fork/Join的平均響應(yīng)時間為k個任務(wù)中平均響應(yīng)時間的最大值與第k次調(diào)和函數(shù)的乘積.公式如下:

其中,Hk=∑si=1/i,s為優(yōu)先級樹子節(jié)點的數(shù)量.

優(yōu)先級樹是一個二進制樹,所以Hk=3/2,?k,父節(jié)點的響應(yīng)時間等于最大子節(jié)點的響應(yīng)時間加上可能的延遲[6].

圖5 工作內(nèi)和工作間重疊因素

(5)融合測試

在融合測試階段,比較前一次迭代產(chǎn)生的總響應(yīng)時間總值與當(dāng)前計算產(chǎn)生的響應(yīng)時間總值,當(dāng)二者足夠接近時(例如Rcurr-Rprev＜10?7),算法執(zhí)行完畢.否則,算法將返回到優(yōu)先級樹構(gòu)建階段重新執(zhí)行.經(jīng)試驗測試,將差值標準定為10?7,可在精度級別和算法復(fù)雜性(迭代次數(shù))之間提供良好的折衷方案.當(dāng)這個差值值較低時,計算出的作業(yè)響應(yīng)時間幾乎不再改變,但是算法迭代次數(shù)會繼續(xù)增長[7].

4 實驗

4.1 試驗設(shè)置

實驗中使用基于Fork/Join 框架的模型與Hadoop1.x原生方法的測量結(jié)果進行比較.設(shè)計一組實驗參數(shù),在Map-Reduce 任務(wù)中輸入大量作業(yè)(例如word-count 程序),輸入數(shù)據(jù)經(jīng)過處理會生成大量中間數(shù)據(jù)用來分析作業(yè)響應(yīng)時間.分析每個實驗中固定3 個參數(shù)中兩個參數(shù)的工作響應(yīng)時間,每個實驗重復(fù)5 次,然后取響應(yīng)時間的中位數(shù).

實驗參數(shù)如下:

(1)節(jié)點數(shù)量:4 個,6 個,8 個.

(2)輸入數(shù)據(jù)量:1 GB,5 GB.

(3)集群中同時執(zhí)行的任務(wù)數(shù)量:1～4 個.

(4)集群中每個節(jié)點的配置相同:XeonE5-2630@2.4 GHz/128 GB /1 TB /4 GiEthernet.

4.2 試驗結(jié)果

使用固定的輸入數(shù)據(jù),在集群中使用不同數(shù)量的節(jié)點(4 個,6 個,8 個),并發(fā)地執(zhí)行不同數(shù)量的作業(yè)(1 個,4 個).圖中使用實線表示Hadoop1.x 原生值,使用虛線表示基于Fork/Join 框架的計算值.輸入數(shù)據(jù)量為1 GB和5 GB的實驗結(jié)果分別如圖6–圖9所示.使用固定輸入數(shù)據(jù)在集群中同時執(zhí)行不同的作業(yè)數(shù)量(從1 個到4 個)的響應(yīng)時間如圖10所示.

圖6 作業(yè)數(shù)量1,輸入數(shù)據(jù)量1 GB

圖7 作業(yè)數(shù)量4,輸入數(shù)據(jù)量1 GB

圖8 作業(yè)數(shù)量1,輸入數(shù)據(jù)量5 GB

通過實驗發(fā)現(xiàn),基于Fork/Join 框架的算法的誤差在11%到13.5%之間,當(dāng)輸入數(shù)據(jù)量為5 GB的時候,誤差值達到最大13.5%.假設(shè)算法的準確性取決于Map 任務(wù)的數(shù)量而不是輸入數(shù)據(jù)量.Map 任務(wù)越多優(yōu)先級樹越復(fù)雜(深度越大),所以出現(xiàn)誤差的值就越大.為了證明這個假設(shè),在實驗中增加Map 任務(wù)的數(shù)量而不增加輸入數(shù)據(jù)量,將Map 任務(wù)的數(shù)據(jù)塊從128 MB減小為64 MB.實驗結(jié)果如圖11所示,當(dāng)輸入數(shù)據(jù)量為5 GB,作業(yè)數(shù)量為1 個的時候,誤差值為17%,是實驗中得到的最大值.當(dāng)優(yōu)先級樹的最大深度減小時,誤差也會降低.

圖9 作業(yè)數(shù)量4,輸入數(shù)據(jù)量5 GB

圖10 節(jié)點數(shù)量4,輸入數(shù)據(jù)量5 GB

圖11 數(shù)據(jù)塊64 MB,作業(yè)數(shù)量1,輸入數(shù)據(jù)量5 GB

基于Fork/Join 框架的算法比Hadoop1.x 原生方法提供了更加準確的結(jié)果,可以進一步調(diào)整開銷模型,通過計算作業(yè)疊加因素的變化來提高準確性.

5 結(jié)論

本文解決了為Hadoop2.x 創(chuàng)建MapReduce 性能評估模型的問題.該模型考慮了由于共享資源爭用而導(dǎo)致的排隊延遲,以及在同一作業(yè)中進行協(xié)作的各任務(wù)之間由于優(yōu)先級約束而導(dǎo)致的同步延遲(Map 階段和Reduce 階段).該模型的構(gòu)建方法通過在Hadoop1.x 性能評估模型的基礎(chǔ)上擴展得到,用優(yōu)先級二進制樹表示作業(yè)的執(zhí)行流程,用封閉式排隊網(wǎng)絡(luò)捕獲物理資源上的爭用.通過對Hadoop2.x的資源管理與任務(wù)調(diào)度方法進行分析,考慮到Hadoop2.x架構(gòu)中資源分配改為動態(tài)方式,作者創(chuàng)建了時間線構(gòu)造算法,并在此方法的基礎(chǔ)上構(gòu)建出優(yōu)先級樹.

在實驗中從同時執(zhí)行的不同數(shù)量作業(yè)的真實Hadoop設(shè)置值中獲得測量值,使用實驗測量值對該模型進行驗證:使用標準數(shù)據(jù)塊(128 MB)計算出作業(yè)響應(yīng)時間的平均誤差在11%和13.5%之間.該模型可用于理論上估計作業(yè)響應(yīng)時間,所用成本要比實際中設(shè)置實驗數(shù)據(jù)低得多.該模型對于作業(yè)負載管理和資源分配規(guī)劃中的決策也能夠起到輔助作用.