基于Hadoop的海量小文件存儲(chǔ)方法的研究

時(shí)倩　方?！≡懒痢∨碛芊?/p>

摘要：隨著科學(xué)技術(shù)的發(fā)展，各行業(yè)及領(lǐng)域需要處理的數(shù)據(jù)呈爆炸式增長(zhǎng)。Hadoop是大文件存儲(chǔ)處理的理想平臺(tái)，但Hadoop在處理海量小文件時(shí)的表現(xiàn)并不令人滿意。本文首先對(duì)HDFS的系統(tǒng)架構(gòu)作了簡(jiǎn)要介紹，進(jìn)而分析了HDFS處理海量小文件時(shí)存在的問題，最后介紹了目前國(guó)內(nèi)外對(duì)該問題提出的優(yōu)化方案。

關(guān)鍵詞：HDFS 海量數(shù)據(jù) 小文件 存儲(chǔ)優(yōu)化

中圖分類號(hào)：TP333 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1007-9416（2014）01-0050-02

1 引言

Hadoop[1]是由Apache基金會(huì)研發(fā)的能夠?qū)Ａ繑?shù)據(jù)進(jìn)行分布式處理的基礎(chǔ)框架，是海量數(shù)據(jù)存儲(chǔ)與處理的理想平臺(tái)。然而由于Hadoop采用流式方式讀寫文件，對(duì)于大文件處理效率極高，但對(duì)小文件處理效果并不是很好。當(dāng)處理如氣象數(shù)據(jù)這種海量小文件時(shí)，Hadoop的優(yōu)勢(shì)并不能展示出來，故需要對(duì)小文件的存儲(chǔ)進(jìn)行優(yōu)化。

2 HDFS的系統(tǒng)架構(gòu)

HDFS是Hadoop的分布式文件系統(tǒng)，其具有高容錯(cuò)性的特點(diǎn)，設(shè)計(jì)用來部署在低廉硬件上，能夠提供極高的數(shù)據(jù)吞吐量，適合那些有著超大數(shù)據(jù)集的應(yīng)用程序[2]，因而成為了云存儲(chǔ)平臺(tái)的代表性系統(tǒng)。

HDFS采用主從架構(gòu)，由一個(gè)名稱節(jié)點(diǎn)和多個(gè)數(shù)據(jù)節(jié)點(diǎn)組成。名稱節(jié)點(diǎn)是HDFS的主服務(wù)器，主要負(fù)責(zé)管理元數(shù)據(jù)和數(shù)據(jù)塊、持久化元數(shù)據(jù)、處理請(qǐng)求及管理數(shù)據(jù)節(jié)點(diǎn)，數(shù)據(jù)節(jié)點(diǎn)主要負(fù)責(zé)數(shù)據(jù)塊的讀寫、向名稱節(jié)點(diǎn)報(bào)告狀態(tài)及執(zhí)行數(shù)據(jù)的流水線復(fù)制?？蛻舳送ㄟ^與名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)的交互來訪問整個(gè)文件系統(tǒng)。

3 HDFS處理海量小文件存在的問題

HDFS設(shè)計(jì)用來對(duì)大文件進(jìn)行流式存儲(chǔ)，在處理小文件時(shí)會(huì)產(chǎn)生一些問題[3]。小文件是指文件大小小于HDFS塊大?。J(rèn)為64MB）的文件，大量的小文件會(huì)嚴(yán)重影響Hadoop的性能及其擴(kuò)展性。首先，海量小文件大量耗費(fèi)名字節(jié)點(diǎn)的內(nèi)存。每個(gè)小文件作為一個(gè)塊存儲(chǔ)，海量數(shù)據(jù)塊的元數(shù)據(jù)信息會(huì)占用大量?jī)?nèi)存，這樣名稱節(jié)點(diǎn)的內(nèi)存容量會(huì)嚴(yán)重制約集群的擴(kuò)展。其次，海量小文件的存取效率低。大量小文件寫入HDFS時(shí)需頻繁請(qǐng)求名稱節(jié)點(diǎn)分配數(shù)據(jù)塊，讀取大量小文件時(shí)需頻繁請(qǐng)求數(shù)據(jù)節(jié)點(diǎn)以獲取文件，嚴(yán)重影響了名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)的I/O性能。

4 HDFS小文件問題優(yōu)化方案

4.1 Hadoop自帶的解決方案

對(duì)于小文件問題，Hadoop自身提供了以下三種解決方案。

4.1.1 Hadoop Archive（HAR）

HAR文件歸檔技術(shù)用來緩解大量小文件消耗名稱節(jié)點(diǎn)內(nèi)存的問題。HAR在HDFS上構(gòu)建一個(gè)層次化的文件系統(tǒng)，通過將小文件打包成HAR文件來減少HDFS中的文件數(shù)量，從而提高HDFS元數(shù)據(jù)的存儲(chǔ)效率。但讀取HAR中的文件需讀取兩層index文件及讀取文件本身數(shù)據(jù)，并且HAR不支持存檔文件的壓縮，因此使用HAR處理小文件效率較低。

4.1.2 Sequence File

SequenceFile是HDFS提供的一種二進(jìn)制文件技術(shù)，通過將對(duì)序列化到SequenceFile文件，實(shí)現(xiàn)多個(gè)小文件的合并存儲(chǔ)，合并同時(shí)還支持基于數(shù)據(jù)塊的壓縮，顯著減少了名稱節(jié)點(diǎn)的內(nèi)存及數(shù)據(jù)節(jié)點(diǎn)的磁盤空間。但這種方法沒有建立相應(yīng)的小文件到大文件的映射，查找小文件需遍歷整個(gè)SequenceFile文件，讀取效率較低。

4.1.3 CombineFileInputFormat

CombineFileInputFormat是一種新的輸入格式，用于將多個(gè)文件合并成一個(gè)單獨(dú)的split，另外它會(huì)考慮數(shù)據(jù)的存儲(chǔ)位置。對(duì)于HDFS中已經(jīng)存在大量小文件的情況比較適用。但CombineFileInputFormat是一個(gè)抽象類，沒有提供實(shí)體類，所以使用的時(shí)候需要一些額外的工作，在實(shí)踐中使用較少。

4.2 HDFS小文件問題的優(yōu)化方案

針對(duì)HDFS處理海量小文件的問題，一些相應(yīng)的優(yōu)化方案在研究中被相繼提出。

4.2.1 通用技術(shù)方案

江柳[4]提出下放名稱節(jié)點(diǎn)的權(quán)限給數(shù)據(jù)節(jié)點(diǎn)的方法。其基本思路是將名稱節(jié)點(diǎn)的部分權(quán)限下放到數(shù)據(jù)節(jié)點(diǎn)上，在數(shù)據(jù)節(jié)點(diǎn)上緩存部分小文件元數(shù)據(jù)信息，讓數(shù)據(jù)節(jié)點(diǎn)處理絕大多數(shù)小文件的讀寫請(qǐng)求，從而最大限度的減輕名稱節(jié)點(diǎn)的負(fù)擔(dān)。

李寬[5]提出了采用分布式名稱節(jié)點(diǎn)模型來處理HDFS的單節(jié)點(diǎn)瓶頸及擴(kuò)展性問題。文章提出了一種二級(jí)元數(shù)據(jù)分布算法，將元數(shù)據(jù)信息分離成目錄信息和數(shù)據(jù)位置信息兩部分，采用不同的分布策略進(jìn)行分布。該方法在保證高效率的元數(shù)據(jù)服務(wù)的基礎(chǔ)上，考慮了元數(shù)據(jù)的負(fù)載均衡性和擴(kuò)展性，并提出名稱節(jié)點(diǎn)集群中元數(shù)據(jù)的可靠性機(jī)制。

4.2.2 WebGIS優(yōu)化方案

文獻(xiàn)[6]針對(duì)WebGIS系統(tǒng)的特點(diǎn)提出了解決HDFS小文件問題的方案。WebGIS是結(jié)合Web和地理信息系統(tǒng)（GIS）而誕生的一種新系統(tǒng)。在WebGIS中，為了使瀏覽器和服務(wù)器之間傳輸?shù)臄?shù)據(jù)量盡可能少，通常將數(shù)據(jù)切分為KB大小的文件存儲(chǔ)在分布式系統(tǒng)中。Liu等結(jié)合WebGIS數(shù)據(jù)的相關(guān)特征，將相鄰地理位置的小文件合并成一個(gè)大的文件，并為這些文件構(gòu)建索引以便對(duì)小文件進(jìn)行存取。文獻(xiàn)中將小于16MB的文件作為小文件進(jìn)行合并處理，將其合并成64MB大小的數(shù)據(jù)塊并構(gòu)建索引。

4.2.3 BlueSky解決方案

Bo Dong等[7]基于BlueSky在線教育資源分享系統(tǒng)的應(yīng)用提出了一種新的改善Hadoop中小文件存儲(chǔ)和訪問效率的方法。BlueSky系統(tǒng)主要存放教學(xué)用的PPT文件和視頻文件，用戶對(duì)文件的請(qǐng)求具有很強(qiáng)的關(guān)聯(lián)性，當(dāng)用戶瀏覽PPT時(shí)，其他相關(guān)的PPT和文件也會(huì)在短時(shí)間內(nèi)被訪問。文獻(xiàn)主要提出了兩個(gè)基本思路：1）將相關(guān)的小文件合并成一個(gè)大文件，從而減輕名稱節(jié)點(diǎn)的內(nèi)存壓力，提高小文件的存儲(chǔ)效率；2）通過索引文件和數(shù)據(jù)文件的預(yù)取機(jī)制提高小文件的讀取效率。索引文件預(yù)取是指當(dāng)用戶訪問某個(gè)文件時(shí)，將文件所在數(shù)據(jù)塊對(duì)應(yīng)的索引文件加載到內(nèi)存，用戶訪問這些文件時(shí)不必再與名稱節(jié)點(diǎn)交互。數(shù)據(jù)文件預(yù)取是指用戶訪問某個(gè)文件時(shí)，將該文件所在課件中的所有文件加載到內(nèi)存，若用戶繼續(xù)訪問本課件的其他文件，速度會(huì)明顯提高。

4.2.4 MP3文件解決方案

趙曉永等[8]提出了一種基于Hadoop的海量MP3文件存儲(chǔ)架構(gòu)。該架構(gòu)利用MP3文件自身包含的豐富的描述信息，通過在預(yù)處理模塊中使用歸類算法，將相關(guān)性強(qiáng)的文件合并為序列文件，能夠大量減少HDFS中的文件數(shù)量；同時(shí)引入高效的擴(kuò)展一級(jí)索引機(jī)制，用來快速定位到MP3文件所在的序列文件及其偏移位置；另外在富元數(shù)據(jù)管理模塊中將MP3文件的富元信息進(jìn)行集中索引和管理，從而解決Hadoop處理小文件時(shí)名稱節(jié)點(diǎn)的內(nèi)存瓶頸問題。該方法具備良好的性能，能夠支撐大規(guī)模用戶的并發(fā)訪問。

5 結(jié)語

Hadoop目前還沒有一個(gè)系統(tǒng)級(jí)的通用的解決HDFS小文件問題的方案。第4章提到的Hadoop自帶的解決方案各有優(yōu)缺點(diǎn)，通用技術(shù)方案應(yīng)用到不同環(huán)境時(shí)效果也不盡相同，針對(duì)具體應(yīng)用場(chǎng)景提出的解決方案具有一定局限性，對(duì)其他應(yīng)用系統(tǒng)具有借鑒意義但并不能搬用。針對(duì)Hadoop中海量小文件存儲(chǔ)優(yōu)化的問題還值得進(jìn)一步的深入研究。

參考文獻(xiàn)

[1]Hadoop[EB/OL].http：//Hadoop.apache.org，2012.

[2]周敏奇，王曉玲，金澈清，錢衛(wèi)寧.Hadoop權(quán)威指南（第2版）[M].北京：清華大學(xué)出版社，2011.

[3]Small files problem[EB/OL].http：//www.cloudera.com/blog/2009/02/the-small-files-problem.

[4]江柳.HDFS下小文件存儲(chǔ)優(yōu)化相關(guān)研究[D].北京：北京郵電大學(xué)，2010.

[5]李寬.基于HDFS的分布式名稱節(jié)點(diǎn)節(jié)點(diǎn)模型的研究[D].廣州：華南理工大學(xué)，2011.

[6]Xuhui Liu，Jizhong Han，Yunqin Zhong，et al. Implementing WebGIS on Hadoop：a case study of improving small file I/O performance on HDFS[C].Proc.of the 2009 IEEE Conf.on Cluster Computing：1-8.

[7]Bo Dong，Jie Qiu，Qinghua Zheng，et al.A novel approach to improving the efficiency of storing and accessing small files on Hadoop：a case study by powerpoint files[C].In Proceedings of IEEE SCC，2010.

[8]趙曉永，楊揚(yáng)，孫莉莉，陳宇.基于Hadoop的海量MP3文件存儲(chǔ)架構(gòu)[J].計(jì)算機(jī)應(yīng)用技術(shù)，2012，32（6）：1724-1726.