王鵬 劉鵬* 劉佳祎
(1.廣西師范大學(xué)網(wǎng)絡(luò)信息中心 廣西壯族自治區(qū)桂林市 541000)(2.桂林理工大學(xué)現(xiàn)代教育技術(shù)中心 廣西壯族自治區(qū)桂林市 541000)
隨著云計(jì)算、容器云、物聯(lián)網(wǎng)及人工智能等信息技術(shù)的迅速發(fā)展,以互聯(lián)網(wǎng)數(shù)據(jù)中心(IDC)發(fā)布得預(yù)測為依據(jù),預(yù)計(jì)全球產(chǎn)生的數(shù)據(jù)總量在2022年將達(dá)到54 個(gè)ZB,其中我國占18%,近8060個(gè)EB[1]。由于數(shù)據(jù)的獲取技術(shù)在不斷的更新突破,我們在獲取越來越多數(shù)據(jù)同時(shí),更加重視對數(shù)據(jù)的管理及治理 。若數(shù)據(jù)產(chǎn)生量在GB 級和TB 級之間,我們可以通過文件的共享方式如Docker 技術(shù)[2]等來進(jìn)行存儲。當(dāng)數(shù)據(jù)的產(chǎn)生量達(dá)到 PB 級別時(shí),可能會有非常多的不可控因素發(fā)生,存儲系統(tǒng)的需求也會非常高。云存儲[3-4]則滿足上述條件不但存儲性能高,而且還可以保障數(shù)據(jù)的安全性,由此利用云存儲系統(tǒng)對數(shù)據(jù)進(jìn)行存儲將成為必然的趨勢。
目前很多IT 公司踴躍加入到研發(fā)云存儲系統(tǒng)的項(xiàng)目中,用以解決自身在公司發(fā)展中產(chǎn)生海量數(shù)據(jù)的存儲問題。部分公司逐漸從銷售軟硬件轉(zhuǎn)向可以為各企業(yè)和租戶提供按需收費(fèi)的各類云存儲服務(wù)。目前相對成熟,已投入商用的云存儲平臺有如:國外的Google文件系統(tǒng)、Amazon 基礎(chǔ)存儲服務(wù),及國內(nèi)的淘寶訂單系統(tǒng),圖床的圖片存儲系統(tǒng)等,同時(shí)在國內(nèi),一些大公司也開始逐漸向外界推出自己的云存儲服務(wù),如華為、百度等[6]。與此同時(shí),以Hadoop的 HDFS[7]和 Open Stack 的 Swift[8]為首的開源云存儲平臺也隨之而來。
云存儲技術(shù)的核心就是文件的傳輸,其在傳輸過程中也是耗時(shí)占比相對最重的環(huán)節(jié),節(jié)省的傳輸時(shí)間可以同時(shí)降低物理機(jī)和服務(wù)器這兩方面的使用和功能的消耗。因此本文提出一個(gè)利用并行處理技術(shù)優(yōu)化傳輸過程的新算法用于增加傳輸效率,同時(shí)將傳統(tǒng)框架運(yùn)用到MapReduce 模型中改變其工作運(yùn)行架構(gòu),使Mapper 和Reducer 機(jī)制可以同時(shí)運(yùn)行減少時(shí)間提高工作效率。
圖1:并行處理模塊
圖2:MPI 技術(shù)并行化流程圖
建立在分布式環(huán)境上的MapReduce 模型在并行處理上有相當(dāng)大的優(yōu)勢,它不但斟酌怎樣調(diào)度工作機(jī)制實(shí)現(xiàn)系統(tǒng)的負(fù)載平衡同時(shí)還考慮到如何保障數(shù)據(jù)間的通信順暢等問題。在MapReduce 進(jìn)行代碼編寫時(shí)用戶完全不用考慮其如何實(shí)現(xiàn),只需了解可以分割數(shù)據(jù)集的Map 機(jī)制和結(jié)果匯聚集的Reduce 機(jī)制。故用戶所提交的務(wù)必是可以拆分成很多塊的并且能夠完成自身計(jì)算任務(wù)的數(shù)據(jù)文件。
MapReduce 的作業(yè)運(yùn)行流程步驟[9]:
(1)客戶端啟動(dòng)MapReduce 開始作業(yè);
(2)JobClient 向 JobTracker 請求一個(gè)作業(yè)號;
圖3:實(shí)驗(yàn)數(shù)據(jù)分布圖
圖4:傳輸時(shí)間對比圖
圖5:文件計(jì)算時(shí)間對比圖
(3)同步作業(yè)所需的各類依賴包及配置文件等,如MapReduce 中JAR 包、配到HDFS 上;
(4)工作調(diào)度:運(yùn)算遷移而數(shù)據(jù)不動(dòng);
由于在Map 端數(shù)據(jù)是本地化,此時(shí)任務(wù)將會被分發(fā)傳到不同的TaskTracker 上。當(dāng)JobTracker 端接收到相應(yīng)消息后,依據(jù)一定策略排列等待進(jìn)入作業(yè),并實(shí)時(shí)動(dòng)態(tài)的采用不同的計(jì)算策略進(jìn)行相應(yīng)的調(diào)度。
(5)TaskTracker 每隔一段時(shí)間向 JobTracker 發(fā)送一個(gè)信號。
針對云存儲過程中通常是接收全部的文件包后再打包、解包,這對大批量文件從本地傳輸?shù)椒?wù)器端這一過程來說,該傳輸過程是耗時(shí)最久的而且這種傳輸也存在效率低等問題。因此,本文提出一種并行處理優(yōu)化策略。該算法通過設(shè)定一個(gè)閾值,在打包文件的同時(shí)對其進(jìn)行相應(yīng)的解包操作,并利用MD5 值驗(yàn)證法[10]對文件的完整性進(jìn)行驗(yàn)證。由于傳輸來文件隨著時(shí)間遞增容量不斷的變大,因此,在解包的過程中耗時(shí)也會逐漸變長,但并行處理優(yōu)化算法在某種程度上表現(xiàn)出良好的傳輸效率。并行處理模塊示意圖如圖1所示。
3.2.1 MPI 技術(shù)并行優(yōu)化處理MapReduce 模型
本文將使用MPI 技術(shù)以Yarn 框架為基底通過對Mapper 和Reducer 進(jìn)行并行處理來解決Reduce 機(jī)制因?yàn)镸apper 尚未執(zhí)行完畢時(shí)長時(shí)間處于等待準(zhǔn)備狀態(tài)從而形成資源空閑的問題。MapReduce 詳細(xì)把執(zhí)行過程進(jìn)行分解步驟如下:
(1)將文件拆分為多個(gè)相對應(yīng)的
(2)采用map 法對其進(jìn)行剖析,得到全新的
(3)鍵值對
(4)在Reducer 中將(3)得到的鍵值對
本文結(jié)合MPI 技術(shù)將第2、4 步并行處理,充分將MapReduce的執(zhí)行效率得到提高。具體流程如圖2所示。
由圖2可知,系統(tǒng)在進(jìn)行數(shù)據(jù)計(jì)算時(shí),相應(yīng)的文件會作出splits 分割,為數(shù)據(jù)處理在傳遞過程中做預(yù)處理準(zhǔn)備,以便結(jié)果執(zhí)行、統(tǒng)計(jì)。
本文根據(jù)上述算法提出了可以提升云存儲效率的優(yōu)化方案。該方案將并行完整性算法與優(yōu)化后的MapReduce 模型相結(jié)合,不僅打破傳統(tǒng)傳輸方式的制約還提升了文件傳輸時(shí)的計(jì)算效率。為了檢測并行完整算法在優(yōu)化后的MapReduce 模型上在節(jié)約傳輸時(shí)間和存儲效率是否能夠提升,通過在開源數(shù)據(jù)集(data.gov)上獲取的6種不同的數(shù)據(jù)集,在Ubuntu 14.10 操作系統(tǒng)、hadoop-2.6.0 版本的電腦上以每批次N=10 的打包量將這些數(shù)據(jù)集傳輸?shù)紿DFS 系統(tǒng)進(jìn)行實(shí)驗(yàn)測試,實(shí)驗(yàn)數(shù)據(jù)分布圖如圖3所示。
本文通過6 組文件詳細(xì)對比傳統(tǒng)方法與優(yōu)化方式在傳輸時(shí)間上的變化情況,如圖4所示。通過對比圖可知,文件存儲量在1G 內(nèi)兩者在傳輸過程中所用的時(shí)間幾乎相同,在達(dá)到1.5G、2G 時(shí)傳輸時(shí)間變化尤為明顯。與此同時(shí),本文還與傳統(tǒng)構(gòu)架針對不同容量在文件計(jì)算時(shí)間進(jìn)行模擬比較如圖5。根據(jù)圖5可知,均在相同的文件容量內(nèi)優(yōu)化后的架構(gòu)用時(shí)更加短。
在分析當(dāng)前云存儲效率的基礎(chǔ)上,提出一種用于提高云存儲效率的MapReduce 并行處理優(yōu)化策略。本文將并行處理技術(shù)運(yùn)用到文件傳輸過程中,并且提出新的優(yōu)化算法加快文件存儲時(shí)間提升傳輸效率。與此同時(shí)本文還將MapReduce 模型進(jìn)行優(yōu)化,縮小由于系統(tǒng)順序制約、存儲制約所帶來的資源浪費(fèi),充分體現(xiàn)系統(tǒng)的高效性。實(shí)驗(yàn)?zāi)M結(jié)果表示并行完整性算法及優(yōu)化后的系統(tǒng)架構(gòu),用于解決文件傳輸時(shí)間提高傳輸和計(jì)算效率等問題。