基于Hadoop的小文件存儲優化方案

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

?

基于Hadoop的小文件存儲優化方案

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

【摘要】Hadoop作為成熟的分布式云平臺，對較大的文件提供了可靠高效的存儲服務，但在處理海量小文件時效率顯著降低。該文提出了基于Hadoop的海量教育資源小文件的存儲優化方案，利用教育資源小文件間的關聯關系，將小文件進行合并成大文件以減少文件數量，并索引機制訪問小文件、元數據緩存和關聯小文件預取機制來提高文件的讀取效率。實驗結果表明，該方法提高了Hadoop文件系統存儲小文件的存取效率。

關 鍵 詞Hadoop; 索引機制; 關聯關系; 小文件存儲

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)是一個具有高容錯性、成本低廉性等特點的分布式文件系統。在實際應用中，小文件的數量遠遠多于大文件的數量。尤其是在互聯網應用中，諸如網頁中的圖片、文檔以及包括其他的數據信息xml文件等多數為小文件。 HDFS設計來對大文件進行流式存儲，在處理小文件時會產生一些問題。因此，如何高效地存儲和處理大量的小文件成為一個研究熱點[1-3]。

HDFS對于處理海量小文件的存儲有以下不足：1) 海量小文件耗費主節點內存，可能造成NAMEDODE瓶頸問題；2) 海量小文件的I/O效率低，沒有一種優化機制來提高I/O性能；3) HDFS下沒有明確的能夠區分何為小文件的分界點；4) 沒有考慮海量小文件之間的相關性等。

本文所提的教育資源小文件包括各種形式的教育資源，如word文檔、pdf文檔、ppt課件及文件資料等，只要和教育資源相關的內容且大小遠小于Hadoop的存儲塊64 MB的文件都可稱為教育資源小文件。這類文件具有3個特點：1) 這些文件通常在幾十到幾百KB，和Hadoop的存儲塊大小64 MB相比較??；2) 小文件之間有關聯性，整理歸檔同類課程的小文件然后進行合并；3) 小文件的數量很多，因為網絡中存在的各種學習資源量非常大，且不斷地以指數級速度增長。

1 相關工作

針對小文件在HDFS中存儲出現的問題，目前出現了許多的解決方案[4-10]，歸納起來主要分為：

1) 第一類都對寫入的小文件進行緩沖，將緩沖的多個小文件合并為一個臨時文件，將臨時文件的元數據和數據對象存儲至元數據服務器節點和數據服務器節點的后端存儲中，從而可以有效地提高集群文件系統服務的響應時間和速度，提升數據整體的單位時間數據讀寫次數、吞吐量。

2) 第二類針對機群文件系統中的小文件提出新的存儲和訪問，步驟為：① 設置閾值，區分大小文件；② 在元數據服務器上，存儲小文件的數據；③ 在元數據服務器上進行小文件創建、讀寫和刪除。由于把小文件的數據存儲在元數據服務器上，這樣對于小文件的IO訪問操作，如創建、讀寫和刪除等，發起IO訪問的客戶端只需要與元數據服務器交互，無需與數據服務器交互，減少了小文件訪問的網絡延遲，提高了小文件IO的性能，從而從整體上提高了機群文件系統的IO性能。

3) 第三類面向大批量文件數據存取方法，包括將所有小文件的數據合并成一個大文件；建立每個小文件的文件名及其文件編號的一一對應關系；建立每個所述文件編號與小文件的文件信息的對應關系，文件信息包括所述小文件在所述大文件中的位置。相應地，還公開一種大批量文件數據讀取方法，用于讀取按照本文的存放方法存放的文件數據，包括有：根據小文件的文件名來獲得所述小文件的文件編號；根據所述文件編號獲得所述小文件的文件信息；根據所述文件信息獲得所述小文件在大文件中的位置；根據所述小文件在大文件中的位置，通過所述大文件的IO接口實現對所述小文件數據的讀取。

上述現有解決小文件存儲問題的專利技術方案存在以下問題：1) 已有小文件存儲效率的研究主要集中在非云存儲的文件系統上，而不是針對云存儲環境下的分布式文件系統，即Hadoop分布式文件系統上的存儲優化方法；2) 現有方法雖然提出了合并小文件的方法，但在合并時沒有考慮文件之間的關聯關系，且合并后讀取文件時所增加的索引查詢會影響文件的讀取效率。

2 本文方法

本文提出了一種基于Hadoop的海量可歸類小文件關聯存儲方法，主要解決可歸類小文件的存取效率問題。針對屬于某一類別的獨立的小文件進行文件聚合和全局索引管理，大幅度提高了內存利用率，提高單位內存支持的最大文件數量。

2.1 文件歸并

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

2) 對每個merged file建立一個局部索引，并在上傳時將局部索引文件與文件實體一同存放在Hadoop系統的DataNode上；

3) 在讀取非獨立小文件時，采用元數據緩存、局部索引文件預取和關聯文件預取提高文件的讀取效率。

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

1) 局部索引文件結構

局部索引文件采用靜態查找表結構，由索引頭部、序列索引和文件索引3部分構成；其中索引頭部由占1字節的版本號、占4字節的索引項數和占4字節的局部索引文件長度組成；序列索引由占4字節的序列名稱、占4字節的文件索引的起始編號和占4字節的文件索引項數構成；文件索引項由占16字節的文件名稱、占4字節的文件長度和占4字節的文件偏移構成；

2) 讀文件時對局部索引文件的操作

首先根據merged file名從NameNode獲取元數據；然后由merged file的元數據，從Hadoop文件系統的相應DataNode讀取指定的數據塊，并根據數據塊內索引文件長度項讀取數據塊的局部索引文件；最后根據小文件名稱，查找局部索引文件，獲得該小文件的起始位置和長度，從而完成對小文件的讀操作。當該merged file的小文件數目少于1 000 時，采用順序查找方法；當小文件的數目超過1 000 時，順序查找會影響讀取性能，在文件索引上建立序列索引，避免查詢的開銷過大；如果是一級索引格式，則從局部索引文件中第一個目錄項開始，與請求小文件名稱逐條對比，若文件索引項的小文件名稱符合，則查找成功，返回該小文件索引記錄；否則，繼續查找直至最后一個記錄項，若沒有記錄項合，則返回小文件名查找失敗。

如果是兩級索引格式，則查找分為兩個階段：首先根據待查小文件的序列名稱，在序列索引表中查找序列，如果索引表內沒有記錄項，則表明該序列不存在；否則根據序列指定的位置，開始順序查找文件索引位置。

文件歸并操作在Hadoop文件系統的客戶端上進行，將屬于同一個大文件的所有小文件合并成一個文件；具體步驟如下：

1) 計算非獨立小文件總數，根據文件的數目決定采用文件索引還是采用序列索引+文件索引，由于索引每項長度固定，計算得出局部索引文件的長度，用Lindex表示，過程如下：

① 如果采用一級索引格式，用Lfindex表示單個索引項的長度，Number表示小文件總數，Lhead表示索引頭部的長度，則：

② 如果采用兩級索引結構，假設有N個序列，每一個序列的小文件數為Number1，Number2，…，NumberN，序列索引長Lsindex為：

2) 計算該merged file所有非獨立小文件的長度和與局部索引文件長度的和Lmerge，將Lmerge與Hadoop文件系統的塊大小作比較；

3) 如果Lmerge小于Hadoop文件系統的塊大小，則該merged file只占用一個數據塊，所有文件按默認順序存放：首先是局部索引文件，然后是小文件序列，小文件序列按照小文件的邏輯順序依次排列，按照小文件順序計算每個小文件的偏移和長度，建立局部索引文件，進行步驟4)；如果Lmerge超過Hadoop文件系統的塊長，歸并后文件會被分成多個數據塊存儲，當有小文件跨數據塊時，采用邊界填充算法寫入一段空白文件將原來的數據塊填充，然后在新申請的數據塊中寫入該文件；

4) 根據局部索引文件中每個文件的偏移對小文件進行歸并，用空白文件填充兩個文件之間的空白區域。

2.2 局部索引

過程如下：

1) 依次計算每個文件的偏移，在數據塊的邊界處，檢查是否有文件會橫跨兩個數據塊，如果沒有，轉向步驟3)，否則，轉向步驟2)；

2) 在這個橫跨兩個數據塊的小文件前，建立額外的局部索引文件，該索引文件的偏移是下一個數據塊的起始位置，橫跨小文件的偏移是該局部索引文件的結束位置，設塊長為Lblock，局部索引文件的大小為Lindex，新塊的序列號為W，新索引文件偏移量為Loffset，新索引文件長度為Llength，橫跨小文件的偏移量為Lfoffset，則：

3) 對下一個數據塊，重復步驟1)和步驟2)

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

2.3 緩存與預取

元數據緩存、局部索引文件預取和關聯文件預取包括：

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

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

3) 關聯文件預?。和粋€merged file的非獨立小文件有著直觀的關聯關系和明確的邏輯順序，當被請求的小文件返回到客戶端后，關聯文件預取操作被觸發，根據文件之間的邏輯順序將該merged file下的相關小文件預取。

2.4 碎片整理

碎片整理是對DataNode的數據塊中存在的空白區域的再利用。當某個小文件被刪除或者其他原因造成數據塊中存在空閑區域，為了利用這些空間提出了碎片整理機制。該機制通過建立一個碎片索引集合，并利用二叉樹結構來定位碎片。索引集合包括各碎片所在塊中的偏移和碎片的長度，按碎片長度將其依次放入索引項中，通過對碎片索引集合中索引項的查找來定位碎片，然后進行插入操作將相應大小的文件存入塊中，或刪除操作刪除不需要的小文件，這些操作與二叉樹的查找、插入和刪除操作相同。

當寫入某類小文件時，將小文件所屬大文件相應的塊上，先通過大文件的碎片索引，查看該塊中是否有適合的碎片可以存入小文件，則將該碎片分為兩個部分，前一部分分配給待寫入小文件，后一部分碎片作為新的碎片，在碎片索引集合，刪除原碎片的索引項，為新的碎片插入索引項，在小文件索引集合中插入新寫入小文件的索引項；如果沒有，對碎片索引集合不進行任何改動，直接在數據塊末尾的空白區分配空間給小文件存儲，并在小文件索引集合插入其索引項。

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

3 實驗與分析

為了驗證所述方案的優化，本文設計了一個實驗方案，用于測試在優化后的HDFS中小文件的讀寫效率的變化以及所用內存開銷。由于基于HDFS的分布式文件系統的核心功能為分布式存儲，因此客戶端對文件的操作集中在文件上傳和文件下載，但無論是上傳操作還是下載操作其本質都是文件讀取。實驗過程中以HDFS中的NameNode內存占用、文件的數量和大小、文件讀取時間等數據作為實驗參考指標，將實驗結果與在原生HDFS中的實驗結果對比分析。

表1　實驗環境

3.1 內存占用實驗結果與分析

為了分析基于HDFS的分布式文件存儲系統中NameNode的內存占用情況，設計了以下實驗方法。

選取100 000個大小為1～100 KB的小文件作為實驗數據集，將這些小文件依次以不同的數量分別存儲在原生的HDFS系統中和經過優化過的HDFS系統中。每次啟動NameNode后，分析隨機讀取文件時NameNode的內存占用情況。

圖1為文件大小及數量分布。將這100 000個文件以10種不同的數量規模分別存儲在原生HDFS系統和優化后的HDFS系統中。然后在1 h的時間內不斷的隨機讀取小文件，觀察讀取小文件時HDFS中NameNode所占用系統內存的變化并取其平均值。圖2為NameNode內存大小占用圖。

圖1　文件大小及數量分布圖

圖2　NameNode內存大小占用情況

從圖中可以看出當小文件數量不超過10 000時，本文設計的優化方案效果并不明顯。但是隨著小文件數量的不斷增加，尤其是文件數量超過30 000后，優化后的HDFS中NameNode所占用的系統內存比原生HDFS節省，尤其是文件數量較大時，效果較為明顯。

3.2 讀寫性能結果及分析

基于本文提出的優化方案，根據相應的合并規則對這些小文件進行進行合并存儲。文件分類及索引處理時間為Tsort，存入HDFS的時間為Tstore，文件總數量為N。則得到小文件的平均存儲時間為：

對于原生的HDFS系統，由于小文件在存入HDFS之前無須合并及建立索引之類的工作，因此上傳到HDFS的時間即為小文件存儲到HDFS中的時間T′ = T′store。

因此，同樣選取100 000個大小為1～100 KB的小文件作為實驗數據集。將這些小文件以不同的數量規模存入HDFS中，對相應的存儲過程重復3次，最終3次的平均時間作為小文件存儲時間。然后再將這些文件全部從HDFS中讀取出來，同樣重復3次，3次操作的平均時間為小文件的讀取時間，如圖3所示。

圖3　小文件讀取時間對比

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

4 結 束 語

本文提出的小文件歸并及緩存策略將大量關聯小文件合并成大文件后存于HDFS上，有效地緩解了NameNode主存的瓶頸問題；通過關聯小文件及元數據的預取方案有效地提高了I/O性能，解決了HDFS上存儲小文件存在的問題。對100 000個小文件進行實驗，結果表明通過小文件合并及相關緩存預取策略使內存占用相對原始HDFS系統減少了19%，讀取效率相對原始HDFS提高了20%。下一步將針對小文件的來源構成與分塊進行更深入的研究，以進一步提高小文件在HDFS中的存取效率。

參 考 文 獻

[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.

編 輯 稅 紅

·光電子學工程與應用·

作者簡介：李孟(1981 ? )，女，博士生，主要從事計算機網絡和知識工程方面的研究.

基金項目：教育部-中國移動科研基金(MCM20121041)；國家自然科學基金(61133016, 61103206)；國家863計劃(2011AA010706)

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

中圖分類號TP391.6

文獻標志碼A

doi:10.3969/j.issn.1001-0548.2016.01.024