秦加偉　劉輝　方木云

摘 ?要：Hadoop存儲海量小文件將導(dǎo)致存儲和計算性能顯著下降。本文通過分析HDFS架構(gòu)提出了一種基于文件類型的小文件合并方法，即根據(jù)文件類型將相同類型的小文件合并為大文件，并建立小文件到合并文件的索引關(guān)系，索引關(guān)系存儲于HashMap中。為了進(jìn)一步提高文件讀取速度，建立了基于HashMap的緩存機(jī)制。實(shí)驗(yàn)表明該方法能顯著提高HDFS在存儲和讀取海量小文件時的整體性能。

關(guān)鍵詞：HDSF;HashMap;索引;合并;緩存

中圖分類號：TP3-0 ? ? 文獻(xiàn)標(biāo)識碼：A

Type-based Small File Merging Method on Big Data Platform

QIN Jiawei， LIU Hui， FANG Muyun

（School of Computer Science and Technology， Anhui University of Technology， Ma'anshan 243002， China）

738437340@qq.com; liuhui@ahut.edu.cn; fangmy@ahut.edu.cn

Abstract： Storage of large numbers of small files by Hadoop will lead to inefficiency in storage and computing performance. This paper proposes a small file merging method based on file type by analyzing the framework of HDFS （Hadoop Distributed File System）， that is to say， small files of the same type are merged into large ones， and an index relationship of small files to the merged files is established. The index relationship is stored in HashMap. In order to further improve the file reading speed， a cache mechanism based on HashMap is established. Experiments show that this method significantly improves the overall performance of HDFS when storing and reading massive small files.

Keywords： HDSF; HashMap; index; merge; cache

1 ? 引言（Introduction）

隨著互聯(lián)網(wǎng)和5G技術(shù)的快速發(fā)展，數(shù)據(jù)處理需求日漸提高，基于此，大數(shù)據(jù)[1]和云計算[2]技術(shù)應(yīng)運(yùn)而生。以Hadoop[3]為主的大數(shù)據(jù)處理平臺因其優(yōu)秀的穩(wěn)定性和高擴(kuò)展性而成為主流。Hadoop由HDFS（Hadoop Distributed File System）[4]、MR（MapReduce）[5]、YARN等構(gòu)成，其中HDFS負(fù)責(zé)存儲數(shù)據(jù)，MR負(fù)責(zé)處理數(shù)據(jù)。HDFS設(shè)計的目的是為了存儲并訪問超大文件。研究發(fā)現(xiàn)，F(xiàn)aceBook、Twitter、微信、QQ等社交軟件每天產(chǎn)生的社交數(shù)據(jù)總量都在PB級，而這些數(shù)據(jù)大多是一些KB級別的小文件，包含日志、照片、短消息等[6]。所謂小文件，目前沒有準(zhǔn)確的定義，一般意義上是指小于HDFS儲存塊（Hadoop1.x默認(rèn)64M，Hadoop2.X默認(rèn)128M）大小的文件，當(dāng)HDFS存儲海量小文件時，其性能會顯著降低。

2 ? HDFS存儲小文件的不足（The lack of HDFS to store small files）

HDFS是一個分布式多節(jié)點(diǎn)存儲集群架構(gòu)，有一個NameNode節(jié)點(diǎn)和多個DataNode節(jié)點(diǎn)構(gòu)成。NameNode節(jié)點(diǎn)用于管理HDFS的元數(shù)據(jù)信息。DataNode節(jié)點(diǎn)用于存儲實(shí)際的文件，DataNode以存儲塊的形式存儲數(shù)據(jù)，當(dāng)文件大于存儲塊時文件會分多個塊存儲于多個DataNode節(jié)點(diǎn)中。HDFS中無論文件多大，其在NameNode中存儲的元數(shù)據(jù)大致為150字節(jié)，固定大小的NameNode內(nèi)存決定了只能存儲固定數(shù)量的元數(shù)據(jù)。當(dāng)存儲的文件中小文件占大多數(shù)時將極大的消耗NameNode內(nèi)存，影響元數(shù)據(jù)的檢索速度，進(jìn)而顯著降低HDFS存取性能。

3 ? 相關(guān)研究工作（Related research work）

基于小文件問題，HDFS自身提供了四種解決方案，分別是Hadoop Archive方案[7]、CombineFileInputFormat方案[8]、

SequenceFile[9]方案和MapFile[10]方案。這些方案應(yīng)用場景較為廣泛但也存在一些問題，如Hadoop Archive（簡稱Har方法）合并后沒有刪除原文件且需運(yùn)行MapReduce合并文件、CombineFi-leInputFormat沒有真正合并小文件、SequenceFile沒有建立索引，讀取小文件只能遍歷，效率低、MapFile雖然添加了索引但沒有緩存機(jī)制且隨機(jī)讀取文件效率低。

一些學(xué)者針對小文件的問題也展開了相關(guān)研究。游小榮、曹晟基于教育資源小文件間的關(guān)聯(lián)關(guān)系提出了存儲優(yōu)化方案，即把同一課程的關(guān)聯(lián)小文件歸類合并成大文件并建立預(yù)取機(jī)制加快讀取速度[11]。趙曉永等提出一種基于Hadoop的海量MP3文件存儲架構(gòu)，利用MP3文件自身包含的豐富描述信息，通過歸類算法將相關(guān)性較強(qiáng)的文件合并為大文件，同時通過引入索引機(jī)制，加快了讀取文件的速度[12]。淘寶針對自己平臺產(chǎn)生的特定小文件，基于HDFS開發(fā)了TFS：Taobao File System[13]，以實(shí)現(xiàn)對小文件的高效存儲。

以上方案在一定程度能解決小文件所帶來的問題，但仍然存在一些問題。例如，一些方案只能針對特定的應(yīng)用場景，不具有普適性。另一些方案則能應(yīng)用在所有的應(yīng)用場景，但其做法通常是不考慮文件類型將所有文件全部合并，這將不利于合并后對小文件進(jìn)行分類管理和處理。基于此本文提出基于文件類型的小文件合并方法，即將大量小文件按照文件類型合并到各自類型的大文件中。

4 ? 解決方案（Solution）

本方案主要有四個模塊，即大小文件判斷模塊、分類合并模塊、建立索引模塊和索引緩存模塊。為了減小NameNode內(nèi)存壓力，本方案在文件上傳時需判斷大小文件，大小文件判定閾值目前沒有準(zhǔn)確的定義，大多數(shù)學(xué)者認(rèn)為小于存儲塊的文件即可認(rèn)為是小文件。以存儲塊大小作為判斷閾值顯然沒有試驗(yàn)做支撐，文獻(xiàn)[14]通過一系列測試得出閾值為4.35M，故本文沿用文獻(xiàn)[14]的結(jié)論以4.35M作為閾值。上傳的小文件一般包括多種類型，常見的有日志文件、文本文件以及圖片，具體的場景會有差異。文件合并模塊中需要為每一種類型的文件建立一個大的合并文件，上傳時根據(jù)文件的類型合并到該類型的合并文件中，并為每一種類型的合并文件建立索引。索引中存儲的是每個小文件在合并文件中的起始字節(jié)偏移量和文件字節(jié)長度，索引關(guān)系存儲在HashMap中，上傳完成后寫入到相應(yīng)的索引文件。為了進(jìn)一步提高讀取效率，本方案創(chuàng)建了基于HashMap的索引緩存模塊，該緩存模塊可以顯著提高查詢重復(fù)文件時的效率，小文件合并處理架構(gòu)如圖1所示。

4.1 ? 合并文件

客戶端向HDFS上傳文件時，首先在HDFS的上傳目錄中打開對應(yīng)文件類型的合并文件輸出流和創(chuàng)建用于保存合并文件索引關(guān)系的HashMap對象（在索引機(jī)制中詳細(xì)說明）。上傳文件時根據(jù)大小文件判斷閾值將文件分為大、小文件，大文件直接存儲于HDFS上傳目錄，小文件則根據(jù)其文件類型合并到該類型的合并文件中。合并完成后關(guān)閉合并文件輸出流并將保存有索引關(guān)系的HashMap對象寫入到上傳目錄，此時上傳目錄中只存在大文件和分類合并文件及其索引文件，文件合并流程如圖2所示。

4.2 ? 索引機(jī)制

在介紹索引機(jī)制前先介紹HashMap，HashMap是Java語言中的一種數(shù)據(jù)結(jié)構(gòu)。它的特點(diǎn)是以key-value對存儲，且通過key不需或經(jīng)過少量比較即可查詢到value，查詢value的速度幾乎不受HashMap長度的影響，在查詢大量數(shù)據(jù)時具有明顯的優(yōu)勢。HashMap對象可以通過對象流寫入文件和還原回內(nèi)存中的對象。可以根據(jù)這種特點(diǎn)應(yīng)用于存儲索引關(guān)系，由于其完全由Java語言內(nèi)置，可以極大地提高查詢效率。

HashMap支持泛型，其key和value的數(shù)據(jù)類型可自行指定。本文中key為文件名，故其類型指定為String，value需記錄小文件在合并文件中的起始字節(jié)偏移量和字節(jié)長度，故其為可記錄字節(jié)偏移量和長度的Info類類型。

為檢索合并文件中的小文件，在合并文件的過程需要建立每個小文件到合并文件的索引關(guān)系。即當(dāng)每一個小文件寫入到該類型的合并文件后，以該文件名為key，該小文件在合并文件中的字節(jié)偏移量和長度封裝為Info對象作為value添加到該類型的HashMap對象中，合并完成后將HashMap對象通過對象輸出流寫入到對應(yīng)類型的索引文件中，合并文件和索引文件的存儲結(jié)構(gòu)如圖3所示。

4.3 ? 緩存機(jī)制

在讀取文件時，最耗時的是通過文件名查找文件的索引信息，它需向NameNode發(fā)送讀取索引文件的請求，而后從相應(yīng)的DataNode中將索引文件還原為HashMap對象，并通過HashMap對象獲取索引信息。每次讀取文件都要經(jīng)過這一過程，這在查詢重復(fù)文件時效率較低。基于此本方案通過將歷史訪問的索引信息保存在內(nèi)存中的HashMap中，并記錄每個索引被緩存命中的次數(shù)，緩存容量的閾值N可以根據(jù)硬件配置自行指定，當(dāng)緩存容量超過閾值時將命中次數(shù)最少的索引信息移除。利用HashMap緩存在讀取重復(fù)文件時效率顯著提高且無論緩存容量多大，查詢?nèi)我馑饕男释瑯痈摺?/p>

4.4 ? 文件讀取

讀取文件時先根據(jù)閾值判斷大小文件，大文件直接通過原HDFS查找并讀取，小文件則先通過文件名在緩存中查找，如命中緩存則根據(jù)文件類型打開讀取目錄下該類型的合并文件并根據(jù)緩存中的索引信息讀取數(shù)據(jù)，緩存命中次數(shù)加1。如沒有命中緩存則根據(jù)文件類型打開讀取目錄下該類型的索引文件并將該文件還原為HashMap對象，根據(jù)文件名查找索引信息，獲取索引信息后即打開該類型的合并文件并讀取數(shù)據(jù)。由于緩存機(jī)制的存在，需將本次讀取的索引信息添加到內(nèi)存中的緩存HashMap中，因首次讀取該文件，故將緩存命中次數(shù)置為0，文件讀取流程如圖4所示。

5 ? 實(shí)驗(yàn)驗(yàn)證（Experimental verification）

本實(shí)驗(yàn)Hadoop版本為2.7.2，Hadoop運(yùn)行模式為偽分布式模式，操作系統(tǒng)為CentOS-6.8，數(shù)據(jù)塊副本數(shù)為3。計算機(jī)處理器Intel（R） Core（TM） i7-3540M @ 3.0GHz、內(nèi)存大小為8G、機(jī)械硬盤60G。本實(shí)驗(yàn)測試數(shù)據(jù)集為10000個文件，共包含為三類，第一類為文本文件，平均大小為100kB，占比57.18%。第二類為圖片文件，平均大小18kB，占比41.76%。第三類為視頻文件，平均大小6.8MB，占比1.06%。

將10000個文件隨機(jī)打亂，分成4組測試數(shù)據(jù)，每組數(shù)據(jù)量分別為2500、5000、7500和10000個。下面分別從寫入速度、NameNode內(nèi)存占用和讀取速度三個方面進(jìn)行比較。

5.1 ? 寫入速度測試

為驗(yàn)證本文方法在上傳速度上效率的提升，將四組文件分別通過本文方法、原HDFS方法及Har方法上傳至HDFS，分別記錄每組上傳所用的時間。每組每個方法實(shí)驗(yàn)進(jìn)行五次，并去除最大和最小值，取余下數(shù)據(jù)的平均值，實(shí)驗(yàn)結(jié)果如圖5所示。

由實(shí)驗(yàn)結(jié)果可知，本文方法所用時間遠(yuǎn)小于原HDFS及Har方法。其原因在于原HDFS客戶端每次上傳小文件時都要向NameNode發(fā)送寫文件請求，發(fā)送請求的時間遠(yuǎn)遠(yuǎn)大于寫入文件的時間，故其上傳速度最慢。Har方法上傳之前需要運(yùn)行MapReduce進(jìn)行合并，故其上傳速度介于原HDFS和本文方法之間。本文方法在上傳之前不需要運(yùn)行MapReduce且直接將合并文件寫入到HDFS中，所以其速度最優(yōu)。

5.2 ? NameNode內(nèi)存占用測試

為測試本文方法在NameNode內(nèi)存占用方面和原HDFS的差異，分別通過本文方法和原HDFS方法將4組文件上傳至HDFS。每組文件上傳完成之后記錄NameNode編輯日志edit_inprogress所占空間增長情況，實(shí)驗(yàn)結(jié)果如圖6所示。

由實(shí)驗(yàn)結(jié)果可以看出，本文方法在NameNode內(nèi)存占用方面擁有較好的性能。主要原因在于本文方法通過將小文件分類合并為大文件，在上傳至HDFS之后有效地減少了元數(shù)據(jù)的數(shù)量，進(jìn)而顯著降低了NameNode內(nèi)存占用量。

5.3 ? 讀取速度測試

為了驗(yàn)證本文方法在讀取文件速度方面和原HDFS及Har方法的差異，記錄每組讀取單位大小的文件所用的時間，每組實(shí)驗(yàn)進(jìn)行五次并去除最大和最小值，取余下數(shù)據(jù)的平均值。同時為了驗(yàn)證緩存機(jī)制對讀取文件時的影響，設(shè)置緩存容量閾值N為1000，實(shí)驗(yàn)結(jié)果如圖7所示。

實(shí)驗(yàn)結(jié)果表明，本文方法顯著優(yōu)于原HDFS和Har方法，在重復(fù)讀取時由于命中緩存，讀取時間進(jìn)一步縮短，且讀取時間不隨文件數(shù)量的增大而提高，在文件數(shù)量越多時優(yōu)勢越明顯。原因在于隨著HDFS存儲的小文件增多，HDFS檢索元數(shù)據(jù)的性能下降，而本文方法由于使用HashMap保存索引信息，在通過文件名查找索引信息時直接獲取，時間復(fù)雜度為O（1）。在讀取重復(fù)文件時，由于首次讀取已將索引信息添加到內(nèi)存中的HashMap對象中，再次讀取時直接從內(nèi)存中的HashMap中查詢索引信息，讀取效率進(jìn)一步提高。

6 ? 結(jié)論（Conclusion）

本文通過分析Hadoop存儲模塊HDFS的架構(gòu)并引出其存儲海量小文件的不足，進(jìn)而提出一種基于分類合并思想的改進(jìn)方案。即將小文件按照文件類型（擴(kuò)展名）分類合并為大文件，并為每一類型的合并文件添加索引，將索引保存在HashMap中，最終寫入到索引文件。同時為了進(jìn)一步提高讀取文件的速度，本方案設(shè)置了基于HashMap的緩存機(jī)制，即在內(nèi)存中緩存已讀文件的索引信息。實(shí)驗(yàn)表明，本方案在寫入速度、NameNode內(nèi)存占用，以及讀取速度上均顯著優(yōu)于原HDFS。

參考文獻(xiàn)（References）

[1] 馮貴蘭，李正楠，周文剛.大數(shù)據(jù)分析技術(shù)在網(wǎng)絡(luò)領(lǐng)域中的研究綜述[J].計算機(jī)科學(xué)，2019，46（06）：1-20.

[2] 王佳雋，呂智慧，吳杰，等.云計算技術(shù)發(fā)展分析及其應(yīng)用探討[J].計算機(jī)工程與設(shè)計，2010，31（20）：4404-4409.

[3] 夏靖波，韋澤鯤，付凱，等.云計算中Hadoop技術(shù)研究與應(yīng)用綜述[J].計算機(jī)科學(xué)，2016，43（11）：6-11;48.

[4] 郭建華，楊洪斌，陳圣波.基于HDFS的海量視頻數(shù)據(jù)重分布算法[J].計算機(jī)科學(xué)，2016，43（S1）：480-484.

[5] 李建江，崔健，王聃，等.MapReduce并行編程模型研究綜述[J].電子學(xué)報，2011，39（11）：2635-2642.

[6] 鄭通，郭衛(wèi)斌，范貴生.HDFS中海量小文件合并與預(yù)取優(yōu)化方法的研究[J].計算機(jī)科學(xué)，2017，44（S2）：516-519.

[7] 李三淼，李龍澍.Hadoop中處理小文件的四種方法的性能分析[J].計算機(jī)工程與應(yīng)用，2016，52（09）：44-49.

[8]劉斌.Hadoop小文件編程處理的性能優(yōu)化[J].工業(yè)控制計算機(jī)，2018，31（12）：47-48.

[9] 譚臺哲，向云鵬.Hadoop平臺下海量圖像處理實(shí)現(xiàn)[J].計算機(jī)工程與設(shè)計，2017，38（04）：976-980.

[10] 段隆振，洪新利，邱桃榮.基于MapFile的HDFS小文件存取優(yōu)化[J].南昌大學(xué)學(xué)報（工科版），2017，39（02）：175-178.

[11] 游小容，曹晟.海量教育資源中小文件的存儲研究[J].計算機(jī)科學(xué)，2015，42（10）：76-80.

[12] 趙曉永，楊揚(yáng)，孫莉莉，等.基于Hadoop的海量MP3文件存儲架構(gòu)[J].計算機(jī)應(yīng)用，2012，32（06）：1724-1726.

[13] 趙洋.淘寶TFS深度剖析[J].數(shù)字化用戶，2013，19（03）：58-59.

[14] Bo Dong， Qinghua Zheng， Feng Tian， et al. An optimized approach for storing and accessing small files on cloud storage[J]. Journal of Network and Computer Applications， 2012， 35（6）： 1847-1862.

作者簡介：

秦加偉（1995-），男，碩士生.研究領(lǐng)域：大數(shù)據(jù)，大數(shù)據(jù)分析.

劉 ?輝（1979-），男，碩士，副教授.研究領(lǐng)域：軟件工程，信息系統(tǒng).

方木云（1968-），男，博士，教授.研究領(lǐng)域：軟件工程，信息系統(tǒng).