A Novel Approach to Improvingthe Efficiency of Storing and Accessing Small Files on Hadoop: a Case S

2010 IEEEInternational Conference on Services Computing

A Novel Approach to Improvingthe Efficiency of Storing and Accessing Small Files on Hadoop: a Case Study by PowerPoint File

Abstract

     Hadoop分布式文件系统（HDFS）成为代表性的云存储平台，得益于其可靠，可扩展性、低成本的存储能力。 HDFS有被用在BlueSky上，在中国较为流行的电子资料分享平台，主要以PPT文件和视频剪辑的形式存储和共享学习资源和课件。不幸的是，HDFS在大量的小文件方面性能不佳，因为大量的小文件给HDFS的NameNode造成沉重的负担，数据放置不考虑文件之间相关性，并且也没有预取机制来提高I/O性能。本文介绍了一种新的方法来提高HDFS存储和访问的小文件的效率。在存储和访问课件时，充分利用了文件的相关性和课件中余下的小文件内容的位置。首先，一个 PPT课件的所有相关的小文件合并成一个较大的文件来减少metadata，以减少NameNode的负担 。其次，小文件的访问采用二级prefetching机制，以提高效率。实验结果表明，该方法是能够有效地减轻NameNode的负荷，提高HDFS存储和访问大量小文件的工作效率。

Keywords：small filestorage; Hadoop distributed file system; cloud storage; PowerPoint storage;prefetching。

Ⅰ.INTRODUCTION

    Hadoop是一个开放源代码的软件框架，是可靠的，可扩展的，分布式计算和存储。它越来越受欢迎，例如云大数据生态系统就是在其基础上建设的。HDFS来源于GFS，是由Namenode和DataNode构成。 NameNode的管理文件系统命名空间和控制客户端的接入。DataNode提供数据块存储，为客户端I/O请求服务，并根据NameNode指令执行块操作。

    HDFS是一个具有代表性的在集群上运行的互联网服务文件系统[4]，被许多互联网应用和文件系统广泛采用采用，例如BlueSky[5]，它是一个最普遍的电子学习资源共享系统，利用HDFS存储主要以PPT文件和视频剪辑形式的课件。BlueSky中的文件有固有的相关性和直观的访问点。例如，一个PPT形式的课件通常是由一个PPT文件和一定量的预览图片组成的，这些图片是PPT文件的每个一个页面的snapshot。当一个文件被请求时，更多的在同一个PPT课件中的相邻的文件可能立刻会被请求。此外，类似的文件的相关性的特征和accesslocality在包括视频的其他课件中也存在，视屏课件切成以章为基础的剪辑。

    HDFS被设计用于存储以数据流访问模式的大文件[6]，在存储小文件方面的效率低下。存储大量的小文件会占用大量内存。例如，458,000个尺寸范围从32 KB到3796 KB的小文件存储在HDFS，约占用NameNode 184.86 MB的内存空间。由此可以推断2400万个文件将占用NameNode 16 GB内存空间。因此，用HDFS存储和管理大量的小文件是一大挑战。

    HDFS上的小文件存储和访问的效率问题（即所谓的小文件问题）是由以下因素所造成的：（1）大量文件占用大量的内存空间，（2）不考虑文件的数据位置的相关性也没有prefetching机制，这将导致读取的代价高，时间长。学术界和工业界对小文件问题的研究分为两类：通用的解决方案，和特别解决方案，以满足特定的场景。在一般情况下，他们的基本想法是小文件合并成大文件以减少文件数量，并建立索引或为每个原始文件建立key-value对。

    在本文中，提出一种新方法以优化在HDFS上小文件的存储，减轻NameNode的负担和提高访问小文件的吞吐量。在介绍这个方法之前，首先定义存储和访问文件效率的量化标准，并以此构成实验的结果。然后PPT课件将作为一个例子来研究描述所提出的方法。特别地， PPT课件特征，如PPT课件中文件之间的相关性和access locality将被考虑。在较高的水平，所提出的方法是合并属于一个PPT课件的小文件，并使用prefetching技术。本文的主要贡献是：总结如下：

    1、与大文件和其它类型的小文件相比，PPT课件的文件相关性和access locality是固定的；

    2、合并属于同一个PPT课件的文件的方法改进小文件存储的效率，为每个合并的文件建立本地索引文件；

    3、一个二级prefetching机制，包括本地索引文件prefetching和相关文件prefetching，提高小文件读取效率，这是以前的HDFS一直没有做的。

    应该注意到，所提出的方法是一般在两个方面。首先它不只是适用于PPT课件文件。事实上，它可以应用到互联网上其他常见的类型的小文件，如视频剪辑，flash文件，镜像图片等形式的课件。对于此类型的文件，它们都属于一个大文件或一个逻辑文件。其次，它也可以应用到其它互联网服务的文件系统，尤其是那些主从式架构和客户端直接访问的。

    本文的其余部分安排如下：。第2节描述HDFS的存储和访问的效率标准，第3节介绍PPT课件的特点，第4节分析HDFS的小文件问题，第5节介绍了设计细节，第6节所对提出的方法进行评估，第7讨论了相关工作，第8的做出结论并介绍今后要改进的工作。

 

II. STORING AND ACCESSING EFFICIENCYCRITERIA FORHDFS

    HDFS的存储容量通常是没有问题的，即使它存储了大量的小文件。但是大量的文件占用了很多的HDFS的内存。例如，NameNode的维护文件系统的namespace（包括目录、文件和块的metadata）和表示块在DataNode中分布的Block Map。在存储大量小文件时HDFS的内存是一个瓶颈，FNPK（内存每KB的文件数）是HDFS存储效率的一个重要标准测量，定义如下：

在这里，N表示存储在HDFS中的文件数量，M表示HDFS集群使用的内存。

    具体而言，FNPK有两种变体，它们是FNPKN（NameNode的每KB内存中的文件数）和FNPKD（DataNode每KB的内存中的文件数）。它们的定义如下：

在这里，M'代表使用的NameNode的内存，M“是一个Datanode的平均占用的内存。

    目前， NameNode总的可用内存上是可扩展性的主要制约因素[1]。因此，FNPKN是衡量HDFS存储效率的更关键参数。FNPK，FNPKN和FNPKD的关系，如下所示：

在这里，Q代表HDFS集群中Datanode的数目。

    MFPMS（每毫秒读取的文件MB）是一个衡量HDFS读取效率的标准，它被定义为：

这里，S表示读取文件的总大小，T代表的读取时间。

    当使用一个基准来评估，MSPF（每访问一个文件使用多少毫秒），它代表平均时间访问一个文件中的基准，也是用于测量读取效率。它被定义为：

在这里，TB代表HDFS一个标准读取执行的总时间，NB代表HDFS一个基准的文件总数。

    在实验部分，FNPKN，FNPKD和MSPF被用来评估HDFS存储和读取小文件的效率。

 

III. CHARACTERISTICS OF PPT COURSEWARE

    读取PPT主要的方式是下载PPT文件。然而，它不是最佳的。当创建一个PPT文件时，除了组织信息，作者通常花大量的时间添加动画和优化风格。所以，一些作者选择将PPT文件转换成PDF文件来保存其动画和风格。最近，采用预览图片的形式浏览PPT文件的风受到欢迎。每个预览图片就是PPT文件种单页的快照。比如，SlideShare[7]，全球最大的PPT文件共享社区，就支持这种浏览模式。

    在BlueSky中，PPT文件上传后被转换成一系列的预览图片。为提供多种分辨率的浏览体验，一个PPT文件被转换成多种分辨率的系列图片。其中，一个被称为标准分辨率的图片系列，其分辨率等于BlueSky的播放器的默认分辨率。

    对于一个PPT文件，所有图片在逻辑上属于一个PPT课件。一个PPT课件中的文件具有固有文件相关性。例如，同一系列中的图像具有继承性，图片和PPT文件具有因果关系。

    在BlueSky中，对所有PPT课件提供浏览功能，但只是其中的一部分允许被下载。对于一个PPT课件，常用的访问模式是用户首先按顺序地或者跳跃地浏览一些图片，然后下载PPT文件。因此，当预览图片被请求时，更多相邻的图片和PPT文件可能会被立刻请求。

 

IV. SMALL FILE PROBLEMS OF HDFS

    在HDFS中，每个小文件都被当作一个独立的文件来存储。HDFS上存储大量的小文件时，性能将显著降低，例如，导致较高的内存占用和不可接受的读去成本。图1列出了HDFS存储2000，4000，6000，8000，10,000个 PPT课件时NameNode和DataNode的内存利用率。每个课件的平均文件数为48.5。

    在分析的问题之前，第一个注意到的应该是，HDFS存储小文件磁盘利用率是没有问题的。在HDFS存储一个小文件时不占用超出要求存储内容的任何磁盘空间[6]。例如，一个2.5 MB的文件存储在block size大小为64 MB时，使用2.5 MB的磁盘空间，而不是64 MB。

    如下所述，主要有两方面的原因，导致HDFS的小文件问题：

Highmemory usage caused by huge numbers of files

    文件系统的命名空间会存储在NameNode内存中。每个文件的metadata大约需要250bytes的内存，每个block有3个默认副本，其metadata大约达到368bytes[8]。大量的文件占用了很多的NameNode内存。可以推断出，2400万文件将消耗16 GB的内存。

    另一方面，Datanode周期性地向NameNode发送报告，报告它存储的block的列表。NameNode收集这些报告，并把它们作为Block Map存储在内存中。由于大量的block（每个小文件都被作为一个单独的block存储），Datanode的内存使用和Block Map给 NameNode带来的内存的成本也非常高。

Highaccess cost caused by the access mechanism of HDFS

    HDFS的主要目的是提供数据流访问模式，最适合大文件。读取文件时，HDFS的客户端与NameNode连接获取文件的元数据，每个文件的访问发生一次。为访问大文件，它们之间的连接时间只是数据访问开销中的微小开销[9]。例如，一个在300MB吞吐量的I/O，如果是一个大文件，HDFS客户端只需要向NameNode发出一次查询请求。然而，对于小文件，在相同的吞吐量的情况下，HDFS客户端需要与NameNode联系数百次或甚至更多次。

    另一方面，HDFS具有其自己的数据存放策略，将block的副本保存在 DataNode上，它在可靠性，读写带宽，读性能和block在整个群集上的分布提供了良好平衡[6]。然而，它没有block之间的沟通。在block层次，顺序文件通常不是顺序放置的，甚至是放置在不同的DataNode上的。此外，HDFS目前不提供perfecting功能。因此，在不考虑文件的数据位置的相关性和没有perfecting机制情况下，读取小文件会导致大量的从Datanode到Datanode的查询和跳跃来检索每个小文件[10]。

 

V. SMALL FILE TUNING APPROACH FOR HDFS

    在本节中将详细介绍所提出的方法。首先概要的描述，包括其基本思想，架构和处理过程。随后介绍三个关键技术：文件merging，文件mapping和prefetching。

A.Overview of the proposed approach

    根据上述的问题分析，所提出的方法的基本思想主要包括两个方面：（1）小文件merging成更大的文件，以减少文件的数量，这是类似于其他的压缩文件的解决方案，（2）使用prefetching，以减轻NameNode的负载和提高访问效率，这在以前HDFS上没有做过的。特别地，根据PPT课件的特点，提出了新颖的设计以满足他们。首先，考虑到一个PPT课件之间的密切的相关性。一个PPT课件中的所有文件被合并成一个文件存储在HDFS上。其次，基于PPT课件文件的accesslocality，采用二级prefetching机制。

    BlueSky采用的是所推荐的三层的方法。用户界面层是整个系统的入口点，提供交互功能和接口，如上传，浏览和下载接口。事物处理层提供文件转换，文件合并，文件命名，Web服务和缓存功能，通过HDFS客户端与HDFS交互。存储层利用HDFS集群提供持久性的功能。

    如该图2所示，uploading process主要包括转换的PPT文件，创建本地索引的文件，合并文件并通过HDFS客户端上传合并的文件。

    1）通过网页上传PPT文件到BlueSky的Web服务器。

    2）它被转换成一系列图片。

    3）建立本地索引文件，并根据本地索引文件中的每个文件的​​偏移量和长度，原始文件依次合并到一个文件中。

    4）通过HDFS客户端上传合并后的文件到HDFS。此步骤与常规的HDFS的写过程相同。

    browsing process如图3示。这主要是将所请求的文件映射到一个合并的文件，读取本地索引文件，splitting有目标block和prefetching，这个过程发生在DataNode上，只有被请求的文件和预取的文件被返回到客户端。虽然block可以被直接发送到客户端并在客户端被split，但是这种方法降低了网络传输成本。

    1）一个文件的读请求到达高速缓存。缓存检查文件是否存在。如果存在，它将直接从缓存中读取，browsing process结束。如果没有，然后检查所请求的文件的元数据和索引信息在缓存是否存在。如果存在，执行步骤4和6。否则，请转至步骤2。

    2）所请求的文件被映射到一个合并的文件。如果合并后的文件包含许多block，还需要映射到它所在的block。

    3）HDFS客户与NameNode连接查找的合并后的文件的元数据。

    4）根据元数据，HDFS客户端与对应block所在的DataNode进行连接。

    5）从对应的DataNode的磁盘中取出目标块到它的内存。然后首先读取本地索引文件，之后从索引文件读出所请求的文件的偏移量和长度。

    6）基于偏移量和长度，从块split出所需的文件，并且被返回到客户端。

    7）然后，prefetching被触发，开始prefetch相关文件。对于每一个文件的prefetch，循环执行步骤6。

    Downloading process只针对PPT文件。如果所请求的PPT文件已被prefetch，直接从高速缓存中读取。否则，下载过程才执行，这与browsing process几乎是相同的。唯一的区别是，这里不会触发prefetching。

B.File merging

    在一个PPT文件转换成图片预览后，本地，PPT文件和所有预览图片merge成一个较大的文件。每一个合并后的文件有一个本地的索引文件，这表明了在这个merged文件中的每个原始文件的偏移量和长度。索引文件被存储在合并后的文件所在的每个块的开始位置，并仅对合并文件服务。相比在其他解决方案中的NameNode的全局索引文件，不会导致NameNode有额外的开销。

    在讨论之前，假设索引文件和PPT文件的长度总和小于的HDFS块大小。

    file merging process执行如下：首先，计算所有PPT文件和其所有的预览图片的数量。由于是采用固定长度的索引，可以计算出其本地索引文件的长度。第二，计算包括本地索引文件的所有文件的长度的总和，与HDFS的block size相比。第三，根据比较结果，采用不同的策略建立本地索引文件：1、如果总和小于HDFS的blocksize，合并的文件将只有一个块。所有的文件被按默认情况下排序，即本地索引文件、PPT文件、标准分辨率的预览图片组和其他分辨率的预览图片组。在每个分辨率的预览图片组中，根据页的序列号预览图片按升序排列。根据此顺序，指示出每个文件的偏移量和长度，本地索引文件就建立了。2、如果总和超过HDFS的blocksize，合并后的文件将被分解成多个数据块。与此相对应，为保证阅读和预取效率，采用两种策略：

    First strategy: the order adjustment ofpicture series

    从预取的观点出发，相关性强的文件最好是放在一个block。这是由于在HDFS预取时，将要预取的文件和所请求的文件，需要在相同的块中。

    第一个策略通过调整图片组的顺序，来避免同一个预览图片在在不同的block上。在第一个策略中，每一个预览图片组都不会被分割。换句话说，一个预览图片组在处理时作为一个整体。第一个策略有三个步骤，阐述如下：

    1）本地索引文件、PPT文件、标准分辨率预览图片组的长度总和，被称为prefix length。

    2）prefix length与HDFS块大小进行比较。如果它超过了块的大小，则处理结束，文件默认顺序排列。否则，请转至步骤3。

    3）在第2步中，已建立的顺序是本地索引文件、PPT文件和标准分辨率预览图片组。 其他分辨率预览图片组的排序是检查它们中的一个或一些和prefix length的总长度是否刚好等于HDFS块大小进行调整。如果不是这样，他们仍然采用默认顺序，过程结束。

    Second strategy: filling in the blank atthe boundary of adjacent blocks

    采用第一策略后，如果一个分辨率预览图片组还是不可避免被分别存储到两个块，前提是一个原始文件占用两个块是必须避免的。否则，阅读这小文件时需要从两个块获取数据（更糟糕的是，这两个块经常出现在不同的DataNode中），这极大地增加了读的代价。这是可以采用第二个策略，且如图4示：

    1）顺序计算每个文件的偏移量。在两个块的边界，检查是否有文件延伸穿过它。如果没有，请转到步骤3，否则，请转到步骤2。

    2）然后调整文件的顺序，并在横跨边界的secant file之前添加局部索引文件。添加的本地索引文件的偏移量是下一个数据块的起始位置，secant file的偏移量是添加的本地索引文件后面的位置。

    3）对于下一个块，循环执行步骤1和2。                 

    执行两种策略后，每个文件的顺序和偏移量就确定了，同时就可以建立本地索引文件。最后，在存储器中，根据本地索引文件中的每个文件的偏移量，原文件将被依次合并。对于两个相邻文件之间的空缺域，填补一个空文件。

C.File mapping

    当一个文件被请求时，HDFS客户端首先与NameNode连接获取该文件的元数据。在BlueSky中，NameNode管理着合并后的文件的元数据。因此，查询元数据之前，所请求的原始文件需要被映射到一个合并的文件。此外，如果合并后的文件包含多个块，映射到请求的文件所在目标块也是必要的。

    一个简单的方法是使用名称映射。由于PPT课件的图片要被转换，他们的名称遵守一些明确的规则。在当前的设计中，名称有四个域，它们分别是name domain, resolution domain, serial number domain and block numberdomain。在转换时，前三个值已经确定，最后一个是在创建本地索引文件时确定的。例如，如果PPT文件的名称是A，那么合并后的文件命名为A，，其之一图片的名称可能是A_1280_05_01.jpg。对于原始文件，通过分析它的名字，可以被映射到一个合并的文件或者特定的块。

    然而，这种方法不通用。对于其他情况下，它可能是不适合的。一个通用的解决方案是建立一个全局性的映射表，为每个原始文件创建一个记录，把它映射到一个其位于合并的文件和块。当合并后的文件上传到NameNode，它的本地索引文件也要上传。通过分析本地索引文件，对于这些文件创建映射记录。 全局映射表是在NameNode的内存中，同时也有一个持久的文件在磁盘上。当HDFS集群启动时，持久性文件被读入内存中，然后重建表。

D.Prefetching

    预取是一种使用广泛的存储优化技术[11]。它隐藏掉了可见的磁盘I/O成本，通过利用access locality和在请求之前读取数据到高速缓存来提高响应的时间。目前，HDFS不提供预取功能。然而，考虑到PPT课件的文件之间的内在的相关性和access locality，预取可以提高读取性能。

    在新方法中，采用二级预取机制，其中包括本地索引文件预取和相关文件预取。对于HDFS，基本的读取单元是块。在浏览图片时，从磁盘读取其中包含所请求的文件的块到内存，并在DataNode中的内存被分割。然后预取活动被触发，在相同的PPT课件的文件被预取出来。

    本地索引文件预取是相对简单的。如果本地索引文件已被预取，阅读属于PPT课件的文件不再需要的文件映射和与NameNode的交互。如果它没有被预取，局部索引文件预取活动被触发，本地索引文件返回到缓存中。在高速缓存中，索引文件和元数据在处理之前会返回到NameNode，对于每个原始文件的元数据和索引信息是建立预取记录。预取记录的数据结构图5所示。

    在相关文件预取设计，主要考虑三个问题：如何预取，预取多少文件，何时触发预取。

         What to prefetch

         文件的相关性以相关文件之间的共同accesslocality形式来表现的[12]。在文件级别中，预取什么取决于使用哪种基于文件关联分析和挖掘的模式来预取文件。相同PPT课件中的文件具有直观的相关性和访问点。因此，一个特殊的预取策略，属于相同的PPT课件。虽然PPT课件之间也可能有关系，本文讨论的是基于这种特殊的策略，由于它的简单并适用于BlueSky的情景。

    How many files to prefetch

    目前提供三种级别的预取策略。第一个是在一个预览图片组中，跟在所请求的文件串行后的预览图片。第二级别，除了第一个策略的文件还包括PPT文件。第三级别是在所有图片组中，包括所有其序列号在所请求的文件之后的PPT文件和预览图片。在未来，更复杂的预取机制会被开发出来。

    当PPT课件包含有多个块，预取度的机制变得更加复杂。上述策略需要添加一个新的限制。预取的文件应该与所请求的文件是在相同的块。否则，多个块将读取吐和分割，预取的成本明显增加。

    When to prefetch

    何时预取是指如何控制触发下一个预取活动。在BlueSky中，在浏览过程进行预取活动。高速缓存中，当读取一张预览图片的请求到达时，高速缓存首先检查文件是否存在，如果不存在，高速缓存然后检查预取记录是否已经存在。如果有存在，以相关联的文件预取将被触发。如果没有，本地索引文件的预取将被触发。考虑到很少有用户下载PPT文件还去浏览图片，下载PPT文件时不进行预取的活动。

 

VI. EXPERIMENTAL EVALUATION

A.Experimental environment and workload overview

    测试平台是建立在一个9 PC服务器集群上。一个IBM X3650服务器节点作为NameNode的，它是8核2.00GHz的Intel Xeon CPU，16 GB内存和3 TB磁盘。其他8个IBM X3610服务器节点作为的DataNode。他们每个人都拥有88核2.00GHz的Intel Xeon CPU， 8 GB内存和3TB的磁盘。所有节点使用1.0 Gbps以太网络互联。

    在每个节点上，安装的是Ubuntu服务器9.04，内核版本2.6.28-11， Hadoop版本0.20.1和Java版本是1.6.0。副本的数目设置为3，在测试过程中，HDFS块大小为64 MB。

    由于文件的数目影响HDFS的性能，特别是对于HDFS的内存开销，使用多个文件集合，分别包含2000，4000，6000，8000，10,000个PPT课件。课件中的文件平均数目（除了本地索引文件）为48.5。这些课件大小范围从32 KB到3796KB，文件大小在32KB和256KB数量占总的文件的98.25％。文件的大小的分布图6示。

B.Experiments

    测试项目包括两大类：Namenode和Datanode的内存使用情况和访问操作成本。访问操作，本文测试的是读操作，因为它是在BlueSky中最常见的操作。

    在每个实验中，所提出的方法与原来的HDFS和Hadoop存档（HAR）[13] 相比较。 HAR一般的小文件解决方案的存档小文件到更大的文件。对于HAR，一个PPT课件中的所有文件存储为一个HAR文件。考虑到建立一个HAR时，每个原始文件产生一个副本，原始文件归档后即被删除。

    除非有其他说明，所有的读操作实验重复7次，并对于每个结果的平均值的计算是除去了2最大值和2个最小值。通过这样做，可以过滤由于网络拥塞和其他不确定因素可能产生的异常值。

    Efficiency experiment of storing small files

    对于原HDFS，HAR和提出的新方法，当系统存储2000，4000，6000，8000和10000个 PPT课件时对NameNode和Datanode的存储器的使用进行评估。内存使用情况图7和图8示

    对于原HDFS，HAR和提出的新方法，平均FNPKN分别为2.63， 6.43和37.04，FNPKD分别为4.58， 18.10和46.08。正如预期的那样，用HAR和所提出的方法来存放小文件比原来的HDFS达到更高的效率，由于其文件归档功能，对于FNPKN平均提高了524.71％和1308.20％，对于FNPKD平均提高了295.20％906.16％。具体地说，因为本地索引文件的设计，本文提出的方法比HAR还占用较少的内存。

    Efficiency experiment of accessing smallfiles

    由于我们的NameNode服务器的高处理能力， HDFS存储 2000，4000，6000，8000和10000个PPT课件时读取一个文件平均时间是很接近的。例如图9示，对于所提出的方法，不同的MSPF读取一个文件时间小于1秒。

    因此，在访问效率的实验中，五个文件的MSPF平均时间进行了比较。结果图 10示。

    对于原始HDFS中，MSPF为31.86。建议的方法减少了约56.54％，为13.85，主要得益于二级预取机制。然而，对于HAR，MSPF为43.13，这约是原HDFS的135.37％。

    对所提出的方法，图11给出了在最好预取的情况（下一个请求的文件时，一直是预取）的MSPF，在最坏的预取情况（所请求的文件时，经常不在高速缓存中）的MSPF。从图11中可以看出，MSPF在最好的情况下约是原HDFS的26.12％，即使在糟糕的情况下约是原HDFS的73.76％，这主要是由于本地索引文件的预取。

VII. RELATED WORK

    HDFS小文件存储的研究分为两类：通用的解决方案和满足特定的场景的特别解决方案。前者包括HAR，SequenceFile [14]和mapfile [15]。至于特殊解决方案，HDWebGIS [16]最近是一个有趣的解决方案。

    HAR的归档功能压缩文件到一个HDFS块。它包含元数据（_index和_masterindex的形式）和数据（part-*）文件[13]。部分文件包含这些文件的一部分存档内容。一个SequenceFile的提供了一个固定的二进制键-值对数据结构。它使用文件名作为键，文件的内容作为值，并且支持在记录级别或块级别的压缩和解压缩。在mapfile中是一个排序的SequenceFile，通过key索引查询。它包括一个索引文件和数据文件。数据文件存储键-值对的记录，这些记录key的顺序进行排序。索引文件存储key的位置信息和位置的偏移量，其中第一条记录包含此key在数据文件中的位置[17]。

    与上述解决方案比较，本文中所提出的方法有以下几个方面不同。

    1、它是一个HDFS存储 PPT课件的解决方案，也适用于一定类型的小文件。

     2、合并文件时，要考虑文件的相关性，所有PPT课件相关文件归档为一个较大文件。

     3、二级预取机制被用来提高访问效率。

    HDWebGIS是一个有趣的方法，优化HDFS存储大量地理数据信息系统小的数据I/O表现，通过合并小文件成较大的文件，每个小文件生成哈希索引。本文所提出的方法在一些的想法与HDWebGIS是相似的。相比与HDWebGIS，它具有以下不同之处。

    1、文件合并后，合并后的文件将被视为独立的文件，而不会接收其他文件。

    2、合并后的文件，不是使用全局索引，而每个合并后的文件有本地索引文件。

    3、合并的文件的长度的总和不再限于HDFS块大小，还有两种策略用来保证访问效率。

 

VIII. CONCLUSION

    在处理小文件工作，大量的研究主要集中在解决读取延迟和元数据服务器的负载问题[9]。当大量小文件存储在HDFS，由于现有的读取机制，造成文件访问文件时大量的内存使用和高的成本。在本文中，定义了存储效率标准和量化访问文件的效率的级别。基于PPT课件的特点和小文件问题的分析，本文所提出的方法采用文件合并的方法和二级预取机制来减轻HDFS的小文件问题。实验结果表明，它可以有效地减少HDFS负载和提高的小文件存储和读取的效率。

    至于今后的工作中，将主要研究一般的小文件的存储方案解决HDFS上存储其他类型的文件。基于上文件关联分析，小文件被列为将提供多种类型和自定义的方法不同类型的效率进一步提高。

 

ACKNOWLEDGMENT

         This research is partially supported byNational Science Foundation of China (No. 60825202 and 60921003), NationalHigh-Tech R&D Program of China (No. 2008AA01Z131), IBM Research ChinaUniversity Relation Program (Research on BlueSky storage for cloud computing platform)and IBM Shared University Research Program (Research on transferring BlueSkysystem to cloud computing platform).

 

REFERENCES

[1] Hadoop officialsite, http://hadoop.apache.org/.

[2] Feng Wang, JieQiu, Jie Yang, Bo Dong, Xinhui Li, and Ying Li, “Hadoop high availabilitythrough metadata replication,” Proc. of the First CIKM Workshop on Cloud DataManagement, pp. 37-44, 2009.

[3] S. Ghemawat, H.Gobioff, and S. Leung, “The Google File System,” Proc. of the 19th ACM Symp. onOperating System Principles, pp. 29–43, 2003.

[4] W. Tantisiriroj,S. Patil, and G. Gibson, “Data-intensive file systems for internet services: Arose by any other name…,” Tech. Report CMU-PDL-08-114 , Oct. 2008.

[5] Bo Dong, QinghuaZheng, Mu Qiao, Jian Shu, and Jie Yang, “BlueSky Cloud Framework: An E-LearningFramework Embracing Cloud Computing,” Proc. of the 1st Conf. on CloudComputing, Lecture Notes in Computer Science 5931, pp. 577-582, 2009.

[6] Tom White.Hadoop: The Definitive Guide. O’Reilly Media, Inc. June 2009.

[7] SlideShare site,http://www.slideshare.net/.

[8]Http://issues.apache.org/jira/browse/HADOOP-1687.

[9] J. Hendricks, R.Sambasivan, S. Sinnamohideenand, and G.Ganger, “Improving small fileperformance in object-based storage,” Technical report, Tech. ReportCMU-PDL-06-104, May 2006.

[10] Tom White, TheSmall Files Problem, http://www.cloudera.com/blog/2009/02/02/the-small-files-problem/.

[11] Mingju Li, E.Varki, S. Bhatia, and A. Merchant, “TaP: Table-based Prefetching for StorageCaches,” Proc. of the 6th USENIX Conf. on File and Storage Technologie, pp.81–96, 2008.

[12] Peng Xia, DanFeng, Hong Jiang, Lei Tian, Fang Wang, “FARMER: a novel approach to file accesscorrelation mining and evaluation reference model for optimizing peta-scalefile system performance,” Proc. of the 17th International Symp. on Highperformance distributed computing, pp.185-195, 2008.

[13] Hadooparchives, http://hadoop.apache.org/common/docs/current/hadoop_archives.html.

[14] Sequence FileWiki, http://wiki.apache.org/hadoop/SequenceFile.

[15] Map files, http://hadoop.apache.org/common/docs/current/api/org/ pache/hadoop/io/MapFile.html.

[16] Xuhui Liu,Jizhong Han, Yunqin Zhong, Chengde Han, and Xubin He, “Implementing WebGIS onHadoop: A Case Study of Improving Small File I/O Performance on HDFS,” Proc. ofthe 2009 IEEE Conf. on Cluster Computing, DOI: 10.1109/CLUSTR.2009.5289196.

[17] Jason Venner.Pro Hadoop. Apress. Jun 2009.