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