彭建烽，魏文國(guó)，鄭東煒

（廣東技術(shù)師范學(xué)院電子與信息學(xué)院，廣東廣州 510665）

基于Hadoop的海量小文件合并的研究與設(shè)計(jì)

彭建烽，魏文國(guó)，鄭東煒

（廣東技術(shù)師范學(xué)院電子與信息學(xué)院，廣東廣州 510665）

基于Hadoop海量小文件合并的策略研究，一方面為了減輕NameNode的元數(shù)據(jù)量，利用Eclipse開發(fā)工具實(shí)現(xiàn)了Har、HBase、SequenceFile三種主流合并方案對(duì)海量小文件的合并；另一方面分析這三種主流合并方案在不同場(chǎng)景下性能以及應(yīng)用方面的優(yōu)劣，進(jìn)而為海量小文件在Hadoop上的存儲(chǔ)提供一些有價(jià)值的參考.

Hadoop；HDFS；小文件；元數(shù)據(jù)；Har；HBase；SequenceFile

1 引言

Hadoop分布式數(shù)據(jù)存儲(chǔ)和處理框架憑借其高效、可靠、高容錯(cuò)等優(yōu)點(diǎn)，漸漸成為了炙手可熱的大數(shù)據(jù)存儲(chǔ)和處理工具.Hadoop分布式文件系統(tǒng)（HDFS）是Hadoop的核心部分，它所具有的兩類節(jié)點(diǎn)以管理者-工作者的模式運(yùn)行，即單一NameNode（管理者）和若干個(gè)DataNode（工作者）.NameNode負(fù)責(zé)管理文件系統(tǒng)的命名空間，DataNode作為系統(tǒng)的工作節(jié)點(diǎn)，它們根據(jù)需要存儲(chǔ)并檢索數(shù)據(jù)塊(受客戶端或NameNode調(diào)度)，并且定期向NameNode發(fā)送它們所存儲(chǔ)的塊列表［1］.

但HDFS并不適合存儲(chǔ)海量小文件，主要因?yàn)镹ameNode將文件系統(tǒng)的元數(shù)據(jù)放在內(nèi)存中，整個(gè)系統(tǒng)的文件數(shù)目受到NameNode內(nèi)存大小的限制.根據(jù)經(jīng)驗(yàn)，每個(gè)文件、目錄和數(shù)據(jù)塊的存儲(chǔ)信息大約占150字節(jié).舉例來(lái)說(shuō)，如果有一百萬(wàn)個(gè)文件，且每個(gè)文件占一個(gè)數(shù)據(jù)塊，那至少需要300MB的內(nèi)存.盡管存儲(chǔ)上百萬(wàn)個(gè)文件是可行的，但是存儲(chǔ)數(shù)十億個(gè)文件就超出了當(dāng)前硬件的能力［1］.如今，Hadoop存儲(chǔ)海量小文件已成為了大數(shù)據(jù)領(lǐng)域的熱點(diǎn)問(wèn)題.

2 相關(guān)研究

解決Hadoop上海量小文件的存儲(chǔ)問(wèn)題可以歸結(jié)為兩類：HDFS自身提供的解決方案和針對(duì)不同的應(yīng)用場(chǎng)景采取特定的優(yōu)化方案.

文獻(xiàn)［2-4］是HDFS自身提供的解決方案. Har方案執(zhí)行MapReduce任務(wù)將HDFS中的大量小文件合并成大文件，以此減少元數(shù)據(jù)量，不足之處在于歸并的過(guò)程耗時(shí)較長(zhǎng)，且隨機(jī)讀取小文件需要額外訪問(wèn)一層索引，導(dǎo)致訪問(wèn)速度可能更慢［2］.SequenceFile方案工作原理是采取keyvalue鍵值對(duì)存儲(chǔ)合并后的小文件，key是小文件名，value是對(duì)應(yīng)的內(nèi)容.但該方案不適合低延時(shí)的隨機(jī)訪問(wèn)，因?yàn)槊看巫x取小文件都需要遍歷整個(gè)大的文件［3］.MapFile方案是在SequenceFile方案基礎(chǔ)上進(jìn)行優(yōu)化的，增添按key排序、有索引的功能，讀取小文件的性能優(yōu)于后者［4］.

文獻(xiàn)［5-7］根據(jù)不同應(yīng)用場(chǎng)景采取特定解決方案.文獻(xiàn)［5］在WebGIS系統(tǒng)中，將保存在相鄰地理位置具有相關(guān)性的小文件合并成一個(gè)大文件，進(jìn)而優(yōu)化NameNode的內(nèi)存開銷，同時(shí)為合并后的小文件建立索引，進(jìn)一步提高小文件的訪問(wèn)速度.文獻(xiàn)［6］認(rèn)為Bluesky系統(tǒng)缺乏考慮ppt之間的相關(guān)性和預(yù)存取機(jī)制，一方面將同屬于一個(gè)課件的ppt文件合并成一個(gè)大文件；另一方面建立索引文件和數(shù)據(jù)文件的預(yù)取機(jī)制，提高文件的訪問(wèn)速度.文獻(xiàn)［7］將NameNode中的元數(shù)據(jù)遷移到集群的數(shù)據(jù)庫(kù)中，發(fā)揮關(guān)系型數(shù)據(jù)庫(kù)的讀寫性能快的優(yōu)勢(shì)，實(shí)現(xiàn)對(duì)元數(shù)據(jù)快速讀??；同時(shí)將塊校驗(yàn)工作轉(zhuǎn)交到元數(shù)據(jù)存儲(chǔ)集群中，進(jìn)一步減輕NameNode的負(fù)載壓力.

針對(duì)當(dāng)前眾多小文件合并方案雖能在一定程度上解決文件合并所帶來(lái)的性能問(wèn)題，但都不具備很好的通用性，缺乏對(duì)幾種不同合并方案的綜合性分析和總結(jié).因此，本文對(duì)當(dāng)前三種流行的Har、HBase、SequenceFile合并方案進(jìn)行綜合性的研究，分析這三種解決方案在不同場(chǎng)景下的性能以及應(yīng)用方面的優(yōu)劣，為解決小文件問(wèn)題提供一些有價(jià)值的參考.

3 文件合并方案比較分析

Har是一種特殊的檔案格式，它在HDFS上再建立一層文件系統(tǒng)，通過(guò)在HDFS文件索引的基礎(chǔ)上再添加一個(gè)索引，即主索引記錄了這些Har索引，而Har索引則記錄了文件數(shù)據(jù)的信息和內(nèi)容，從而實(shí)現(xiàn)歸檔合并文件.Har方式通過(guò)減少NameNode元數(shù)據(jù)的條數(shù)，將海量的小文件歸檔為少量或者一個(gè)大文件，有效地提高了網(wǎng)絡(luò)吞吐量，使得元數(shù)據(jù)減少了對(duì)內(nèi)存的占用和消耗，從而緩解了NameNode壓力.但這種方式不足之處在于不僅要讀取HDFS上的索引，還要讀取Har的索引，從而對(duì)數(shù)據(jù)文件進(jìn)行加載，效率比原來(lái)的直接存放低.

HBase是一個(gè)分布式、面向列的開源數(shù)據(jù)庫(kù)，HBase表的數(shù)據(jù)被分割成多個(gè)Region，是分布式存儲(chǔ)的最小單元，分別由HBase集群中的RegionServer所管理，主節(jié)點(diǎn)NameNode有一個(gè)HMaster，負(fù)責(zé)管理集群中DataNode節(jié)點(diǎn)的HRegionServer，每一個(gè)HRegionServer存放客戶端提交的數(shù)據(jù)，即分布式存儲(chǔ)的最小單元Region，它是由一個(gè)或多個(gè)HSTORE組成的，而一個(gè)HSTORE保存一個(gè)列族，每個(gè)HSTORE又由一個(gè)MEMSTORE和多個(gè)Hfile組成.HFile是只讀的，一旦創(chuàng)建就不可修改.當(dāng)出現(xiàn)多個(gè)HFile的時(shí)候，就會(huì)進(jìn)行HFile合并，而如果HFile大小到達(dá)一定閾值之后就會(huì)觸發(fā)split操作，這個(gè)由HRigionServer檢測(cè)是否達(dá)到閾值，將當(dāng)前Region分割成兩個(gè)Region，再由HMaster分配給其他server，從而保證了I/O讀取的高性能.但不足之處在于HBase只是適合大量稀疏數(shù)據(jù).

SequenceFile是一種存儲(chǔ)大量二進(jìn)制鍵值對(duì)數(shù)據(jù)文件格式，用來(lái)作為小文件的容器，從而提高M(jìn)apReduce處理數(shù)據(jù)的效率.SequenceFile將小文件合并成一個(gè)格式為SEQ的序列大文件，作為MapReudce的輸入輸出.此外，SequenceFile提供三種基于None、RECORD、BLOCK鍵值對(duì)壓縮方式，SequenceFile不僅從源頭解決了小文件過(guò)多導(dǎo)致元數(shù)據(jù)消耗大量?jī)?nèi)存的問(wèn)題，而且提高了MapReduce任務(wù)處理速度，壓縮還能減少空間的占用，但是不足在于SequenceFile不支持追加，不能往里面添加數(shù)據(jù).

4 測(cè)試與分析

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

實(shí)驗(yàn)環(huán)境搭建了5個(gè)節(jié)點(diǎn)的Hadoop集群，每個(gè)節(jié)點(diǎn)的配置為：四核Intel Core CPU，主頻3.6GHz，內(nèi)存4GB，1TB硬盤空間，其中一臺(tái)機(jī)器作為NameNode，其余四臺(tái)作為DataNode.每臺(tái)節(jié)點(diǎn)安裝的操作系統(tǒng)為Ubuntu 12.04，Hadoop版本為Hadoop-2.6.3，JDK版本為1.8.0_73.實(shí)驗(yàn)用到的數(shù)據(jù)類型為txt格式文檔、jpg格式圖片、mp3音頻文件，jpg格式圖片的大小分布在0～200KB，大小2MB到10MB的txt文檔和mp3音頻文件分別占各自數(shù)據(jù)總量的80.3%、93.7%.

4.2 實(shí)驗(yàn)分析

實(shí)驗(yàn)1通過(guò)上傳2000、4000、6000、8000、10000個(gè)小文件，對(duì)原始HDFS、Har的NameNode的內(nèi)存使用情況進(jìn)行了測(cè)試.結(jié)果如圖1所示.

圖1 NameNode的內(nèi)存使用大小對(duì)比

圖1的實(shí)驗(yàn)結(jié)果表明，Har能顯著降低NameNode的內(nèi)存開銷，而且隨著小文件數(shù)量的增多，Har的優(yōu)勢(shì)更加地明顯.這是因?yàn)镠ar將多個(gè)小文件合并成大文件能有效地減少NameNode元數(shù)據(jù)量，使得客戶端在NameNode檢索元數(shù)據(jù)時(shí)變得更快，從而提高訪問(wèn)速度.

實(shí)驗(yàn)2采用10000個(gè)小文件，測(cè)試原始HDFS和HBase合并后小文件4次順序讀取的耗時(shí)開銷，實(shí)驗(yàn)結(jié)果如圖2所示.

圖2 原始HDFS、HBase合并順序讀取時(shí)間對(duì)比

通過(guò)計(jì)算，最終HBase順序讀取平均時(shí)間是原始HDFS的1/1.61，HBase合并后順序讀取性能優(yōu)于原始HDFS.這是因?yàn)镠Base合并會(huì)提高I/O性能，檢索速度變快.在實(shí)際應(yīng)用環(huán)境中數(shù)據(jù)量更大，差異也會(huì)更加明顯，但是這種方式的合并并不能隨意使用，否則會(huì)引起阻塞，應(yīng)該在HBase集群空閑時(shí)間調(diào)用.

實(shí)驗(yàn)3通過(guò)對(duì)1000個(gè)txt格式文檔分別采用直接讀取文件方式、SequenceFile合并再讀取然后進(jìn)行詞頻統(tǒng)計(jì)，實(shí)驗(yàn)共進(jìn)行4次，每次采用不同內(nèi)容的txt文檔.測(cè)試原始HDFS和SequenceFile合并后讀取全部txt文檔的耗時(shí)開銷.

實(shí)驗(yàn)發(fā)現(xiàn)進(jìn)行詞頻統(tǒng)計(jì)需要讀取文件時(shí)，SequeceFile合并后產(chǎn)生的單個(gè)序列文件再進(jìn)行一次讀取平均只用了約12秒，而普通文本的全部讀取約12000秒，SequeceFile合并后的全部讀取時(shí)間是原始HDFS讀取耗時(shí)的1/1000左右.顯然對(duì)于txt文檔而言，先將其采取SequeceFile合并再一次讀取進(jìn)行詞頻統(tǒng)計(jì)的效率要遠(yuǎn)遠(yuǎn)高于普通文本的多次讀取.

5 結(jié)語(yǔ)

本文基于Hadoop海量小文件的存儲(chǔ)問(wèn)題，測(cè)試并總結(jié)三種合并方案在不同場(chǎng)景下的性能以及應(yīng)用方面的優(yōu)劣.Har合并能顯著減少NameNode節(jié)點(diǎn)上的元數(shù)據(jù)量，減輕NameNode內(nèi)存開銷，且Har合并最為常用，適用于眾多的文件格式.HBase主要對(duì)序列化到磁盤的文件進(jìn)行合并，以此達(dá)到提高小文件檢索速度；而且能提高復(fù)雜環(huán)境下數(shù)據(jù)檢索的速度，但是需要根據(jù)實(shí)際生產(chǎn)情況進(jìn)行配置才能達(dá)到很好的效果.SequenceFile針對(duì)的是數(shù)據(jù)文件的合并，從而快速提高M(jìn)apReuce作業(yè)對(duì)數(shù)據(jù)的讀取，適用于用于數(shù)據(jù)分析的應(yīng)用，例如天氣預(yù)測(cè)、用戶手機(jī)流量統(tǒng)計(jì)、詞頻統(tǒng)計(jì)等應(yīng)用.

［1］tom white.Hadoop權(quán)威指南（第三版）［M］北京:清華大學(xué)出版社，2015.2.

［2］HadoopArchives［OL］.http://hadoop.apache.org/docs/ r-1.2.1/hadoop_archives.html．

［3］SequenceFileWiki［OL］.http://wiki.apache.org/hadoop/ SequenceFile.

［4］Mapfiles［OL］.http://hadoop.apache.org/common/docs /current/api/org/apache/hadoop/io/MapFile.html．

［5］Liu,Xuhui,et al.Implementing WebGIS on Hadoop: A case study of improving small file I/O performance on HDFS［C］.2009IEEE International Conference on Cluster ComputingandWorkshops.IEEE,2009.

［6］Dong B,et al.A novel approach to improving the efficiency of storing and accessing small files on hadoop: a case study by powerpoint files［C］.Services Computing(SCC),2010IEEEInternationalConferenceon. IEEE,2010.

［7］馬志強(qiáng)，楊雙濤，閆瑞，張澤廣.SQL-DFS:一種基于HDFS的海量小文件存儲(chǔ)系統(tǒng)［J］.北京工業(yè)大學(xué)學(xué)報(bào)，2016.01.

［責(zé)任編輯：王曉軍］

Research and Design of Massive Small File Merging Based on Hadoop

PENG Jianfeng，WEI Weiguo，ZHENG Dongwei

（Guangdong Polytechnic Normal University，Guangzhou Guangdong 510665）

The research is based on consolidation of the massive small files storage on Hadoop.On the one hand,in order to reduce the metadata footprint in memory,the different solutions of Har,HBase and sequence were combined by using Eclipse development tools.On the other hand，we analysed the advantages and disadvantages of the performance and application of the three massive file merging solutions,and provided some valuable reference for the storage of massive small files on Hadoop.

Hadoop；HDFS；Small files；Metadata；Har；HBase；SequenceFile

TP 391

A

1672-402X（2016）11-0040-03

2016-05-20

廣東省公益研究與能力建設(shè)專項(xiàng)資金（2014A010103032）和廣東省科技型中小企業(yè)技術(shù)創(chuàng)新專項(xiàng)資金項(xiàng)目（2016A010120010、2014A010101109、2014A010101092）資助.

彭建烽(1991-)，男，廣東湛江人，2015級(jí)碩士研究生.研究方向：網(wǎng)絡(luò)信息技術(shù).

魏文國(guó)(1968-)，男，湖北公安人，博士，廣東技術(shù)師范學(xué)院教授，研究方向：計(jì)算機(jī)網(wǎng)絡(luò)及其應(yīng)用.