基于Hadoop的小文件存儲(chǔ)優(yōu)化方案

李 孟，曹 晟，秦志光(電子科技大學(xué)計(jì)算機(jī)科學(xué)與工程學(xué)院 成都 611731)

?

基于Hadoop的小文件存儲(chǔ)優(yōu)化方案

李 孟，曹 晟，秦志光
(電子科技大學(xué)計(jì)算機(jī)科學(xué)與工程學(xué)院 成都 611731)

【摘要】Hadoop作為成熟的分布式云平臺(tái)，對(duì)較大的文件提供了可靠高效的存儲(chǔ)服務(wù)，但在處理海量小文件時(shí)效率顯著降低。該文提出了基于Hadoop的海量教育資源小文件的存儲(chǔ)優(yōu)化方案，利用教育資源小文件間的關(guān)聯(lián)關(guān)系，將小文件進(jìn)行合并成大文件以減少文件數(shù)量，并索引機(jī)制訪問(wèn)小文件、元數(shù)據(jù)緩存和關(guān)聯(lián)小文件預(yù)取機(jī)制來(lái)提高文件的讀取效率。實(shí)驗(yàn)結(jié)果表明，該方法提高了Hadoop文件系統(tǒng)存儲(chǔ)小文件的存取效率。

關(guān) 鍵 詞Hadoop; 索引機(jī)制; 關(guān)聯(lián)關(guān)系; 小文件存儲(chǔ)

Storage Optimization Method of Small Files Based on Hadoop

LI Meng, CAO Sheng, and QIN Zhi-guang
(School of Computer Science and Engineering, University of Electronic Science and Technology of China Chengdu 611731)

Abstract Hadoop distributes file system (HDFS) can process large amounts of data effectively through large clusters. However, HDFS is designed to handle large files and suffers performance penalty while dealing with large number of small files. An approach based on HDFS is proposed to improve storage efficiency of small files in HDFS. The main idea is to classify the mass small files, merge them by classes, and index the merged files aiming at reducing the amount of index items in namenodes and improving the storage efficiency. Experimental results show that the storage efficiency of small files is improved contrasting to Hadoop Archives (HAR files).

Key words Hadoop; index mechanism; relationship; storage of small files

HDFS(hadoop distributed file system)是一個(gè)具有高容錯(cuò)性、成本低廉性等特點(diǎn)的分布式文件系統(tǒng)。在實(shí)際應(yīng)用中，小文件的數(shù)量遠(yuǎn)遠(yuǎn)多于大文件的數(shù)量。尤其是在互聯(lián)網(wǎng)應(yīng)用中，諸如網(wǎng)頁(yè)中的圖片、文檔以及包括其他的數(shù)據(jù)信息xml文件等多數(shù)為小文件。 HDFS設(shè)計(jì)來(lái)對(duì)大文件進(jìn)行流式存儲(chǔ)，在處理小文件時(shí)會(huì)產(chǎn)生一些問(wèn)題。因此，如何高效地存儲(chǔ)和處理大量的小文件成為一個(gè)研究熱點(diǎn)[1-3]。

HDFS對(duì)于處理海量小文件的存儲(chǔ)有以下不足：1) 海量小文件耗費(fèi)主節(jié)點(diǎn)內(nèi)存，可能造成NAMEDODE瓶頸問(wèn)題；2) 海量小文件的I/O效率低，沒(méi)有一種優(yōu)化機(jī)制來(lái)提高I/O性能；3) HDFS下沒(méi)有明確的能夠區(qū)分何為小文件的分界點(diǎn)；4) 沒(méi)有考慮海量小文件之間的相關(guān)性等。

本文所提的教育資源小文件包括各種形式的教育資源，如word文檔、pdf文檔、ppt課件及文件資料等，只要和教育資源相關(guān)的內(nèi)容且大小遠(yuǎn)小于Hadoop的存儲(chǔ)塊64 MB的文件都可稱為教育資源小文件。這類文件具有3個(gè)特點(diǎn)：1) 這些文件通常在幾十到幾百KB，和Hadoop的存儲(chǔ)塊大小64 MB相比較?。?) 小文件之間有關(guān)聯(lián)性，整理歸檔同類課程的小文件然后進(jìn)行合并；3) 小文件的數(shù)量很多，因?yàn)榫W(wǎng)絡(luò)中存在的各種學(xué)習(xí)資源量非常大，且不斷地以指數(shù)級(jí)速度增長(zhǎng)。

1 相關(guān)工作

針對(duì)小文件在HDFS中存儲(chǔ)出現(xiàn)的問(wèn)題，目前出現(xiàn)了許多的解決方案[4-10]，歸納起來(lái)主要分為：

1) 第一類都對(duì)寫(xiě)入的小文件進(jìn)行緩沖，將緩沖的多個(gè)小文件合并為一個(gè)臨時(shí)文件，將臨時(shí)文件的元數(shù)據(jù)和數(shù)據(jù)對(duì)象存儲(chǔ)至元數(shù)據(jù)服務(wù)器節(jié)點(diǎn)和數(shù)據(jù)服務(wù)器節(jié)點(diǎn)的后端存儲(chǔ)中，從而可以有效地提高集群文件系統(tǒng)服務(wù)的響應(yīng)時(shí)間和速度，提升數(shù)據(jù)整體的單位時(shí)間數(shù)據(jù)讀寫(xiě)次數(shù)、吞吐量。

2) 第二類針對(duì)機(jī)群文件系統(tǒng)中的小文件提出新的存儲(chǔ)和訪問(wèn)，步驟為：① 設(shè)置閾值，區(qū)分大小文件；② 在元數(shù)據(jù)服務(wù)器上，存儲(chǔ)小文件的數(shù)據(jù)；③ 在元數(shù)據(jù)服務(wù)器上進(jìn)行小文件創(chuàng)建、讀寫(xiě)和刪除。由于把小文件的數(shù)據(jù)存儲(chǔ)在元數(shù)據(jù)服務(wù)器上，這樣對(duì)于小文件的IO訪問(wèn)操作，如創(chuàng)建、讀寫(xiě)和刪除等，發(fā)起IO訪問(wèn)的客戶端只需要與元數(shù)據(jù)服務(wù)器交互，無(wú)需與數(shù)據(jù)服務(wù)器交互，減少了小文件訪問(wèn)的網(wǎng)絡(luò)延遲，提高了小文件IO的性能，從而從整體上提高了機(jī)群文件系統(tǒng)的IO性能。

3) 第三類面向大批量文件數(shù)據(jù)存取方法，包括將所有小文件的數(shù)據(jù)合并成一個(gè)大文件；建立每個(gè)小文件的文件名及其文件編號(hào)的一一對(duì)應(yīng)關(guān)系；建立每個(gè)所述文件編號(hào)與小文件的文件信息的對(duì)應(yīng)關(guān)系，文件信息包括所述小文件在所述大文件中的位置。相應(yīng)地，還公開(kāi)一種大批量文件數(shù)據(jù)讀取方法，用于讀取按照本文的存放方法存放的文件數(shù)據(jù)，包括有：根據(jù)小文件的文件名來(lái)獲得所述小文件的文件編號(hào)；根據(jù)所述文件編號(hào)獲得所述小文件的文件信息；根據(jù)所述文件信息獲得所述小文件在大文件中的位置；根據(jù)所述小文件在大文件中的位置，通過(guò)所述大文件的IO接口實(shí)現(xiàn)對(duì)所述小文件數(shù)據(jù)的讀取。

上述現(xiàn)有解決小文件存儲(chǔ)問(wèn)題的專利技術(shù)方案存在以下問(wèn)題：1) 已有小文件存儲(chǔ)效率的研究主要集中在非云存儲(chǔ)的文件系統(tǒng)上，而不是針對(duì)云存儲(chǔ)環(huán)境下的分布式文件系統(tǒng)，即Hadoop分布式文件系統(tǒng)上的存儲(chǔ)優(yōu)化方法；2) 現(xiàn)有方法雖然提出了合并小文件的方法，但在合并時(shí)沒(méi)有考慮文件之間的關(guān)聯(lián)關(guān)系，且合并后讀取文件時(shí)所增加的索引查詢會(huì)影響文件的讀取效率。

2 本文方法

本文提出了一種基于Hadoop的海量可歸類小文件關(guān)聯(lián)存儲(chǔ)方法，主要解決可歸類小文件的存取效率問(wèn)題。針對(duì)屬于某一類別的獨(dú)立的小文件進(jìn)行文件聚合和全局索引管理，大幅度提高了內(nèi)存利用率，提高單位內(nèi)存支持的最大文件數(shù)量。

2.1 文件歸并

1) 將屬于某個(gè)大文件的所有小文件歸并為一個(gè)文件，稱為merged file；

2) 對(duì)每個(gè)merged file建立一個(gè)局部索引，并在上傳時(shí)將局部索引文件與文件實(shí)體一同存放在Hadoop系統(tǒng)的DataNode上；

3) 在讀取非獨(dú)立小文件時(shí)，采用元數(shù)據(jù)緩存、局部索引文件預(yù)取和關(guān)聯(lián)文件預(yù)取提高文件的讀取效率。

為每一個(gè)merged file建立一個(gè)局部索引文件，記錄屬于該merged file的所有小文件的起始位置和長(zhǎng)度，局部索引文件位于該merged file的每一個(gè)塊的起始位置，并且只為該merged file服務(wù)。

1) 局部索引文件結(jié)構(gòu)

局部索引文件采用靜態(tài)查找表結(jié)構(gòu)，由索引頭部、序列索引和文件索引3部分構(gòu)成；其中索引頭部由占1字節(jié)的版本號(hào)、占4字節(jié)的索引項(xiàng)數(shù)和占4字節(jié)的局部索引文件長(zhǎng)度組成；序列索引由占4字節(jié)的序列名稱、占4字節(jié)的文件索引的起始編號(hào)和占4字節(jié)的文件索引項(xiàng)數(shù)構(gòu)成；文件索引項(xiàng)由占16字節(jié)的文件名稱、占4字節(jié)的文件長(zhǎng)度和占4字節(jié)的文件偏移構(gòu)成；

2) 讀文件時(shí)對(duì)局部索引文件的操作

首先根據(jù)merged file名從NameNode獲取元數(shù)據(jù)；然后由merged file的元數(shù)據(jù)，從Hadoop文件系統(tǒng)的相應(yīng)DataNode讀取指定的數(shù)據(jù)塊，并根據(jù)數(shù)據(jù)塊內(nèi)索引文件長(zhǎng)度項(xiàng)讀取數(shù)據(jù)塊的局部索引文件；最后根據(jù)小文件名稱，查找局部索引文件，獲得該小文件的起始位置和長(zhǎng)度，從而完成對(duì)小文件的讀操作。當(dāng)該merged file的小文件數(shù)目少于1 000 時(shí)，采用順序查找方法；當(dāng)小文件的數(shù)目超過(guò)1 000 時(shí)，順序查找會(huì)影響讀取性能，在文件索引上建立序列索引，避免查詢的開(kāi)銷過(guò)大；如果是一級(jí)索引格式，則從局部索引文件中第一個(gè)目錄項(xiàng)開(kāi)始，與請(qǐng)求小文件名稱逐條對(duì)比，若文件索引項(xiàng)的小文件名稱符合，則查找成功，返回該小文件索引記錄；否則，繼續(xù)查找直至最后一個(gè)記錄項(xiàng)，若沒(méi)有記錄項(xiàng)合，則返回小文件名查找失敗。

如果是兩級(jí)索引格式，則查找分為兩個(gè)階段：首先根據(jù)待查小文件的序列名稱，在序列索引表中查找序列，如果索引表內(nèi)沒(méi)有記錄項(xiàng)，則表明該序列不存在；否則根據(jù)序列指定的位置，開(kāi)始順序查找文件索引位置。

文件歸并操作在Hadoop文件系統(tǒng)的客戶端上進(jìn)行，將屬于同一個(gè)大文件的所有小文件合并成一個(gè)文件；具體步驟如下：

1) 計(jì)算非獨(dú)立小文件總數(shù)，根據(jù)文件的數(shù)目決定采用文件索引還是采用序列索引+文件索引，由于索引每項(xiàng)長(zhǎng)度固定，計(jì)算得出局部索引文件的長(zhǎng)度，用Lindex表示，過(guò)程如下：

① 如果采用一級(jí)索引格式，用Lfindex表示單個(gè)索引項(xiàng)的長(zhǎng)度，Number表示小文件總數(shù)，Lhead表示索引頭部的長(zhǎng)度，則：

② 如果采用兩級(jí)索引結(jié)構(gòu)，假設(shè)有N個(gè)序列，每一個(gè)序列的小文件數(shù)為Number1，Number2，…，NumberN，序列索引長(zhǎng)Lsindex為：

2) 計(jì)算該merged file所有非獨(dú)立小文件的長(zhǎng)度和與局部索引文件長(zhǎng)度的和Lmerge，將Lmerge與Hadoop文件系統(tǒng)的塊大小作比較；

3) 如果Lmerge小于Hadoop文件系統(tǒng)的塊大小，則該merged file只占用一個(gè)數(shù)據(jù)塊，所有文件按默認(rèn)順序存放：首先是局部索引文件，然后是小文件序列，小文件序列按照小文件的邏輯順序依次排列，按照小文件順序計(jì)算每個(gè)小文件的偏移和長(zhǎng)度，建立局部索引文件，進(jìn)行步驟4)；如果Lmerge超過(guò)Hadoop文件系統(tǒng)的塊長(zhǎng)，歸并后文件會(huì)被分成多個(gè)數(shù)據(jù)塊存儲(chǔ)，當(dāng)有小文件跨數(shù)據(jù)塊時(shí)，采用邊界填充算法寫(xiě)入一段空白文件將原來(lái)的數(shù)據(jù)塊填充，然后在新申請(qǐng)的數(shù)據(jù)塊中寫(xiě)入該文件；

4) 根據(jù)局部索引文件中每個(gè)文件的偏移對(duì)小文件進(jìn)行歸并，用空白文件填充兩個(gè)文件之間的空白區(qū)域。

2.2 局部索引

過(guò)程如下：

1) 依次計(jì)算每個(gè)文件的偏移，在數(shù)據(jù)塊的邊界處，檢查是否有文件會(huì)橫跨兩個(gè)數(shù)據(jù)塊，如果沒(méi)有，轉(zhuǎn)向步驟3)，否則，轉(zhuǎn)向步驟2)；

2) 在這個(gè)橫跨兩個(gè)數(shù)據(jù)塊的小文件前，建立額外的局部索引文件，該索引文件的偏移是下一個(gè)數(shù)據(jù)塊的起始位置，橫跨小文件的偏移是該局部索引文件的結(jié)束位置，設(shè)塊長(zhǎng)為L(zhǎng)block，局部索引文件的大小為L(zhǎng)index，新塊的序列號(hào)為W，新索引文件偏移量為L(zhǎng)offset，新索引文件長(zhǎng)度為L(zhǎng)length，橫跨小文件的偏移量為L(zhǎng)foffset，則：

3) 對(duì)下一個(gè)數(shù)據(jù)塊，重復(fù)步驟1)和步驟2)

在完成邊界填充后，能夠確定每一個(gè)小文件在merged file內(nèi)的順序和偏移，因此可以建立局部索引文件。

2.3 緩存與預(yù)取

元數(shù)據(jù)緩存、局部索引文件預(yù)取和關(guān)聯(lián)文件預(yù)取包括：

1) 元數(shù)據(jù)緩存：當(dāng)小文件被讀取時(shí)，將小文件映射到merged file以獲取merged file的元數(shù)據(jù)，NameNode將元數(shù)據(jù)返回給客戶端后，客戶端根據(jù)元數(shù)據(jù)信息與相應(yīng)的DataNodes交互，然后客戶端將該merged file的元數(shù)據(jù)緩存，則如果該merged file的其他小文件被請(qǐng)求時(shí)，能夠直接從緩存中讀取元數(shù)據(jù)，從而減少與NameNode的交互；

2) 局部索引文件預(yù)?。焊鶕?jù)merged file的元數(shù)據(jù)，客戶端獲知從哪些數(shù)據(jù)塊中讀取被請(qǐng)求文件，如果局部索引文件已經(jīng)被預(yù)取，當(dāng)屬于該merged file的小文件被請(qǐng)求時(shí)，客戶端根據(jù)被緩存的索引信息，直接從對(duì)應(yīng)DataNode中讀取；否則，局部索引文件預(yù)取操作被觸發(fā)，將局部索引文件預(yù)取到客戶端的緩存中，在緩存中，預(yù)取得到的局部索引文件和元數(shù)據(jù)被處理，為每一個(gè)小文件生成元數(shù)據(jù)索引信息，索引信息包括：原始小文件文件名(16字節(jié))、DataNode ID(4字節(jié))、塊ID(4字節(jié))、偏移(4字節(jié)) 和長(zhǎng)度(4字節(jié)) ；

3) 關(guān)聯(lián)文件預(yù)?。和粋€(gè)merged file的非獨(dú)立小文件有著直觀的關(guān)聯(lián)關(guān)系和明確的邏輯順序，當(dāng)被請(qǐng)求的小文件返回到客戶端后，關(guān)聯(lián)文件預(yù)取操作被觸發(fā)，根據(jù)文件之間的邏輯順序?qū)⒃搈erged file下的相關(guān)小文件預(yù)取。

2.4 碎片整理

碎片整理是對(duì)DataNode的數(shù)據(jù)塊中存在的空白區(qū)域的再利用。當(dāng)某個(gè)小文件被刪除或者其他原因造成數(shù)據(jù)塊中存在空閑區(qū)域，為了利用這些空間提出了碎片整理機(jī)制。該機(jī)制通過(guò)建立一個(gè)碎片索引集合，并利用二叉樹(shù)結(jié)構(gòu)來(lái)定位碎片。索引集合包括各碎片所在塊中的偏移和碎片的長(zhǎng)度，按碎片長(zhǎng)度將其依次放入索引項(xiàng)中，通過(guò)對(duì)碎片索引集合中索引項(xiàng)的查找來(lái)定位碎片，然后進(jìn)行插入操作將相應(yīng)大小的文件存入塊中，或刪除操作刪除不需要的小文件，這些操作與二叉樹(shù)的查找、插入和刪除操作相同。

當(dāng)寫(xiě)入某類小文件時(shí)，將小文件所屬大文件相應(yīng)的塊上，先通過(guò)大文件的碎片索引，查看該塊中是否有適合的碎片可以存入小文件，則將該碎片分為兩個(gè)部分，前一部分分配給待寫(xiě)入小文件，后一部分碎片作為新的碎片，在碎片索引集合，刪除原碎片的索引項(xiàng)，為新的碎片插入索引項(xiàng)，在小文件索引集合中插入新寫(xiě)入小文件的索引項(xiàng)；如果沒(méi)有，對(duì)碎片索引集合不進(jìn)行任何改動(dòng)，直接在數(shù)據(jù)塊末尾的空白區(qū)分配空間給小文件存儲(chǔ)，并在小文件索引集合插入其索引項(xiàng)。

當(dāng)刪除小文件時(shí)，首先使用待刪除小文件的文件名查找索引項(xiàng)，判斷是否存在該文件，若不存在，則刪除失??；如果存在，則在碎片索引集合中插入一條新的碎片索引項(xiàng)；然后在碎片索引集合，判斷新的碎片索引項(xiàng)的相鄰的數(shù)據(jù)單元是否同樣為碎片數(shù)據(jù)，如果存在任何一邊的數(shù)據(jù)單元是空白索引，那么合并多個(gè)數(shù)據(jù)碎片成一個(gè)大的數(shù)據(jù)碎片，并更新碎片索引，當(dāng)數(shù)據(jù)碎片的相鄰碎片是由于數(shù)據(jù)塊的分界造成時(shí)，不需要進(jìn)行數(shù)據(jù)碎片的合并。

3 實(shí)驗(yàn)與分析

為了驗(yàn)證所述方案的優(yōu)化，本文設(shè)計(jì)了一個(gè)實(shí)驗(yàn)方案，用于測(cè)試在優(yōu)化后的HDFS中小文件的讀寫(xiě)效率的變化以及所用內(nèi)存開(kāi)銷。由于基于HDFS的分布式文件系統(tǒng)的核心功能為分布式存儲(chǔ)，因此客戶端對(duì)文件的操作集中在文件上傳和文件下載，但無(wú)論是上傳操作還是下載操作其本質(zhì)都是文件讀取。實(shí)驗(yàn)過(guò)程中以HDFS中的NameNode內(nèi)存占用、文件的數(shù)量和大小、文件讀取時(shí)間等數(shù)據(jù)作為實(shí)驗(yàn)參考指標(biāo)，將實(shí)驗(yàn)結(jié)果與在原生HDFS中的實(shí)驗(yàn)結(jié)果對(duì)比分析。

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

3.1 內(nèi)存占用實(shí)驗(yàn)結(jié)果與分析

為了分析基于HDFS的分布式文件存儲(chǔ)系統(tǒng)中NameNode的內(nèi)存占用情況，設(shè)計(jì)了以下實(shí)驗(yàn)方法。

選取100 000個(gè)大小為1～100 KB的小文件作為實(shí)驗(yàn)數(shù)據(jù)集，將這些小文件依次以不同的數(shù)量分別存儲(chǔ)在原生的HDFS系統(tǒng)中和經(jīng)過(guò)優(yōu)化過(guò)的HDFS系統(tǒng)中。每次啟動(dòng)NameNode后，分析隨機(jī)讀取文件時(shí)NameNode的內(nèi)存占用情況。

圖1為文件大小及數(shù)量分布。將這100 000個(gè)文件以10種不同的數(shù)量規(guī)模分別存儲(chǔ)在原生HDFS系統(tǒng)和優(yōu)化后的HDFS系統(tǒng)中。然后在1 h的時(shí)間內(nèi)不斷的隨機(jī)讀取小文件，觀察讀取小文件時(shí)HDFS中NameNode所占用系統(tǒng)內(nèi)存的變化并取其平均值。圖2為NameNode內(nèi)存大小占用圖。

圖1　文件大小及數(shù)量分布圖

圖2　NameNode內(nèi)存大小占用情況

從圖中可以看出當(dāng)小文件數(shù)量不超過(guò)10 000時(shí)，本文設(shè)計(jì)的優(yōu)化方案效果并不明顯。但是隨著小文件數(shù)量的不斷增加，尤其是文件數(shù)量超過(guò)30 000后，優(yōu)化后的HDFS中NameNode所占用的系統(tǒng)內(nèi)存比原生HDFS節(jié)省，尤其是文件數(shù)量較大時(shí)，效果較為明顯。

3.2 讀寫(xiě)性能結(jié)果及分析

基于本文提出的優(yōu)化方案，根據(jù)相應(yīng)的合并規(guī)則對(duì)這些小文件進(jìn)行進(jìn)行合并存儲(chǔ)。文件分類及索引處理時(shí)間為T(mén)sort，存入HDFS的時(shí)間為T(mén)store，文件總數(shù)量為N。則得到小文件的平均存儲(chǔ)時(shí)間為：

對(duì)于原生的HDFS系統(tǒng)，由于小文件在存入HDFS之前無(wú)須合并及建立索引之類的工作，因此上傳到HDFS的時(shí)間即為小文件存儲(chǔ)到HDFS中的時(shí)間T′ = T′store。

因此，同樣選取100 000個(gè)大小為1～100 KB的小文件作為實(shí)驗(yàn)數(shù)據(jù)集。將這些小文件以不同的數(shù)量規(guī)模存入HDFS中，對(duì)相應(yīng)的存儲(chǔ)過(guò)程重復(fù)3次，最終3次的平均時(shí)間作為小文件存儲(chǔ)時(shí)間。然后再將這些文件全部從HDFS中讀取出來(lái)，同樣重復(fù)3次，3次操作的平均時(shí)間為小文件的讀取時(shí)間，如圖3所示。

圖3　小文件讀取時(shí)間對(duì)比

在小文件讀取方面，優(yōu)化后的HDFS的小文件讀取性能略有提升，其原因歸結(jié)于NameNode在文件讀取時(shí)查詢速度的提升。但對(duì)于小文件的存儲(chǔ)，優(yōu)化后的HDFS的寫(xiě)入時(shí)間相對(duì)于原生HDFS有明顯縮短。原因有兩個(gè)方面：1) 雖然小文件文件在存入HDFS之前需要額外的索引建立與文件合并操作，但隨著小文件索引的合理優(yōu)化，這些操作額外消耗的時(shí)間相對(duì)于存儲(chǔ)時(shí)間微乎其微；2) 本文提出的優(yōu)化方案采用的文件合并策略，大幅度減少了NameNode中元數(shù)據(jù)的數(shù)量，因此小文件在寫(xiě)入HDFS時(shí)，NameNode檢索HDFS空閑塊的時(shí)間隨著元數(shù)據(jù)的減少而減少。

4 結(jié) 束 語(yǔ)

本文提出的小文件歸并及緩存策略將大量關(guān)聯(lián)小文件合并成大文件后存于HDFS上，有效地緩解了NameNode主存的瓶頸問(wèn)題；通過(guò)關(guān)聯(lián)小文件及元數(shù)據(jù)的預(yù)取方案有效地提高了I/O性能，解決了HDFS上存儲(chǔ)小文件存在的問(wèn)題。對(duì)100 000個(gè)小文件進(jìn)行實(shí)驗(yàn)，結(jié)果表明通過(guò)小文件合并及相關(guān)緩存預(yù)取策略使內(nèi)存占用相對(duì)原始HDFS系統(tǒng)減少了19%，讀取效率相對(duì)原始HDFS提高了20%。下一步將針對(duì)小文件的來(lái)源構(gòu)成與分塊進(jìn)行更深入的研究，以進(jìn)一步提高小文件在HDFS中的存取效率。

參 考 文 獻(xiàn)

[1] LIU X, HAN J, ZHONG Y, et al. Implementing WebGIS on Hadoop: a case study of improving small file I/O performance on HDFS[C]//Cluster Computing and Workshops, 2009. CLUSTER'09. New Orleans, LA: IEEE, 2009: 1-8.

[2] MACKEY G, SEHRISH S, WANG J. Improving metadata management for small files in HDFS[C]//Cluster Computing and Workshops, 2009. CLUSTER'09. New Orleans, LA：IEEE, 2009: 1-4.

[3] JIANG L, LI B, SONG M. The optimization of HDFS based on small files[C]//Broadband Network and Multimedia Technology (IC-BNMT), 2010 3rd IEEE International Conference on IEEE. Beijing: IEEE, 2010.

[4] BORTHAKUR D. The hadoop distributed file system: Architecture and design[J]. Hadoop Project Website, 2007, 11: 21.

[5] SHAFER J, RIXNER S, COX A L. The hadoop distributed filesystem: balancing portability and performance[C]// Performance Analysis of Systems & Software (ISPASS), 2010 IEEE International Symposium. White Plains, NY: IEEE, 2010: 122-133.

[6] DUTCH M, BOLOSKY W. A study of practical deduplication[C]//Proceedings of the 9th USENIX Conference on File and Storage Technology(FAST’11). San Jose, CA, USA: [s.n.], 2011.

[7] ATTEBURY G, BARANOVSKI A, BLOOM K, et al. Hadoop distributed file system for the grid[C]//Nuclear Science Symposium Conference Record (NSS/MIC). Orlando, FL: IEEE, 2009: 1056-1061.

[8] POTERAS C M, PETRISOR C, MOCANU M, et al. DCFMS: A chunk-based distributed file system for supporting multimedia communication[C]//2011 Federated Conference on Computer Science and Information Systems (FedCSIS). Szczecin: IEEE Press, 2011: 737-741.

[9] CHANDRASEKAR S, DAKSHINAMURTHY R, SESHAKUMAR P, et al. A novel indexing scheme for efficient handling of small files in hadoop distributed file system[C]//2013 International Conference on Computer Communication and Infromatics. Coimbatore, India: [s.n.], 2013.

[10] FU Song-ling, LIAO Xiang-ke, HE Li-gang, et al. FlatLFS: a lightweight file system for optimizing the performance of accessing massive small files[J]. Journal of National University of Defense Techonology, 2013, 35(2): 120-126.

編 輯 稅 紅

·光電子學(xué)工程與應(yīng)用·

作者簡(jiǎn)介：李孟(1981 ? )，女，博士生，主要從事計(jì)算機(jī)網(wǎng)絡(luò)和知識(shí)工程方面的研究.

基金項(xiàng)目：教育部-中國(guó)移動(dòng)科研基金(MCM20121041)；國(guó)家自然科學(xué)基金(61133016, 61103206)；國(guó)家863計(jì)劃(2011AA010706)

收稿日期：2014 ? 10 ? 08; 修回日期：2015 ? 05 ? 11

中圖分類號(hào)TP391.6

文獻(xiàn)標(biāo)志碼A

doi:10.3969/j.issn.1001-0548.2016.01.024