摘要：HDFS（Hadoop Distributed File System）作为开源系统广泛地适用于各类存储服务中，具有高容错，易扩展，廉价存储等特点。然而，HDFS基于单一的服务器NameNode来处理元数据信息管理，当处理海量小文件时会造成NameNode内存过分消耗以及存储和读取性能并不理想，使NameNode成为系统瓶颈。本文提出一种基于HAR（HadoopArchive）的优化机制来提高NameNode存储元数据信息的内存利用效率和提高读取小文件的访问效率。另外，该策略也扩展了HAR文件追加的优化和为提高访问效率采用索引预取机制。实验结果表明该优化策略能够提高现有HAR处理小文件的能力和访问海量小文件的效率。
关键词：HDFS；小文件；HAR；索引策略；索引预取
中图分类号：TP391.1 文献标识码：A DOI：10.3969/j.issn.1003-6970.2015.02.023
0 引言
随着网络服务的高速发展，数据的数量呈现井喷之势，云计算技术已经成为提供主机数据和软件与服务部署方面越来越受欢迎的下一代基础设施。分布式文件系统是网络服务基层实施的重要组件。HDFS作为Hadoop的分布式文件系统，已经成为海量存储集群上部署的主流文件系统。由于HDFS是一个开源软件框架，获得了许多大公司的青睐，根据存储与处理海量数据时的优异表现得到广泛用与分析。然而HDFS在处理海量小文件时却忍受着性能降低，因为NameNode把文件系统的元数据信息放置于内存中，所以海量小文件的存储会引发的NameNode内存消耗过度以及NameNode性能降低，使NameNode成为了系统瓶颈。
随着各类社交网络的兴起，产生了大量数据文件，如日志，用户文件，图片等等小文件，所以针对Hadoop小文件问题现在已经有一些解决方案，这些方案可以大体分为两种策略：第一种是通过部署多个NameNode来支持更多的负载以此来提高系统性能；另一种则是通过合并小文件来最大限度的减轻NameNode的内存负载。其中Apache Hadoop基金会已经再次开发了HDFS，HDFS能够在一个集群中支持多命名空间从而提高系统的可扩展性以及隔离性，但是还是存在系统很难去配置各个命名空间的协调问题。文献提出了通过客户端本地缓存来存储索引文件实现索引或者数据预取减少NameNode的使用，从而优化HDFS的I/O性能。但是实验结果表现出的文件访问性能提高不是很显著。文献提出了一种优化I/O性能的方法，但是只是针对存储于HDFS上的地理信息数据。这种方法只适用于特定的数据并且没有提高文件访问效率。另外其他处理小文件的方法包括Sequence文件和Hadoop Archive。SequenceFile是HDFS提供的一种二进制的文件技术，通过将对序列化到SequenceFile实现小文件的合并，同时还支持基于数据块的压缩，显著减少了名称节点的内存，但是这种方法存储花费时间长，并且查找一个小文件就需要遍历整个SequenceFile，对系统访问性能产生了影响。HadoopArchive（HAR）是一种文件归档技术，通过将小文件打包成HAR文件来减少HDFS中文件数量，从而减轻NameNode内存负载压力。但是读取HAR中的文件需要读取两层index文件以及读取文件数据本身，并且HAR不允许对已生成的文件继续追加，所以使用HAR的系统访问性能受到影响。
为了克服上面提到的困难，本文提出一种基于已有的HAR方法的优化机制，HAR被从新设计索引机制来提高对元数据信息的管理，并在不需要改变HDFS体系结构的情况下提升文件访问性能。通过对HAR的索引策略进行改进，并且实现对已有HAR文件进行追加操作和通过客户端对索引文件进行预取，很好的提高了HDFS在面对小文件存储与读取上的性能。
1 研究现状
Hadoop平台提供了与google文件系统相似的分布式文件系统HDFS和MapReduce计算框架。HDFS具有高容错性，易扩展的特点，能够提高极高的数据吞吐量，适合那些有着超大数据集的应用程序，因而被各大公司广泛运用，包括AOL，Amazan，Facebook，Twitter等。HDFS有一个单一的NameNode节点和多个DataNode节点，属于主从式架构。体系结构如图1所示。
NameNode管理元数据信息以及文件系统内部配置数据，HDFS中的文件被分成块，每个块被复制和存储到多个DataNode～L13I。DataNode管理块存储以及响应来至客户端从NameNode指向的请求。HDFS提供了优化方法处理海量数据，计算被分摊到各个节点，使存储输入数据的传输负载最小化，并且数据复制确保了软件与硬件的高容错性。但是HDFS设计初衷是用流数据访问方式存储大文件数据，简而言之，就是说在处理小文件上会有如下问题：
（1）高的NameNode内存消耗。NameNode内存存放元数据信息。一个文件的元数据信息大概占用内存250bytes，然后每一个块默认有3个备份，那么大约消耗368bytes。也就是说文件越多，内存消耗越多，而NameNode内存有限，所以需要降低NameNode消耗。
（2）不能接受的存储时间。如文献[7]中提到存储1KB到10KB之间大小的550000个小文件耗时7.7个小时，但是存储这些文件到本地文件系统如ext3，仅仅花费660秒。
（3）NameNode成为瓶颈。元数据信息管理是一个费时的任务。为访问一个文件HDFS客户端会先去NameNode取元数据信息。对于小文件而已数据传输花费非常短，所以磁盘寻找和管理元数据信息变成主要负载对象。当有大量小文件访问时，HDFS客户端访问NameNode会非常频繁，从而影响NameNode性能。 为解决这个问题，Hadoop提高了HAR方法处理海量小文件。用户可以把小文件归档存储在归档文件中（.har）中并且如访问正常文件一样去访问归档文件。这种方法减少了文件数量，从而减少了NameNode内存消耗，也一并减少了HDFS客户端访问NameNode的次数。HAR方法是通过一个MapReduce作业将小文件打包为大文件，原文件也可以被并行透明的访问。
如图2所示HAR文件结构包括以下三个部分：
（1）bar.har/ masterindex：存储哈希代码和偏移量。
（2）bar.har/index：存储文件状态。
（3）bar.bar/part-[0..n]：存储文件数据。
小文件被存储在归档文件的多个部分内并且依据索引保持着原来的数据分离。文件索引结构如下图3所示。
在HAR文件中读取文件要比在HDFS中读取慢的多，因为读取一个HAR中的小文件需要经过2层索引。另外，HAR文件一旦被创建，要想添加文件，就只能重新创建HAR文件，这样又会花费很多HDFS很多时间。
2 优化策略
本文提出优化策略主要包含三个方面：（1）合并小文件减少NameNode内存消耗和提高其访问性能；（2）扩展现有HAR技术，提高文件追加的能力；（3）基于HAR的新索引实现HDFS客户端的索引预取，减少NameNode负载。
2.1 单层索引机制
为提高现有HAR技术的访问效率，本文利用单层索引，放弃双层索引。通过创建一个哈希表分离许许多多的索引文件。索引结构如下图4所示。
在此索引机制下，当访问一个文件时，由归档程序根据文件名称派生出的一个哈希代码，根据索引文件的数目作为关键值和散列码，去定位包含元数据的索引文件。如下图5所示，假设file-1的哈希代码是9768。用此哈希代码除以文件数，4得出0值，这个值定位到元数据文件中的index 0文件，实际的文件与HAR方法中相似也将被保持于Part文件。这样可以将定位文件的位置最简化。
2.2 文件追加策略
当创建一个HAR文件时，HAR将依据文件名称获得一个哈希代码并将信息存放在依据哈希值排序方便快速查找的masterindex文件中。然而，插入文件需要合适的位置去存放文件，而这样做时要确保HAR文件的结构很困难，在这种限制之下，HAR方法不允许修改已经生成的HAR文件。为了添加额外的文件到HAR文件，就必须生成新的HAR文件，这样的方法非常的低效。
为克服这个缺点，这里依据之前提供的新索引机制提出对HAR方法进行改进，新方法允许用户不通过重新创建NAR文件，添加额外的文件到已经存在的HAR文件中去。如图6所示，这个插入方法包括3个步骤：合并新文件、合并索引文件、移动新Part文件。
例如图6中所示，插入file-8，file-9到bar.har中，首先合并文件到tmp.bar中并且检查bar.har中的part文件是否存在以防止文件重复。然后合并tmp.bar中的索引文件到已经存在的bar.har中的索引文件。再移动tmp.har中的part文件到bar.har中去，最后删除tmp.har。
在上述插入文件的过程中，要注意检查part文件的大小，如果超过大小，需要重新设定索引表哈希表的散列函数创建HAR文件，另外可以将默认块大小设置为128M以减少part文件过大的概率。
2.3 元数据预取
新索引机制生成的索引文件存放于Namenode，为减轻NameNode负载，在HDFS客户端和NameNode直接添加专门用于小文件读取的索引预取机制。当HDFS客户端试图读取HAR文件中的一个小文件时，与该文件在同一个part文件中的其他小文件的元数据信息从NameNode节点预取。假设被归档小文件之间具有一定相关性，被一起访问的可能性很大，当相关小文件的元数据存在于HDFS客户端缓存内时，客户端不需要启动PRC请求到NameNode节点。在这种预取机制之下，NameNode节点请求将大量减少，从而提高了NameNode的运行性能。
3 评价与测试
3.1 实验环境及数据
本文实验环境是有4个节点的hadoop集群，其中3台是DELL OPTIPLEX790，Intel（R）
Core（TM）i3-2120 CPU 3.30GHz，2G内存，160G硬盘。另外一个节点是Lenovo扬天M4660N，Pentium（R）Dual-CoreCPU E6600 3.06GHz 3.07GHz，4G内存，200G硬盘。网络环境是百兆以太网。其中，最后一台机器作为NameNode，前3台机器作为DataNode。每个节点安装的是Centos6.5，hadoop版本是0.20.2-cdh3u5，JDK版本为1.6.0 24。数据来自多个数据集，分别包括20000、40000、80000个小文件，它们分别总计大小为1.4Gb、2.8Gb、5.6Gb。
3.2 实验结果及分析
实验主要对比HAR方法和改进的HAR方法在以下三个方面的性能表现：NameNode主存消耗，文件读取时间，以及添加文件消耗时间。
3.2.1 读取性能
为评估访问小文件的策略，我们通过HAR方法与改进HAR方法及实现同part文件元数据预取情况下分别做读写操作，实验评估来自多个数据集（20 000，40 000 and 80 000 files），每个数据集测试重复6次，取平均值。每次从数据集中读取100个随机的小文件。结果如下图7所示。
由图7可知，改进HAR方法及实现part文件元数据信息预取情况下的读取文件的速度比HAR方法读取文件的速度在三个数据文件集中读取文件上显著提高。
3.2.2 文件添加时间
为添加小文件到已存在的HAR文件中，HAR不得不重新创建HAR文件，对于改进HAR文件通过新索引机制可以直接追加文件到已存在的HAR文件。在实验中添加545个小文件大约40M到已存在的HAR文件中去，结果如下图8所示，改进HAR方法在追求文件上比HAR方法效率显著提高。
3.2.3 NameNode主存消耗
同样使用20000、40000、80000数据集分别存储到10、20、40个目录中去，并且对HAR方法和改进HAR方法使用NameNode内存消耗情况进行测试比较，结果如下图9所示。
根据图9可以发现改进HAR方法在使用内存情况上比HAR方法有轻微的提高，这是因为改进HAR方法使用单层索引策略，而HAR方法使用两层索引，索引文件要较改进HAR索引文件占用NameNode内存较少。但改进HAR方法对于HAR方法对NameNode内存使用的优化影响不大。
4 结论
本文针对Hadoop处理小文件时NameNode内存消耗过重，负载过重性能降低在现有HAR文件合并技术的基础上提出了一种新的索引策略，使两层索引变单层索引，降低了索引时间，并且改进现有HAR技术实现了对HAR文件的追加功能，并对相关part文件实现元数据信息预取操作，优化了HDFS系统的负载均衡。实验结果表明，本文建议的方法可以实现DHFS系统对小文件存储访问时I/O性能的明显改善，另外NameNode内存消耗明显降低，文件追加效率显著提高。
