Hadoop中海量小文件的處理分析

摘 要：論文將通過具體設(shè)計，提出一個行之有效的處理分析Hadoop中海量小文件的應(yīng)用方法。

關(guān)鍵詞：Hadoop 海量小文件 索引 算法

中圖分類號：TP391 文獻(xiàn)標(biāo)識碼：A 文章編號：1672-3791（2012）10（a）-0013-01

目前，國內(nèi)外很多大型企業(yè)和機(jī)構(gòu)都采用Hadoop技術(shù)處理規(guī)模巨大的數(shù)據(jù)，但是如何高效穩(wěn)定地處理好伴隨大數(shù)據(jù)而產(chǎn)生的各類海量小文件就成了一個決定系統(tǒng)穩(wěn)定、數(shù)據(jù)可靠與否的重要依據(jù)。本文將根據(jù)個人研究淺談一下海量小文件的處理分析。

1 Hadoop中海量小文件處理存在的問題

1.1 海量的小文件堆積造成系統(tǒng)節(jié)點內(nèi)存不足

我們知道在HDFS整合數(shù)據(jù)時，是將數(shù)據(jù)分割成若干塊存儲在多個數(shù)據(jù)節(jié)點上的。因此，HDFS存儲的大文件都是被分成許多塊分?jǐn)偝鋈サ?。由此，不可避免的就會產(chǎn)生很多尺寸小，甚至比Hadoop應(yīng)用中默認(rèn)分塊小很多的小文件，這些文件被認(rèn)為是不可以分塊的而被保留在了各個數(shù)據(jù)節(jié)點上。當(dāng)這些海量小文件達(dá)到一定規(guī)模后就會淹沒數(shù)據(jù)節(jié)點的內(nèi)存從而造成硬件內(nèi)存供應(yīng)不足的現(xiàn)象。

1.2 海量小文件的檢索效率低

由于Hadoop的分布式存儲對象是海量的廉價計算機(jī)，因此存儲系統(tǒng)中數(shù)據(jù)節(jié)點的內(nèi)存限制也對可存放的文件數(shù)量造成了制約，從而增加了系統(tǒng)管理的難度。一但某一數(shù)據(jù)節(jié)點上出現(xiàn)了海量小文件，文件的檢索效率就會急劇下降，當(dāng)小文件的數(shù)量達(dá)到一定規(guī)模后，甚至可能導(dǎo)致數(shù)據(jù)節(jié)點崩潰。

2 Hadoop中海量小文件的處理分析方法

2.1 構(gòu)建海量小文件分析處理架構(gòu)

文件→合并→建立索引→分布存儲。

將數(shù)據(jù)節(jié)點中的數(shù)據(jù)分成兩種塊形式。一種是存儲小文件的文件塊，一種是存儲索引的檢索塊。本架構(gòu)的核心主要是處理分布式存儲小文件的單位數(shù)據(jù)。主要實現(xiàn)的一個過程是，先將數(shù)據(jù)節(jié)點上的海量小文件合并，寫入數(shù)據(jù)節(jié)點，再利用Map/Reduce對存儲在塊中的小文件分類并創(chuàng)建索引，然后將索引分布式存儲在數(shù)據(jù)節(jié)點上。

2.2 設(shè)計海量小文件合并算法

以時間作為合并的依據(jù)，創(chuàng)建以時間作為文件名字段的大文件，就能有效地應(yīng)用Hadoop技術(shù)合理地生成系統(tǒng)可處理的塊文件。合并的設(shè)計算法如下：

小文件結(jié)構(gòu)：LFile

String LFile_Name//小文件名

String LFile_Content//小文件內(nèi)容，以字符型存儲

DateTime LFile_Time//小文件創(chuàng)建時間

Int Flag //小文件結(jié)尾標(biāo)志符，如果為1，表示文件被刪除；如果為0則表示文件存在，標(biāo)志符初始值為0

合并文件結(jié)構(gòu)：CFile

String CFile_Name//合并文件名，含創(chuàng)建文件的時間信息

String CFile_Content//合并文件內(nèi)容，包含每個小文件的名字、創(chuàng)建時間、內(nèi)容及結(jié)尾標(biāo)志符

DateTime CFile_Time//合并文件創(chuàng)建時間

Input： 小文件的結(jié)構(gòu)體

Output：

Open（CFile[0]）；

int i=0；//用于小文件的計數(shù)

While （T1

//定義時間字段T1，獲取小文件的生成時間；合并文件的創(chuàng)建時間其實就是我們定義的小文件合并的結(jié)束時間，一般取時間區(qū)間為1小時，即：T2=T1+3600s

{WriteLine（LFile[i]）；

If（！LFile[i]. Flag）

{Write the rest of LFile[i]；}

i++；}

Close（CFile[0]）；

CFile.CFile_Name=（Char）T1；

Return；

如上算法，每寫入一個小文件都有時間閥的判斷，則1小時內(nèi)所需合并的n個小文件就有n次while的循環(huán)。其時間復(fù)雜度為n，空間復(fù)雜度為1。

2.3 設(shè)計海量小文件索引方法

由于海量小文件的增長是動態(tài)、不規(guī)律的，因此在無法確定每個父節(jié)點下的孩子數(shù)量的情況下，使用節(jié)省內(nèi)存的孩子兄弟表示法就無法滿足要求。而Trie樹型的每個節(jié)點都有唯一的父節(jié)點，如果選擇雙親表示法就能唯一確定節(jié)點的指針域，從而便于磁盤存儲，使得內(nèi)存分配更為規(guī)則。

要提高海量小文件的索引效率，僅僅建立一級索引是遠(yuǎn)遠(yuǎn)不夠的，因此在將一級索引建立在數(shù)據(jù)節(jié)點的基礎(chǔ)上，為了避免在調(diào)用索引時的頁面頻繁替換所造成的磁盤損壞和大量耗時，我們在一級索引的基礎(chǔ)上在數(shù)據(jù)節(jié)點內(nèi)存中保存二級索引。這樣就能在每個數(shù)據(jù)節(jié)點上調(diào)用一個二級索引，而不會出現(xiàn)每個數(shù)據(jù)塊都建立二級索引。從而提高索引效率。

索引的構(gòu)建過程主要分為三大塊。

（1）利用Map任務(wù)對海量小文件創(chuàng)建并行索引；

（2）利用Reduce任務(wù)對所有小索引進(jìn)行合并整理，形成能夠索引小文件的大索引。

（3）將文件擴(kuò)展名放入名稱節(jié)點，并將擴(kuò)展名下的索引文件分塊寫入對應(yīng)的數(shù)據(jù)節(jié)點中。

2.4 設(shè)計海量小文件分塊方法

海量小文件分塊就是將全局索引根據(jù)數(shù)據(jù)節(jié)點上塊的大小進(jìn)行分割，確保每個索引的完整性，使得文件查找過程中盡可能的節(jié)省索引次數(shù)。根據(jù)每個分割好的索引合理分配塊的位置，使其存儲在對應(yīng)文件的相鄰節(jié)點上，減少通訊過長造成的代價損失。分塊遵循“塊中所有文件都具有相同擴(kuò)展名”這一原則。具體算法如下：

Int c1=0；//計數(shù)器

Int S；//樹的大小

Int BMax；//塊的最大值

Int BMin；//塊的最小值

If （S

{

If （S

{

While（c1

{

Read next tree；//讀取下一顆樹

c1+=S；//合并樹

If （c1>=BMax）

{Split（type 1，tree T，int Offset）；//分裂樹}

}

Write into Block； //將樹放進(jìn)塊中

}

}

Else

{Split（type 1，tree T，int Offset）；//分裂樹}

如上分塊算法能將某個擴(kuò)展名下的樹都寫入塊中，不論同一擴(kuò)展名下的樹是否寫滿都不再寫入，這樣才能使索引效率最大化。

3 結(jié)語

本文的研究工作有一定的借鑒作用，同時也存在了諸多不足之處。在未來的研究過程中，將探索Hadoop中小文件的更新方法，尤其是基于批量索引的更新將是一個復(fù)雜的過程。并結(jié)合實際環(huán)境進(jìn)行真實系統(tǒng)測試。

參考文獻(xiàn)

[1] ZDNet，Nasuni Cloud Storage Gateway By Dan Kusnetzky，June 1，2010.

[2] Hussam Abu-Libdeh，Lonnie Princehouse，Hakim Weatherspoon， RACS：a case for cloud storage diversity，2010.

[3] Cong Wang，Qian Wang，Kui Ren， Wenjing Lou，Ensuring data storage security in Cloud Computing，2009.