HDFS中高效存儲小文件的方法

尹 穎，林 慶，2，林涵陽

（1.江蘇大學 計算機科學與通信工程學院，江蘇 鎮江212013；2.南京理工大學 計算機系，江蘇 南京210094；3.江蘇實達迪美數據處理有限公司，江蘇 昆山215332）

0 引 言

目前，HDFS （Hadoop distributed file system）作 為Hadoop 分布式文件系統已經廣泛用于各種大數據應用中［1，2］，提供了高吞吐量的數據訪問，適合存儲海量的大文件。然而，在Web 2.0應用場景中，小文件數量呈幾何級增長，HDFS在處理大量小文件時由于所有文件請求都需要單NameNode進行處理，性能十分低下［3］，因此，優化HDFS存取大量小文件的效率是必要的。

在基于HDFS 存儲海量小文件問題上，Bo Dong 等2012年通過實驗驗證了文件小于4.35 MB時，存取效率明顯降低，因此將4.35 MB 作為大小文件的分界點更為合理［4］。在HDFS中文件系統的元數據掛載在Namenode內存中，文件系統所能容納的文件數目由Namenode的內存大小決定。在HDFS使用小文件時需要大量的尋址和數據節點的跳躍來檢索小文件的位置，若系統中存在1 000 000個文件，則需消耗300MB內存，當系統中文件上升到十億級別或更多時就超出了名字節點的負載能力。從客戶機的角度來看，HDFS是一個分為兩級的分布式文件系統，所有文件和塊映射的元數據查詢事務都要經過NameNode，這樣在面對高并發訪問時是非常低效的；同時大量小文件的存在使得集群內部數據節點和名字節點之間心跳信號交換的信息量增加。

1 相關研究

目前針對小文件問題的解決方法主要有兩種：一是HDFS系統 自帶的Hadoop Archiver［5］和Sequence file［6］解決方法；二是在讀取數據之前判斷是否為小文件，若是則增加小文件處理模塊［7］。

1.1 Hadoop Archiver和Sequence file

Hadoop Archiver是構建在HDFS之上的文件系統，將小文件存入HDFS塊中打包成HAR 文件，從而有效的減少NameNode內存使用率，對客戶端提供透明的訪問，但由于讀取過程為兩層的索引文件和數據文件的讀取，所以Hadoop Archiver在處理海量小文件讀操作時并不高效。

Hadoop Sequence file為二進制鍵值對提供一個持久化的數據結構，可以作為小文件的容器，將大量小文件打包到Sequence file類中，有助于存儲和處理小文件。使用Sequence file合并小文件可以有支持基于Record或Block 壓縮，并且在MapReduce中支持本地任務獲得較高效率，但文件合并過程一般需要消耗很長時間。

1.2 小文件處理模塊

小文件處理模塊通常是先判斷文件是否為小文件，如果判斷文件為小文件則將一定數量的小文件合并為大文件，同時為文件合并前后的對應關系建立索引，來提供對文件的訪問。地理信息系統中結合WebGIS 數據的相關特征，將相鄰地理位置小于16 MB的小文件合并成一個64 MB文件，并為其構建索引［8］。BlueSky 中國電子教學共享系統中，把屬于同一課件的小文件合并成一個大文件，存放教學所用的PPT 文件和視頻文件［9］。目前此方案僅僅成功應用在某種特殊文件存儲上，并無不限應用的統一方案。

通過對已存在的海量小文件存儲方案的研究，本文針對大量的小文件元數據信息給名字節點內存帶來的壓力，采用把由名字節點維護的文件系統的命名空間和塊管理從名字節點中分離出來，利用NFS服務器同步系統中的元數據，以適應當前大數據時代數量不斷增長的海量小文件的存儲。針對Hadoop小文件處理低效的問題，修改文件和數據塊之間的對應關系，允許在同一數據塊中存儲多個小文件，以此增加文件處理是的吞吐量，提高MR 效率。

2 基于HDFS處理小文件的優化方案

2.1 系統架構

在原HDFS中Namenode作為系統唯一的管理者，不僅負責文件和目錄的相關事務還要處理文件的讀寫請求。小文件由于其文件數據較小，使得元數據在整個文件存儲所占比例較大，因此給NameNode節點管理整個文件系統造成較大壓力。所以在本系統中將文件和目錄的管理同文件的讀請求事務分開來處理，增加了負責響應客戶端讀文件請求的Read NameNode節點，以及NFS服務器。系統架構如圖1所示。

圖1 系統架構

對各節點進行說明：

PrimaryNameNode：繼承自NameNode，作為主要的NameNode節點負責更新、創建、刪除等邏輯操作，還負責DataNode之間的通信監控各個節點的狀態。

ReadNameNode：繼承自NameNode，它定期讀取PrimaryNameNode存儲在NFS上的日志來更新自己內存中的文件系統目錄樹元數據，和PrimaryNameNode聯合完成原生的NameNode服務。

DataNode：此節點存儲數據塊，并向PrimaryNameNode和ReadNameNode同時發送心跳信息和BlockReport，其中包括Block的位置信息。

NFS 服 務 器：存 儲PrimaryNameNode 和ReadName－Node的映像和日志。PrimaryNameNode提供一個基于HTTP的流式接口，NFS服務器利用NameNode內建的HTTP服務器，使用GET 操作，周期性的讀取Primary NameNode命名空間鏡像和鏡像編輯記錄，每次讀取的結果都更新到系統中的元數據中。ReadNameNode讀取此文件，更新內存中的元數據，并定時做CheckPoint，將映像和日志回寫到NFS服務器。

客戶端：此節點向ReadNameNode查詢元數據信息。

文件系統的元數據存儲在Read NameNode和Primary NameNode中，這些元數據主要為兩種：目錄樹和塊位置。作為文件系統的管理層，他們之間的元數據信息應該保持同步。其中數據塊和DataNode的映射關系是通過同時向兩個NameNode匯報來維持一致，而目錄樹的一致性則需通過使用NFS 服務器來完成。Primary NameNode將日志實時同步到NFS上，Read NameNode可以實時讀取NFS 上的日志，通過日志回放，可以解決目錄樹信息一致的問題。

2.2 文件和數據塊的對應方式

采用兩種服務器Read NameNode和Primary NameNode分別完成客戶端對文件的不同請求，這種方式可以提高HDFS中小文件的存取效率；修改文件和塊的對應方式，允許一個塊內存放多個小文件，可以增加小文件的管理能力和MapReduce計算小文件的能力。

HDFS中小文件小于數據塊的大小，不會占用比存儲原始文件占用磁盤空間更大的空間。對于小文件而言，存儲在塊中最多需要一次切割，因此索引節點中是數據塊索引無需二次間接塊、三次間接塊等，保留i－node內索引，在NameSpace中增加塊內偏移索引offset，用于查找文件在Block中的起始位置，文件和數據塊的對應關系如下。

不在不同數據塊內的大文件：文件名 ｛塊ID＋塊內偏移索引offset｝＋ ｛間接塊ID…｝＋｛塊ID＋塊內偏移＋塊內長度｝

文件在一個數據塊內：文件名 ｛塊ID＋塊內偏移＋塊內長度｝

其中，小文件的以字節為單位的長度作為塊內長度。

在文件寫入系統的時候根據文件長度判斷文件是否為小文件，若是，則為小文件優先查找剩余空間大于文件的長度的數據塊，若存在這樣的數據塊怎將該數據塊剩余空間的起始位置作為文件在塊中的偏移位置。若未寫滿的塊中不存在剩余空間大于小文件大小的數據塊，怎為該小文件分配新的未使用的數據塊。

如此一來，Namespace中文件與數據塊對應列表增加偏移量屬性，但對于存儲在同一數據塊上的小文件來說，它們使用相同的塊管理元數據，因此從總體上說元數據信息量減少了。

系統中文件和數據塊的對應方式改變后，相應的小文件的索引方式也要修改。獲取文件和數據塊的位置信息是讀寫數據的前提條件。但對于小文件的開始位置不一定在數據塊的起始處，所以針對修改小文件和塊的對應方式后的讀取，需要增加文件的塊中偏移量參量。相應的讀請求字段如圖2所示。

圖2 讀請求字段

請求的前兩個字段包括版本號和操作碼，數據塊ID 和數據塊版本號，通過這兩個參數數據節點可以確定操作的目標數據塊。以上4個參數還不足以確定存儲開始位置不在數據塊起始位置的小文件，因而需要使用startOffset來定位小文件的開始位置和length獲取要讀取的文件的長度信息。

3 實驗性能測試

系統構架圖如圖1所示，從邏輯上來看整個系統的節點包含NameNode、NFS Server、DataNode和Client這4種類型，Client和DataNode部署在同一節點上，共需6個虛擬節點，具體見表1。

表1 系統節點配置

Primary NameNode先啟動，啟動時首先判斷本節點的角色，接著產生一個Read NameNode實例，對父類Name－Node初始化，同時啟動Web服務器、RPC 遠程過程調用服務器和相關服務線程；接下來啟動Read NameNode；最后Primary NameNode和Read NameNode啟動接收Client請求服務。

實驗主要測試海量小文件同時上傳和讀取所需時間，以及各Deamon的內存占用情況。

（1）向HDFS上傳文件和從系統中讀取文件所需時間測試：測試所用文件數量250 000，文件大小在4K 和60 M 之間，平均大小31.2K，總大小7.42G。分別測試將這些小文件上傳至原始文件系統和針對大量小文件優化后的文件系統的時間消耗，以及從原始文件系統中讀取和從優化后的文件系統中讀取文件的時間消耗。見表2。

表2 用戶操作原系統和優化后系統時間消耗

（2）平均內存占用情況：分別測試用戶操作原始系統時NameNode內存占用率和優化后文件上傳中Primary NameNode內存占用率、客戶端請求讀寫文件時Read Name－Node內存占用率以及無讀寫操作時兩種NameNode內存占用率。結果如圖3所示。

圖3 用戶操作和無操作時原系統和優化后系統中名稱節點內存占用率

4 結束語

本文針對HDFS云存儲不適合大量小文件存儲的問題，采用將讀請求從NameNode任務中分離出來，使用NFS服務器同步文件元數據的策略，以提高整個系統中文件數量的容量，并且減輕Primary NameNode的作業量。這種機制解決了HDFS對小文件存儲和計算能力低效的問題，但是由于相關的研究資料太少，只能通過分析源碼來獲取信息，而且其機制相對復雜，該方案存在一些不足之處。如Name－Node 的 FailOver［10］恢 復 沒 有 改 善， 不 支 持 HDFS HA［11，12］；同時，系統中存儲元數據的NFS是單一故障點。但軟件成熟可靠，壞的幾率很小，該機制穩定性和性能有待進一步的檢驗。

［1］CHEN Xuwen，HUANG Yingming.Cloud computing technology and modeling of mass VOD system ［J］.Modern Electronics Technique，2013 （14）：10－12 （in Chinese）. ［陳旭文，黃英銘.海量視頻點播系統的云計算技術與建模實現 ［J］.現代電子技術，2013 （14）：10－12.］

［2］SUN Yuancheng.Hadoop key support video surveillance technology research and application－based data center［D］.Beijing：Beijing University of Posts and Telecommunications，2012 （in Chinese）.［孫元成.基于Hadoop的視頻監控數據中心關鍵支 撐技術研究與應用 ［D］.北京：北京郵電大學，2012.］

［3］WANG Linghui，LI Xiaoyong，ZHANG Yibin，et al.Mass small－file storage file system research overview ［J］.Computer Applications and Software，2012，29 （8）：106－109 （in Chinese）.［王鈴惠，李小勇，張軼彬，等.海量小文件存儲文件系統研究綜述［J］.計算機應用與軟件，2012，29（8）：106－109.］

［4］Dong Bo，Qiu Jie，Zheng Qinghua，et al.A novel approach to improving the efficiency of storing and accessing small fileson Hadoop：A case study by PowerPoint files［C］／／IEEE International Conference on Services Computing，2010：65－72.

［5］Rajeev Gupta，Himanshu Gupta，Ullas Nambiar，et al.Efficiently querying archived data using Hadoop ［C］／／19th ACM Conference on Information and Knowledge Management，2010：1301－1304.

［6］Zhao Xiaoyong，Yang Yang，Sun Lili，et al.Metadata－aware small files storage architecture on Hadoop ［C］／／Web Information Systems and Mining，2012：136－143.

［7］YU Si，GUI Xiaolin，HUANG Ruwei，et al.Improving the storage efficiency of small files in cloud storage［J］.Journal of Xi’an Jiaotong University，2011，45 （6）：59－63 （in Chinese）.［余思，桂小林，黃汝維，等.一種提高云存儲中小文件存儲效率的方案［J］.西安交通大學學報，2011，45 （6）：59－63.］

［8］Liu Xuhui，Han Jizhong，Zhong Yunqin，et al.Implementing WebGIS on Hadoop：A case study of improving small file I／O performance on HDFS ［C］／／IEEE International Conference on Cluster Computing and Workshops，2009：429－436.

［9］Bluesky’s integrated LiDAR imaging system ［J］.Highways，2012，81 （7）：76.

［10］DENG Peng，LI Meiyi，HE Cheng，et al.Research on Name－Node single point of fault solution ［J］.Computer Engineering，2012，38 （21）：40－44（in Chinese）.［鄧鵬，李枚毅，何誠，等.Namenode單點故障解決方案研究［J］.計算機工程，2012，38（21）：40－44.］

［11］Doug Henschen.NetApp teams with cloudera to back Hadoop［EB／OL］.http：／／www.informationweek.com，2013.

［12］Oriani Andre，Garcia Islene C.From backup to hot standby：High availability for HDFS ［C］／／IEEE 31st Symposium on Reliable Distributed Systems，2012：131－140.