尹 穎，林 慶，2，林涵陽

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

0 引 言

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

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

1 相關(guā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)存使用率，對客戶端提供透明的訪問，但由于讀取過程為兩層的索引文件和數(shù)據(jù)文件的讀取，所以Hadoop Archiver在處理海量小文件讀操作時并不高效。

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

1.2 小文件處理模塊

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

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

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

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

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

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

對各節(jié)點進行說明：

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

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

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

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

客戶端：此節(jié)點向ReadNameNode查詢元數(shù)據(jù)信息。

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

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

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

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

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

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

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

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

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

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

圖2 讀請求字段

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

3 實驗性能測試

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

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

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

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

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

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

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

圖3 用戶操作和無操作時原系統(tǒng)和優(yōu)化后系統(tǒng)中名稱節(jié)點內(nèi)存占用率

4 結(jié)束語

本文針對HDFS云存儲不適合大量小文件存儲的問題，采用將讀請求從NameNode任務(wù)中分離出來，使用NFS服務(wù)器同步文件元數(shù)據(jù)的策略，以提高整個系統(tǒng)中文件數(shù)量的容量，并且減輕Primary NameNode的作業(yè)量。這種機制解決了HDFS對小文件存儲和計算能力低效的問題，但是由于相關(guān)的研究資料太少，只能通過分析源碼來獲取信息，而且其機制相對復(fù)雜，該方案存在一些不足之處。如Name－Node 的 FailOver［10］恢 復(fù) 沒 有 改 善， 不 支 持 HDFS HA［11，12］；同時，系統(tǒng)中存儲元數(shù)據(jù)的NFS是單一故障點。但軟件成熟可靠，壞的幾率很小，該機制穩(wě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）. ［陳旭文，黃英銘.海量視頻點播系統(tǒng)的云計算技術(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)控數(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）.［王鈴惠，李小勇，張軼彬，等.海量小文件存儲文件系統(tǒng)研究綜述［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）.［余思，桂小林，黃汝維，等.一種提高云存儲中小文件存儲效率的方案［J］.西安交通大學(xué)學(xué)報，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.