HDFS中高效存儲(chǔ)小文件的方法

尹 穎，林 慶，2，林涵陽(yáng)

（1.江蘇大學(xué) 計(jì)算機(jī)科學(xué)與通信工程學(xué)院，江蘇 鎮(zhèn)江212013；2.南京理工大學(xué) 計(jì)算機(jī)系，江蘇 南京210094；3.江蘇實(shí)達(dá)迪美數(shù)據(jù)處理有限公司，江蘇 昆山215332）

0 引 言

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

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

1 相關(guān)研究

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

1.1 Hadoop Archiver和Sequence file

Hadoop Archiver是構(gòu)建在HDFS之上的文件系統(tǒng)，將小文件存入HDFS塊中打包成HAR 文件，從而有效的減少NameNode內(nèi)存使用率，對(duì)客戶(hù)端提供透明的訪(fǎng)問(wèn)，但由于讀取過(guò)程為兩層的索引文件和數(shù)據(jù)文件的讀取，所以Hadoop Archiver在處理海量小文件讀操作時(shí)并不高效。

Hadoop Sequence file為二進(jìn)制鍵值對(duì)提供一個(gè)持久化的數(shù)據(jù)結(jié)構(gòu)，可以作為小文件的容器，將大量小文件打包到Sequence file類(lèi)中，有助于存儲(chǔ)和處理小文件。使用Sequence file合并小文件可以有支持基于Record或Block 壓縮，并且在MapReduce中支持本地任務(wù)獲得較高效率，但文件合并過(guò)程一般需要消耗很長(zhǎng)時(shí)間。

1.2 小文件處理模塊

小文件處理模塊通常是先判斷文件是否為小文件，如果判斷文件為小文件則將一定數(shù)量的小文件合并為大文件，同時(shí)為文件合并前后的對(duì)應(yīng)關(guān)系建立索引，來(lái)提供對(duì)文件的訪(fǎng)問(wèn)。地理信息系統(tǒng)中結(jié)合WebGIS 數(shù)據(jù)的相關(guān)特征，將相鄰地理位置小于16 MB的小文件合并成一個(gè)64 MB文件，并為其構(gòu)建索引［8］。BlueSky 中國(guó)電子教學(xué)共享系統(tǒng)中，把屬于同一課件的小文件合并成一個(gè)大文件，存放教學(xué)所用的PPT 文件和視頻文件［9］。目前此方案僅僅成功應(yīng)用在某種特殊文件存儲(chǔ)上，并無(wú)不限應(yīng)用的統(tǒng)一方案。

通過(guò)對(duì)已存在的海量小文件存儲(chǔ)方案的研究，本文針對(duì)大量的小文件元數(shù)據(jù)信息給名字節(jié)點(diǎn)內(nèi)存帶來(lái)的壓力，采用把由名字節(jié)點(diǎn)維護(hù)的文件系統(tǒng)的命名空間和塊管理從名字節(jié)點(diǎn)中分離出來(lái)，利用NFS服務(wù)器同步系統(tǒng)中的元數(shù)據(jù)，以適應(yīng)當(dāng)前大數(shù)據(jù)時(shí)代數(shù)量不斷增長(zhǎng)的海量小文件的存儲(chǔ)。針對(duì)Hadoop小文件處理低效的問(wèn)題，修改文件和數(shù)據(jù)塊之間的對(duì)應(yīng)關(guān)系，允許在同一數(shù)據(jù)塊中存儲(chǔ)多個(gè)小文件，以此增加文件處理是的吞吐量，提高M(jìn)R 效率。

2 基于HDFS處理小文件的優(yōu)化方案

2.1 系統(tǒng)架構(gòu)

在原HDFS中Namenode作為系統(tǒng)唯一的管理者，不僅負(fù)責(zé)文件和目錄的相關(guān)事務(wù)還要處理文件的讀寫(xiě)請(qǐng)求。小文件由于其文件數(shù)據(jù)較小，使得元數(shù)據(jù)在整個(gè)文件存儲(chǔ)所占比例較大，因此給NameNode節(jié)點(diǎn)管理整個(gè)文件系統(tǒng)造成較大壓力。所以在本系統(tǒng)中將文件和目錄的管理同文件的讀請(qǐng)求事務(wù)分開(kāi)來(lái)處理，增加了負(fù)責(zé)響應(yīng)客戶(hù)端讀文件請(qǐng)求的Read NameNode節(jié)點(diǎn)，以及NFS服務(wù)器。系統(tǒng)架構(gòu)如圖1所示。

圖1 系統(tǒng)架構(gòu)

對(duì)各節(jié)點(diǎn)進(jìn)行說(shuō)明：

PrimaryNameNode：繼承自NameNode，作為主要的NameNode節(jié)點(diǎn)負(fù)責(zé)更新、創(chuàng)建、刪除等邏輯操作，還負(fù)責(zé)DataNode之間的通信監(jiān)控各個(gè)節(jié)點(diǎn)的狀態(tài)。

ReadNameNode：繼承自NameNode，它定期讀取PrimaryNameNode存儲(chǔ)在NFS上的日志來(lái)更新自己內(nèi)存中的文件系統(tǒng)目錄樹(shù)元數(shù)據(jù)，和PrimaryNameNode聯(lián)合完成原生的NameNode服務(wù)。

DataNode：此節(jié)點(diǎn)存儲(chǔ)數(shù)據(jù)塊，并向PrimaryNameNode和ReadNameNode同時(shí)發(fā)送心跳信息和BlockReport，其中包括Block的位置信息。

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

客戶(hù)端：此節(jié)點(diǎn)向ReadNameNode查詢(xún)?cè)獢?shù)據(jù)信息。

文件系統(tǒng)的元數(shù)據(jù)存儲(chǔ)在Read NameNode和Primary NameNode中，這些元數(shù)據(jù)主要為兩種：目錄樹(shù)和塊位置。作為文件系統(tǒng)的管理層，他們之間的元數(shù)據(jù)信息應(yīng)該保持同步。其中數(shù)據(jù)塊和DataNode的映射關(guān)系是通過(guò)同時(shí)向兩個(gè)NameNode匯報(bào)來(lái)維持一致，而目錄樹(shù)的一致性則需通過(guò)使用NFS 服務(wù)器來(lái)完成。Primary NameNode將日志實(shí)時(shí)同步到NFS上，Read NameNode可以實(shí)時(shí)讀取NFS 上的日志，通過(guò)日志回放，可以解決目錄樹(shù)信息一致的問(wèn)題。

2.2 文件和數(shù)據(jù)塊的對(duì)應(yīng)方式

采用兩種服務(wù)器Read NameNode和Primary NameNode分別完成客戶(hù)端對(duì)文件的不同請(qǐng)求，這種方式可以提高HDFS中小文件的存取效率；修改文件和塊的對(duì)應(yīng)方式，允許一個(gè)塊內(nèi)存放多個(gè)小文件，可以增加小文件的管理能力和MapReduce計(jì)算小文件的能力。

HDFS中小文件小于數(shù)據(jù)塊的大小，不會(huì)占用比存儲(chǔ)原始文件占用磁盤(pán)空間更大的空間。對(duì)于小文件而言，存儲(chǔ)在塊中最多需要一次切割，因此索引節(jié)點(diǎn)中是數(shù)據(jù)塊索引無(wú)需二次間接塊、三次間接塊等，保留i－node內(nèi)索引，在NameSpace中增加塊內(nèi)偏移索引offset，用于查找文件在Block中的起始位置，文件和數(shù)據(jù)塊的對(duì)應(yīng)關(guān)系如下。

不在不同數(shù)據(jù)塊內(nèi)的大文件：文件名 ｛塊ID＋塊內(nèi)偏移索引offset｝＋ ｛間接塊ID…｝＋｛塊ID＋塊內(nèi)偏移＋塊內(nèi)長(zhǎng)度｝

文件在一個(gè)數(shù)據(jù)塊內(nèi)：文件名 ｛塊ID＋塊內(nèi)偏移＋塊內(nèi)長(zhǎng)度｝

其中，小文件的以字節(jié)為單位的長(zhǎng)度作為塊內(nèi)長(zhǎng)度。

在文件寫(xiě)入系統(tǒng)的時(shí)候根據(jù)文件長(zhǎng)度判斷文件是否為小文件，若是，則為小文件優(yōu)先查找剩余空間大于文件的長(zhǎng)度的數(shù)據(jù)塊，若存在這樣的數(shù)據(jù)塊怎將該數(shù)據(jù)塊剩余空間的起始位置作為文件在塊中的偏移位置。若未寫(xiě)滿(mǎn)的塊中不存在剩余空間大于小文件大小的數(shù)據(jù)塊，怎為該小文件分配新的未使用的數(shù)據(jù)塊。

如此一來(lái)，Namespace中文件與數(shù)據(jù)塊對(duì)應(yīng)列表增加偏移量屬性，但對(duì)于存儲(chǔ)在同一數(shù)據(jù)塊上的小文件來(lái)說(shuō)，它們使用相同的塊管理元數(shù)據(jù)，因此從總體上說(shuō)元數(shù)據(jù)信息量減少了。

系統(tǒng)中文件和數(shù)據(jù)塊的對(duì)應(yīng)方式改變后，相應(yīng)的小文件的索引方式也要修改。獲取文件和數(shù)據(jù)塊的位置信息是讀寫(xiě)數(shù)據(jù)的前提條件。但對(duì)于小文件的開(kāi)始位置不一定在數(shù)據(jù)塊的起始處，所以針對(duì)修改小文件和塊的對(duì)應(yīng)方式后的讀取，需要增加文件的塊中偏移量參量。相應(yīng)的讀請(qǐng)求字段如圖2所示。

圖2 讀請(qǐng)求字段

請(qǐng)求的前兩個(gè)字段包括版本號(hào)和操作碼，數(shù)據(jù)塊ID 和數(shù)據(jù)塊版本號(hào)，通過(guò)這兩個(gè)參數(shù)數(shù)據(jù)節(jié)點(diǎn)可以確定操作的目標(biāo)數(shù)據(jù)塊。以上4個(gè)參數(shù)還不足以確定存儲(chǔ)開(kāi)始位置不在數(shù)據(jù)塊起始位置的小文件，因而需要使用startOffset來(lái)定位小文件的開(kāi)始位置和length獲取要讀取的文件的長(zhǎng)度信息。

3 實(shí)驗(yàn)性能測(cè)試

系統(tǒng)構(gòu)架圖如圖1所示，從邏輯上來(lái)看整個(gè)系統(tǒng)的節(jié)點(diǎn)包含NameNode、NFS Server、DataNode和Client這4種類(lèi)型，Client和DataNode部署在同一節(jié)點(diǎn)上，共需6個(gè)虛擬節(jié)點(diǎn)，具體見(jiàn)表1。

表1 系統(tǒng)節(jié)點(diǎn)配置

Primary NameNode先啟動(dòng)，啟動(dòng)時(shí)首先判斷本節(jié)點(diǎn)的角色，接著產(chǎn)生一個(gè)Read NameNode實(shí)例，對(duì)父類(lèi)Name－Node初始化，同時(shí)啟動(dòng)Web服務(wù)器、RPC 遠(yuǎn)程過(guò)程調(diào)用服務(wù)器和相關(guān)服務(wù)線(xiàn)程；接下來(lái)啟動(dòng)Read NameNode；最后Primary NameNode和Read NameNode啟動(dòng)接收Client請(qǐng)求服務(wù)。

實(shí)驗(yàn)主要測(cè)試海量小文件同時(shí)上傳和讀取所需時(shí)間，以及各Deamon的內(nèi)存占用情況。

（1）向HDFS上傳文件和從系統(tǒng)中讀取文件所需時(shí)間測(cè)試：測(cè)試所用文件數(shù)量250 000，文件大小在4K 和60 M 之間，平均大小31.2K，總大小7.42G。分別測(cè)試將這些小文件上傳至原始文件系統(tǒng)和針對(duì)大量小文件優(yōu)化后的文件系統(tǒng)的時(shí)間消耗，以及從原始文件系統(tǒng)中讀取和從優(yōu)化后的文件系統(tǒng)中讀取文件的時(shí)間消耗。見(jiàn)表2。

表2 用戶(hù)操作原系統(tǒng)和優(yōu)化后系統(tǒng)時(shí)間消耗

（2）平均內(nèi)存占用情況：分別測(cè)試用戶(hù)操作原始系統(tǒng)時(shí)NameNode內(nèi)存占用率和優(yōu)化后文件上傳中Primary NameNode內(nèi)存占用率、客戶(hù)端請(qǐng)求讀寫(xiě)文件時(shí)Read Name－Node內(nèi)存占用率以及無(wú)讀寫(xiě)操作時(shí)兩種NameNode內(nèi)存占用率。結(jié)果如圖3所示。

圖3 用戶(hù)操作和無(wú)操作時(shí)原系統(tǒng)和優(yōu)化后系統(tǒng)中名稱(chēng)節(jié)點(diǎn)內(nèi)存占用率

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

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

［1］CHEN Xuwen，HUANG Yingming.Cloud computing technology and modeling of mass VOD system ［J］.Modern Electronics Technique，2013 （14）：10－12 （in Chinese）. ［陳旭文，黃英銘.海量視頻點(diǎn)播系統(tǒng)的云計(jì)算技術(shù)與建模實(shí)現(xiàn) ［J］.現(xiàn)代電子技術(shù)，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的視頻監(jiān)控?cái)?shù)據(jù)中心關(guān)鍵支 撐技術(shù)研究與應(yīng)用 ［D］.北京：北京郵電大學(xué)，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）.［王鈴惠，李小勇，張軼彬，等.海量小文件存儲(chǔ)文件系統(tǒng)研究綜述［J］.計(jì)算機(jī)應(yīng)用與軟件，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）.［余思，桂小林，黃汝維，等.一種提高云存儲(chǔ)中小文件存儲(chǔ)效率的方案［J］.西安交通大學(xué)學(xué)報(bào)，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）.［鄧鵬，李枚毅，何誠(chéng)，等.Namenode單點(diǎn)故障解決方案研究［J］.計(jì)算機(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.