歐躍發(fā)+黃文明

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

關(guān)鍵詞：Hadoop；HDFS；MapReduce；負(fù)載均衡；分布式計(jì)算

中圖分類號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：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)的實(shí)現(xiàn)。它采用主從（Master/Slave）體系結(jié)構(gòu)，名字節(jié)點(diǎn)Namenode、數(shù)據(jù)節(jié)點(diǎn)DataNode和客戶端Client是HDFS中的3個(gè)重要角色。名字節(jié)點(diǎn)是一個(gè)中心服務(wù)器，是分布式文件系統(tǒng)的管理者，負(fù)責(zé)管理文件系統(tǒng)的命名空間、集群配置和數(shù)據(jù)塊復(fù)制等。數(shù)據(jù)節(jié)點(diǎn)是文件存儲(chǔ)的基本單元，以數(shù)據(jù)塊的形式進(jìn)行存儲(chǔ)?？蛻舳撕兔止?jié)點(diǎn)、數(shù)據(jù)節(jié)點(diǎn)進(jìn)行通信，訪問HDFS，并對文件進(jìn)行操作?；贖DFS的云存儲(chǔ)平臺(tái)，可以減少專用服務(wù)器的數(shù)量，降低應(yīng)用成本，提高系統(tǒng)的性能、穩(wěn)定性和效率，所以它不僅在工業(yè)界得到推崇，在如傳媒、電信、金融、學(xué)校等傳統(tǒng)行業(yè)中也備受青睞。當(dāng)前HDFS主要應(yīng)用在數(shù)據(jù)的存儲(chǔ)和為MapReduce高性能計(jì)算提供底層支持兩個(gè)方面，在多用戶并發(fā)訪問系統(tǒng)中卻沒有發(fā)揮出集群優(yōu)勢。

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

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

1.2 當(dāng)前HDFS框架存在的不足

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

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

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

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

2 OBDR中間件架構(gòu)

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

2.1 OBDR結(jié)構(gòu)與優(yōu)化策略

2.1.1 OBDR-Block

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

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

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

2.1.2 OBDR-DataNode

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

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

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

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

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

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

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

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

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

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

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

7）結(jié)束。

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

1）基于OBDR的HDFS文件存儲(chǔ)流程

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

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

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

3 實(shí)驗(yàn)及分析

3.1實(shí)驗(yàn)環(huán)境

本實(shí)驗(yàn)運(yùn)行在由5臺(tái)PC機(jī)組成的Hadoop集群上，其中一臺(tái)為NameNode節(jié)點(diǎn)，主機(jī)Slave1，Slave2，Slave3和Slave4為DataNode節(jié)點(diǎn)。五臺(tái)機(jī)器的系統(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；

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

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

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

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

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

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

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

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

4 結(jié)束語

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

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

參考文獻(xiàn)：

[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權(quán)威指南[M]. 北京： 清華大學(xué)出版社， 2011.1-73.

[4] 劉鵬.實(shí)戰(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ù)字圖書館云存儲(chǔ)系統(tǒng)研究[J].情報(bào)探索，2012，9：98-101.

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

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