一种Hadoop小文件存储优化策略研究

摘 要：随着“大数据”时代的到来，Hadoop等大数据处理平台也应运而生。但其存储载体――Hadoop分布式文件系统却在海量小文件存储方面存在着很大缺陷，存储海量小文件会导致整个集群的负载增高、运行效率下降。为了解决这一针对小文件的存储缺陷，通常的方法是将小文件进行合并，将合并后的大文件进行存储，但以往方法并未将文件体积大小分布加以利用，未能进一步提升小文件合并效果。本文提出一种基于数据块平衡的小文件合并算法，优化合并后的大文件体积分布，有效降低HDFS数据分块，从而减少集群主节点内存消耗、降低负载，使数据处理过程可以更高效的运行。

关键词：HDFS；小文件存储；小文件合并算法

中图分类号：TP391.41 文献标识号：A 文章编码：2095-2163（2015）03-

Research on Small Files Optimized Storage Strategy in Hadoop System

DU Zhonghui， HE Hui， WANG Xing

（School of Computer Science and Technology， Harbin Institute of Technology， Harbin 150001， China）

Abstract： With the advent of "BIG data"， big data processing platform such as Hadoop has emerged. But its storage carrier --Hadoop distributed file system has many significant flaws on the storage of mass small files， storing massive amounts of small files will not only increase the load of entire cluster， but also decrease operating efficiency. In order to solve the defect， the usual method is to merge small files to a big one， and then it will be stored instead. However， the conventional method does not take advantage of the volume size distribution， so it failed to further enhance the combined effect of small files. This paper presents a data block based on a balance of small files merging algorithm to optimize distribution of merged large files volume， which could effectively reducing the HDFS data block. Thereby the reducing of primary node memory consumption and running load will cause data processing can be run more efficiently.

Keywords： HDFS； Storage of Small Files； Small Files Merge Algorithm

0 引 言

在2012年，“大数据”开始在国内兴起、并普受关注，随后即公认为2013年则是中国的“大数据元年”[1]。根据ZDNET的数据显示[2]，2013年中国产生的数据总量超过0.8ZB（相当于8亿TB），已两倍于2012年，具体来说就相当于2009年全球的数据总量。由此预计到2020年，中国产生的数据总量将是2013年的10倍，也就是必将超过8.5ZB。

Hadoop在诸如可伸缩性、健壮性、计算性能和成本上均具有无可替代的优势，并在事实上已然成为当前互联网企业大数据分析的主流平台[3]。Hadoop采用的是Hadoop分布式文件系统（Hadoop Distributed Filesystem，以下简称HDFS）来进行数据存储。但由于Hadoop集群利用了Namenode主节点存储集群中所有数据块的信息元数据，所以当存储对象变为体积在5MB以下的海量小文件时，Namenode节点的运行压力将会急剧上升――占用更多的内存来存储信息元数据；同时，处理大量小文件时就需要建立更多的MapReduce任务，而大量的MapReduce任务间的交互、通信基数也必将增大CPU的开销，这会使Hadoop集群的整体运行效率呈显著下降态势。

本文提出一种基于数据块平衡的小文件合并算法，用于优化HDFS的小文件存储以及数据处理过程，使系统可以实现更为平稳、高效的运行。

1 相关工作

海量小文件问题是工业和学术界的公认难题[4]，通常研究认为大小在5MB以内的文件即称为小文件。目前的文件系统，包括本地文件系统、分布式文件系统和对象存储系统，都是主要针对大文件而研发设计的，比如XFS/EXT4、Lustre、GlusterFS、GPFS、ISLION、GFS、HDFS，在元数据管理、数据布局、条带设计、缓存管理等实现策略上都侧重大文件，而海量小文件应用在性能和存储效率方面却会大幅降低，甚至无法工作。

目前实际中，小文件应用日趋常见和普及，如社交网站、电子商务、广电、网络视频、高性能计算，这里举几个典型应用场景。著名的社交网站Facebook存储了600亿张以上的图片，推出了专门针对海量小图片定制优化的Haystack[5]进行完善存储。淘宝目前则是最大C2C电子商务网站，其存储超过了200亿张图片，平均大小仅为15KB，为此也针对性推出了有关小文件优化的TFS[6]文件系统来进行图片存储，并且还实现了开源。而FastDFS[7]针对小文件的优化则类似于TFS。国防科学技术大学也对Lustre进行了小文件优化工作，并在OST组件中设计实现了一种分布独立式的小文件Cache结构：Filter Cache，通过扩展Lustre的OST端的数据通路，在原有数据通路的基础上，增加了对小对象I/O的缓存措施，凭此来改善Lustre性能[8]。

当下有关HDFS小文件存储优化的研究方面，文献[9]提出了一种新的文件合并策略，对系统 I/O性能发挥了一定的优化作用，因而提高了分布式文件系统的性能。文献[10]则针对HDFS存储小文件的问题，对HDFS存储前的小文件处理工作和存储后的检索，提出专项相关算法，在一定程度上提高了 HDFS对小文件的存储和读取效率。此外，另有文献[11]提出一种将小文件合并为大小为一个单一的大文件、再存储于HDFS中的方法，即合并后的文件体积等于所有小文件的体积和，从而使系统的存储及CPU计算开销都得到了有效控制与降低。但是其并未针对小文件的体积大小具体分布以及HDFS文件块大小作进一步的设计优化。针对以上不足，本文提出一种基于数据块平衡的小文件合并算法，实现了HDFS的小文件存储优化，使系统可以更高效、合理地运行与工作。

2 HDFS小文件存储缺陷及解决方案

Hadoop分布式文件系统（以下简称HDFS）在处理大体积数据文件时的表现十分优异。HDFS会将输入的数据文件切分为64MB大小的数据块。集群的Namenode节点将存储集群中的所有数据块的信息元数据，Datanode节点则存储所有数据块实体，而且每个信息元数据将占用Namenode节点150字节的内存空间 。这些数据块将由MadReduce框架进行调用处理。

Hadoop在处理大量小体积文件（一般大小为10KB～5MB）时是十分低效的。这类小文件将给Hadoop的性能表现带来显著影响。首先，在Hadoop中存储大量小体积文件将会导致Namenode中用于存储数据块信息元数据占用内存的增大，进而限制了这个集群的整体性能，例如对于一个大小为1GB的大文件，HDFS会将其切分为16个大小为64MB的数据块，此时Namenode内存开销仅为2.4KB，但如果将其切分为1GB的一万个100KB的文件，Namenode的内存开销将增长至1.5MB，即增长了600余倍；其次，在块大小范围内的小文件则将依然占用64M的空间，处理大量小文件就需要建立更多的MapReduce任务，而大量的MapReduce任务间的交互、通信数目也将增大CPU的开销。

针对Hadoop在处理大量小文件的缺点与不足，一般的解决方法是将小文件合并为一个大文件后再导入HDFS。采用这种策略将具有相当优势，具体论述如下。

首先，减少了大量元数据，降低了NameNode节点负担。通过将大量的小文件存储到一个大文件中，从而把大量的小文件数据变成大文件数据，减少了文件数量，也就减少了NameNode的元数据数量，提高了元数据的检索和查询效率，而且降低了文件读写的I/O操作延时，同时节省了大量的数据传输时间。离散化的小文件元数据开销所占比重较大，若大幅减少元数据，将直接导致性能的显著提升。合并后的大文件存储在磁盘文件系统上，相当程度上就降低了磁盘文件系统在元数据和I/O方面的压力，因此即可改善每个节点的存储性能。

其次，增加了数据局部性，提高了HDFS存储效率。磁盘文件系统或者分布式文件系统中，文件的元数据和各类数据存储在不同位置。采用合并存储机制后，小文件的元数据和各类数据均可连续一并存储于大文件中，这即于无形之中显著增强了单个小文件内部的数据局部性。小文件合并过程中，可以利用文件间的空间局部性、时间局部性以及关联，尽量将可能连续访问的小文件在大文件中进行连续存储，为此增强了小文件之间的数据局部性。这也直接降低了磁盘上随机I/O比率，将其转换为顺序I/O，如此即能有效提高I/O读写性能。另外，小文件单独存储将会形成外部和内部碎片，而合并存储后存储碎片将明显降低，这也极大提高了小文件存储效率。

再次，简化了Hadoop节点I/O访问流程。采用小文件合并存储后，I/O访问流程发生了重大变化，主要体现在存储节点磁盘文件系统上。当磁盘文件系统读写一个小文件，系统能量更多地消耗在文件打开的系统调用，具体包括路径查找，路径名的分量解析，转换成对应文件在内核中的内部表示。这个过程占用系统开销较大，尤其是深目录下的文件。而经过合并，众多的小文件将共享一个大文件，文件打开操作也转换成了开销更小的数据偏移定位操作，也就是根据索引定位到大文件内部相应位置即可，而且也不再需要于内核中创建相关的VFS数据对象，这就节省了最初绝大部分的系统开销。

综上可知，HDFS将合并后的大文件在进行大小为64M的数据块切分后，存储在Namenode节点上的数据块信息元数据就会明显减少，因而有效降低了内存方面的开销。同时，又进一步提高了MapReduce任务处理中各Datanode节点上数据块的运行效率。

3基于数据块平衡的小文件合并算法的设计与实现

3.1 算法基本思想

已有基于文件体积大小的小文件合并算法往往是设定一个缓冲区阈值，在遍历小文件的同时针对缓冲区队列不断累加文件，当累加总大小超过阈值后，即对缓冲区队列中的文件集合实行合并打包存储。执行过程示例如图1所示。但是这样的算法常常以“文件体积溢出”作为合并条件，同时忽略了文件体积分布不均的缺点，最终造成的结果就是合并后的大文件体积大小各异，在一定程度上对Hadoop集群中的NameNode节点形成了内存浪费，同时文件体积分布不均也不利于MapReduce框架并行计算高效实施。

图1 现有小文件合并算法过程示意图

Fig.1 Process of existing small file merging algorithm schematic

本文提出一种基于数据块平衡的小文件合并算法，其核心思想就是根据小文件的体积大小，使其进行均匀分布、再传至合并后的大文件中，而且又将文件合并条件由“文件体积溢出”转换为“文件体积接近临界”，由此保证合并后的大文件在HDFS中不会被分割出多余的块。该算法的提出在一定程度上降低了NameNode节点内存负载，同时文件体积均匀分布也将利于MapReduce并行计算的效率发挥。由于小文件合并策略类似于游戏“俄罗斯方块”中的填补空白的方法，为此即将该算法命名为Tetris Merge（俄罗斯方块似的合并）算法，简称TM算法。

3.2 算法设计

首先，介绍算法中使用的数据结构。本文将算法中使用的队列分为两类――文件合并队列和容忍队列。共有若干个文件合并队列用于存放待合并的小文件集合，当队列中的文件总大小达到合并条件时，即将文件集统一打包合并存入HDFS，且清空该队列；同时还有若干个容忍队列用于存储非预期情况下出现的体积偏大的文件，发挥应有的缓冲作用，并保证合并后文件大小尽量均匀分布。两类队列可以相互转换，后文将介绍其转换策略与条件。

算法的执行流程如图2所示。算法共分为两个阶段：文件合并阶段，后处理阶段。

图2 TM算法执行流程图

Fig.2 TM algorithm execution flow

算法执行流程如下：

（1）根据文件合并阈值创建m个文件合并队列qfl和n个容忍队列qtl（一般n

（2）遍历所有待合并小文件f，选择一个文件合并队列添加入队，实施原则是选择当前队列集合中文件总体积最小的队列（剩余空间最大的队列）qmax。如果文件加入队列后的总文件容积小于合并阈值，则正常加入；反之即进入异常处理步骤。

（3）异常处理步骤，文件加入队列使总大小超过合并阈值。如果此时该队列qmin中文件总大小已经超过合并阈值的95%，则将qmin中文件合并输出，且清空队列，同时将亟待入列的文件加入该队列；反之未超过阈值的95%，则证明待入列文件是一个偏大文件，则将该队列插入容忍队列（存在空容忍队列时）。此时，该容忍队列将转变为文件合并队列，参与到下一轮合并队列挑选中。

（4）队列清空原则。步骤（3）中提到的队列清空之前要进行一定条件的判断，如果当前文件合并队列数量大于初始化的m个时，该队列清空后将不插入任何文件，而是直接转换为一个空容忍队列。

（5）前面的4步就是文件合并阶段。当所有待合并小文件遍历结束，将有一些尚未合并的文件仍然留存于当前队列集合中，此时将进入后处理阶段。该阶段主要采用单文件队列的方法，由此而将队列中剩余文件实现合并。

由图1给出的实例如果采用TM算法，其合并效果将如图3所示。

图3 TM算法文件合并效果

Fig.3 The effect of file merging by TM algorithm

3.3算法的实现

TM算法核心实现的伪代码描述如下：

Algorithm TM：

Input： FileList待合并小文件集合，MergeLimit合并阈值，FileQNum文件合并队列数量，TolerateQNum容忍队列数量

Output：MergedFile合并后的大文件

1.Initialization：qfl， qtl

2.For each file f in FileList. Then goto step 10

3.Select max freespace queue qmax in qfl

4.If f's size less than remain size of qmax， goto step 5， else goto step 6

5.Push f into qmax， goto step 2

6.Calc min freespace queue qmin remain size Smin

7.If Smin /MergeLimit >0.95 or qtl is empty， goto step 8， else goto step 9

8.Merge files in qmin to MergedFile， push qmin into qtl

9.Select a queue qt from qtl， push f int qt， push qt into qfl

10.Merge remain files to MergedFile in queues

小文件合并后形成的大文件采用Hadoop支持的SequenceFile文件格式。在存储结构上，SequenceFile主要由一个Header及其后的多条Record组成。具体地，Header主要包含了Key classname，Value classname，存储压缩算法，以及用户自定义元数据等信息；除此之外，还包含了一些同步标识，用于快速定位到记录的边界。Sequence File文件格式即如图4所示。

图4 SequenceFile文件格式

Fig.4 SequenceFile file format

4 实验

4.1 实验环境

实验中，本文使用了两台服务器组成Hadoop集群，Namenode、Datanode节点各一个，设计构建的硬件环境如表1所示。

表1 实验环境

Tab.1 Experimental environment

Namenode 操作系统 CentOS 6.2

CPU AMD Opteron（TM） 8Core 1.4GHz *32

内存 32GB

硬盘 320GB

Datanode 操作系统 CentOS 6.2

CPU AMD Opteron（TM） 8Core 1.4GHz *32

内存 32GB

硬盘 320GB

Hadoop版本为1.2.1，Java运行环境版本为1.6。副本数量设置为2，HDFS数据块大小采用系统默认的64MB。

测试数据的小文件集合包含4 294个文件，总大小为10.12GB。这些小文件均为各类格式的小文件，文件体积从不足100KB到64MB各有不等。图5展示了文件集合的体积大小数量分布，其中体积为5MB以下的小文件占到总文件数量的97.71%，而5～64MB的文件则主要用于观察文件合并效果。

图5 文件集合体积大小数量分布

Fig.5 File size distribution of test file collection

4.2向HDFS导入文件时间消耗对比实验

通过包括TM算法在内的三种不同方法向HDFS进行文件导入，记录导入文件操作所消耗的时间。其中单文件合并算法中，合并文件的大小将选择与TM算法阈值相同的128MB。表2显示了三种方法向HDFS中导入数据的时间消耗结果比较。

表2 小文件导入消耗时间对比

Tab.2 Time consuming on importing small files

文件导入算法 文件数量/体积 合并后文件数量 消耗时间（秒）

正常导入 4 294/10.12GB 4294 567

单文件合并算法 4 294/10.12GB 82 249

TM算法 4 294/10.12GB 84 252

图6用柱状图的形式显示了三种方法的时间消耗对比。

图6 小文件导入时间消耗对比

Fig.6 Time consuming on importing small files

通过对比测试实验可以看出，在文件导入时间消耗方面，TM算法稍逊于单文件合并算法。造成这一结果的原因是两个算法的“文件合并”操作触发条件不同，就使得合并后的文件数量有所差异，TM算法合并的文件数量并未少于单文件合并算法，由此导致在文件导入时间对比上略呈劣势。

4.3 Namenode节点内存消耗对比

HDFS会将导入的数据分割成默认大小的64MB的数据块。其后系统就会将所有数据块信息的元数据存储到Namenode节点上，同时再将所有的数据块保存在Datanode节点上。而在Namenode节点上，每个数据块的信息元数据均将占用150字节左右的内存。

在研究的测试数据文件集中，共包含总大小为10.12GB，总计4 294个体积小于64MB的文件。如果不加任何处理，HDFS将创建4294个数据块。若为存储这些数据块信息元数据，Namenode节点即将消耗掉644 100字节的内存空间。而在文献[11]中提出的单文件合并算法，由于合并后的文件（128MB）在分割为数据块时总会遗留多余的数据块，就使得在内存消耗上并不能保证最低开销。另有TM算法是根据HDFS数据分块大小的特点进行优化，从而保证了合并后的文件不会被分割出多余的数据块，因此分割后的数据块对Namenode节点的内存消耗上则要优于前两者。

表3给出了三种数据导入方法对分割产生数据块数量的影响，最终导致Namenode节点在内存消耗上的变化结果对比。

表3 Namenode节点内存消耗对比

Tab.3 Consumption of Namenode memory

文件导入算法 生成数据块数量 Namenode节点内存消耗（字节）

正常导入 4 294 644 100

单文件合并算法 245 36 750

TM算法 168 25 200

图7用柱状图的形式显示了三种方法导致Namenode节点内存消耗的对比。

图7 Namenode节点内存消耗对比

Fig.7 Consumption of Namenode memory

通过实验对比测试可以看出，单文件合并算法与TM算法生成的大文件相比于不加处理直接导入的方法对Namenode节点的内存消耗都有十分明显的改善效果。同时由于TM算法考虑到HDFS数据块大小对数据块分割的影响，致使其产生的大文件在分割为数据块之后的数量与单文件合并算法相比即有明显的下降，最终导致对Namenode节点内存消耗的大幅下降。在本实验中，较之单文件合并算法，Namenode节点内存消耗下降了31.4%。

4.4 文件数据处理速度对比

Hadoop设计的初衷是用于大体积文件处理，因而用其处理数量巨大但是体积很小的文件将会使Hadoop的处理性能下降。测试数据文件集合中共计有可占空间为10.12GB的4 294个小文件，如果进行各自的单独处理，必将耗费相当长的时间。

测试实验是利用同样一个中文word count（先对中文分词然后计数）MapReduce程序对三个算法导入到HDFS中的数据分别处理，并对比消耗时间，得出处理速度。表4给出了对三种方法生成的数据进行MapReduce处理所用的时间对比，反映了处理速度的快慢。

表4 MapReduce数据处理速度对比

Tab.4 Time consuming of MapReduce data processing

导入数据所使用算法 Map阶段耗时 Reduce阶段耗时 总耗时

正常导入 13 993 s 333 s 14 326 s

单文件合并算法 1 190 s 119 s 1 309 s

TM算法 1 035 s 101 s 1 136 s

图8利用柱形图的形式显示了MapReduce处理三种方法生成数据速度对比。

图8 MapReduce数据处理速度对比

Fig.8 Time consuming of MapReduce data processing

通过实验对比测试可以看出，无论是单文件合并算法还是TM算法所生成的数据，在应对MapReduce处理数据时都较正常，其导入数据在处理时间上均呈较大幅度的下降，也就是处理速度得到了很大提升。同时，TM算法对比单文件合并算法在处理速度上也有较大提升，Map阶段、Reduce阶段和整体过程的处理速度分别提高了15.0%、17.8%、15.2%。出现这样结果的原因是TM算法生成的数据在HDFS中的分块结果更趋合理，产生的数据分块数量更少，因此就进一步降低了系统I/O时间消耗，相应地也提升了数据处理速度。

通过三个对比测试实验综合可知，TM算法仅在数据导入时间上稍落后于文献[11]提出的单文件合并算法，但其在Namenode节点内存消耗和生成数据被处理速度方面都有较大提升，由此即证明了该算法的有效性。

5 结束语

本文针对Hadoop分布式文件系统对小文件存储、处理缺陷，提出一种优化的文件合并及存储策略，利用文件体积大小分布实现对合并文件的优化组合，大幅减少了Hadoop集群中主节点的内存消耗，提升了MapReduce处理数据效率；相比单文件合并算法，提升效果达15%以上。

首先，本文对现有的小文件存储处理方案进行了归纳总结。其次，对Hadoop分布式文件系统的小文件存储缺陷展开了详细分析，在此基础上结合传统的单文件合并算法以及小文件体积分布规律，提出了基于数据块平衡的小文件合并算法，并给出了完整的算法思想及算法实现。最后，针对提出的算法进行了实验分析，证明了该研究算法可降低集群主节点内存消耗、以及提升集群数据处理效率。

接下来的工作中可以针对文件类型的异同进行合并测试，探讨相同的文件类型合并成大文件后对数据处理效率的影响，同时还要测试不同数据集对实验结果的影响。

参考文献：

[1] http：///stock/wmkzg/a/2014/0910/14/28200740.shtml

[2] .cn至顶网-云计算第一门户

[3] 大数据架构hadoop http：///guoxiaoqian8028/article/details/18772363

[4] YU L， CHEN G， WANG W， et al. Msfss： A storage system for mass small files[C]//Computer Supported Cooperative Work in Design， 2007. CSCWD 2007. 11th International Conference on，[S.l.]： IEEE， 2007：1087-1092.

[5] BEAVER D， KUMAR S， LI H C， et al. Finding a Needle in Haystack： Facebook's Photo Storage[C]//OSDI. 2010， 10， Vancouver， BC： [s.n.]： 1-8.

[6] Taobao File System 项目主页， http：///

[7] LIU X， YU Q， LIAO J. FASTDFS： A High Performance Distributed File System[J]. ICIC express letters. Part B， Applications： an international journal of research and surveys， 2014， 5（6）： 1741-1746.

[8] QIAN Y， YI R， DU Y， et al. Dynamic I/O congestion control in scalable Lustre file system[C]//Mass Storage Systems and Technologies （MSST）， 2013 IEEE 29th Symposium on. IEEE， Lake Arrowhead： [s.n.]， 2013：1-5.

[9] 陈剑， 龚发根. 一种优化分布式文件系统的文件合并策略[J]. 计算机应用， 2011， 31（2）： 161-163.

[10] 董其文. 基于 HDFS 的小文件存储方法的研究[D]. 大连：大连海事大学， 2013.

[11] PRASAD G， NAGESH H R， DEEPTHI M. Improving the performance of processing for small files in Hadoop： A case study of weather data analytics[J]. International Journal of Computer Science & Information Technolo，2014， 5（5） ：6436.