基于云計算的虛擬實驗系統(tǒng)的設計及應用

歐躍發(fā)+黃文明

摘要：傳統(tǒng)HDFS缺乏存儲和訪問優(yōu)化，以致在多用戶并發(fā)系統(tǒng)中難以發(fā)揮集群優(yōu)勢。該文設計了一個基于HDFS的中間件，主要對數(shù)據(jù)塊、存儲負載均衡和數(shù)據(jù)訪問三方面進行了優(yōu)化，并提出了相應的改進算法。仿真實驗證明，改進后的HDFS系統(tǒng)，在多用戶并發(fā)和低延時訪問方面有了明顯提高，進而能夠在網(wǎng)盤系統(tǒng)、視頻系統(tǒng)、數(shù)字化校園等系統(tǒng)中得到更好的應用。

關鍵詞：Hadoop；HDFS；MapReduce；負載均衡；分布式計算

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2016）08-0243-04

Abstract： As the traditional HDFS lack the optimization of storage and access， it is difficult to play a cluster edge in multi-user concurrent systems. This paper is designed a middleware based on HDFS，which is mainly optimized on the data block， the load balancing of storage and data access and it presents the corresponding improved algorithm. Simulation results show that the improved HDFS systems has been significantly improved in multi-user concurrency and low latency access， thus it will get a good application in network disk system， video system， and other digital campus system in the future.

Key words： Hadoop； HDFS； MapReduce； load balancing； distributed computing

1 引言

1.1 HDFS框架

HDFS[1]是Hadoop[3]分布式文件系統(tǒng)的實現(xiàn)。它采用主從（Master/Slave）體系結構，名字節(jié)點Namenode、數(shù)據(jù)節(jié)點DataNode和客戶端Client是HDFS中的3個重要角色。名字節(jié)點是一個中心服務器，是分布式文件系統(tǒng)的管理者，負責管理文件系統(tǒng)的命名空間、集群配置和數(shù)據(jù)塊復制等。數(shù)據(jù)節(jié)點是文件存儲的基本單元，以數(shù)據(jù)塊的形式進行存儲?？蛻舳撕兔止?jié)點、數(shù)據(jù)節(jié)點進行通信，訪問HDFS，并對文件進行操作。基于HDFS的云存儲平臺，可以減少專用服務器的數(shù)量，降低應用成本，提高系統(tǒng)的性能、穩(wěn)定性和效率，所以它不僅在工業(yè)界得到推崇，在如傳媒、電信、金融、學校等傳統(tǒng)行業(yè)中也備受青睞。當前HDFS主要應用在數(shù)據(jù)的存儲和為MapReduce高性能計算提供底層支持兩個方面，在多用戶并發(fā)訪問系統(tǒng)中卻沒有發(fā)揮出集群優(yōu)勢。

文獻[1-4] 主要對Hadoop和HDFS進行了詳細介紹；文獻[5]詳細介紹了GFS的系統(tǒng)架構，工作負荷分析，并使用一些小規(guī)?；鶞蕼y試來展現(xiàn)了GFS在實現(xiàn)上的一些固有瓶頸；文獻[6]描述了Bigtable提供的簡單的數(shù)據(jù)模，Bigtable的設計和實現(xiàn)，并從引入局部性群組、壓縮、增加緩存提高讀操作等策略來提高Bigtable的性能；文獻[7]闡明了訪問大量小文件會嚴重影響HDFS的IO性能和HDFS的擴展性；文獻[8]結合Sequence File文件合并技術，構建了具有訪問特點的云存儲系統(tǒng)，但該系統(tǒng)缺乏對多用戶并發(fā)訪問優(yōu)化的考慮；文獻[9]詳細描述了一種建立在P2P上的分布式存儲系統(tǒng)的體系結構，并提出了預分組的理論和算法；文獻[10]從三個方面對文件下載策略進行了改進，優(yōu)化了負載均衡性能，忽略了HDFS系統(tǒng)內(nèi)部優(yōu)化對并發(fā)文件訪問的影響。

基于以上分析，本文在客戶端和HDFS系統(tǒng)之間架構了一層中間件OBDR（Optimization of Block choice DataNode and Read Datablock.），對HDFS做進一步的優(yōu)化，以提高HDFS在多用戶并發(fā)系統(tǒng)中的應用。

1.2 當前HDFS框架存在的不足

HDFS具有高容錯性、易擴展性等優(yōu)點，允許用戶將Hadoop部署在廉價的硬件上，構成分布式存儲系統(tǒng)，是云存儲的一種落地實現(xiàn)形式。對于一些諸如網(wǎng)盤系統(tǒng)、視頻系統(tǒng)、數(shù)字化校園系統(tǒng)以及一些中小型企事業(yè)單位的內(nèi)部系統(tǒng)，他們需要以相對廉價的方式搭建自己的云平臺，但并不需要高性能計算或者海量數(shù)據(jù)的處理，存儲和多用戶并發(fā)訪問是他們的主要需求。針對這方面的應用，當前的HDFS缺乏系統(tǒng)優(yōu)化，使得其難以發(fā)揮集群優(yōu)勢，進而在上述類似系統(tǒng)中，很難得到廣泛應用。該文主要從以下三方面討論當前HDFS存在的不足：

首先，HDFS缺乏對數(shù)據(jù)塊的優(yōu)化。DataNode節(jié)點存儲數(shù)據(jù)是以數(shù)據(jù)塊的形式進行存儲的，每個Block的大小默認為64MB（除最后一個Block外），而海量數(shù)據(jù)文件大小不一，如果數(shù)據(jù)塊大小設定不合理，將會給主節(jié)點帶來負擔，同時不停切換DataNode節(jié)點，必然消耗系統(tǒng)資源，導致集群效率降低。在存儲海量數(shù)據(jù)時，依據(jù)文件實際大小動態(tài)設定合理的數(shù)據(jù)塊大小至關重要。

其次，HDFS缺乏負載均衡策略。HDFS在選擇節(jié)點存取數(shù)據(jù)塊時，節(jié)點在滿足基本條件下，是隨機選擇的，這就有可能造成存儲容量大的節(jié)點沒有得到充分利用，存儲容量小的節(jié)點幾乎接近飽和，從而引起負載不均衡現(xiàn)象，使得存儲效率降低，用戶訪問數(shù)據(jù)塊節(jié)點時，由于存儲節(jié)點性能問題，影響訪問效率。

再次，缺乏訪問優(yōu)化策略。HDFS文件讀取策略中，每個客戶端讀取文件時，總是依次讀每個數(shù)據(jù)塊，最后組裝成整個文件返回客戶端，這種缺乏并發(fā)機制的數(shù)據(jù)讀取方式，必然使得Hadoop集群在客戶端獲取數(shù)據(jù)低延時方面或者交互式應用方面會遇到很大的瓶頸問題。

2 OBDR中間件架構

基于以上對HDFS框架中存在的不足，本文在HDFS和客戶端之間架構了一個中間件OBDR，以對傳統(tǒng)HDFS進行進一步優(yōu)化。改進后的HDFS架構如圖1所示，OBDR中間件主要三個組成模塊，數(shù)據(jù)塊優(yōu)化模塊（ODBR-Block）存儲的數(shù)據(jù)節(jié)點負載均衡模塊（ODBR-DataNode）和數(shù)據(jù)訪問的多線程優(yōu)化模塊（ODBR-ReadThread）。

2.1 OBDR結構與優(yōu)化策略

2.1.1 OBDR-Block

數(shù)據(jù)塊大小由變量blocksize來設定。決定blocksize大小的因素是文件大小，存儲文件大小由filesize來表示，如果文件比較大，而設置的bolocksize比較小，必然導致數(shù)據(jù)塊數(shù)量變大，增加NameNode節(jié)點內(nèi)存壓力，客戶端讀取文件時，訪問NameNode和切換DataNode節(jié)點次數(shù)增加，在同等網(wǎng)絡質(zhì)量的前提下，文件讀取效率降低。反之，如果設置的blocksize太大，集群DataNode節(jié)點得不得充分利用，效率也會降低。由于系統(tǒng)默認數(shù)據(jù)塊大小為64M，實際Blocksize大小最好應是64M的整數(shù)倍。OBDR-Block功能模塊通過優(yōu)化算法1，依據(jù)上傳文件的大小，去改寫HDFS配置文件dfs.block.size的屬性值，以實現(xiàn)數(shù)據(jù)塊的合理設置。

算法1 數(shù)據(jù)塊優(yōu)化算法

[filesize]代表上傳文件的實際大小，[Blocksize]代表優(yōu)化后的數(shù)據(jù)塊大小，一個合理數(shù)據(jù)塊大小設定公式，一般需要經(jīng)過大量的實驗測試數(shù)據(jù)驗證總結而確定。本文通過部分實驗數(shù)據(jù)驗證，總結出如下算法公式，實驗證明對HDFS性能改進有較大幫助。當[filesize≤128Mb?2]時，

2.1.2 OBDR-DataNode

HDFS在存儲數(shù)據(jù)塊時，選擇合理的DataNode節(jié)點對提高存取效率至關重要。比如某DataNode節(jié)點，存儲新的數(shù)據(jù)塊后，硬盤空間已經(jīng)基本飽和，而其他DataNode節(jié)點硬盤空間可能很空閑，這就會使得客戶端在讀取數(shù)據(jù)文件時候，由于某個或者某些DataNode節(jié)點的問題，而導致整個文件存儲和讀取速度降低，集群內(nèi)的資源得不到充分利用，所以數(shù)據(jù)塊存儲的負載均衡是提高客戶端數(shù)據(jù)讀取效率的一個重要因素。合理的存儲節(jié)點的選擇主要取決于該節(jié)點剩余資源的大小。

定義1. 設dfs.download.remaining為配置文件中設定的某DataNode剩余資源百分比，用[Noderemain]表示。

在類DatanodeInfo中，可以使用remaining屬性獲得各數(shù)據(jù)節(jié)點的剩余資源。

算法2 數(shù)據(jù)塊存儲優(yōu)化算法

算法4多線程數(shù)據(jù)塊并行下載算法

1）初始化：設[m]為Hadoop設置副本的數(shù)量，[bsize]為文件塊大小，[filesize]為文件大小。[m]的值可以從Hadoop配置文件中dfs.replication讀?。籟bsize]通過dfs.block.size獲??；文件大小[filesize]是通過客戶端調(diào)用DistributedFileSystem的open（）方法建立與NameNode的連接而獲得。

2）DistributedFileSystem對象通過RPC從NameNode返回一個LocationBlocks對象給DFSInputStream。

3）調(diào)用LocationBlocks.size得到文件的數(shù)據(jù)塊個數(shù)[n]，下載優(yōu)化器產(chǎn)生[n]個下載線程，并初始化[n]個數(shù)據(jù)塊下載狀態(tài)標示數(shù)組flag[[n]]={0，0…0}。

4）采用算法3選擇優(yōu)化下載點，得到availableNodes[]，從availableNodes[]中隨機選擇一個DataNode節(jié)點作為下載點，下載線程利用FSDataInputStream.read（）進行下載。

5）當4中第[i]（1=<[i]<=[n]）塊Block下載完畢，調(diào)用FSDataInputStream.close方法進行關閉與資源釋放，并設置下載狀態(tài)標示數(shù)據(jù)flag[[i]]=1。

6）循環(huán)檢查flag[[n]]數(shù)組，當數(shù)組全為1時，則表示所有數(shù)據(jù)塊下載完畢，將[n]個數(shù)據(jù)塊在優(yōu)化器力合并為完整文件，并返回給客戶端，否則，轉(zhuǎn)到4，繼續(xù)下載。

7）結束。

2.2基于OBDR的HDFS存取數(shù)據(jù)流程

1）基于OBDR的HDFS文件存儲流程

客戶端上傳文件時，OBDR中間件OBDR-Block模塊和OBDR-DataNode模塊被啟動，OBDR-Block模塊依據(jù)上傳文件的大小，按照算法1，計算出合理的數(shù)據(jù)塊大小，并改寫HDFS配置文件dfs.block.size的值，此時數(shù)據(jù)塊大小已確定。然后，HDFS將文件分成[n]個數(shù)據(jù)塊，存放到DataNode節(jié)點上，數(shù)據(jù)塊存放的數(shù)據(jù)節(jié)點，是由OBDR-DataNode模塊按照算法2選出的最優(yōu)節(jié)點序列。

2）基于OBDR的HDFS文件讀取或下載流程

客戶端在讀取或者下載文件時，OBDR中間件的OBDR-ReadThread模塊被啟動，HDFS的NameNode節(jié)點將該文件的所有數(shù)據(jù)塊存儲的DataNode節(jié)點的地址列表返回給OBDR中間件，中間件依據(jù)算法4，生成[n]個線程與相應的DataNode建立連接，進行數(shù)據(jù)塊下載。每個線程在與DataNode連接時，首先經(jīng)過OBDR-ReadThread模塊，通過算法3，隨機選擇出符合條件的節(jié)點來下載。最后將所有下載好的數(shù)據(jù)塊整合成所需文件，返回給客戶端。

3 實驗及分析

3.1實驗環(huán)境

本實驗運行在由5臺PC機組成的Hadoop集群上，其中一臺為NameNode節(jié)點，主機Slave1，Slave2，Slave3和Slave4為DataNode節(jié)點。五臺機器的系統(tǒng)配置如下：

NameNode： cpu i5-2400 3.1Ghz*4，內(nèi)存： 4G，硬盤： 500G，操作系統(tǒng)：ubuntu12.04；

DataNode： cpu i5-3470 3.1Ghz*4，內(nèi)存： 4G，硬盤： 500G，操作系統(tǒng)：ubuntu12.04；

實驗主要是通過對多客戶端并發(fā)訪問下載集群中數(shù)據(jù)文件的效率，來對比Hadoop框架優(yōu)化前后的性能，從而提高HDFS在多用戶并發(fā)訪問系統(tǒng)中的應用。

同時，為了能夠?qū)崟r畫出性能曲線分析圖，實驗中使用JFreeChart插件，并通過java xml編碼將實驗數(shù)據(jù)實時傳到HDFS，畫出實驗分析圖。實驗是在Eclipse集成開發(fā)環(huán)境下進行程序開發(fā)的。

3.2實驗結果與分析

實驗1：數(shù)據(jù)塊大小和存儲優(yōu)化對訪問HDFS文件的影響

實驗是由20個客戶端同時分別下載10M、20M、40M、80M、160M、1G、3G、6G和10G的9個不同大小的文件。第一種方式是使用原始集群框架，數(shù)據(jù)塊大小是系統(tǒng)默認的64M，各下載文件上傳至集群時未使用存儲優(yōu)化。第二種方式是使用優(yōu)化后的HDFS集群框架，在上傳10M、20M、40M、80M、160M、1G、3G、6G和10G文件至集群時，啟動OBDR-Block和OBDR-DataNode優(yōu)化模塊，采用算法1和算法2將數(shù)據(jù)存儲成功，然后通過公式1測試20客戶端下載9個不同大小的文件時的平均速度，測試結果如圖2所示：

隨著文件大小的增加，系統(tǒng)默認的數(shù)據(jù)塊大小使得大文件被分割成大量的數(shù)據(jù)塊，給主節(jié)點造成了較大負擔，同時讀取或者下載該文件時，由于不斷地切換集群DataNode節(jié)點，使得文件整體下載效率降低。而啟動了OBDR-Block和OBDR-DataNode優(yōu)化模塊以后，文件在上傳至集群時，數(shù)據(jù)塊存儲得到了優(yōu)化，數(shù)據(jù)塊大小也得到了合理設定，集群性能得到充分發(fā)揮，由圖2可知，優(yōu)化后的HDFS在大文件的訪問上效率有了明顯提高。

實驗2：文件的多線程并發(fā)訪問對HDFS性能的影響

由于小文件和低并發(fā)下載很難明顯體驗出多線程的優(yōu)勢，所以本實驗采用固定大文件，遞增并發(fā)訪問的方式來測試。實驗中，通過對比1到30個節(jié)點并發(fā)下載1G大小文件的平均速度，來驗證HDFS改進前后的效率問題。改進后的HDFS集群，客戶端在讀取和下載時采用基于算法4的多線程并發(fā)訪問，各節(jié)點的下載平均速度按照公式1計算得出。由圖3所示，改進后的HDFS在文件下載方面比普通HDFS文件下載的平均速度要高，說明，使用多線程能夠充分利用集群資源，提高集群效率。同時，由圖3也可以看出，不同節(jié)點數(shù)下載的平均速度并非是一個平滑的曲線，而是有些節(jié)點出現(xiàn)了跳躍，這是因為在實際測試環(huán)境下，集群機器本身性能差異以及網(wǎng)絡的不穩(wěn)定等原因所造成，屬于不可避免的。但是，從整體趨勢來看，改進后的HDFS在文件下載方面，效率有了明顯的提高。

4 結束語

本文分析了HDFS集群內(nèi)部在優(yōu)化方面存在的不足，在原HDFS架構中，增加了一個中間件，分別從數(shù)據(jù)塊大小、存儲的負載均衡和文件的多線程訪問三個方面進行設計和改進，并分別提出了相應改進算法，通過模擬實驗表明，優(yōu)化后的HDFS集群在文件下載的平均速度上有了明顯提高，從而反映出集群性能有了比較明顯的提高，這就使得HDFS在圖書管理系統(tǒng)、網(wǎng)盤系統(tǒng)、視頻播放系統(tǒng)等此類需要多用戶并發(fā)訪問且響應時間要求不是很嚴格的系統(tǒng)中得到更加廣泛的應用，而不僅僅只是用來存儲和為Mapreduce提供基礎服務。

下一步的主要工作如下：① 針對HDFS集群NameNode性能瓶頸問題進行進一步的研究；② 在本文算法的基礎上，選擇合適的算法與Map/Reduce進行匹配，達到存儲、計算和訪問下載協(xié)同工作。③實現(xiàn)已存儲的數(shù)據(jù)塊進行重新分塊。

參考文獻：

[1] Dhruba Borthaku. The Hadoop Distributed File System：Architecture and Design.2007

[2] Luo Junzhou，Jin Jiahui，SongAibo，etal.Cloud computing：Architecture and key technologies[J]. Journalon CommuNications，2011，32（7）：3-21.

[3] 周敏奇，王曉玲，金澈清等.Hadoop權威指南[M]. 北京： 清華大學出版社， 2011.1-73.

[4] 劉鵬.實戰(zhàn)Hadoop [M]. 北京： 電子工業(yè)出版社， 2011.1-83.

[5] GHEMAWAT S，GOBIFFH ，LEUNG S-T. The Google file system[C]//Proceeding of 19th ACM Symposium on Operating System Principles.New York：ACM，2003：29-43.

[6] CHANG F， DEAN J，GHEMAWAT S，etal.Bigtable：a distributed storage ststem for structured data[C]//Proceedings of the 7th USENIX Syrup on Operating Systems Design and Implementation.

[7] Bo Dong，Jie Qiu，Qinghua Zheng，etal. A Novel Approach to Improving the Efficiency of Storing and Accessing Small Files on Hadoop：a Case Study by PowerPoint Files[C].Proceedings of the 7th IEEE 2010 Interanational Conference on Services Computing，2010：65-72.

[8] 黎平國.基于HDFS的數(shù)字圖書館云存儲系統(tǒng)研究[J].情報探索，2012，9：98-101.

[9] 徐飛，楊廣文，鞠大鵬.基于Peer-to-Peer的分布式存儲系統(tǒng)的設計[J].軟件學報，2004，15（2）：268-277.

[10] 廖彬，于炯，張?zhí)?，?基于P2P的分布式文件系統(tǒng)下載效率優(yōu)化[J].計算機應用，2011，31（9）：2317-2321.