基于改进HDFS的冠字号小文件分布式存储研究

徐俊　王庆华　赵云龙

摘要：针对冠字号小图片存储到HDFS系统中带来的访问瓶颈问题，改进了原有的HDFS系统，新提出的分布式系统机制是充分基于文件相关性（File Correlation）进行合并处理的HDFS（FCHDFS）。由于HDFS中所有的文件都是由单一的主节点服务器托管-NameNode，每个存储到HDFS的文件在NameNode主存储器中都需要存储它的元数据，这必然导致小文件数量越大HDFS性能就越差。存储和管理大量的小文件，对NameNode是一个沉重的负担。可以存储在HDFS的文件数量是受到NameNode的内存大小约束。为了提高存储和访问HDFS上的冠字号小文件的效率，该文提出了一个基于文件关联性的小文件高效处理机制。在这种方法中，按照客户和时间区分，一组相关的文件相结合为一个大文件，从而减少文件数目。而新建的索引机制能从相应的联合文件中访问单个文件。实验结果表明，FCHDFS大大减少主节点内存中元数据数量，也提高了存储和访问大量小文件的效率。

关键词：Hadoop；小文件；HDFS；文件合并

中图分类号：TP18 文献标识码：A 文章编号：1009-3044（2014）17-3980-06

Research on Distributed Memory of Crown Size Small Files Based on Improved HDFS

XU Jun1，2， WANG Qing-hua1， ZHAO Yun-long1

（ 1. ATM Research Institute， GRGBanking，Guangzhou Radio Group， Guangzhou 510663， China； 2. College of Computer， South China Normal University， Guangzhou 510631， China ）

Abstract： Aiming at the access bottleneck problem caused by storage crown size small picture to the HDFS system， improved the existing HDFS system， new mechanism of distributed system is fully based on files correlation （File Correlation） and combined these correlated files. Because of all the files in HDFS are made by the master node server hosting the -NameNode single， each stored in the HDFS file needs to store the metadata it in NameNode main memory， which is bound to lead to a larger number of small file HDFS performance worse. For small file storage and management， NameNode is a heavy burden. The number of HDFS stored documents is constrainted by NameNode memory size. In addition， HDFS does not consider the correlation between files. In order to improve the efficiency of small file storage and access of HDFS， this paper proposes an efficient mechanism for handling small files based on crown size file association. In this method， according to differentiate customer and time， a group of related files are combined into one big file， thereby reducing the number of files. To access a single file from the file corresponding to the new index mechanism. The experimental results show that， FCHDFS greatly reduce the number of master nodes in data memory， and also improve the efficiency of storage and access to a large number of small files.

Key words： Hadoop； small file； HDFS； file merge

根据目前各大银行总行的需求，冠字号信息需要集中到总行管理，冠字号图像采用网点节点机保存，支持保存至少3个月的全行数据，数据量达几十亿上百亿条。需求分析表明，记录的产生速度和记录的数量都满足典型的大数据特征[1，2]，已经接近或超过传统数据库技术的处理能力，而随着系统的持久运行和业务扩大，记录数量还有持续增长的趋势。因此分析系统的架构应以成熟的大数据系统架构为基础才能良好的实现其业务能力的要求。因此需要用到Hadoop[3]的分布时文件存储系统（HDFS）[4]，然而采集的钞票冠字号图片是平均大小只有几K的小文件，但存储大量的小文件到HDFS中，NameNode节点需要存储元数据将需要较大内存开销。在这种情况下，当应用程序访问大量的这些小文件时，单个NameNode节点成为处理元数据请求的瓶颈。此外，NameNode节点的内存大小限制HDFS可以存储的文件数量。对于科学和许多其他需要产生了大量小文件应用而言，正因为此限制了HDFS被用来作为一个主要的数据存储方式，也无法收益于Hadoop的数据处理能力，小文件处理问题[5-7]也逐渐成为并行分布系统研究的一个热点。endprint

Hadoop是一个开源项目，开发可靠性和可扩展的分布式计算软件。Hadoop框架已被广泛应用在各种集群构建的大型高性能的系统中。Hadoop架构由Hadoop分布式文件系统（HDFS）和MapReduce[8，9]编程模型，在商业的计算机集群中执行数据密集型计算。Hadoop集群通过简单地增加商业机器，扩充了计算能力、存储容量和I/O带宽。

Hadoop分布式文件系统（HDFS）是Hadoop文件系统组件的核心子项目。灵感来自谷歌的分布式文件系统（GFS）[10]，HDFS为写一次读很多次的模式。HDFS是主从式架构，一个单一的主节点-NameNode和多个从数据节点-DataNode。NameNode节点管理HDFS元数据和文件系统配置数据。元数据是保存在NameNode的主内存中，保证客户端快速访问和读写请求。在HDFS中，数据节点DataNode存储文件和满足读/写请求，并按照NameNode节点指令进行。每个存储到HDFS文件都会在任何一个数据节点做备份，以确保数据可靠性和可用性，这些分布在集群中的副本能确保被快速访问。

在本文中，针对冠字号小图片存储到HDFS系统中带来的访问瓶颈问题，改进了原有的HDFS系统，通过考虑每次交易产生的一组冠字号图片文件的关联性，通过合并小文件操作，该文的FCHDFS提供一个解决方案来减少节点的内存元数据。这需要一种在HDFS存储小文件的有效方式。基本的方法是将单个客户相关的小文件合成一个大文件。这有助于减少文件数量，从而减少元数据的存储。新的索引机制能够从合并的文件访问单个文件。此外，基于文件的相关性合并操作将有助于减少NameNode元数据请求负载，相关文件的索引也被缓存到客户端，达到更好的读请求的性能。

1 背景

Hadoop是一个开源框架，为数据密集型的应用提供分布式的数据存储和处理能力。它包括两个主要部分组成：Hadoop分布式文件系统（HDFS）和MapReduce分布式计算。

1）Hadoop分布式文件系统

Hadoop分布式文件系统提供了在集群中对文件全局统一访问。HDFS由两类服务器节点组成，即NameNode节点和DataNode节点。NameNode是集中式单一的服务器，负责维护文件在HDFS中的元数据。它也维护了配置数据，比如对文件每一块的副本数量称为备份参数，块的大小和其它HDFS参数等。每个块作为一个单独的文件存储在节点的本地文件系统中。作为数据节点抽象了底层的文件系统的细节，所有节点的特征不需要是相同的。数据节点负责按照NameNode要求存储，检索和删除数据块。在HDFS中文件被分成块，每个块的大小默认是64 MB，被复制和存储在多个数据节点中。NameNode在主存储器里维护了每个存储在HDFS中的文件的元数据。这包括存储文件名之间的映射，相应每个文件在数据节点中的块。因此，客户创建、写入、读取或删除文件的每个请求都需要通过NameNode节点。使用元数据存储，NameNode节点必须为来自客户的每次请求导向到适当的数据节点集合上。然后客户端直接与数据节点通信来执行文件操作。

单个NameNode节点，在主存储器中存储元数据，当它必须处理大量的小文件时将成为一个瓶颈。小文件指的是任何尺寸小于HDFS块大小的文件。这个问题，称为小文件的问题，阻碍了许多潜在的应用使用Hadoop框架的好处。

2）小文件的问题

为了满足客户端快捷、高效的请求服务，NameNode在主内存中存储整个元数据。文件的每个块都需要对应元数据被存储。当一个存储的文件大小大于块大小时，存储的元数据量由文件大小决定。然而当大量小于块大小的小文件需要存储时，每个文件都需要以块的形式存储，因此相应存储的元数据数量也是相当高的。例如假设每一个元数据占用150个字节，那么对于一个1 GB的文件，分为16个不同64MB块，就需要2.4KB的空间存储元数据。然而对于10500个大小为100KB的文件（共1 GB），大约需要1.5MB空间存储元数据。因此大量的小文件占用文件系统的空间小，但相应的元数据却需要占用较大的NameNode节点的主内存量空间。这样的情况是对集群的可用空间不合理的应用。此外，访问大量的这些小文件的结果是会造成NameNode访问瓶颈的。这有碍于HDFS在各种应用的最佳使用。

2 本文小文件处理机制

本文提出的考虑文件关联性的分布式文件系统（FCHDFS）提供了一种小文件合并操作和改进的索引机制。为提高HDFS处理小文件的效率，FCHDFS中四项技术发挥了重要的作用。它们分别是文件合并，文件映射，文件提取。如图1所示系统的总体架构描述处理这些业务模块的位置。

下面的部分详细描述了这些技术。

1）文件合并

HDFS小文件的主要问题是NameNode节点需要较大的内存空间用于管理这些小文件。HDFS不会从一个大的文件中区分小的文件，因此无论文件大小都需要存储相同大小的元数据。NameNode节点在HDFS中维护两种类型的元数据即文件的元数据和文件块的元数据。文件的元数据包括了文件的文件名、文件在名称空间树中的位置、文件大小、修改时间、访问时间、所有的细节和文件权限等信息。块的元数据包括关于这些块的信息和存储位置。

文件合并技术减少了NameNode节点处理小文件需要存储的文件元数据和块元数据。该技术是基于这个事实，客户端把文件合并到一起上传到HDFS系统与每一个文件单独上传到HDFS，所需要的文件元数据大小是相同的。文件合并保证NameNode节点只保存组合文件的元数据并不是所有存在于它的小文件的元数据。组成文件的名称和块信息作为一个特殊的数据结构在NameNode节点里维护处理。

使用FCHDFS创建文件时，文件合并过程在客户端进行。在创建组合文件时，客户端说明了小文件的名称和每个文件相关的数据。这个数据在客户端缓存，直到没有不超过HDFS块大小的文件数据需要添加。这确保了没有小文件在块之间分割存储。endprint

随着文件数据，索引表放在每个数据块的开始。该表包含每个小文件的入口，这一块的一部分。每个表项是一个（偏移量，长度）对。在块和文件，索引表中的第i项指定的小文件的第一个字节的偏移量从开始的块长度的小文件的字节数。在索引表中的信息可以被用来确定相应的文件的开始和结束位置。所产生的块结构，称为扩展块，如图2所示。

扩展块代表组合文件的一部分。在HDFS DataNode节点中，这些块像任何其他正常文件块一样存储。

2）文件映射

文件映射是将小文件名映射到包含该文件的组合文件块的过程。这是由NameNode节点执行的。用户要从组合文件中读取一个小文件，文件映射技术就起作用了。启动读操作时，用户必须明确指定组合文件和小文件的名称。一个请求发送到NameNode节点，根据这两个文件名，能获取所需的小文件的位置

对于每个组合文件，NameNode节点维护一个数据结构叫做组合文件映射表。它包含一个小的文件名称和包含该小文件的合并文件的逻辑块号之间的映射。针对逻辑块号和数据节点的信息，NameNode还提供了一个“索引号”。对应于请求的小文件，这种“索引号”指定了索引表存储在块开始的入口地址，从而避免了线性搜索。

图4显示了一个组合文件File的组合文件映射表数据结构。此文件包含分布在2个块中的5个小文件。块1包含文件F1和F2。块2保存从F3到F5的3个文件。文件名被散列到组合文件映射表中。除了文件的名称，还存储了有关块的排序信息。这个排序信息是存储在“索引号”字段里。

“索引号”值1表示这是在给定的块和它的索引表中的相应条目出现在从块开始的偏移量为零的第一个文件。在文件合并过程中，索引号码以类似的方式分配给块中的每个文件。块如图3所示。

相比传统所使用的技术，该文的映射技术具有更好的可扩展性。它也不会保持逻辑块号映射为文件名的一部分的任何文件。这使该解决方案与领域无关。

3）文件提取

文件提取涉及到从一个块中提取所需的文件内容的过程。这个操作由DataNode数据节点完成。当读取文件时，用户需要指明小文件名和组合文件名。此信息是用于获得包含文件的块，存储块的DataNode和NameNode 的“索引号”。所得的“索引号”发送到存储数据块的DataNode节点。DataNode然后使用此值去寻求所需放置在块开始的索引表中入口地址。索引表中的条目包含从块开始文件数据的偏移和数据文件的长度。DataNode然后寻找所需的偏移量和读取文件数据并将数据发送到客户端。同时把整个数据块发送回客户端，此操作大大降低了网络负载。

4）文件访问操作

以下各节描述文件的读写操作在FCHDFS是如何进行的。

1） 写操作：使用FCHDFS创建组合文件时，写操作被启动。在客户端，用户使用FCHDFS模块调用创建操作。然后将请求发送到NameNode节点，通过RPC为所需存储的组合文件创建和初始化数据结构。从NameNode节点创建一个特殊的inode表示文件被创建的是一个组合文件并保存到命名空间树。NameNod节点初始化一个组合文件映射。该映射是保存为代表的文件的inode部分认为条目表示形式的联合文件的部分的小的文件。

客户端被提供了一个输出流和一些额外的辅助方法，有助于关联文件数据到组合文件中一个入口地址。写入输出流数据最初在客户端的缓存执行文件合并。缓冲区可容纳的数据块的值。一个索引表是由目前在缓冲区中的所有文件构成。该表包含每个文件的元组作为在合并过程中的解释。缓冲区的内容附加上索引表被发送到数据节点。表中被计算的每个项的偏移量，也包括在块开始的表的大小。

该索引表的目的是快速定位所需的块的文件开始位置而不需要扫描整个块。随着逻辑块号所需文件元组在NameNode节点存储，使得速度更快。

成功地写入数据块到数据节点，客户端发送一个更新请求到NameNode节点，指明被写入最近的块文件名列表，以及每个文件的索引条目编号。这被NameNode节点使用来构造组合文件的映射。重复此过程，直到用户关闭被创建的组合文件。

2） 读操作：用户启动读操作直接访问合并文件中的小文件。在文件系统中的文件的路径是通过指定文件名的组合含有小文件的文件夹名来表示。换句话说，如果“ABC”是组合文件和“file1”是小文件的名称，然后用户可以指定“file1”“路径为“组合文件的位置/ ABC / file1”。

客户端模块从给定的路径提取组合的文件名和小文件名，并从NameNode请求对应于小文件元数据。这是一个基于RPC的请求，NameNode节点响应它通过存储在指定的组合文件的组成文件映射查找小文件名。块的位置（列表的数据节点）、逻辑块号和索引号为响应发送回客户端。

请求文件的元数据从缓存或NameNode节点中获取后，将在客户端和存储该块的数据节点之间建立流连接。在这阶段，请求文件的索引号发送到数据节点，并且数据节点在块索引表中读取到指定的项。在未来的读操作中，它将使用该偏移量和长度值。

客户可以通过文件读入指定偏移相对于文件的开始，即第一个字节的文件偏移零从文件的开始。这个偏移然后转换为它添加在数据节点的索引表中的块的偏移值计算等效。读取操作，然后委托给现有的API，允许原HDFS读取块开始在指定的偏移量。整个阅读过程如图7所示。

3 实验仿真及结果分析

本文提出的文件小文件处理技术方案需要在Hadoop集群上进行相关实验。通过实验，该文针对完成读写操作所占用的内存和花费时间等指标参数，对比了传统HDFS与FCHDFS系统性能。实验测试平台包含3台普通PC机，其中一台作为名称服务器节点NameNode，其它两台作为数据服务器节点DataNode。这些机器都具有以下配置：Intel酷睿2双核2.10 GHz，2GB的内存，320 GB/5400硬盘。在每一台机器安装Linux操作系统。开发环境是Hadoop版本0.20.1分布式系统、Eclipse4.2.1和Java版本1.6.0。endprint

对于NameNode内存使用的测量，该试验测试工作共包含200000个文件。这些文件从20KB到300kb大小范围。所有文件的累积大小约为12.35gb。采取的读写操作时的工作量是用于内存使用实验工作量的一个子集的分布，包含1000个文件。

基于以下参数测定集群性能：

1）使用NameNode节点存储元数据的内存量

2）完成读写操作使用时间量

采用内存分析器工具包测量NameNode节点存储元数据所使用的内存情况。Jmap工具被用来获取所有目前在Java NameNode进程内存中活对象的堆转储。内存分析器工具包进行分析所得到的堆转储。完成读写操作的时间使用操作系统Linux命令以毫秒测量。

实验是在原有的HDFS和FCHDFS上进行。通过放置2000批文件在HDFS后分析堆转储，测定节点的内存使用情况。共有2000000个文件被放置和100次读写（以每2000个放置到HDFS的文件），重复3次及三个读数，并计算平均值。FCHDFS采用同样的步骤，比较了两种情况下内存使用情况，如图5所示。

图5 NameNode内存使用

图5显示了两种情况下内存的使用模式。三角形标记的曲线对应的原始没做任何更改的HDFS内存使用情况。随着文件的数量增加，内存使用也线性增加。这是预期的结果，因为作为NameNode节点必须保存文件和块的元数据。第二条是正方形标记的曲线代表FCHDFS，为了有效的文件访问，NameNode必须保存额外的数据结构。存储相同数量的文件，通过FCHDFS使用的内存明显小于使用HDFS。FCHDFS只维护每个小文件的文件元数据，而不用维护它们的块元数据。NameNode只维护单个联合文件的块元数据，而不为每一个小文件维护它们的块元数据，所以FCHDFS将占用更少的内存。

在这个实验中，对HDFS和FCHDFS测试写操作的结果如图6所示。

图6 写操作所耗时间

FCHDFS的写操作是大大快于HDFS的写操作。通过图6实验分析结果清楚地显示这一点。10000个文件写到HDFS的时间是非常高的，因为NameNode节点必须为每个写入HDFS的文件创建和分配块空间。FCHDFS避免了这种繁琐的操作，文件的创建NameNode 节点被访问一次，并且只有再加入一新块到合并文件中才调用写操作。另一个发挥作用的重要因素是用于客户端合并文件的缓冲机制。添加一个新块的请求发送到NameNode节点前，数据块是先缓存到客户端。只为每个64MB的数据发送一个请求到NameNode节点，而不是每一个小的文件。

4 结束语

HDFS最初被设计为存储大文件的。当它是用来存储大量的小文件时，I/O性能成为瓶颈。在本文中，针对冠字号小图片存储到HDFS系统中带来的访问瓶颈问题，改进了原有的HDFS系统，提出了基于文件关联性合并机制的FCHDFS，它把大量的小文件合并成一个单一的联合文件。从性能进行分析，对于小文件的存储和管理，FCHDFS提高了对小文件的访问效率和减少节点的内存元数据数量。FCHDFS通过提供更高效的小文件元数据管理，允许更充分的利用HDFS的资源。该文对于2000000个小文件进行试验测试，结果证实内存的使用量大大减少了。相比原来的HDFS，FCHDFS写操作时间也有较明显的缩短。

参考文献：

[1] 覃雄派，王会举，王珊，等.大数据分析-RDBMS与MapReduce的竞争与共生[J].软件学报，2012，23（1）：32-45.

[2] 王珊，王会举，等.架构大数据：挑战、现状与展望[J].计算机学报，2011，34（10）：1742-1752.

[3] Chuck Lam.Hadoop实战[M].北京：人民邮电出版社，2012.

[4] Shvachko K，Hairong Kuang，Radia S.The Hadoop Distributed File System，Mass Storage Systems and Technologies（MSST）[C].2010 IEEE 26th Symposium， 2010：1-10， 3-7.

[5] Li xiu-qiao，Dong bin，Xiao Li-min，et al.Small Files Problem inParallel File System[J].Network Computing and Information Security，New York： IEEE Computer Society，2011：227-232.

[6] Carns P，Lang S，Ross R，et al.Small-file access in parallel file systems[C].International Parallel and Distributed Processing Symposium，New York：IEEE Computer Society，2009：1-11.

[7] Faraz Shaikh，Mikhil Chainani.A case for small file packing in parallel virtual file system （pvfs2）[C].Advanced and Distributed Operating Systems Fall 07， 2007.

[8] Grant Mackey，Saba Sehrish，Julio LopezIntroducing Map-Reduce to High End Computing. InPetascale Data Storage Workshop at SC08， Austin， Texas， November 2008.

[9] Michael C Schatz.CloudBurst：Highly Sensitive Read Mapping with MapReduce[J].Bioinformatics，2009.

[10] Ghemawat S，Gobioff H，Leung S.The Google file system[C].Symposium on Operating Systems Principles 2003.New York：ACM.2003：29-43.endprint

对于NameNode内存使用的测量，该试验测试工作共包含200000个文件。这些文件从20KB到300kb大小范围。所有文件的累积大小约为12.35gb。采取的读写操作时的工作量是用于内存使用实验工作量的一个子集的分布，包含1000个文件。

基于以下参数测定集群性能：

1）使用NameNode节点存储元数据的内存量

2）完成读写操作使用时间量

采用内存分析器工具包测量NameNode节点存储元数据所使用的内存情况。Jmap工具被用来获取所有目前在Java NameNode进程内存中活对象的堆转储。内存分析器工具包进行分析所得到的堆转储。完成读写操作的时间使用操作系统Linux命令以毫秒测量。

实验是在原有的HDFS和FCHDFS上进行。通过放置2000批文件在HDFS后分析堆转储，测定节点的内存使用情况。共有2000000个文件被放置和100次读写（以每2000个放置到HDFS的文件），重复3次及三个读数，并计算平均值。FCHDFS采用同样的步骤，比较了两种情况下内存使用情况，如图5所示。

图5 NameNode内存使用

图5显示了两种情况下内存的使用模式。三角形标记的曲线对应的原始没做任何更改的HDFS内存使用情况。随着文件的数量增加，内存使用也线性增加。这是预期的结果，因为作为NameNode节点必须保存文件和块的元数据。第二条是正方形标记的曲线代表FCHDFS，为了有效的文件访问，NameNode必须保存额外的数据结构。存储相同数量的文件，通过FCHDFS使用的内存明显小于使用HDFS。FCHDFS只维护每个小文件的文件元数据，而不用维护它们的块元数据。NameNode只维护单个联合文件的块元数据，而不为每一个小文件维护它们的块元数据，所以FCHDFS将占用更少的内存。

在这个实验中，对HDFS和FCHDFS测试写操作的结果如图6所示。

图6 写操作所耗时间

FCHDFS的写操作是大大快于HDFS的写操作。通过图6实验分析结果清楚地显示这一点。10000个文件写到HDFS的时间是非常高的，因为NameNode节点必须为每个写入HDFS的文件创建和分配块空间。FCHDFS避免了这种繁琐的操作，文件的创建NameNode 节点被访问一次，并且只有再加入一新块到合并文件中才调用写操作。另一个发挥作用的重要因素是用于客户端合并文件的缓冲机制。添加一个新块的请求发送到NameNode节点前，数据块是先缓存到客户端。只为每个64MB的数据发送一个请求到NameNode节点，而不是每一个小的文件。

4 结束语

HDFS最初被设计为存储大文件的。当它是用来存储大量的小文件时，I/O性能成为瓶颈。在本文中，针对冠字号小图片存储到HDFS系统中带来的访问瓶颈问题，改进了原有的HDFS系统，提出了基于文件关联性合并机制的FCHDFS，它把大量的小文件合并成一个单一的联合文件。从性能进行分析，对于小文件的存储和管理，FCHDFS提高了对小文件的访问效率和减少节点的内存元数据数量。FCHDFS通过提供更高效的小文件元数据管理，允许更充分的利用HDFS的资源。该文对于2000000个小文件进行试验测试，结果证实内存的使用量大大减少了。相比原来的HDFS，FCHDFS写操作时间也有较明显的缩短。

参考文献：

[1] 覃雄派，王会举，王珊，等.大数据分析-RDBMS与MapReduce的竞争与共生[J].软件学报，2012，23（1）：32-45.

[2] 王珊，王会举，等.架构大数据：挑战、现状与展望[J].计算机学报，2011，34（10）：1742-1752.

[3] Chuck Lam.Hadoop实战[M].北京：人民邮电出版社，2012.

[4] Shvachko K，Hairong Kuang，Radia S.The Hadoop Distributed File System，Mass Storage Systems and Technologies（MSST）[C].2010 IEEE 26th Symposium， 2010：1-10， 3-7.

[5] Li xiu-qiao，Dong bin，Xiao Li-min，et al.Small Files Problem inParallel File System[J].Network Computing and Information Security，New York： IEEE Computer Society，2011：227-232.

[6] Carns P，Lang S，Ross R，et al.Small-file access in parallel file systems[C].International Parallel and Distributed Processing Symposium，New York：IEEE Computer Society，2009：1-11.

[7] Faraz Shaikh，Mikhil Chainani.A case for small file packing in parallel virtual file system （pvfs2）[C].Advanced and Distributed Operating Systems Fall 07， 2007.

[8] Grant Mackey，Saba Sehrish，Julio LopezIntroducing Map-Reduce to High End Computing. InPetascale Data Storage Workshop at SC08， Austin， Texas， November 2008.

[9] Michael C Schatz.CloudBurst：Highly Sensitive Read Mapping with MapReduce[J].Bioinformatics，2009.

[10] Ghemawat S，Gobioff H，Leung S.The Google file system[C].Symposium on Operating Systems Principles 2003.New York：ACM.2003：29-43.endprint

对于NameNode内存使用的测量，该试验测试工作共包含200000个文件。这些文件从20KB到300kb大小范围。所有文件的累积大小约为12.35gb。采取的读写操作时的工作量是用于内存使用实验工作量的一个子集的分布，包含1000个文件。

基于以下参数测定集群性能：

1）使用NameNode节点存储元数据的内存量

2）完成读写操作使用时间量

采用内存分析器工具包测量NameNode节点存储元数据所使用的内存情况。Jmap工具被用来获取所有目前在Java NameNode进程内存中活对象的堆转储。内存分析器工具包进行分析所得到的堆转储。完成读写操作的时间使用操作系统Linux命令以毫秒测量。

实验是在原有的HDFS和FCHDFS上进行。通过放置2000批文件在HDFS后分析堆转储，测定节点的内存使用情况。共有2000000个文件被放置和100次读写（以每2000个放置到HDFS的文件），重复3次及三个读数，并计算平均值。FCHDFS采用同样的步骤，比较了两种情况下内存使用情况，如图5所示。

图5 NameNode内存使用

图5显示了两种情况下内存的使用模式。三角形标记的曲线对应的原始没做任何更改的HDFS内存使用情况。随着文件的数量增加，内存使用也线性增加。这是预期的结果，因为作为NameNode节点必须保存文件和块的元数据。第二条是正方形标记的曲线代表FCHDFS，为了有效的文件访问，NameNode必须保存额外的数据结构。存储相同数量的文件，通过FCHDFS使用的内存明显小于使用HDFS。FCHDFS只维护每个小文件的文件元数据，而不用维护它们的块元数据。NameNode只维护单个联合文件的块元数据，而不为每一个小文件维护它们的块元数据，所以FCHDFS将占用更少的内存。

在这个实验中，对HDFS和FCHDFS测试写操作的结果如图6所示。

图6 写操作所耗时间

FCHDFS的写操作是大大快于HDFS的写操作。通过图6实验分析结果清楚地显示这一点。10000个文件写到HDFS的时间是非常高的，因为NameNode节点必须为每个写入HDFS的文件创建和分配块空间。FCHDFS避免了这种繁琐的操作，文件的创建NameNode 节点被访问一次，并且只有再加入一新块到合并文件中才调用写操作。另一个发挥作用的重要因素是用于客户端合并文件的缓冲机制。添加一个新块的请求发送到NameNode节点前，数据块是先缓存到客户端。只为每个64MB的数据发送一个请求到NameNode节点，而不是每一个小的文件。

4 结束语

HDFS最初被设计为存储大文件的。当它是用来存储大量的小文件时，I/O性能成为瓶颈。在本文中，针对冠字号小图片存储到HDFS系统中带来的访问瓶颈问题，改进了原有的HDFS系统，提出了基于文件关联性合并机制的FCHDFS，它把大量的小文件合并成一个单一的联合文件。从性能进行分析，对于小文件的存储和管理，FCHDFS提高了对小文件的访问效率和减少节点的内存元数据数量。FCHDFS通过提供更高效的小文件元数据管理，允许更充分的利用HDFS的资源。该文对于2000000个小文件进行试验测试，结果证实内存的使用量大大减少了。相比原来的HDFS，FCHDFS写操作时间也有较明显的缩短。

参考文献：

[1] 覃雄派，王会举，王珊，等.大数据分析-RDBMS与MapReduce的竞争与共生[J].软件学报，2012，23（1）：32-45.

[2] 王珊，王会举，等.架构大数据：挑战、现状与展望[J].计算机学报，2011，34（10）：1742-1752.

[3] Chuck Lam.Hadoop实战[M].北京：人民邮电出版社，2012.

[4] Shvachko K，Hairong Kuang，Radia S.The Hadoop Distributed File System，Mass Storage Systems and Technologies（MSST）[C].2010 IEEE 26th Symposium， 2010：1-10， 3-7.

[5] Li xiu-qiao，Dong bin，Xiao Li-min，et al.Small Files Problem inParallel File System[J].Network Computing and Information Security，New York： IEEE Computer Society，2011：227-232.

[6] Carns P，Lang S，Ross R，et al.Small-file access in parallel file systems[C].International Parallel and Distributed Processing Symposium，New York：IEEE Computer Society，2009：1-11.

[7] Faraz Shaikh，Mikhil Chainani.A case for small file packing in parallel virtual file system （pvfs2）[C].Advanced and Distributed Operating Systems Fall 07， 2007.

[8] Grant Mackey，Saba Sehrish，Julio LopezIntroducing Map-Reduce to High End Computing. InPetascale Data Storage Workshop at SC08， Austin， Texas， November 2008.

[9] Michael C Schatz.CloudBurst：Highly Sensitive Read Mapping with MapReduce[J].Bioinformatics，2009.

[10] Ghemawat S，Gobioff H，Leung S.The Google file system[C].Symposium on Operating Systems Principles 2003.New York：ACM.2003：29-43.endprint