Hadoop平台下基于HDFS的小文件存储问题的优化与实现

分类号 学号 M*********

学校代码 10487 密级

硕士学位论文

Hadoop平台下基于HDFS的小文件存储问题的优化与实现

学位申请人： 罗 青

学科专业： 软件工程

指导教师： 傅邱云教授

答辩日期： 2019年 1月18日

A Dissertation Submitted in Partial of Fulfillment of the Requirements for

the Degree of Master of Engineering

Optimization and implementation of small file

storage in HDFS under Hadoop platform

Candidate : Luo Qing

Major : Software engineering

Supervisor : Prof. Fu Qiuyun

Huazhong University of Science & Technology

Wuhan, Hubei 430074, P. R. China

January, 2019

华 中 科 技 大 学 硕 士 学 位 论 文

摘 要

大数据技术随着互联网的发展及信息量爆炸增长的趋势应运而生。面对异常庞大的数据，多种分布式文件系统为大数据的存储提供了解决方案。其中Hadoop由于自身高扩展性、高可靠性等优点被业界广泛使用。HDFS作为Hadoop的核心组件，为处理大数据提供了文件存储服务。然而HDFS更擅长处理流式的大文件，面对海量小文件存储时的表现不佳。

本文为了解决HDFS存储小文件效率低下的问题，对Hadoop架构和HDFS存储文件的流程进行详细分析，提出了引入多级处理模块MPM（Multilevel Processing

Module for Small Files）的方案。该方案首先通过文件预处理模块，对系统中发出操作请求的文件进行过滤，筛选4.35MB以下的文件为小文件，并将其按文件扩展名进行初步分类。随后文件合并模块会将预处理后的小文件合并成尽可能少的大文件，以减少系统NameNode内存负载。为了提高小文件的查询速度，方案中除了利用小文件创建时间和小文件扩展名建立的二级索引模块，还引入了基于用户常用文件的预取和缓存模块。最后，针对系统长时间运行导致的碎片问题，当系统满足设定条件时，碎片整理模块会对合并文件的空白空间进行清理，以提高系统空间的利用率。

本文将提出的MPM方案与三种HDFS现有存储方案：原生存储方案、HAR文件归档方案、Sequence File方案进行实验对比。当存取数量为100000的文件时，MPM方案可为系统节省95.56%的内存占用，空间利用率高达99.92%。同等条件下，与原生存储方案相比，MPM方案的写入速率是未优化前的两倍；由于合并机制步骤更多，写入耗时只降低了31%。读取速率提升了2.25倍左右，读取耗时是所有方案中最低的。实验结果表明，MPM方案对HDFS的存储性能改善明显。大幅减少了系统中的文件数量，有效降低NameNode内存负载，提高了系统内存利用率，实现了高速率的小文件读写性能。

关键词：HDFS、海量小文件、文件合并、二级索引

IV

华 中 科 技 大 学 硕 士 学 位 论 文

Abstract

With the development of the Internet, the big data technology has emerged as the trend

of information explosion. In the face of extremely large data, a variety of distributed file

systems provide solutions for the storage of big data. Hadoop is widely used in the industry

due to its advantages of high scalability and high reliability. HDFS, as the core component

of Hadoop, provides file storage service for processing big data. HDFS, however, is better

at handling large, streaming files, and does not perform well when storing large amounts of

small files.

In order to solve the problem of low efficiency in HDFS storage of Small Files, this

paper analyzes the Hadoop architecture and the process of HDFS storage of Files in detail,

and proposes a scheme of introducing Multilevel Processing Module (MPM) for Small

Files. This scheme firstly filters the files that send operation requests in the system through

the file preprocessing module. Files under 4.35MB are screened as small files and are

preliminarily classified according to file extensions. The file merge module then merges

the pre-processed small files into as few large files as possible to reduce the system

NameNode memory load. In order to improve the query speed of small files, the scheme

not only USES the creation time of small files and the secondary index module established

by the extension of small files, but also introduces the prefetch and cache module based on

the common files of users. Finally, aiming at the fragmentation problem caused by the long

running of the system, when the system meets the set conditions, the defragmenting module

will clear the blank space of the merged files to improve the utilization rate of the system

space.

This paper compares the proposed MPM scheme with three existing HDFS storage

schemes: native storage scheme, HAR File archive scheme and Sequence File scheme.

When 100,000 files are accessed, the MPM scheme can save the system 95.56% in memory

usage and 99.92% in space utilization. Under the same conditions, compared with the native

storage scheme, the write rate of the MPM scheme is twice as high as that before

optimization. Because of the more steps in the merge mechanism, the write time is reduced

by only 31%. The reading rate is improved by about 2.25 times, and the reading time is the

lowest among all schemes. Experimental results show that MPM scheme improves HDFS

V

华 中 科 技 大 学 硕 士 学 位 论 文

storage performance significantly. Greatly reduce the number of files in the system,

effectively reduce the NameNode memory load, improve the system memory utilization,

and achieve high rate of small file read and write performance.

Key words: HDFS, lots of small files, file merge, secondary index

VI

华 中 科 技 大 学 硕 士 学 位 论 文

目 录

摘 要 ........................................................................................................... IV

Abstract ........................................................................................................... V

1

1.1

1.2

1.3

2

2.1

2.2

2.3

2.4

2.5

3

3.1

3.2

3.3

4

4.1

4.2

4.3

4.4

绪论 ......................................................................................................... 1

研究背景及意义 ................................................................................. 1

国内外研究现状 ................................................................................. 3

论文组织结构 ..................................................................................... 4

小文件问题相关技术分析 ..................................................................... 6

Hadoop系统架构 ................................................................................ 6

分布式文件系统HDFS ...................................................................... 8

编程模型MapReduce ....................................................................... 13

Hadoop现有技术方案分析.............................................................. 15

本章小结 ........................................................................................... 18

基于HDFS的小文件多级处理模块（MPM）的设计 ..................... 19

小文件多级处理模块（MPM）的架构 .......................................... 20

小文件多级处理模块（MPM）的读写流程 .................................. 27

本章小结 ........................................................................................... 31

基于HDFS的小文件多级处理模块（MPM）的实现 ..................... 32

文件预处理模块 ............................................................................... 32

基于空间最优化的合并模块 ........................................................... 33

二级索引模块 ................................................................................... 35

预取和缓存模块 ............................................................................... 36

VII

华 中 科 技 大 学 硕 士 学 位 论 文

4.5

4.6

5

5.1

5.2

5.3

5.4

5.5

6

碎片整理 ........................................................................................... 38

本章小结 ........................................................................................... 39

实验与分析 ........................................................................................... 40

Hadoop平台搭建 .............................................................................. 40

实验设计 ........................................................................................... 41

对比实验 ........................................................................................... 42

实验结论 ........................................................................................... 48

本章小结 ........................................................................................... 48

总结与展望 ........................................................................................... 50

参考文献 ....................................................................................................... 52

VIII

华 中 科 技 大 学 硕 士 学 位 论 文

1 绪论

1.1 研究背景及意义

随着移动互联网的普及和应用，全球的数据信息呈现了爆发式的增长。国际数据中心IDC（International Data Corporation）在2014年发布的统计结果[1]中，前一年全球数据量共计不足1.5ZB；而报告预测，5年后该数字将超过40ZB。日新月异的大数据时代促使传统的数字化产业寻求转型，人工智能、云计算等新兴产业迅速发展[2]。

几何式增长的数据量要求计算机必须拥有更大容量、处理速度更快的存储系统，传统的计算机存储系统的成长速度无法与之匹配，因此催生了大量的数据存储系统[3]。目前企业常用的主流分布式文件系统有Hadoop[4]、Lustre[5]、MogileFS、FreeNAS、FastDFS[6]、GoogleFS[7][8]等。Hadoop具有可靠性高、可扩展性强、存储速度快、容错率高等一系列优势[9]。又由于其可以被部署在廉价硬件上，让用户在短时间内构建一个高效处理海量数据的分布式集群，因此得到众多企业以及学术界的青睐。

高校和研究机构针对Hadoop系统在数据存储、资源整合、编程引擎、效率优化等方向开展了深入的研究。相关研究成果都可以在Hadoop开源社区进行分享和讨论。为了支持广告和搜索平台的正常运行，Yahoo[10]创建了超过3500个节点的Hadoop集群；国际知名的互联网企业“脸书”[11]也使用了上千个节点的Hadoop集群存储日志数据，以此支撑企业日常的数据分析，并在此基础上进行机器学习的研究。早在2009年，国内就提出了“大云（Big Cloud）”商务智能系统[12]的想法，可以实现高性能低成本的分布式文件存储，由中国移动的业务支撑研究所进行开发。其他互联网企业如百度，每日仅搜索引擎和网页数据产生的数据量就有30TB，使用Hadoop才能满足这样庞大的文件存储需求。如今，Hadoop已经成为了大数据存储领域中常用的数据存储系统，在数据处理的实际任务里有着举足轻重的地位。

分布式存储文件系统的出现使大数据得到处理和存储，但是庞大的信息流并不是数据存储系统所面临的唯一问题。互联网技术的出现，让每个行业都有了与互联网结合的需求，且移动应用开发成本及门槛不断降低，海量的移动应用如雨后春笋般出现。1

华 中 科 技 大 学 硕 士 学 位 论 文

到2018年4月为止，我国市场上监测到的移动APP为414万款，本国移动APP数量达到了231万款。其中占比最多的前四种应用分别是游戏类应用、生活服务类应用、电子商务类应用和影音播放类应用[13]。这些占据我们生活绝大部分时间的移动应用每天会产生十亿级的图片、视频、office文档等，这些文件的体积大多大于1KB，小于等于10MB。比如，淘宝作为目前国内最大的电子商务网站，在2010年其存储的图片文件数量就接近300亿个，平均图片大小仅有18KB[14]。以抖音为代表的移动端短视频平台，至2018年6月，国内日活跃用户数超过1.5亿，假设每位活跃用户平均每天发布一个10s的短视频，单个视频容量通常在5MB-10MB不等，那么抖音每日都需要存储1.5亿个总量为715TB-1430TB的视频小文件数据[15]，并且随用户增长及活跃度不定期增长。

面对不断增长的移动应用，以及用户使用应用过程中产生的海量小文件。Hadoop分布式文件系统在设计之初并没有考虑到海量小文件存储带来的内存浪费等一系列问题。因为Hadoop中一个最小的存储单元叫做Block[16]，默认存储文件阈值为64MB。小文件在存储时被分割成若干个内容连续的数据文件进行存储，小于64MB的文件会占据节点空间但不占满整个空间。小文件数量的增多使得系统中的存储空间无法被完全利用，存在大量的内存浪费的情况。

Hadoop系统在处理小文件数据时，存储性能和读写效率都无法维持原有水准。海量的小文件数据使得存储系统变得臃肿、缓慢甚至无法工作。通常业内将文件大小为1KB-10MB的数据称为小文件，数量在百万级及以上的是海量数据。由此引出分布式文件存储系统中的海量小文件问题（Lots of Small Files，简称LOSF）[17]。LOSF的存储问题成为业界久经不衰的研究课题。

为了解决LOSF带来的文件存储效率低下的问题，Hadoop社区提出了Hadoop

Archive（HAR）归档[18]、Sequence File[19]、HDFS Federation[20]等技术方案。这几种方案的实现原理都是将小文件按照某些标准组合成一定大小的合并文件，再将其放入HDFS进行存储。这样可以使系统中的文件数量大幅减少，从而降低存储文件所需的节点内存和元数据数量，以此提升系统性能。但是目前的合并标准会导致例如跨块存储、合并效率不高等新的问题。可以说现有解决方案对Hadoop系统存储性能的改善2

华 中 科 技 大 学 硕 士 学 位 论 文

并不成功。

如何有效的解决LOSF，提高Hadoop系统存储海量小文件时的存储性能，是现在甚至未来大数据存储领域将会一直探讨的重要议题。因此，本文的研究方向——Hadoop平台中基于HDFS的海量小文件存储问题的优化与实现，具有非常重要的科研意义和实用价值。

1.2 国内外研究现状

随着数据，尤其是小文件数据的爆发式增长，国内外学术界与相关企业对海量小文件存储问题进行了广泛的研究。提出了一些针对特定文件类型或特定系统的解决方法，一定程度上缓解了LOSF对文件存储系统带来的影响。

针对单机环境下的词频统计[21]场景，袁玉等人对比了系统在存储不同文件类型的测试数据集时，系统的内存消耗情况、文件读写速率情况等，得到了系统对不同文件输入格式和词频统计时间的关系。结果显示通过将大量小文件合并为一个大文件可以显著提升Hadoop系统的存储性能。但是因为实验是在单机环境下进行的，该实验存在一定的局限性。

针对浏览器和服务集群之间的传输数据过多的情况，一种结合了网络Web和地理信息的系统WebGIS系统[22]应运而生。该系统将数据切割成小文件进行传输以最大限度的减少系统节点之间传输的数据，通常这些小文件的大小是KB级别的。受到WebGIS的启发，X Liu等人[23]在处理海量小文件存储问题时，将小文件的合并依据设定为地理位置信息。将地理位置相近的小文件合并成大文件，并引入索引机制便于文件查找。这种方法针对拥有地理位置信息的特殊数据合并效率较高，对其他类型的数据没有可用性。另外这个方法的索引机制较为复杂，随着存储数据量的不断增多，文件读取效率反而会降低。

为了提高小文件合并后文件之间的结构相关性和逻辑相关性，文献[24]提出了一种三级缓存策略。通过预取文件元数据、索引数据以及数据本身的方法增强文件之间的结构相关性；同样在文件分组时预取三级缓存以提高逻辑相关性。并对提出的方法进行了实验验证，但由于数据集受到了限制，该方案虽然一定程度上提高了LOSF的存3

华 中 科 技 大 学 硕 士 学 位 论 文

储性能，但仍需要更多无约束的数据继续实验。

扩展的Hadoop分布式文件系统——EHDFS（Extend Hadoop Distributed Files

System，简称EHDFS）由Chandrasekar S等人[25]提出。该方案在HDFS原生系统的基础上增加了许多文件处理模块，所以是扩展的HDFS。与其他小文件处理方案一样，EHDFS的仍然是先通过合并操作降低文件数量，同时为合并后的文件建立有效的索引机制，随后通过预取和缓存模块提高访问速率。该方案不仅确实降低了文件数量，减少了NameNode消耗；还降低了文件定位的时间。对大部分文件系统都有长远的借鉴意义。

Hadoop也被用于批量处理大量的3D渲染素材。文献[26]为了解决大量小文件素材存储影响渲染性能的问题，引入了向量机并运用了粒子集算法，根据不同的渲染场景对不同体积的小文件进行分类。这样的合并算法使场景中的文件素材相对统一，在降低系统内存占用的同时提高了渲染精度。在“数字城市”系统的小文件处理中，为了存储大量的不断变化且数据内容丰富的文件信息，文献[27]的合并思路是利用关系数据库选择了两种合并依据分为信息来源和信息时间，以此达到减少系统内文件数量的目的。这些方案针对特殊场景的小文件存储问题进行了研究，虽然这给同类场景的LOSF问题的解决指出了方向，但它们的可移植性普遍较差。

1.3 论文组织结构

本文包括六个章节。各章节的主要内容如下：

第一章为绪论。首先，阐述了本文研究课题Hadoop平台下基于HDFS的小文件存储问题的问题背景，探讨了研究该课题的实际意义；提出了海量小文件LOSF的定义；随后说明了解决海量小文件存储问题的重要性。最后还选取了部分具有代表性的国内外相关研究，简要介绍了方案原理并说明优缺点。

第二章对本文课题相关的技术背景进行了研究。具体解释了HDFS分布式存储系统的架构及其核心组件的运行机制，系统中对存储操作有重要作用的节点原理和读写流程也进行了深入的分析。最后，对HAR文件归档方案、Sequence File方案、Map

File方案、HDFS Federation方案等四种小文件解决方案的原理和优缺点进行了详细的4

华 中 科 技 大 学 硕 士 学 位 论 文

阐述。

第三章根据前述方案中存在的问题，为解决LOSF存储问题提出了一种新的优化策略——小文件多级处理模块（MPM）方案。对MPM方案的设计思路和体系架构做了清晰的介绍。MPM方案中包括文件预处理模块、文件合并模块、文件索引模块、文件预取和缓存模块以及碎片整理模块等五个部分。其中，文件预处理模块执行文件大小判定操作并对小文件简单分类后传给下一级处理模块，是方案中的准备阶段。举例说明了文件合并模块凭借合并队列和缓冲队列的设计可以将大量的小文件合并成尽可能少的大文件，释放更多的节点内存。而文件索引模块和预取缓存模块的设置，能够提高文件检索的效率。最后，碎片整理模块能够动态自查，保证整个系统空间的搞利用率。最后重新梳理了引入MPM方案后HDFS系统的读写流程。

第四章在第三章的基础上，对基于HDFS的小文件多级处理模块（MPM）的具体实现过程进行了叙述，并注明了各个步骤的算法流程。首先介绍了文件预处理模块中的小文件大小检测算法，提出了小文件的定义，即检测阈值为4.35MB，说明了小文件分类的根据。其次介绍了文件合并模块中合并和缓冲队列的初始化以及队列相互转换的过程。之后通过技术实现文件二级索引机制，为文件所在块及具体数据信息之间建立关联关系。接着介绍了文件预取和缓存模块基于文件操作频率对数据进行动态预取并缓存。最后，对如定时器阈值、系统空间利用率、文件剩余体积大小等判断碎片整理模块是否启动的条件进行了说明。

第五章是实验与分析。为了验证本文所提出的方案的可行性，将本文方案与其他三种方案进行了实验对比。首先，对Hadoop集群伪分布式搭建的实验环境及其参数配置做了简单说明。然后展示了实验用数据集的构成和大小。对实验对比内容及实验项目的细节也进行了介绍。通过节点内存占用实验、小文件写入效率实验、小文件读取效率实验对原生HDFS方案、HAR文件归档方案、Sequence File方案以及本文提出的MPM方案进行了对比，最终验证了MPM方案对HDFS小文件存储问题的优化效果最好。能够有效降低节点内存消耗、提升系统的文件读写速度。

第六章是总结与展望。总结了本课题的研究成果并指出了后续改进的方向。

5

华 中 科 技 大 学 硕 士 学 位 论 文

2 小文件问题相关技术分析

本文的研究是基于Hadoop平台的分布式文件存储系统HDFS中小文件存储问题的优化。因此需要对课题相关的理论知识进行详细的研究和深入的了解。本章首先将对Hadoop系统架构及其中的关键模块进行详细的介绍。其次，对四种现有小文件处理方案：HAR文件归档、Sequence File、Map File、HDFS Federation等方案的优化原理、实现方式及其优缺点进行阐述和说明。

2.1 Hadoop系统架构

Apache Software Foundation公司[28]受到Google开发的Map/Reduce[29]和Google

File System（简称GFS）的引导，在2007年下半年Hadoop作为Lucene[30]的subproject正式引入。作为一个分布式文件系统基础框架，Hadoop的工作原理是将单一的服务器扩充为成百上千台的计算机，形成一个集群。集群中的每一台计算机都作为一个本地服务器为集群系统提供计算和存储服务。除此之外，Hadoop允许用户在集群中使用编程模型跨计算机处理海量数据集。尽管存在集群中的单个计算机损坏导致系统无法工作的风险，但由于Hadoop可以在廉价的硬件上进行部署以完成工作，所以不需要成千上万的硬件支持，可以便捷的达到监测和处理故障的目的，用最短的时间最少的成本为计算机集群提供更好的服务。

图2-1 Hadoop生态系统

6

华 中 科 技 大 学 硕 士 学 位 论 文

Hadoop有许多系统一起工作，但其中最重要的构成是HDFS[31]和MapReduce[32]。HDFS的全称是Hadoop Distributed File System，即Hadoop中的分布式文件系统，为Hadoop提供文件存储和管理功能。可以支持文件的创建、删除、移动以及重命名等操作。MapReduce是Hadoop中的一种底层执行引擎，利用编程模型对海量数据集进行并行高效运算。其具体工作原理将会在后续章节进行详细介绍。

HDFS与MapReduce在Hadoop生态系统[33]中的位置如图2-1所示。目前Hadoop的传统生态系统得到了进一步的扩展，其中一些重要项目有：

Ambari：用于配置和监测Hadoop集群，支持HDFS，MapReduce，Hive， Pig和Sqoop等。以仪表板的形式直观地展示MapReduce，Pig和Hive等程序的完成进度。

Avro：数据序列化系统。

Cassandra：一种不存在SP故障（single point of failure）的可扩展的主数据库。

Chukwa：数据收集系统。

HBase：支持海量数据的结构化表存储。

Hive[34]：支持即席查询和统计数据功能的数据仓库。

Mahout：基于部分人工智能的数据分析算法。

Pig：用于并行运算的高级数据流语言和执行架构。

Spark[35]：一种简单实用的计算引擎，允许包括ETL，人工智能，图像处理等在内的大部分应用运行。具有快速性、通用性等优点。

Tez：一种新型的底部运算模型。通过执行随机的DAG任务来处理大量的交互式用例。完成率高、数据功能强大，有实力逐渐取代Hadoop MapReduce。

ZooKeeper[36]：为其他应用提供支持的协调工具。

综上所述，Hadoop之所以成为许多公司和组织研究和生产的首选的开源分布式文件存储平台，它具有如下5点优势[37]：

（1）可靠性高。Hadoop具有优秀的按位存储算法和高速处理数据的能力。

（2）扩展性强。Hadoop集群中的每一个计算机被分配数据并完成计算任务，每个计算机内可以扩展为数以千记的计算节点（DataNode），用户可以随时对这些节点进行修改、增删的操作。当存储数据量不断增长时可以通过增加新的DataNode来系7

华 中 科 技 大 学 硕 士 学 位 论 文

统正常运行。

（3）效率高。Hadoop会根据各个节点当下的实际负载情况进行动态分配，保证系统内各节点负载的均衡性。同时，实现了集群整体的高效运行。

（4）容错性高。Hadoop可以自动保存数据副本。当某一任务没有成功，可以由副本恢复数据，并且被重新执行。

（5）低成本。与其他的商用大数据处理系统相比，Hadoop是开源的。且对部署硬件的要求不高，用户可以利用价格便宜的普通计算机搭建一个完整的计算机集群，进而进行数据处理。项目的软、硬件成本大大降低。

2.2 分布式文件系统HDFS

2.2.1 HDFS架构

HDFS是Hadoop项目的核心组成，是存储和管理文件数据的基础。采用的是Master/Slave的系统结构，NameNode、Secondary NameNode[38]、Client、DataNode是其重要组成部分。HDFS的系统结构如图2-2所示。

图2-2 HDFS系统架构

8

华 中 科 技 大 学 硕 士 学 位 论 文

（1）Client

客户端。主要功能是当文件被传送到HDFS时将文件切分成一个一个的Block再进行存储。向NameNode发出指令可以获取文件的位置信息；向DataNode发出指令可以对数据进行读写操作。另外还提供一些指令，可以进行如启动、关闭、访问HDFS等操作。

（2）NameNode

名字节点。即HDFS存储结构中的Master管理者，是系统的主节点。管理着HDFS的内存空间以及数据块的映射信息。可以对副本策略进行配置，并协助Client处理操作请求。

NameNode中通过一个NameSpace镜像文件来避免文件元数据因为节点损坏而丢失，另外还引入了日志文件来加强系统的可靠性。

（3）Secondary NameNode

二级名字节点。这是一个NameNode的备份守护程序，分担NameNode上的任务；当NameNode出现状况时，可以帮助其恢复，但不能立马替换NameNode。极大程度上降低了NameNode单个节点发生故障时对系统的影响。

（4）DataNode

数据节点。这是HDFS存储结构中的Slave从节点，执行由主节点NameNode发出的指令操作。

实际的数据块就存储在DataNode中。单个数据被备份成相同的多份，分别保存到不同的DataNode中，每个DataNode中不会用重复的备份数据。在图2-2中，DataNode1、DataNode3、DataNode4中都包含b1数据，但是每个DataNode中都有且只有一个b1数据。其他数据的存储同理。备份机制保证了系统在任意一个DataNode损坏后，仍可以从其他DataNode复制备份文件恢复损坏的DataNode。系统得以正常运转。

DataNode中一个最基本的存储单元叫做Block，一般最多能存储64MB的文件。小于一个Block默认大小的文件也会占据整个Block的内存空间。

9

华 中 科 技 大 学 硕 士 学 位 论 文

2.2.2 HDFS的优缺点

由于HDFS特殊的Master/Slave的系统架构布局，使其具有以下优点[39]：

（1） 适合批量处理海量数据

由于HDFS不需要移动数据，而是通过移动计算的方式来存储文件。且会将固定的数据位置报告给系统，减少系统交互过程，适合批量处理数据。与此同时，HDFS特别适合处理达到GB、TB甚至PB级的数据，是大部分企业存储文件的不二选择。

（2） 对硬件故障具有高容错性

由于拥有备份守护进程，存储在系统中的文件数据集一经生成，系统会执行备份操作，生成多个拷贝数据。之后才将其传输到各个节点中，等待后续的指令操作。HDFS的这种机制允许当某一个数据丢失时，系统自动通过事先备份的数据进行恢复。这使得HDFS得以轻松应对硬件故障问题，系统风险大幅降低。

（3） 保证数据的一致性

HDFS的访问模式为“一次写入，多次读取”，文件一经写入系统后不能够再进行修改，只能追加写入新的文件。保证了写入数据前后的一致性，有着较高的系统稳定性。

（4） 可在廉价设备上扩展

HDFS部署集群时对硬件设备的要求不高，用户可以便捷的通过增删普通商用机的方法增删集群节点，扩展成本低，可扩展性高。

（5） 使用普适的编程语言

HDFS的理想运行平台是Linux，因为它是使用JAVA语言开发的。但某些应用也可以使用C++编辑。掌握这种编程语言的用户可以轻松的使用HDFS进行数据存储工作。

当然HDFS并不是完美的，它也有一些缺点。在低延时的场景下，比如在毫秒量级（ms）读取数据，这是HDFS无法完成的。它只适合高速率的处理数据，保持高吞吐率。“一次写入，多次读取”的访问模式虽然保持了系统数据的一致性，但在特殊场景下，却不支持文件的写入、删除操作，给用户的使用带来不便。最后，跟所有的分布式文件存储系统一样，在面对海量小文件存储问题时，由于小文件的大小通常远远10

华 中 科 技 大 学 硕 士 学 位 论 文

小于一个基础存储空间的大小（通常为64MB），存储空间通常不会被文件占满，有限的节点内存无法承载海量的小文件带来的内存浪费。因此在面对海量小文件时，HDFS的存储性能并不尽如人意。

2.2.3 HDFS读写过程

在HDFS存储文件的机制中，得益于FSDataInputStream类提供的两个接口：PositionReadable接口和Seekable接口，系统可以支持的文件操作方式十分丰富。常见的文件操作指令有新建文件、删除文件、修改文件、查询文件等，其中新建文件和查询文件是分布式文件系统中更加常用的请求。分别对应于文件的读取过程[40]和写入过程[40]，接下来将对这两个操作过程进行详细的介绍。

（1） 文件读取过程

用户通过客户端读取数据过程如图2-3所示。

图 2-3 文件读取过程

HDFS的文件读取过程包含以下步骤：

步骤1：Client调用FileSystem对象的open()接口，在这里获取到一个DistributedFileSystem的实例，是可以打开指定文件所需的数据。

步骤2：FileSystem对象通过远程过程调用协议RPC（Remote Procedure Call

Protocol，简称RPC）向NameNode发送请求，获取文件的Block信息以及Block的位置信息（Block locations）。同一个Block可以返回多个位置信息，这些位置信息根据11

华 中 科 技 大 学 硕 士 学 位 论 文

Hadoop的拓扑规则排序，距离Client近的排序靠前。

步骤3：FileSystem对象通过上一步生成的位置信息序列，返回一个输入流对象FSDataInputStream，用于读取数据和文件位置的定位。为了方便管理NameNode和DataNode数据，将FSDataInputStream封装成一个DFSInputStream对象。随后Client调用read()接口，DFSInputStream对象就可以找到距离最近的DataNode与之连接请求读取数据。

步骤4：DataNode收到数据读取请求，将数据传送至Client。

步骤5：当最近的Block的数据传送完毕后将这个连接通道关闭，与下一个Block相连，继续读取数据。需要注意的是，这些操作对于Client是隐形的，从Client的角度看不存在通道的关闭与重新连接，读取这些数据是一个持续的传送过程。

步骤6：如果所获取到的Block均读取完毕，DFSInputStream会继续执行步骤2，获取第二近的Block及其位置信息，然后重复后续操作。直到所有的Block被读完，此时关闭所有数据流。读取操作结束。

（2） 文件写入过程

用户通过客户端写入数据的过程如图2-4所示。HDFS的文件写入过程包含以下步骤：

步骤1：Client调用DistributedFileSystem中的create()，在HDFS中新建一个文件。

步骤2：通过RPC调用NameNode，在其中新建一个不需要Block关联的文件，存储在NameSpace中。需要注意的是，NameNode会对当前新建文件进行判断，判断内容主要有：该文件是否与已有文件重复，系统是否有权限进行新建操作。任意一项验证不通过，系统会向用户提示异常。

步骤3：FileSystem对象完成前两步之后，与读取文件的步骤类似。系统会返回一个输出流对象FSDataOutputStream，为了方便管理NameNode和DataNode数据流，将FSDataOutputStream封装成一个DFSOutputStream。封装后的数据流对写入文件进行处理，将他们切分成一个一个的Packet，然后按顺序排列成data queue。

12

华 中 科 技 大 学 硕 士 学 位 论 文

图2-4 文件写入过程

步骤4：DataStreamer根据步骤3的顺序为队列中的Packet寻找合适的存储位置。NameNode收到存储请求，返回当前Packet需要存储的DataNode数，将其排列成一个pipeline。之后DataStreamer依次向pipeline中输入数据，直到当前Packet完成写入。

步骤5：DFSOutputStream有一个由切分的Packet组成的队列ack queue，当pipeline中所有被分配的DataNode都成功写入数据后，ack queue自动清除自身的Packet。

步骤6：直到所有的Block被写完，此时关闭所有数据流。

步骤7：DataStreamer收到ack queue自动清除信号，表示当前文件已完成写入，通知DataNode更改标识号。

2.3 编程模型MapReduce

MapReduce是Hadoop中的一个底层执行引擎。使用MapReduce中的编程模型可以运行在Hadoop集群中的所有计算机上，形成一个高速并行处理数据的软件框架。

一个正常的MapReduce任务[42]分为Map任务和Reduce任务，当系统接收到处理数据的请求，首先由Map任务将已经被分割成许多独立的Packet的数据做并行处理，随后输出并按照一定标准排序，再将排序结果传送给Reduce任务。一般来说，MapReduce框架主要执行任务的分配和检测，将失败的任务进行重新传输；而输入和输出的结果都会被存储在HDFS中。这说明Hadoop的计算系统和存储系统是使用同13

华 中 科 技 大 学 硕 士 学 位 论 文

一组节点运行的，这样的机制使得整个集群的灵活度得到提升，可以完整的发挥网络带宽的作用。

图2-5 MapReduce处理数据的流程图

MapReduce运行机制的过程图2-5所示，包含以下步骤：

步骤1：Client启动一个MapReduce任务。

步骤2：JobTracker给Client分配一个 Job ID。

步骤3：运行MapReduce任务所需的source文件包括MapReduce任务形成的JAR文件、配置文件和Client的分割输入数据。拷贝一份传送给HDFS存放在固定的文件夹Job ID中。

步骤4：JobTracker接受到任务请求将其按序排列成队。随后，根据预先设置好的算法作业调度器对队列中的任务进行调度，按照步骤3的分割数据信息为任务新建一个map()，并交给JobTracker运行这个map()。运行map()和reduce()需要使用TaskTracker中的map槽和reduce槽。一般来说，这些槽的数量是固定的。

步骤5：TaskTracker定时向JobTracker发送一个包含当前任务执行进度等数据的心跳信息。最后一个任务执行完毕，相应的心跳信息就会被发送给JobTracker，此时该任务被标记为“完成”，Client会向用户发出任务完成的提示。

综上所述，可以看出MapReduce对数据的处理就是不断的切分再合并的过程。这种将数据切分成小的任务进行处理的方式使得集群中的每个计算节点都能同时并行14

华 中 科 技 大 学 硕 士 学 位 论 文

运算一块不大的部分。保证了系统对数据的高性能处理。

2.4 Hadoop现有技术方案分析

针对Hadoop中的海量小文件问题（LOSF），Apache Software Foundation公司对Hadoop进行了升级，在Hadoop系统中引入了专门的技术方案应对小文件存储。下面将介绍四种方案的存储结构及各自的优缺点。

2.4.1 现有技术方案介绍

（1） HAR归档

Hadoop Archives（简称HAR），顾名思义是一种文件归档技术。简单来说，就是用户通过archive()命令操纵一个MapReduce任务，将一定范围内的小文件合并成为一个大文件，这个大文件中包括原始文件数据以及相应的索引。合并后的大文件被命名为HAR文件，再传送给HDFS进行存储。

图2-6 HAR文件存储结构示意图

如图2-6所示是HAR归档方案的存储结构示意图。一个HAR文件中原始的小文件数据，这里每个小文件被标记为一个Part文件；以及一层主索引和一层二级索引信息。索引文件的作用是在读取文件时，方便进行查找和定位。

HAR归档方案直接将小文件合并成大文件的工作原理虽然比较简单，但是由于文件数量的减少，使得NameNode的内存占用直接降低了。另一方面，由于使用了MapReduce对文件进行操作，即MapReduce对文件的访问是透明的，对HAR文件中小文件的输入也不会产生影响。用户可以便捷的通过一个“HAR://URL”的命令格式对HAR文件中的Part文件进行操作。

当然HAR归档方案并不是完美的。首先，虽然Hadoop对“HAR://URL”命令格15

华 中 科 技 大 学 硕 士 学 位 论 文

式的支持较为全面，但是Hadoop并没有提供关于Part文件相关元数据的管理接口。这给HDFS处理经过HAR归档后的小文件带来了难度。其次，HAR归档方案中为了方便小文件读取时的查找和定位操作，使用了两层索引。读取文件时需要遍历两层索引文件才能够完成文件定位，读取速度略有降低。最后，HAR归档方案在创建HAR文件的同时也会为其创建一个副本文件，这部分副本文件占用了系统中额外的存储空间。一旦需要对HAR文件中的任意一个文件进行修改，则需要重新创建整个HAR文件及其副本文件，十分耗时。

（2） Sequence File

Sequence File方案也是一种常见的小文件存储解决方案。核心原理依旧是将小文件合并成大文件，但存储结构不同。Sequence File方案将其内部的小文件名及小文件内容一一对应转化为Key-Value形式的数据。文件名是Key，文件内容是Value。Sequence File方案中数据的存储结构如图2-7所示。

图2-7 Sequence File存储结构示意图

Sequence File方案的存储结构在节省系统节点内存的基础上，考虑到多层索引带来的读取时间增加问题，使用了扁平化的Key-Value索引。但这也是问题所在，Key-Value形式的数据并没有建立真实的索引。虽然读取排位靠前的文件内容时间大大降低，但是读取随机文件时，必须遍历整个Key-Value序列才能找到目标文件，反而降低了系统的文件读取效率。还有一个与HAR归档方案相同的缺点是，Sequence File方案中，HDFS也无法如处理正常文件一样管理合并后的小文件。

（3） Map File

Map File方案[43]在Sequence File方案的基础上，加入了真正的索引文件。如图2-8所示是改进后的存储结构示意图。一个完整的Map File中除了大量Key-Value形式的数据，还包括小文件的索引文件。

其中一部分小文件的文件名和文件的偏移值共同组成了Map File的索引文件。提前预取这部分文件，可以在读取小文件时，快速的定位文件位置。相比HAR归档方案减少了一层索引，降低了文件查询时间；相比Sequence File方案，增加了真实索引，16

华 中 科 技 大 学 硕 士 学 位 论 文

提高了文件查询效率。缺点是本方案中HDFS也无法正常管理合并后的小文件。

图2-8 Map File存储结构示意图

（4） HDFS Federation

为了解决合并文件后，HDFS对元数据管理的限制。提出了HDFS Federation方案[44]。该方案的存储结构示意图如图2-9所示。

图2-9 HDFS Federation存储结构示意图

本方案中，NameNode被水平扩展为n个空间，每个NameNode n执行来自总节点NameNode的指令，并且向总节点登记和汇报信息。每个扩展节点之间相互独立，管理本空间的元数据信息。

该方案使得将小文件切分成多个块存储在不同的扩展节点中，由于对海量小文件的元数据进行了分散管理，大大减低了节点被元数据信息完全占用的风险。

HDFS Federation方案不再存在前述三种方案的通病，HDFS可以对元数据信息进行正常的管理和操作。但是也正因为“分散管理”的技术原理，一旦系统中任意一个NameNode出现问题，该扩展节点下管理的所有空间将不可用，其中存储的数据将会丢失，整个系统的数据不再完整。因此，尽管有着相对良好的存储性能，但高风险低可靠性的数据特性还是让HDFS Federation未能很好的应用到实际场景中。

17

华 中 科 技 大 学 硕 士 学 位 论 文

2.4.2 存在的问题

根据本节所述，企业和学术界的研究人员为了解决Hadoop中海量小文件存储效率低下的问题，进行了大量的实验和研究。这些研究成果针对具体的系统和不同的文件类型达到了不同程度的优化效果，但是仍然存在诸多问题。总结起来可以概括为如下几个方面。

（1）小文件跨块存储

将海量小文件按照一定依据合并成大文件再进行存储是解决现有LOSF存储问题的常用的思路。由于HDFS自身结构的限制，在合并队伍末端的小文件，很可能被跨块存储，给后续的文件操作如查找、读取、修改、删除等增加了难度。

（2）合并算法不完善

按照一般的按序合并的依据，由于合并队伍末端的小文件其文件大小不固定，有可能合并后，合并文件的体积仍然不能填满默认节点内存。出现的这种合并文件大小差异过大的问题，使得节点内存空间未被充分的使用。

（3）索引机制过于复杂

索引机制是文件合并后文件位置定位的关键环节。缺失索引环节会导致文件合并后数据冗杂读取文件困难；索引机制层级过多会导致文件遍历时间增加，文件读取速率下降。

2.5 本章小结

如何选择适当的合并算法以及索引机制，降低文件的读写过程所消耗的时间，是解决海量小文件存储问题的关键点，也是本文要讨论和研究的主要内容。接下来，本文将针对现有方案中的缺点提出了相对应的解决方案。并对所提方案的各个模块进行详细的分析与介绍。

18

华 中 科 技 大 学 硕 士 学 位 论 文

3 基于HDFS的小文件多级处理模块（MPM）的设计

为了要适应大量体积较大的大型数据的存储， HDFS设计的是Master/Slave的节点关系，整个结构中存在着一个NameNode和多个DataNode。随着存储系统中越来越多的小文件的产生，这些大小文件的混合存储使得HDFS的内存空间利用率并不高，系统性能大幅下降。更严重的还会导致系统无法承载而发生故障。

如何解决海量小文件在分布式存储系统HDFS中的存储性能低下的问题正是当下亟待解决的热门课题之一。这个问题得到了许多企业的研究者和学者的注意，他们针对自身接触的文件类型和实际情况提出了许多经典的方案并进行了验证。几乎所有方案的核心原理都是先合并大量小文件以填充内存空间，随后为了提高读写效率增加或删除一些文件处理模块。比如引入索引机制，帮助系统快速定位合并后的文件位置；引入预取和缓存机制，减少系统中节点的交互过程，节约文件读取时间，达到提升文件读取效率的目的等。然而通过2.4.2节的分析已知，这些方案因为自身研究系统或研究文件类型的局限性，虽然一定程度上的提高了系统的小文件存储性能，但仍然存在诸多的问题。针对目前存在的问题，本文从以下几个方面对小文件存储问题的解决方案进行了改进。

（1）完善文件合并策略，避免小文件被跨块存储或文件合并后体积不均。

（2）增加文件之间的关联性，降低文件读取时间。

（3）选择合适的索引机制。避免索引过于复杂影响文件读取效率。

（4）增加动态预取缓存机制。

（5）增加碎片整理模块。清理异常文件为后续存储提供空间。

总结前述方案的工作原理，合并小文件直接减少了系统中需要存储的文件数量，是处理海量小文件的必经一步，也是关键一步。好的优化合并策略可以避免合并后的大文件体积不均匀或者文件被跨块存储的问题；其次简化索引机制，避免本末倒置的繁杂的索引机制，增加节点交互时间。另外，针对文件的读写操作流程中可以做的优化有：增加预取和缓存模块。对用户经常操作的文件做频率统计，提前将读取频率高的热点文件取出并缓存，这样可以节约大量的访问时间；最后加入碎片整理模块，将19

华 中 科 技 大 学 硕 士 学 位 论 文

系统中的数据存储空间可利用程度最大化。通过上述多级操作的共同处理，提高小文件合并效率，降低NameNode内存浪费，减少节点交互时间，使得整个系统对小文件的处理性能得到可观的提升。

综上所述，本文提出了一种小文件多级处理模块（Multilevel Processing Module for

Small Files，以下简称MPM）。下面将详细介绍小文件多级处理模块（MPM）的架构设计及各个模块的详情。

3.1 小文件多级处理模块（MPM）的架构

小文件多级处理模块（MPM）中通过多模块连续处理达到提升HDFS系统小文件存储效率的目的。MPM中包含以下五个主要的优化模块：

（1）预处理模块。首先在所有文件中筛选出符合条件的小文件，进行简单分类后等待处理。

（2）合并模块。基于空间最优化的原则，合并算法引入了合并队列和缓冲队列，将小文件合并为尽可能接近数据块存储阈值的大文件。一方面直接减少了数据库中小文件的数量，降低了内存消耗；另一方面避免合并后仍有大块的空白空间，使存储空间得到最大程度的利用。

（3）二级索引模块。以小文件的修改日期为依据建立一级索引，小文件的文件名及文件类型作为二级索引。虽然设计了两层索引，但索引的建立依据较为简单，且不再作为NameNode的一部分进行存储。在降低Name Node内存消耗的同时也保证系统的交互时间的不会大幅的增加。

（4）预取和缓存模块。用户在实际存储文件时，会对一部分文件频繁的进行读取，增加预取和缓存模块，将用户读取次数较多的文件提前缓存下来，减少用户获取这部分文件时产生的重复的交互时间。

（5）碎片整理模块。经过多次读写删除操作后，系统中会存在一些空白空间，将这部分空白空间再利用，可以一定程度的提高系统的利用率。

以上五个模块共同组成了一个完整的MPM架构。要实现上述多模块、多级处理的小文件存储优化方案，需要在原生HDFS的基础上加入了一个Client代理服务器20

华 中 科 技 大 学 硕 士 学 位 论 文

（Client proxy）。这个代理的主要作用就是搭载着MPM，在不影响原生HDFS存储系统的情况下，对小文件进行处理，并把处理后的数据传输给HDFS。

图3-1 结合MPM的新HDFS系统架构

结合了MPM的HDFS分布式文件存储系统的新架构，可以从图3-1中看到由三个部分组成，分别是用户操作层，文件处理层和文件存储层。

用户操作层：用户进行文件操作的指令发出层，由这一层的Client客户端将指令发送给下一文件处理层。

文件处理层：这是新架构中最关键的模块，用于对小文件进行分类、合并处理等操作。包括小文件多级处理模块（MPM），以及客户端代理。MPM中又由文件预处理模块、文件合并模块、文件索引模块、文件预取和缓存模块以及文件碎片整理模块5个部分组成。

文件存储层：这是新架构中的最后一层，即原生的HDFS系统。为新架构提供数据存储功能。

21

华 中 科 技 大 学 硕 士 学 位 论 文

下面将对文件处理层MPM中五个主要模块的工作原理进行详细的介绍。

3.1.1 文件预处理模块

文件预处理模块的工作内容包括小文件判定及小文件分类。首先判定接收到的文件是否属于小文件；接着将符合条件的文件根据其后缀扩展名进行简单的分类，相同类型的文件分类到一起；最后送往文件合并模块。不符合条件的文件则直接送到文件存储层，即原生HDFS集群进行存储。为后续小文件合并做准备。

关于如何判定一个输入文件是否属于小文件的问题。本文在对HDFS的架构进行背景介绍时，提到HDFS中一个标准存储块的可用体积是64MB，存储体积小于这个数字的文件，会造成存储空间的浪费。但是，并不是所有小于64MB的文件都应该叫做小文件，都需要进行合并。小文件判定阈值设置的太高会导致文件没有合并的必要，或者无法合并的情况；阈值设置得太低会增加一个合并文件内的小文件数量，增加索引的遍历时间，影响系统的读文件效率。

在文献[24]中，Bo Dong等人对HDFS小文件的判定阈值进行了研究。存储同一份数据，在小文件判定阈值各不相同的情况下，从0.5MB到64MB不等进行了23次合并，最后实验对比多次合并文件所耗费的时间，发现当小文件阈值设置为4.35MB时，HDFS的文件合并效率和系统的存储性能是最优的。因此，在本文之后的研究中，采用的小文件阈值也设定为4.35MB，即小于或等于4.35MB的文件是小文件。小文件通过判定逻辑的筛选，继续被传送给文件合并模块；大于4.35MB的文件将被直接传送到HDFS存储层。

3.1.2 基于空间最优化的合并模块

当前比较流行的文件合并算法的核心思想都是将系统中的小文件按序合并，一旦超过HDFS标准存储空间的大小即暂停合并，把未超过的部分打包成合并文件；再按序合并下一个文件，直到所有文件被合并完成。假设现在有A-Z共26个体积各异的文件，按照上述合并算法进行合并。合并结果如图3-2所示，最终将26个小文件合并成了10个文件集合。合并文件中小文件个数最多的有6个，最少的只有一个。这种22

华 中 科 技 大 学 硕 士 学 位 论 文

设置固定阈值的合并方法，使得系统中合并文件中的小文件数量不均，更严重的是文件之间体积相差很大，内存空间未被完全利用。对系统存储性能的提升并不明显。

图3-2 普通算法合并效果

为了改善普通算法的局限性，尽可能的将存储空间使用率最大化。本文于合并模块设计了一种基于空间最优化的小文件合并算法。该算法在合并时不止存在一个单一序列，而是定义了两个队列：合并队列和缓冲队列。目的是除固定文件阈值外增加队列状态为合并依据，进行合并的二次判定。相比上文提到的普通合并算法，增加一个二次判定依据可以使合并后的大文件体积基本均匀分布，降低NameNode的存储负荷，取得更优的文件合并效果。另外，该算法能够尽量少的把文件分割成冗杂块，避免跨块存储的情况发生。

合并队列的作用是存放待合并的小文件，当文件长度达到合并阈值后，将文件打包并存储到HDFS中。随后清空合并队列，接受下一批待合并的小文件。导致合并队列超出合并阈值的文件会从合并队列中剔除，交给缓冲队列处理。合并队列中的文件累计到一定程度，会优先在缓冲队列中寻找合适的文件填补剩余的空白。这两个队列的角色可以互换，保证队列中始终有等待合并的小文件数据。具体的文件找寻条件以及队列转换条件会在第四章的算法实现小节中做详细的介绍。

经过基于空间最大化的合并算法，图3-2中A-Z的26个体积不同的小文件重新合并后的效果示意图如图3-3所示。合并后的文件集合数从10个减少到了8个，除最后一块存储空间外，其余文件集合的体积大小基本一致，且几乎占满整个数据块。23

华 中 科 技 大 学 硕 士 学 位 论 文

初步证明本合并算法在降低文件数量的同时，系统内存空间的使用率也得到了显著提升。

图3-3 空间最优化合并算法合并效果

3.1.3 二级索引模块

小文件经过前两个模块的处理，已经被分类合并为一些大文件集合。合并文件随后被传送到Hadoop上按照正常存储流程，自动进行备份再分别存储于多个DataNode上。当用户需要提取某个文件时，为了查找该文件被处理后在系统中的存储位置，这时需要一个索引系统进行协助。

在前文对现有技术方案分析的部分指出了当前小文件的索引机制尚不够完善。例如，HAR归档方案中的二级索引算法就存在着文件查找效率低的问题。因为每个索引文件会伴随着其目标文件一起被存储。原因除了二层索引交互时间增加，影响系统的读取效率之外；基于NameNode建立的索引通常文件大小为100B左右，假设每个合并文件中平均有100个小文件，那么索引文件将会占用接近10MB的内存空间。本来是为了提升文件读取速率的操作，反而牺牲了大量的内存空间。使用了类似原理的解决方案在快速读取文件和系统整体性能的取舍上有些本末倒置。

因此本文提出的新的索引模块的设计思路是基本保留HAR归档方案的算法模式，但是更改二级索引的建立标注和索引的存储位置，以改善NameNode上索引空间臃肿的问题。其中一级索引以小文件的修改日期为依据，依然存放在NameNode中。文件名称及文件类型作为二级索引，存放在DataNode中。索引模块工作时，NameNode首24

华 中 科 技 大 学 硕 士 学 位 论 文

先收到由用户操作层发来的小文件访问指令；一级索引开始工作，在索引列表中搜索匹配的文件修改时间找到对应的合并文件的位置，得到该文件被切分存储在哪些DataNode中以及其他块及块偏移数据等。相应DataNode收到访问指令，在自身的二级索引中匹配对应的文件名称以及文件类型，找到目标文件的最终存储位置。将结果反馈给客户端，等待操作执行。索引文件的索引结构如图3-4所示。

图3-4 二级索引的结构示意图

3.1.4 预取和缓存模块

已知NameNode 的内存资源是十分有限且宝贵的，为了降低繁琐的索引机制对内存负荷的占用，上节所述MPM方案中的索引模块我们舍弃了一部分读取速率以换取更多的存储空间。为了补偿读取速率的损耗，因此引入一个预取和缓存模块是十分必要的。

预取和缓存模块的处理思路是提前将用户经常操作的文件进行缓存，当用户再次读取该文件时，系统可以直接从缓存模块获得该文件的相关数据，节省与一层一层的节点交互的时间成本。

当一个文件要存储到本文提出的包含MPM的HDFS新架构中，无论文件体积是否符合小文件判定标准，是否经过MPM的多级处理，最终都会传输给HDFS原生系统进行数据的存放。所以，本模块是独立于MPM中其他模块的，直接与原生的HDFS25

华 中 科 技 大 学 硕 士 学 位 论 文

客户端连接处理数据。如图3-5所示缓存信息结构，缓存索引信息包括文件读取频率数以及其他相关信息。用户对某一文件每读取一次，就给该文件的读取频次数值加一。数值达到一定程度，该文件就会被判定为用户常用文件，由预取和缓存模块提前将其文件信息缓存到本地。用户下一次读取时，将不再需要与底层HDFS进行交互，达到提高系统文件读取效率的目标。

图3-5 缓存信息结构

需要注意的是，读取频次达到什么数值才会被预取模块缓存？这与几个系统环境参数有关。比如系统能够分配给预取和缓存模块的空间，可缓存空间越大读取频次门限值越低，可以被缓存的文件就越多。比如用户经常操作文件的个数，用户对文件的读取频次比较平均，读取频次数值相同的文件，缓存模块将优先缓存最近读取的文件。因此读取频次门限的设置需要动态的校准。另外，每个文件的读取频次并不是实时传输给预取和缓存模块的，这中间存在一些时间延迟，这会造成一定的文件缓存误差。

3.1.5 碎片整理

加入了多级处理模块MPM的分布式文件系统中，用户操作层发出删除指令后，系统会执行两步操作。首先，从NameSpace中删除与该文件相关的数据，并查询被删文件的残留Blocks。其次，将上一步找到的Blocks放入专门的无效Blocks中，等到下一次heartbeat信息发送成功时，一并将删除命令告知DataNode；随后清理被删文件的剩余数据块。由于系统调用了FSDirDeleteOp类的静态接口来执行命令，但这个接口仅仅是把目标文件从节点空间中的可用标志位做了修改，并没有写入编辑日志中，并没有完成真正意义上的删除。这些文件可以被称作系统中的碎片。

碎片整理模块工作时，需要遍历系统中的文件标识号，记录标识号失效的文件位置，这些文件就是本模块需要清理的对象。然而要进行碎片整理，首先要解决两个重要问题，即何时开始整理以及如何整理。最简单的方式是在碎片整理模块中植入一个定时器。每一个定时周期开始时，碎片整理模块即开始运行。显而易见的是，当系统26

华 中 科 技 大 学 硕 士 学 位 论 文

空间利用率较高且文件操作不频繁的情况下，模块仍然要反复遍历所有合并文件的文件标识号以检查碎片数量。

因此本文的碎片整理模块不仅设置模块运行时间，还需要设置清理阈值。只有碎片空间超过总存储空间一定比例，系统中碎片数量过多且模块定时器开启的情况下，碎片整理模块才会运行。这样一方面避免了系统被大量失效文件长时间堆积占用内存，也避免了模块运行过于频繁使得系统操作变得繁琐。

具体的参数设置分析如下：

（1）定时器一个循环周期时设置为10分钟，即每10 分钟检查一次合并文件的元数据，判断它们是否需要进行整理。

（2）由于每一次清理任务运行花销较大，为了不影响系统的节点负载。设定一个清理阈值，当整体空间利用率小于20%时才进行整理。

（3）具体到每一个合并文件，整理的依据是该合并文件中无效小文件的数目占该合并文件中所有小文件的数目的比值大于50%。

综上所述，碎片整理模块的运行思路如下：当模块定时器打开，模块开始遍历合并文件中的小文件。如果该小文件的索引标识号为真，说明这个小文件仍然被正常存储。否则，说明这个小文件被删除或者损坏。判断系统中的小文件碎片占比，如果超过20%，则对碎片占比大于50%的单个文件夹进行碎片整理。删除其中标识号为假的文件索引及内容，并将结果反馈给编辑日志。重复上述步骤直到小文件被遍历完成，最后删除为空的合并文件夹，将标识号分配给新的合并文件，即完成整理。碎片整理模块进入休眠状态，等待下一次定时器周期启动。

3.2 小文件多级处理模块（MPM）的读写流程

本文提出的小文件多级处理模块（MPM）的优化步骤主要是面向系统中最常见也最能体现系统性能优劣的读取、写入、删除等操作的优化。引入了MPM的处理后，HDFS的读写、删除流程发生了变化，具体的介绍见下文。

3.2.1 读取文件

图3-6展示了用户通过含MPM的HDFS读取文件的流程图。具体操作步骤如下：

27

华 中 科 技 大 学 硕 士 学 位 论 文

图3-6 读取文件操作流程图

步骤1：用户执行读取文件操作，发出文件读取请求传给数据处理层的MPM。

步骤2：根据待读取文件信息获得其存储数据。首先文件预处理模块根据文件标识号判断文件是否为小文件。如果是，进入步骤3。否则进入步骤4。

步骤3：小文件被送到文件预取和缓存模块。根据文件名称查找该文件的读取频次，判断其是否为用户的常用文件。如果是，则在预取和缓存模块中以其文件名称为关键信息获取提前缓存的文件内容，将结果返回给用户。否则进入步骤4。

步骤4：将读取请求、文件信息传送给文件存储层直接查询。根据文件修改日期，与NameNode上的一级索引进行匹配；根据文件名称和文件类型，与DataNode上的二级索引进行匹配。最终定位到文件信息。

步骤5：DataNode运行read()操作，将文件所在位置的Blocks中的数据接连传送给Client。

步骤6：文件读取结果返回给用户。读取文件操作完成，相应数据流关闭。

28

华 中 科 技 大 学 硕 士 学 位 论 文

3.2.2 写入文件

图3-7 写入文件操作流程图

用户通过含MPM的HDFS读取文件的流程图如图3-7所示。具体操作步骤如下：

步骤1：用户执行写入文件操作，发出文件写入请求传给数据处理层的MPM。

步骤2：文件预处理模块的文件判定逻辑判断传入的文件是否小于或等于小文件判定阈值。结果为真，该文件是小文件，将其标记准备进入文件合并模块。否则，该文件是大文件，直接将其传给HDFS进行存储进入步骤6。

步骤3：文件预处理模块的分类逻辑将小文件根据文件扩展名进行简单分类，然后按文件后缀传给文件合并模块。

步骤4：文件合并模块根据空间最优化的合并算法将大量的小文件合并，形成合并文件和二级索引文件。其中，合并文件包含要写入文件的完整文件信息；索引文件则是两层索引构成的序列文件，随合并文件一同传送给HDFS客户端，等待系统有读取请求时被使用。

步骤5：合并文件被传到数据存储层的HDFS进行存储。

步骤6：HDFS中NameNode接收到文件存储信号，对文件信息备份、切分存储到DataNode上。特别的是：经过MPM的处理合并文件的体积十分接近存储块阈值，可以直接分配给一个DataNode进行存储。而步骤2中被直接传给HDFS的文件，文29

华 中 科 技 大 学 硕 士 学 位 论 文

件体积可能较大，需要先进行分割才能存储。

步骤7：DataNode确认写入文件的数据信息，将写入结果报告给NameNode以形成与文件信息一一对应的元数据。

步骤8：文件写入结果返回给用户。写入文件操作完成，相应数据流关闭。

3.2.3 删除文件

图3-8 删除文件操作流程图

用户通过含MPM的HDFS删除文件的流程图如图3-8所示。具体操作步骤如下：

步骤1：用户执行删除文件操作，发出文件删除请求传到数据处理层的MPM模块。

步骤2：MPM的文件预处理模块判断待处理文件是小文件还是大文件。如果是小文件，则将小文件名加上小文件类型标记，进入步骤3。否则直接将指令传送到HDFS客户端，进入步骤4。

步骤3：判断待处理小文件是否是预取和缓存模块里的文件。获取小文件的被读取的次数，如果满足用户常用文件的标准，说明预取和缓存模块中已提前缓存了该文30

华 中 科 技 大 学 硕 士 学 位 论 文

件的信息。删除模块内与该文件相关的信息，继续下一步。

步骤4：将删除请求、文件信息传送给文件存储层的HDFS客户端进行信息匹配。遍历一级索引找到对应文件修改日期的NameNode，根据查询结果与二级索引上的DataNode交互，查找拥有相同文件名称和文件类型的文件。得到待删除文件的文件位置。

步骤5：更改文件标识号为无效。删除其中文件索引数据及相关内容。

步骤6：将删除结果汇报给编辑日志。

步骤7：文件删除结果返回给用户。删除文件操作完成，相应数据流关闭。

3.3 本章小结

本章通过分析已有的小文件解决方案的不足，对存储过程中每一个有空间提升或改善的步骤进行了一系列的优化。最终提出了多模块共同作用的、独立于HDFS之外运行的小文件多级处理模块（MPM）。紧接着本章对小文件多级处理模块的五个主要构成部分：文件预处理模块、文件合并模块、文件索引模块、文件预取和缓存模块及碎片整理模块的设计原理及思路进行了详细的阐述。最后，对引入MPM的新Hadoop分布式文件系统的读取、写入及删除操作的流程进行了更新说明。

31

华 中 科 技 大 学 硕 士 学 位 论 文

4 基于HDFS的小文件多级处理模块（MPM）的实现

在上一章中，详细的说明了本文基于HDFS提出的小文件多级处理模块（MPM）的设计思路。MPM包括五个模块，分别是：预处理模块、基于空间最优化的合并模块、二级索引模块、常用文件预取和缓存模块、碎片整理模块。预处理模块根据小文件判定标准判断输入文件是否是小文件，从而为是否进行合并做出选择；合并模块将经过预处理的小文件通过两个特殊队列之间的相互转换和排列，合并为一批文件数量平均，文件空白空间少的大文件集合，提高系统存储空间的使用率。索引模块依旧使用了二级缓存，但两级索引的位置不全存放在NameNode中，这种设计除了能提升查询速度，还能使索引在内存空间中占用更少的体积；碎片整理模块在满足系统设定条件的情况下对无效文件和空白空间进行整理，将部分文件进行重新合并。本章将对MPM各个模块的算法实现进行阐述。

4.1 文件预处理模块

图4-1 文件预处理模块算法流程图

32

华 中 科 技 大 学 硕 士 学 位 论 文

文件预处理模块是MPM的第一步，主要功能是判定收到的文件是否是小文件，并按照文件扩展名对其进行简单分类。这个模块是对文件的一个过滤，为下一步合并操作提供数据。将文件简单的按照扩展名进行分类的方式，避免了精细分类所产生的空间占用和时间损耗。

预处理模块的算法流程图如图4-1所示。当客户端虚拟代理收到用户操作层发送来的文件操作请求时，预处理模块会最先收到这个信息。预处理模块同时获取代理的

IP 地址以确认相应数据库存储位置。文件进入MPM，预处理模块首先在已有文件名称列表中对比，当前文件是否已存在，对比关键词是文件的对象标识号。没有找到重复值，说明该文件是首次写入。否则，说明文件已存在，不能重复存储。

进入小文件判定逻辑部分，本文已经在3.2.1节中说明：文件体积不大于4.35MB的文件属于小文件。若通过此步骤判定文件是小文件的话，将文件按照文件扩展名分类，等待分配给对应的合并文件。大文件则直接传送到文件存储层的HDFS客户端进行存储。

4.2 基于空间最优化的合并模块

表4-1 合并模块相关变量及参数定义

变量与参数定义

本文标签： 文件 合并 模块