魏曉輝, 付慶午, 李洪亮

(吉林大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院, 長(zhǎng)春 130012)

計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)的高速發(fā)展和應(yīng)用, 帶來了數(shù)據(jù)規(guī)模的爆炸式增長(zhǎng), 使大規(guī)模數(shù)據(jù)的處理和存儲(chǔ)成為目前高性能計(jì)算領(lǐng)域的研究熱點(diǎn). 傳統(tǒng)的高性能計(jì)算系統(tǒng)多用于處理計(jì)算密集型作業(yè), 并不適合解決數(shù)據(jù)密集型應(yīng)用問題. Google提出的Mapreduce[1]計(jì)算模型和GFS[2]分布式存儲(chǔ)系統(tǒng), 為海量數(shù)據(jù)處理和存儲(chǔ)需求提供了全新的方法. 近年來, Hadoop作為Mapreduce和GFS模型的開源實(shí)現(xiàn), 得到了廣泛的應(yīng)用和認(rèn)可. Hadoop平臺(tái)是新一代的高性能計(jì)算和存儲(chǔ)平臺(tái), 其系統(tǒng)結(jié)構(gòu)有別于傳統(tǒng)的高性能計(jì)算系統(tǒng)[3-8]. Hadoop的系統(tǒng)結(jié)構(gòu)具有將數(shù)據(jù)資源(HDFS)和計(jì)算資源(Mapreduce)整合的特點(diǎn). 該特點(diǎn)使Hadoop集群資源調(diào)度過程遵循一個(gè)基本思想： 移動(dòng)計(jì)算不移動(dòng)數(shù)據(jù)----將計(jì)算任務(wù)派到包含要處理的數(shù)據(jù)計(jì)算節(jié)點(diǎn), 即任務(wù)本地化計(jì)算(task locality). 任務(wù)調(diào)度作為Hadoop系統(tǒng)的重要組成部分, 直接影響作業(yè)的執(zhí)行效率和機(jī)群資源利用率. 目前的Hadoop調(diào)度方法優(yōu)化多基于提高Locality比例優(yōu)化作業(yè)的執(zhí)行效率, 從而提高系統(tǒng)作業(yè)吞吐量.

本文基于對(duì)機(jī)群整體計(jì)算資源合理分配的調(diào)度思想, 針對(duì)Hadoop集群數(shù)據(jù)資源和計(jì)算資源整合的特點(diǎn), 提出一種資源可用性預(yù)測(cè)方法----基于資源預(yù)測(cè)的Delay調(diào)度算法(resource forecast delay scheduling, RFD). 基于該方法, RFD控制任務(wù)進(jìn)行合理的等待, 提高了系統(tǒng)的整體作業(yè)執(zhí)行效率和系統(tǒng)作業(yè)吞吐量. 實(shí)驗(yàn)結(jié)果表明, 在Hadoop一般應(yīng)用場(chǎng)景下, 本文提出的方法在保證任務(wù)Locality比例相近的前提下, 相比Fairshare算法[9], 平均作業(yè)執(zhí)行效率提高了28.8%.

1 基于資源預(yù)測(cè)的Delay調(diào)度算法

1.1 算法思想及框架

Hadoop系統(tǒng)中作業(yè)的本地化計(jì)算比例(Locality)是影響作業(yè)執(zhí)行效率和系統(tǒng)資源利用率的關(guān)鍵因素. 因此, 如何合理控制任務(wù)進(jìn)行等待, 在保證系統(tǒng)Locality的同時(shí), 合理分配資源是Hadoop調(diào)度程序要解決的關(guān)鍵問題. 本文提出一種基于資源預(yù)測(cè)的Delay調(diào)度算法(RFD). RFD算法以計(jì)算資源可用性為依據(jù)控制任務(wù)進(jìn)行合理地等待, 提高作業(yè)的運(yùn)行效率和系統(tǒng)的整體資源利用率.

數(shù)據(jù)的非本地化計(jì)算和作業(yè)等待過長(zhǎng)都會(huì)導(dǎo)致機(jī)群整體計(jì)算資源浪費(fèi), FIFO和Fairshare算法都沒能很好地解決這個(gè)問題. Delay算法雖然能提高本地化運(yùn)算比例, 但難以適應(yīng)資源可用性動(dòng)態(tài)變化. 因此, RFD調(diào)度器基于Delay思想, 針對(duì)資源實(shí)時(shí)可用性的預(yù)測(cè)進(jìn)行合理地等待, 在數(shù)據(jù)非本地化計(jì)算和作業(yè)等待時(shí)間之間取得更好的平衡, 以提高機(jī)群整體利用效率.

RFD算法包含一個(gè)資源可用性預(yù)測(cè)模塊, 對(duì)各作業(yè)所需的資源可用性進(jìn)行預(yù)測(cè). 每個(gè)作業(yè)的資源需求不同和依賴的數(shù)據(jù)文件不同導(dǎo)致同一個(gè)資源對(duì)不同的作業(yè)可用性不同. 因此, RFD中使用作業(yè)的“可用資源期望”表達(dá)集群資源對(duì)作業(yè)的可用性. 圖1為RFD調(diào)度示意圖, job1的可用資源期望為2, 表示在未來一個(gè)調(diào)度周期中, 將到來的含有job1所需數(shù)據(jù)的節(jié)點(diǎn)請(qǐng)求數(shù)量為2. 在RFD算法進(jìn)行資源分配前, 先根據(jù)歷史數(shù)據(jù)估計(jì)出作業(yè)隊(duì)列中各作業(yè)的資源期望值, 即可根據(jù)可用資源期望進(jìn)行作業(yè)調(diào)度. 由圖1可見, job1的可用資源期望為2, job2的可用資源期望為3. 因此, 這兩個(gè)作業(yè)均可在本輪調(diào)度周期進(jìn)行等待. 如果此時(shí)Tasktracker2有任務(wù)請(qǐng)求且該節(jié)點(diǎn)無job1要處理的數(shù)據(jù)塊, 則可以讓job1等待, 調(diào)度job2在該節(jié)點(diǎn)的本地化運(yùn)算Map任務(wù). 若job2也無本地化運(yùn)行Map任務(wù), 則繼續(xù)等待, 匹配下一個(gè)作業(yè)(如圖1中Tasktracker3的任務(wù)調(diào)度). 因此, RFD算法中任務(wù)等待是依據(jù)作業(yè)的資源可用性進(jìn)行的, 這樣的等待不會(huì)影響作業(yè)的運(yùn)行.

圖1 RFD調(diào)度示意圖Fig.1 Scheme of RFD scheduler

另一方面, 為了在通用環(huán)境下能夠高效運(yùn)行, RFD調(diào)度器引入了FIFO簡(jiǎn)單而高效的設(shè)計(jì)思路, 強(qiáng)調(diào)作業(yè)的先后優(yōu)先級(jí)別. 在為計(jì)算資源匹配本地化計(jì)算任務(wù)時(shí), 按作業(yè)提交順序進(jìn)行匹配, 如圖2所示. 在Delay時(shí)機(jī)選擇方面, 本文遵循使總體效益損失最小的原則進(jìn)行調(diào)度. 圖2為RFD調(diào)度器基本流程, 對(duì)于Tasktracker的任務(wù)請(qǐng)求, 為提高整體作業(yè)Locality計(jì)算比例, 先匹配該Tasktracker數(shù)據(jù)本地化計(jì)算的Map任務(wù)； 若匹配不成功, 為了整體作業(yè)合理等待, 則根據(jù)作業(yè)等待判斷模塊計(jì)算的可用資源期望決定是否等待.

圖2 本文調(diào)度算法基本框架Fig.2 Scheduling algorithm basic framework

1.2 RFD調(diào)度算法

針對(duì)RFD調(diào)度算法的需要, 本文對(duì)Hadoop系統(tǒng)進(jìn)行如下定義：j為jobj;N為機(jī)群中的總機(jī)器數(shù);Mj為作業(yè)j未運(yùn)行的Map task;Kj為Mj未處理數(shù)據(jù)分布的機(jī)器數(shù);TT為數(shù)據(jù)塊在兩個(gè)計(jì)算節(jié)點(diǎn)間傳輸所需的時(shí)間;Pj為下一個(gè)“心跳”的源機(jī)器上有jobj未處理數(shù)據(jù)塊的概率:

Pj=Kj/N;

(1)

H為Jobtracker每秒鐘接收的“心跳”數(shù)：

H=N/3;

(2)

S為每個(gè)Tasktracker上可運(yùn)行的Map任務(wù)數(shù);t為作業(yè)平均完成時(shí)間;Ph為某個(gè)“心跳”有作業(yè)請(qǐng)求的概率：

Ph=3×S/t;

(3)

Ej為在未來TT時(shí)間內(nèi), Jobtracker接收的“心跳”中, 有作業(yè)請(qǐng)求, 且該“心跳”的源機(jī)器上有jobj未處理的數(shù)據(jù)塊的期望：

Ej=H×TT×Pj×Ph;Ej=(TT×N/3)×(kj/N)×(3×S/t)=TT×S×Kj/t.

(4)

期望Ej評(píng)判是否值得對(duì)作業(yè)j等待. 該期望值體現(xiàn)了一個(gè)數(shù)據(jù)塊傳輸?shù)臅r(shí)間內(nèi)能收到本地化作業(yè)請(qǐng)求的期望, 如果Ej≥1, 表明對(duì)于該作業(yè), 等待是值得的.

在作業(yè)進(jìn)行等待的同時(shí), RFD算法需要考慮資源競(jìng)爭(zhēng)問題. 對(duì)于當(dāng)前調(diào)度的作業(yè), 如果在未處理的數(shù)據(jù)塊機(jī)器上同樣含有在它之前作業(yè)未處理的數(shù)據(jù)塊, 則計(jì)算Ej時(shí), 應(yīng)考慮資源競(jìng)爭(zhēng)的問題. 否則, 當(dāng)計(jì)算該作業(yè)的Ej≥1時(shí), 會(huì)出現(xiàn)與前面作業(yè)沖突, 前面的作業(yè)會(huì)占用與該作業(yè)有共同數(shù)據(jù)塊的機(jī)器作業(yè)請(qǐng)求, 導(dǎo)致Ej值虛高, 容易使該作業(yè)出現(xiàn)饑餓. 因此, 本文引入如下兩個(gè)變量：Rj為作業(yè)j與它前面作業(yè)的未處理數(shù)據(jù)塊在同一臺(tái)機(jī)器上的機(jī)器數(shù); Prj為作業(yè)j與它前面作業(yè)會(huì)發(fā)生資源競(jìng)爭(zhēng)的概率:

Prj=Rj/Kj;Ej=TT×S×Kj/t×Prj=TT×S×Rj/t.

(5)

RFD調(diào)度算法流程如下.

Begin

將作業(yè)調(diào)度隊(duì)列JobQueue按提交順序排列

assignedTasks=0； //標(biāo)記已經(jīng)派給Tasktracker的Map任務(wù)數(shù)

while(true)

If (assignedTasks==Tasktracker.請(qǐng)求作業(yè)數(shù)) then //滿足Tasktracker作業(yè)請(qǐng)求

break;

endif

For jobiin jobQueue do

If jobi有數(shù)據(jù)塊在發(fā)送“心跳”的機(jī)器上 then //Data-Local, 直接派作業(yè)

將jobi的數(shù)據(jù)本地化Map派到該機(jī)器上；

assignedTasks + +；

break；

endif

endfor

If (前面沒有找到合適的Map任務(wù)) then //下面引入等待機(jī)制

For jobiin jobQueue do

根據(jù)式(7)計(jì)算作業(yè) jobi的期望值Ei；

If (Ei<1) then //如果Ei<1, 不值得等待, 分非本地化計(jì)算的Map任務(wù)

將jobi的數(shù)據(jù)非本地化Map派到該機(jī)器上；

assignedTasks + +；

break；

Else then

continue; //等待, 調(diào)度隊(duì)列中下一個(gè)作業(yè)

endif

endfor

If (前面沒有找到分配Map任務(wù)) then //前面沒有找到合適Map的任務(wù)

分配隊(duì)首作業(yè)非本地化Map任務(wù)；

assignedTasks + +；

endif

endwhile

End.

RFD調(diào)度算法吸收了FIFO和Delay-Scheduling算法的簡(jiǎn)單高效特點(diǎn), 避免了兩種算法的各自缺點(diǎn), 提高了作業(yè)本地化計(jì)算Map任務(wù)的比例, 同時(shí)不會(huì)產(chǎn)生過度的等待, 有效地提高了機(jī)群整體的資源利用率. 通過分析可知, 第一個(gè)循環(huán)以FIFO的順序?qū)㈥?duì)列中作業(yè)于請(qǐng)求作業(yè)的Tasktracker進(jìn)行數(shù)據(jù)本地化匹配. 循環(huán)結(jié)束, 若未匹配, 則該Tasktracker在當(dāng)前的情況下不能分配到數(shù)據(jù)本地化計(jì)算的Map任務(wù). 進(jìn)入算法的Delay機(jī)制, 考慮作業(yè)是否應(yīng)該等待； 基于對(duì)作業(yè)的可用計(jì)算資源預(yù)測(cè), 對(duì)作業(yè)是否值得等待進(jìn)行合理的評(píng)估. 上述兩次循環(huán)匹配都是基于整體計(jì)算資源的合理利用考慮. 如果還沒有分配到Map任務(wù), 則將作業(yè)隊(duì)列隊(duì)首的Map任務(wù)分配給Tasktracker, 這種情況較少.

2 實(shí)驗(yàn)結(jié)果和數(shù)據(jù)分析

2.1 實(shí)驗(yàn)環(huán)境及結(jié)果

實(shí)驗(yàn)機(jī)群由10臺(tái)Dell optiple x380 PC服務(wù)器構(gòu)成(英特爾酷睿4核處理器, 2 Gb內(nèi)存, 200 Gb硬盤), 采用100 M以太網(wǎng)絡(luò)相連, 實(shí)驗(yàn)軟件采用Hadoop-0.21.0版本, 實(shí)驗(yàn)所用數(shù)據(jù)為某網(wǎng)站訪問日志文件, 經(jīng)過處理分成128 Mb～4 Gb不等10份樣本, 實(shí)驗(yàn)用例是基于基本數(shù)據(jù)采樣處理的Mapreduce 作業(yè), 用于統(tǒng)計(jì)訪問該網(wǎng)站的客戶端IP登陸次數(shù).

本文對(duì)FIFO算法、 Fairshare算法和本文提出的RFD調(diào)度算法進(jìn)行對(duì)比實(shí)驗(yàn). 為了反映真實(shí)的對(duì)比結(jié)果, 所用的實(shí)驗(yàn)環(huán)境、 數(shù)據(jù)分布及作業(yè)完全一致. Fairshare調(diào)度器采用默認(rèn)Delay時(shí)間設(shè)置. 針對(duì)10份不同的數(shù)據(jù)樣本, 每組測(cè)試6個(gè)作業(yè). 在實(shí)驗(yàn)過程中, 重點(diǎn)關(guān)注各實(shí)驗(yàn)用例中作業(yè)的本地化計(jì)算任務(wù)數(shù)(比例)和作業(yè)的平均完成時(shí)間, 實(shí)驗(yàn)結(jié)果列于表1和表2.

由RFD算法分析可知, 調(diào)度器是否對(duì)作業(yè)進(jìn)行等待取決于對(duì)資源的預(yù)測(cè)期望值Ej； 若Ej≥1, 則作業(yè)等待; 否則, 將該作業(yè)非本地化計(jì)算的Map任務(wù)派出去. 可見, 系統(tǒng)計(jì)算期望值Ej的準(zhǔn)確性將對(duì)作業(yè)是否等待產(chǎn)生決定性影響, 若該期望值不符合機(jī)群的實(shí)際運(yùn)行情況, 將導(dǎo)致機(jī)群計(jì)算資源的浪費(fèi), 降低作業(yè)執(zhí)行效率.

由于該期望值是對(duì)未來一段時(shí)間內(nèi)(TT)Jobtracker能夠收到的包含某個(gè)作業(yè)未執(zhí)行的Map任務(wù)要處理的數(shù)據(jù)塊的Tasktracker任務(wù)請(qǐng)求次數(shù). 因此, 要將在某個(gè)時(shí)刻計(jì)算的所有作業(yè)的期望值都記錄下來, 對(duì)于某個(gè)作業(yè), 記錄在未來時(shí)間TT內(nèi), Jobtracker收到任務(wù)請(qǐng)求的Tasktracker中, 包含有該作業(yè)未處理的數(shù)據(jù)塊的任務(wù)請(qǐng)求次數(shù). 過了TT時(shí)刻開始輸出記錄每個(gè)作業(yè)真正收到的本地化計(jì)算Map任務(wù)請(qǐng)求； 實(shí)驗(yàn)測(cè)試中, 在調(diào)度器中啟動(dòng)一個(gè)統(tǒng)計(jì)線程, 該線程負(fù)責(zé)記錄每個(gè)收到的命中每個(gè)作業(yè)的本地化計(jì)算Map任務(wù)請(qǐng)求數(shù), 定時(shí)輸出, 實(shí)驗(yàn)結(jié)果列于表3.

表1 作業(yè)平均完成時(shí)間(s)

表2 數(shù)據(jù)本地化計(jì)算Map任務(wù)比例(%)

表3 資源預(yù)測(cè)準(zhǔn)確性測(cè)試

由表3可見, 系統(tǒng)計(jì)算的資源預(yù)測(cè)期望值Ej與真實(shí)運(yùn)行情況基本相同, 若將預(yù)測(cè)結(jié)果按四舍五入對(duì)應(yīng)真實(shí)值, 預(yù)測(cè)準(zhǔn)確度達(dá)90%以上, 表明本文基于資源預(yù)測(cè)的算法可行、 有效.

2.2 實(shí)驗(yàn)結(jié)果分析

實(shí)驗(yàn)結(jié)果可分為以下3種情況： 1) Map數(shù)為2, RFD調(diào)度器的本地化計(jì)算低于FIFO和Fairshare調(diào)度器, 作業(yè)運(yùn)行時(shí)間高于后兩種調(diào)度器; 2) Map任務(wù)數(shù)為4和8, RFD調(diào)度器的數(shù)據(jù)本地化計(jì)算Map任務(wù)比例和執(zhí)行時(shí)間都優(yōu)于FIFO, 但不如Fairshare調(diào)度器; 3) Map任務(wù)數(shù)為16～64時(shí), RFD調(diào)度器的本地化計(jì)算Map任務(wù)比例和作業(yè)運(yùn)算時(shí)間優(yōu)于FIFO, 本地化計(jì)算比例與Fairshare調(diào)度器相當(dāng), 但作業(yè)執(zhí)行時(shí)間優(yōu)于Fairshare調(diào)度器, 如圖3和圖4所示. 情況1)和2)屬于運(yùn)行小作業(yè)的情況, Hadoop機(jī)群一般運(yùn)行的作業(yè)都較大, 所以前兩種情況不常見； 情況3)運(yùn)行的是中型和大型作業(yè), 是Hadoop機(jī)群實(shí)際應(yīng)用中經(jīng)常出現(xiàn)的情況, 更具代表性.

圖3 作業(yè)運(yùn)行時(shí)間Fig.3 Jobs’ running time

圖4 Map任務(wù)本地化計(jì)算(Locality)比例Fig.4 Percentages of locality computing Map tasks

當(dāng)Hadoop運(yùn)行作業(yè), 分配非本地化計(jì)算的Map任務(wù)時(shí), 傳輸數(shù)據(jù)塊和作業(yè)等待會(huì)導(dǎo)致作業(yè)運(yùn)行時(shí)間增加； Delay算法是通過作業(yè)等待增加本地化計(jì)算Map任務(wù)數(shù), 所以, 如何合理地等待是在這兩者取得平衡、 降低作業(yè)運(yùn)行時(shí)間的關(guān)鍵.

由上述分析可知, RFD算法是否等待與作業(yè)未處理的數(shù)據(jù)塊分布機(jī)器數(shù)有關(guān)； Map任務(wù)數(shù)太少不會(huì)觸動(dòng)等待機(jī)制. 分配一個(gè)非本地化計(jì)算Map任務(wù)給某個(gè)Tasktracker會(huì)影響其他作業(yè)的本地化計(jì)算任務(wù)分配到該Tasktracker(Tasktracker上分布著多個(gè)作業(yè)數(shù)據(jù)塊), 因此, Map任務(wù)較少時(shí), RFD調(diào)度器會(huì)導(dǎo)致整體作業(yè)本地化計(jì)算Map任務(wù)比例低； Fairshare的等待時(shí)間是固定的4.5 s, 初始調(diào)度時(shí), 調(diào)度器一定會(huì)收到一個(gè)Map本地化計(jì)算的作業(yè)請(qǐng)求(3 s就會(huì)收到Tasktracker一次“心跳”), 當(dāng)Map任務(wù)數(shù)太少時(shí), 本地化計(jì)算比例較高. FIFO調(diào)度器調(diào)度時(shí)只針對(duì)隊(duì)首作業(yè), 不會(huì)受多個(gè)作業(yè)的數(shù)據(jù)塊分布在同一個(gè)計(jì)算節(jié)點(diǎn)的情況影響. 由圖3和圖4可見, 情況1)和2)中RFD調(diào)度器與Fairshare調(diào)度器相比, 在本地化計(jì)算任務(wù)比例低, 作業(yè)運(yùn)行時(shí)間長(zhǎng)； 但這兩項(xiàng)指標(biāo)優(yōu)于FIFO調(diào)度器.

隨著Map任務(wù)數(shù)增多, RFD調(diào)度器的等待機(jī)制被觸動(dòng), 本地化計(jì)算Map任務(wù)數(shù)開始增加. FIFO調(diào)度作業(yè)時(shí)只對(duì)隊(duì)首作業(yè)調(diào)度, 本地化計(jì)算Map任務(wù)數(shù)比例增長(zhǎng)緩慢. 由圖4可見, Fairshare的等待時(shí)間固定, 所以本地化計(jì)算Map任務(wù)數(shù)比例變化不大.

情況3)中, RFD調(diào)度器的本地化Map任務(wù)數(shù)比例明顯上升(圖3), 作業(yè)運(yùn)行時(shí)間低于Fairshare調(diào)度器, 這是由于Fairshare調(diào)度器等待時(shí)機(jī)不合理所致. 若某Tasktracker沒有一個(gè)作業(yè)的本地化計(jì)算數(shù)據(jù)會(huì)導(dǎo)致整個(gè)作業(yè)隊(duì)列都在等待, 因此作業(yè)運(yùn)行時(shí)間較長(zhǎng)； RFD調(diào)度器在以動(dòng)態(tài)可用資源預(yù)測(cè)為等待基礎(chǔ)且以數(shù)據(jù)本地化調(diào)度優(yōu)先, 等待時(shí)間較合理. 所以, 該情況下RFD調(diào)度器不僅本地化計(jì)算Map任務(wù)數(shù)比例較高, 且等待時(shí)間較合理, 作業(yè)運(yùn)行時(shí)間也較少.

Hadoop的應(yīng)用場(chǎng)景是處理大數(shù)據(jù), 運(yùn)行作業(yè)的Map任務(wù)數(shù)較多, 情況3)的出現(xiàn)概率遠(yuǎn)大于情況1)和2). 實(shí)驗(yàn)表明, RFD調(diào)度器在一般情況下比Fairshare和FIFO調(diào)度器的作業(yè)運(yùn)行效率高, 且整體機(jī)群資源利用更合理. 根據(jù)Hadoop機(jī)群應(yīng)用場(chǎng)景和本文的實(shí)驗(yàn)結(jié)果可知, RFD在一般情況下, 本地化計(jì)算Map任務(wù)數(shù)比例與Fairshare調(diào)度器相近； 但作業(yè)平均運(yùn)行時(shí)間低于Fairshare調(diào)度器的28.8%.

對(duì)比實(shí)驗(yàn)表明, 本文提出的RFD算法與Fairshare算法相比, 一般情況下, 在保持系統(tǒng)高本地化作業(yè)執(zhí)行比例(Locality)相近的同時(shí), 優(yōu)化了作業(yè)的整體執(zhí)行效率(平均提高28%).

[1] Dean J, Ghemawat S. Mapreduce: Simplified Data Processing on Large Clusters [J]. ACM, 2008, 51: 107-113.

[2] Ghemawat S, Gobioff H, LEUNG Shun-tak. The Google File System [J]. ACM, 2003, 37: 29-43.

[3] Apache. The Oomepage of Hadop [EB/OL]. 2012-03-19. http://Hadoop.apache.org/.

[4] Shvachko K, KUANG Hai-rong, Radia S, et al. The Hadoop Distributed File System [J]. MSST, 2010, 1: 1-10.

[5] Amazon. The Homepage of s3 Distributed File System [EB/OL]. [2011-10-28]. http://aws.amazon.com/s3.

[6] Cloudstore. Cloudstore Distributed File System Website [EB/OL]. [2011-11-29]. http://kosmosfs.sourceforge.net/.

[7] GUO Dong, DU Yong, HU Liang. HDFS Based Cloud Data Backup System [J]. Journal of Jilin University: Science Edition, 2012, 50(1): 101-105. (郭東, 杜勇, 胡亮. 基于HDFS的云數(shù)據(jù)備份系統(tǒng) [J]. 吉林大學(xué)學(xué)報(bào): 理學(xué)版, 2012, 50(1): 101-105.)

[8] WEI Xiao-hui, Li Wilfred, XU Gao-chao, et al. Implementing Data Aware Scheduling on Gfarm by Using LSFTMScheduler Plugin [J]. Journal of Jilin University: Science Edition, 2005, 43(6): 763-767. (魏曉輝, Li Wilfred, 徐高潮, 等. 利用LSF調(diào)度程序的插件機(jī)制在Gfarm上實(shí)現(xiàn)Data aware調(diào)度 [J]. 吉林大學(xué)學(xué)報(bào): 理學(xué)版, 2005, 43(6): 763-767.)

[9] Zaharia M, Borthakur D, Sarma J S, et al. Job Scheduling for Multi-user Mapreduce Clusters [J]. EECS Department, 2009, 55: 1-16.