杜忠暉　何慧　王星

摘 要：隨著“大數(shù)據(jù)”時(shí)代的到來，Hadoop等大數(shù)據(jù)處理平臺也應(yīng)運(yùn)而生。但其存儲載體——Hadoop分布式文件系統(tǒng)卻在海量小文件存儲方面存在著很大缺陷，存儲海量小文件會導(dǎo)致整個(gè)集群的負(fù)載增高、運(yùn)行效率下降。為了解決這一針對小文件的存儲缺陷，通常的方法是將小文件進(jìn)行合并，將合并后的大文件進(jìn)行存儲，但以往方法并未將文件體積大小分布加以利用，未能進(jìn)一步提升小文件合并效果。本文提出一種基于數(shù)據(jù)塊平衡的小文件合并算法，優(yōu)化合并后的大文件體積分布，有效降低HDFS數(shù)據(jù)分塊，從而減少集群主節(jié)點(diǎn)內(nèi)存消耗、降低負(fù)載，使數(shù)據(jù)處理過程可以更高效的運(yùn)行。

關(guān)鍵詞：HDFS；小文件存儲；小文件合并算法

中圖分類號：TP391.41 文獻(xiàn)標(biāo)識號：A 文章編碼：2095-2163（2015）03-

Research on Small Files Optimized Storage Strategy in Hadoop System

DU Zhonghui， HE Hui， WANG Xing

（School of Computer Science and Technology， Harbin Institute of Technology， Harbin 150001， China）

Abstract： With the advent of "BIG data"， big data processing platform such as Hadoop has emerged. But its storage carrier --Hadoop distributed file system has many significant flaws on the storage of mass small files， storing massive amounts of small files will not only increase the load of entire cluster， but also decrease operating efficiency. In order to solve the defect， the usual method is to merge small files to a big one， and then it will be stored instead. However， the conventional method does not take advantage of the volume size distribution， so it failed to further enhance the combined effect of small files. This paper presents a data block based on a balance of small files merging algorithm to optimize distribution of merged large files volume， which could effectively reducing the HDFS data block. Thereby the reducing of primary node memory consumption and running load will cause data processing can be run more efficiently.

Keywords： HDFS； Storage of Small Files； Small Files Merge Algorithm

0 引 言

在2012年，“大數(shù)據(jù)”開始在國內(nèi)興起、并普受關(guān)注，隨后即公認(rèn)為2013年則是中國的“大數(shù)據(jù)元年”[1]。根據(jù)ZDNET的數(shù)據(jù)顯示[2]，2013年中國產(chǎn)生的數(shù)據(jù)總量超過0.8ZB（相當(dāng)于8億TB），已兩倍于2012年，具體來說就相當(dāng)于2009年全球的數(shù)據(jù)總量。由此預(yù)計(jì)到2020年，中國產(chǎn)生的數(shù)據(jù)總量將是2013年的10倍，也就是必將超過8.5ZB。

Hadoop在諸如可伸縮性、健壯性、計(jì)算性能和成本上均具有無可替代的優(yōu)勢，并在事實(shí)上已然成為當(dāng)前互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)分析的主流平臺[3]。Hadoop采用的是Hadoop分布式文件系統(tǒng)（Hadoop Distributed Filesystem，以下簡稱HDFS）來進(jìn)行數(shù)據(jù)存儲。但由于Hadoop集群利用了Namenode主節(jié)點(diǎn)存儲集群中所有數(shù)據(jù)塊的信息元數(shù)據(jù)，所以當(dāng)存儲對象變?yōu)轶w積在5MB以下的海量小文件時(shí)，Namenode節(jié)點(diǎn)的運(yùn)行壓力將會急劇上升——占用更多的內(nèi)存來存儲信息元數(shù)據(jù)；同時(shí)，處理大量小文件時(shí)就需要建立更多的MapReduce任務(wù)，而大量的MapReduce任務(wù)間的交互、通信基數(shù)也必將增大CPU的開銷，這會使Hadoop集群的整體運(yùn)行效率呈顯著下降態(tài)勢。

本文提出一種基于數(shù)據(jù)塊平衡的小文件合并算法，用于優(yōu)化HDFS的小文件存儲以及數(shù)據(jù)處理過程，使系統(tǒng)可以實(shí)現(xiàn)更為平穩(wěn)、高效的運(yùn)行。

1 相關(guān)工作

海量小文件問題是工業(yè)和學(xué)術(shù)界的公認(rèn)難題[4]，通常研究認(rèn)為大小在5MB以內(nèi)的文件即稱為小文件。目前的文件系統(tǒng)，包括本地文件系統(tǒng)、分布式文件系統(tǒng)和對象存儲系統(tǒng)，都是主要針對大文件而研發(fā)設(shè)計(jì)的，比如XFS/EXT4、Lustre、GlusterFS、GPFS、ISLION、GFS、HDFS，在元數(shù)據(jù)管理、數(shù)據(jù)布局、條帶設(shè)計(jì)、緩存管理等實(shí)現(xiàn)策略上都側(cè)重大文件，而海量小文件應(yīng)用在性能和存儲效率方面卻會大幅降低，甚至無法工作。

目前實(shí)際中，小文件應(yīng)用日趨常見和普及，如社交網(wǎng)站、電子商務(wù)、廣電、網(wǎng)絡(luò)視頻、高性能計(jì)算，這里舉幾個(gè)典型應(yīng)用場景。著名的社交網(wǎng)站Facebook存儲了600億張以上的圖片，推出了專門針對海量小圖片定制優(yōu)化的Haystack[5]進(jìn)行完善存儲。淘寶目前則是最大C2C電子商務(wù)網(wǎng)站，其存儲超過了200億張圖片，平均大小僅為15KB，為此也針對性推出了有關(guān)小文件優(yōu)化的TFS[6]文件系統(tǒng)來進(jìn)行圖片存儲，并且還實(shí)現(xiàn)了開源。而FastDFS[7]針對小文件的優(yōu)化則類似于TFS。國防科學(xué)技術(shù)大學(xué)也對Lustre進(jìn)行了小文件優(yōu)化工作，并在OST組件中設(shè)計(jì)實(shí)現(xiàn)了一種分布獨(dú)立式的小文件Cache結(jié)構(gòu)：Filter Cache，通過擴(kuò)展Lustre的OST端的數(shù)據(jù)通路，在原有數(shù)據(jù)通路的基礎(chǔ)上，增加了對小對象I/O的緩存措施，憑此來改善Lustre性能[8]。

當(dāng)下有關(guān)HDFS小文件存儲優(yōu)化的研究方面，文獻(xiàn)[9]提出了一種新的文件合并策略，對系統(tǒng) I/O性能發(fā)揮了一定的優(yōu)化作用，因而提高了分布式文件系統(tǒng)的性能。文獻(xiàn)[10]則針對HDFS存儲小文件的問題，對HDFS存儲前的小文件處理工作和存儲后的檢索，提出專項(xiàng)相關(guān)算法，在一定程度上提高了 HDFS對小文件的存儲和讀取效率。此外，另有文獻(xiàn)[11]提出一種將小文件合并為大小為一個(gè)單一的大文件、再存儲于HDFS中的方法，即合并后的文件體積等于所有小文件的體積和，從而使系統(tǒng)的存儲及CPU計(jì)算開銷都得到了有效控制與降低。但是其并未針對小文件的體積大小具體分布以及HDFS文件塊大小作進(jìn)一步的設(shè)計(jì)優(yōu)化。針對以上不足，本文提出一種基于數(shù)據(jù)塊平衡的小文件合并算法，實(shí)現(xiàn)了HDFS的小文件存儲優(yōu)化，使系統(tǒng)可以更高效、合理地運(yùn)行與工作。

2 HDFS小文件存儲缺陷及解決方案

Hadoop分布式文件系統(tǒng)（以下簡稱HDFS）在處理大體積數(shù)據(jù)文件時(shí)的表現(xiàn)十分優(yōu)異。HDFS會將輸入的數(shù)據(jù)文件切分為64MB大小的數(shù)據(jù)塊。集群的Namenode節(jié)點(diǎn)將存儲集群中的所有數(shù)據(jù)塊的信息元數(shù)據(jù)，Datanode節(jié)點(diǎn)則存儲所有數(shù)據(jù)塊實(shí)體，而且每個(gè)信息元數(shù)據(jù)將占用Namenode節(jié)點(diǎn)150字節(jié)的內(nèi)存空間 。這些數(shù)據(jù)塊將由MadReduce框架進(jìn)行調(diào)用處理。

Hadoop在處理大量小體積文件（一般大小為10KB～5MB）時(shí)是十分低效的。這類小文件將給Hadoop的性能表現(xiàn)帶來顯著影響。首先，在Hadoop中存儲大量小體積文件將會導(dǎo)致Namenode中用于存儲數(shù)據(jù)塊信息元數(shù)據(jù)占用內(nèi)存的增大，進(jìn)而限制了這個(gè)集群的整體性能，例如對于一個(gè)大小為1GB的大文件，HDFS會將其切分為16個(gè)大小為64MB的數(shù)據(jù)塊，此時(shí)Namenode內(nèi)存開銷僅為2.4KB，但如果將其切分為1GB的一萬個(gè)100KB的文件，Namenode的內(nèi)存開銷將增長至1.5MB，即增長了600余倍；其次，在塊大小范圍內(nèi)的小文件則將依然占用64M的空間，處理大量小文件就需要建立更多的MapReduce任務(wù)，而大量的MapReduce任務(wù)間的交互、通信數(shù)目也將增大CPU的開銷。

針對Hadoop在處理大量小文件的缺點(diǎn)與不足，一般的解決方法是將小文件合并為一個(gè)大文件后再導(dǎo)入HDFS。采用這種策略將具有相當(dāng)優(yōu)勢，具體論述如下。

首先，減少了大量元數(shù)據(jù)，降低了NameNode節(jié)點(diǎn)負(fù)擔(dān)。通過將大量的小文件存儲到一個(gè)大文件中，從而把大量的小文件數(shù)據(jù)變成大文件數(shù)據(jù)，減少了文件數(shù)量，也就減少了NameNode的元數(shù)據(jù)數(shù)量，提高了元數(shù)據(jù)的檢索和查詢效率，而且降低了文件讀寫的I/O操作延時(shí)，同時(shí)節(jié)省了大量的數(shù)據(jù)傳輸時(shí)間。離散化的小文件元數(shù)據(jù)開銷所占比重較大，若大幅減少元數(shù)據(jù)，將直接導(dǎo)致性能的顯著提升。合并后的大文件存儲在磁盤文件系統(tǒng)上，相當(dāng)程度上就降低了磁盤文件系統(tǒng)在元數(shù)據(jù)和I/O方面的壓力，因此即可改善每個(gè)節(jié)點(diǎn)的存儲性能。

其次，增加了數(shù)據(jù)局部性，提高了HDFS存儲效率。磁盤文件系統(tǒng)或者分布式文件系統(tǒng)中，文件的元數(shù)據(jù)和各類數(shù)據(jù)存儲在不同位置。采用合并存儲機(jī)制后，小文件的元數(shù)據(jù)和各類數(shù)據(jù)均可連續(xù)一并存儲于大文件中，這即于無形之中顯著增強(qiáng)了單個(gè)小文件內(nèi)部的數(shù)據(jù)局部性。小文件合并過程中，可以利用文件間的空間局部性、時(shí)間局部性以及關(guān)聯(lián)，盡量將可能連續(xù)訪問的小文件在大文件中進(jìn)行連續(xù)存儲，為此增強(qiáng)了小文件之間的數(shù)據(jù)局部性。這也直接降低了磁盤上隨機(jī)I/O比率，將其轉(zhuǎn)換為順序I/O，如此即能有效提高I/O讀寫性能。另外，小文件單獨(dú)存儲將會形成外部和內(nèi)部碎片，而合并存儲后存儲碎片將明顯降低，這也極大提高了小文件存儲效率。

再次，簡化了Hadoop節(jié)點(diǎn)I/O訪問流程。采用小文件合并存儲后，I/O訪問流程發(fā)生了重大變化，主要體現(xiàn)在存儲節(jié)點(diǎn)磁盤文件系統(tǒng)上。當(dāng)磁盤文件系統(tǒng)讀寫一個(gè)小文件，系統(tǒng)能量更多地消耗在文件打開的系統(tǒng)調(diào)用，具體包括路徑查找，路徑名的分量解析，轉(zhuǎn)換成對應(yīng)文件在內(nèi)核中的內(nèi)部表示。這個(gè)過程占用系統(tǒng)開銷較大，尤其是深目錄下的文件。而經(jīng)過合并，眾多的小文件將共享一個(gè)大文件，文件打開操作也轉(zhuǎn)換成了開銷更小的數(shù)據(jù)偏移定位操作，也就是根據(jù)索引定位到大文件內(nèi)部相應(yīng)位置即可，而且也不再需要于內(nèi)核中創(chuàng)建相關(guān)的VFS數(shù)據(jù)對象，這就節(jié)省了最初絕大部分的系統(tǒng)開銷。

綜上可知，HDFS將合并后的大文件在進(jìn)行大小為64M的數(shù)據(jù)塊切分后，存儲在Namenode節(jié)點(diǎn)上的數(shù)據(jù)塊信息元數(shù)據(jù)就會明顯減少，因而有效降低了內(nèi)存方面的開銷。同時(shí)，又進(jìn)一步提高了MapReduce任務(wù)處理中各Datanode節(jié)點(diǎn)上數(shù)據(jù)塊的運(yùn)行效率。

3基于數(shù)據(jù)塊平衡的小文件合并算法的設(shè)計(jì)與實(shí)現(xiàn)

3.1 算法基本思想

已有基于文件體積大小的小文件合并算法往往是設(shè)定一個(gè)緩沖區(qū)閾值，在遍歷小文件的同時(shí)針對緩沖區(qū)隊(duì)列不斷累加文件，當(dāng)累加總大小超過閾值后，即對緩沖區(qū)隊(duì)列中的文件集合實(shí)行合并打包存儲。執(zhí)行過程示例如圖1所示。但是這樣的算法常常以“文件體積溢出”作為合并條件，同時(shí)忽略了文件體積分布不均的缺點(diǎn)，最終造成的結(jié)果就是合并后的大文件體積大小各異，在一定程度上對Hadoop集群中的NameNode節(jié)點(diǎn)形成了內(nèi)存浪費(fèi)，同時(shí)文件體積分布不均也不利于MapReduce框架并行計(jì)算高效實(shí)施。

圖1 現(xiàn)有小文件合并算法過程示意圖

Fig.1 Process of existing small file merging algorithm schematic

本文提出一種基于數(shù)據(jù)塊平衡的小文件合并算法，其核心思想就是根據(jù)小文件的體積大小，使其進(jìn)行均勻分布、再傳至合并后的大文件中，而且又將文件合并條件由“文件體積溢出”轉(zhuǎn)換為“文件體積接近臨界”，由此保證合并后的大文件在HDFS中不會被分割出多余的塊。該算法的提出在一定程度上降低了NameNode節(jié)點(diǎn)內(nèi)存負(fù)載，同時(shí)文件體積均勻分布也將利于MapReduce并行計(jì)算的效率發(fā)揮。由于小文件合并策略類似于游戲“俄羅斯方塊”中的填補(bǔ)空白的方法，為此即將該算法命名為Tetris Merge（俄羅斯方塊似的合并）算法，簡稱TM算法。

3.2 算法設(shè)計(jì)

首先，介紹算法中使用的數(shù)據(jù)結(jié)構(gòu)。本文將算法中使用的隊(duì)列分為兩類——文件合并隊(duì)列和容忍隊(duì)列。共有若干個(gè)文件合并隊(duì)列用于存放待合并的小文件集合，當(dāng)隊(duì)列中的文件總大小達(dá)到合并條件時(shí)，即將文件集統(tǒng)一打包合并存入HDFS，且清空該隊(duì)列；同時(shí)還有若干個(gè)容忍隊(duì)列用于存儲非預(yù)期情況下出現(xiàn)的體積偏大的文件，發(fā)揮應(yīng)有的緩沖作用，并保證合并后文件大小盡量均勻分布。兩類隊(duì)列可以相互轉(zhuǎn)換，后文將介紹其轉(zhuǎn)換策略與條件。

算法的執(zhí)行流程如圖2所示。算法共分為兩個(gè)階段：文件合并階段，后處理階段。

圖2 TM算法執(zhí)行流程圖

Fig.2 TM algorithm execution flow

算法執(zhí)行流程如下：

（1）根據(jù)文件合并閾值創(chuàng)建m個(gè)文件合并隊(duì)列qfl和n個(gè)容忍隊(duì)列qtl（一般n

（2）遍歷所有待合并小文件f，選擇一個(gè)文件合并隊(duì)列添加入隊(duì)，實(shí)施原則是選擇當(dāng)前隊(duì)列集合中文件總體積最小的隊(duì)列（剩余空間最大的隊(duì)列）qmax。如果文件加入隊(duì)列后的總文件容積小于合并閾值，則正常加入；反之即進(jìn)入異常處理步驟。

（3）異常處理步驟，文件加入隊(duì)列使總大小超過合并閾值。如果此時(shí)該隊(duì)列qmin中文件總大小已經(jīng)超過合并閾值的95%，則將qmin中文件合并輸出，且清空隊(duì)列，同時(shí)將亟待入列的文件加入該隊(duì)列；反之未超過閾值的95%，則證明待入列文件是一個(gè)偏大文件，則將該隊(duì)列插入容忍隊(duì)列（存在空容忍隊(duì)列時(shí)）。此時(shí)，該容忍隊(duì)列將轉(zhuǎn)變?yōu)槲募喜㈥?duì)列，參與到下一輪合并隊(duì)列挑選中。

（4）隊(duì)列清空原則。步驟（3）中提到的隊(duì)列清空之前要進(jìn)行一定條件的判斷，如果當(dāng)前文件合并隊(duì)列數(shù)量大于初始化的m個(gè)時(shí)，該隊(duì)列清空后將不插入任何文件，而是直接轉(zhuǎn)換為一個(gè)空容忍隊(duì)列。

（5）前面的4步就是文件合并階段。當(dāng)所有待合并小文件遍歷結(jié)束，將有一些尚未合并的文件仍然留存于當(dāng)前隊(duì)列集合中，此時(shí)將進(jìn)入后處理階段。該階段主要采用單文件隊(duì)列的方法，由此而將隊(duì)列中剩余文件實(shí)現(xiàn)合并。

由圖1給出的實(shí)例如果采用TM算法，其合并效果將如圖3所示。

圖3 TM算法文件合并效果

Fig.3 The effect of file merging by TM algorithm

3.3算法的實(shí)現(xiàn)

TM算法核心實(shí)現(xiàn)的偽代碼描述如下：

Algorithm TM：

Input： FileList待合并小文件集合，MergeLimit合并閾值，F(xiàn)ileQNum文件合并隊(duì)列數(shù)量，TolerateQNum容忍隊(duì)列數(shù)量

Output：MergedFile合并后的大文件

1.Initialization：qfl， qtl

2.For each file f in FileList. Then goto step 10

3.Select max freespace queue qmax in qfl

4.If f's size less than remain size of qmax， goto step 5， else goto step 6

5.Push f into qmax， goto step 2

6.Calc min freespace queue qmin remain size Smin

7.If Smin /MergeLimit >0.95 or qtl is empty， goto step 8， else goto step 9

8.Merge files in qmin to MergedFile， push qmin into qtl

9.Select a queue qt from qtl， push f int qt， push qt into qfl

10.Merge remain files to MergedFile in queues

小文件合并后形成的大文件采用Hadoop支持的SequenceFile文件格式。在存儲結(jié)構(gòu)上，SequenceFile主要由一個(gè)Header及其后的多條Record組成。具體地，Header主要包含了Key classname，Value classname，存儲壓縮算法，以及用戶自定義元數(shù)據(jù)等信息；除此之外，還包含了一些同步標(biāo)識，用于快速定位到記錄的邊界。Sequence File文件格式即如圖4所示。

圖4 SequenceFile文件格式

Fig.4 SequenceFile file format

4 實(shí)驗(yàn)

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

實(shí)驗(yàn)中，本文使用了兩臺服務(wù)器組成Hadoop集群，Namenode、Datanode節(jié)點(diǎn)各一個(gè)，設(shè)計(jì)構(gòu)建的硬件環(huán)境如表1所示。

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

Tab.1 Experimental environment

Namenode 操作系統(tǒng) CentOS 6.2

CPU AMD Opteron（TM） 8Core 1.4GHz *32

內(nèi)存 32GB

硬盤 320GB

Datanode 操作系統(tǒng) CentOS 6.2

CPU AMD Opteron（TM） 8Core 1.4GHz *32

內(nèi)存 32GB

硬盤 320GB

Hadoop版本為1.2.1，Java運(yùn)行環(huán)境版本為1.6。副本數(shù)量設(shè)置為2，HDFS數(shù)據(jù)塊大小采用系統(tǒng)默認(rèn)的64MB。

測試數(shù)據(jù)的小文件集合包含4 294個(gè)文件，總大小為10.12GB。這些小文件均為各類格式的小文件，文件體積從不足100KB到64MB各有不等。圖5展示了文件集合的體積大小數(shù)量分布，其中體積為5MB以下的小文件占到總文件數(shù)量的97.71%，而5～64MB的文件則主要用于觀察文件合并效果。

圖5 文件集合體積大小數(shù)量分布

Fig.5 File size distribution of test file collection

4.2向HDFS導(dǎo)入文件時(shí)間消耗對比實(shí)驗(yàn)

通過包括TM算法在內(nèi)的三種不同方法向HDFS進(jìn)行文件導(dǎo)入，記錄導(dǎo)入文件操作所消耗的時(shí)間。其中單文件合并算法中，合并文件的大小將選擇與TM算法閾值相同的128MB。表2顯示了三種方法向HDFS中導(dǎo)入數(shù)據(jù)的時(shí)間消耗結(jié)果比較。

表2 小文件導(dǎo)入消耗時(shí)間對比

Tab.2 Time consuming on importing small files

文件導(dǎo)入算法 文件數(shù)量/體積 合并后文件數(shù)量 消耗時(shí)間（秒）

正常導(dǎo)入 4 294/10.12GB 4294 567

單文件合并算法 4 294/10.12GB 82 249

TM算法 4 294/10.12GB 84 252

圖6用柱狀圖的形式顯示了三種方法的時(shí)間消耗對比。

圖6 小文件導(dǎo)入時(shí)間消耗對比

Fig.6 Time consuming on importing small files

通過對比測試實(shí)驗(yàn)可以看出，在文件導(dǎo)入時(shí)間消耗方面，TM算法稍遜于單文件合并算法。造成這一結(jié)果的原因是兩個(gè)算法的“文件合并”操作觸發(fā)條件不同，就使得合并后的文件數(shù)量有所差異，TM算法合并的文件數(shù)量并未少于單文件合并算法，由此導(dǎo)致在文件導(dǎo)入時(shí)間對比上略呈劣勢。

4.3 Namenode節(jié)點(diǎn)內(nèi)存消耗對比

HDFS會將導(dǎo)入的數(shù)據(jù)分割成默認(rèn)大小的64MB的數(shù)據(jù)塊。其后系統(tǒng)就會將所有數(shù)據(jù)塊信息的元數(shù)據(jù)存儲到Namenode節(jié)點(diǎn)上，同時(shí)再將所有的數(shù)據(jù)塊保存在Datanode節(jié)點(diǎn)上。而在Namenode節(jié)點(diǎn)上，每個(gè)數(shù)據(jù)塊的信息元數(shù)據(jù)均將占用150字節(jié)左右的內(nèi)存。

在研究的測試數(shù)據(jù)文件集中，共包含總大小為10.12GB，總計(jì)4 294個(gè)體積小于64MB的文件。如果不加任何處理，HDFS將創(chuàng)建4294個(gè)數(shù)據(jù)塊。若為存儲這些數(shù)據(jù)塊信息元數(shù)據(jù)，Namenode節(jié)點(diǎn)即將消耗掉644 100字節(jié)的內(nèi)存空間。而在文獻(xiàn)[11]中提出的單文件合并算法，由于合并后的文件（128MB）在分割為數(shù)據(jù)塊時(shí)總會遺留多余的數(shù)據(jù)塊，就使得在內(nèi)存消耗上并不能保證最低開銷。另有TM算法是根據(jù)HDFS數(shù)據(jù)分塊大小的特點(diǎn)進(jìn)行優(yōu)化，從而保證了合并后的文件不會被分割出多余的數(shù)據(jù)塊，因此分割后的數(shù)據(jù)塊對Namenode節(jié)點(diǎn)的內(nèi)存消耗上則要優(yōu)于前兩者。

表3給出了三種數(shù)據(jù)導(dǎo)入方法對分割產(chǎn)生數(shù)據(jù)塊數(shù)量的影響，最終導(dǎo)致Namenode節(jié)點(diǎn)在內(nèi)存消耗上的變化結(jié)果對比。

表3 Namenode節(jié)點(diǎn)內(nèi)存消耗對比

Tab.3 Consumption of Namenode memory

文件導(dǎo)入算法 生成數(shù)據(jù)塊數(shù)量 Namenode節(jié)點(diǎn)內(nèi)存消耗（字節(jié)）

正常導(dǎo)入 4 294 644 100

單文件合并算法 245 36 750

TM算法 168 25 200

圖7用柱狀圖的形式顯示了三種方法導(dǎo)致Namenode節(jié)點(diǎn)內(nèi)存消耗的對比。

圖7 Namenode節(jié)點(diǎn)內(nèi)存消耗對比

Fig.7 Consumption of Namenode memory

通過實(shí)驗(yàn)對比測試可以看出，單文件合并算法與TM算法生成的大文件相比于不加處理直接導(dǎo)入的方法對Namenode節(jié)點(diǎn)的內(nèi)存消耗都有十分明顯的改善效果。同時(shí)由于TM算法考慮到HDFS數(shù)據(jù)塊大小對數(shù)據(jù)塊分割的影響，致使其產(chǎn)生的大文件在分割為數(shù)據(jù)塊之后的數(shù)量與單文件合并算法相比即有明顯的下降，最終導(dǎo)致對Namenode節(jié)點(diǎn)內(nèi)存消耗的大幅下降。在本實(shí)驗(yàn)中，較之單文件合并算法，Namenode節(jié)點(diǎn)內(nèi)存消耗下降了31.4%。

4.4 文件數(shù)據(jù)處理速度對比

Hadoop設(shè)計(jì)的初衷是用于大體積文件處理，因而用其處理數(shù)量巨大但是體積很小的文件將會使Hadoop的處理性能下降。測試數(shù)據(jù)文件集合中共計(jì)有可占空間為10.12GB的4 294個(gè)小文件，如果進(jìn)行各自的單獨(dú)處理，必將耗費(fèi)相當(dāng)長的時(shí)間。

測試實(shí)驗(yàn)是利用同樣一個(gè)中文word count（先對中文分詞然后計(jì)數(shù)）MapReduce程序?qū)θ齻€(gè)算法導(dǎo)入到HDFS中的數(shù)據(jù)分別處理，并對比消耗時(shí)間，得出處理速度。表4給出了對三種方法生成的數(shù)據(jù)進(jìn)行MapReduce處理所用的時(shí)間對比，反映了處理速度的快慢。

表4 MapReduce數(shù)據(jù)處理速度對比

Tab.4 Time consuming of MapReduce data processing

導(dǎo)入數(shù)據(jù)所使用算法 Map階段耗時(shí) Reduce階段耗時(shí) 總耗時(shí)

正常導(dǎo)入 13 993 s 333 s 14 326 s

單文件合并算法 1 190 s 119 s 1 309 s

TM算法 1 035 s 101 s 1 136 s

圖8利用柱形圖的形式顯示了MapReduce處理三種方法生成數(shù)據(jù)速度對比。

圖8 MapReduce數(shù)據(jù)處理速度對比

Fig.8 Time consuming of MapReduce data processing

通過實(shí)驗(yàn)對比測試可以看出，無論是單文件合并算法還是TM算法所生成的數(shù)據(jù)，在應(yīng)對MapReduce處理數(shù)據(jù)時(shí)都較正常，其導(dǎo)入數(shù)據(jù)在處理時(shí)間上均呈較大幅度的下降，也就是處理速度得到了很大提升。同時(shí)，TM算法對比單文件合并算法在處理速度上也有較大提升，Map階段、Reduce階段和整體過程的處理速度分別提高了15.0%、17.8%、15.2%。出現(xiàn)這樣結(jié)果的原因是TM算法生成的數(shù)據(jù)在HDFS中的分塊結(jié)果更趨合理，產(chǎn)生的數(shù)據(jù)分塊數(shù)量更少，因此就進(jìn)一步降低了系統(tǒng)I/O時(shí)間消耗，相應(yīng)地也提升了數(shù)據(jù)處理速度。

通過三個(gè)對比測試實(shí)驗(yàn)綜合可知，TM算法僅在數(shù)據(jù)導(dǎo)入時(shí)間上稍落后于文獻(xiàn)[11]提出的單文件合并算法，但其在Namenode節(jié)點(diǎn)內(nèi)存消耗和生成數(shù)據(jù)被處理速度方面都有較大提升，由此即證明了該算法的有效性。

5 結(jié)束語

本文針對Hadoop分布式文件系統(tǒng)對小文件存儲、處理缺陷，提出一種優(yōu)化的文件合并及存儲策略，利用文件體積大小分布實(shí)現(xiàn)對合并文件的優(yōu)化組合，大幅減少了Hadoop集群中主節(jié)點(diǎn)的內(nèi)存消耗，提升了MapReduce處理數(shù)據(jù)效率；相比單文件合并算法，提升效果達(dá)15%以上。

首先，本文對現(xiàn)有的小文件存儲處理方案進(jìn)行了歸納總結(jié)。其次，對Hadoop分布式文件系統(tǒng)的小文件存儲缺陷展開了詳細(xì)分析，在此基礎(chǔ)上結(jié)合傳統(tǒng)的單文件合并算法以及小文件體積分布規(guī)律，提出了基于數(shù)據(jù)塊平衡的小文件合并算法，并給出了完整的算法思想及算法實(shí)現(xiàn)。最后，針對提出的算法進(jìn)行了實(shí)驗(yàn)分析，證明了該研究算法可降低集群主節(jié)點(diǎn)內(nèi)存消耗、以及提升集群數(shù)據(jù)處理效率。

接下來的工作中可以針對文件類型的異同進(jìn)行合并測試，探討相同的文件類型合并成大文件后對數(shù)據(jù)處理效率的影響，同時(shí)還要測試不同數(shù)據(jù)集對實(shí)驗(yàn)結(jié)果的影響。

參考文獻(xiàn)：

[1] http：//finance.21cn.com/stock/wmkzg/a/2014/0910/14/28200740.shtml

[2] www.zdnet.com.cn至頂網(wǎng)-云計(jì)算第一門戶

[3] 大數(shù)據(jù)架構(gòu)hadoop http：//blog.csdn.net/guoxiaoqian8028/article/details/18772363

[4] YU L， CHEN G， WANG W， et al. Msfss： A storage system for mass small files[C]//Computer Supported Cooperative Work in Design， 2007. CSCWD 2007. 11th International Conference on，[S.l.]： IEEE， 2007：1087-1092.

[5] BEAVER D， KUMAR S， LI H C， et al. Finding a Needle in Haystack： Facebook's Photo Storage[C]//OSDI. 2010， 10， Vancouver， BC： [s.n.]： 1-8.

[6] Taobao File System 項(xiàng)目主頁， http：//tfs.taobao.org/

[7] LIU X， YU Q， LIAO J. FASTDFS： A High Performance Distributed File System[J]. ICIC express letters. Part B， Applications： an international journal of research and surveys， 2014， 5（6）： 1741-1746.

[8] QIAN Y， YI R， DU Y， et al. Dynamic I/O congestion control in scalable Lustre file system[C]//Mass Storage Systems and Technologies （MSST）， 2013 IEEE 29th Symposium on. IEEE， Lake Arrowhead： [s.n.]， 2013：1-5.

[9] 陳劍， 龔發(fā)根. 一種優(yōu)化分布式文件系統(tǒng)的文件合并策略[J]. 計(jì)算機(jī)應(yīng)用， 2011， 31（2）： 161-163.

[10] 董其文. 基于 HDFS 的小文件存儲方法的研究[D]. 大連：大連海事大學(xué)， 2013.

[11] PRASAD G， NAGESH H R， DEEPTHI M. Improving the performance of processing for small files in Hadoop： A case study of weather data analytics[J]. International Journal of Computer Science & Information Technolo，2014， 5（5） ：6436.