CN104536959B - 一种Hadoop存取海量小文件的优化方法 - Google Patents

Abstract

一种Hadoop存取海量小文件的优化方法；本发明目的在于提供一种应用于Hadoop的小文件合并、索引及查询方法，主要解决Hadoop中小文件的存取效率问题。本发明提出一种三层Hadoop小文件存取处理架构，三个层次分别为：用户界面层、业务逻辑层、数据存储层；本发明包括预处理器端小文件的合并映射技术和海量小文件的快速索引技术。

Description

一种Hadoop存取海量小文件的优化方法

技术领域

本发明涉及软件开发及应用集成领域，特别涉及一种应用于互联网中海量小文件存取的机制和方法领域。

背景技术

Hadoop是近几年发展比较成熟的云计算平台之一，凭借其可靠、高效、可伸缩的特性在互联网领域得到了广泛应用，同时也得到了学术界的普遍关注。HDFS作为Hadoop的分布式文件系统，已经成为海量存储集群上部署的主流文件系统。HDFS由一个NameNode和若干个DataNode组成，其中NameNode负责管理文件系统的命名空间，DataNode是文件系统的工作节点。HDFS这种主从式的架构模式极大地简化了分布式文件系统的结构，但是由于NameNode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目取决于NameNode的内存大小。这就导致了HDFS对海量小文件支持不理想的问题。而且NameNode过大的内存开销和存储的低效严重影响了系统可扩展性和可用性。

然而,在实际互联网应用当中,存在着海量的小文件.尤其是随着博客,微博、百科、空间等社交网站的兴起改变了互联网提高内容的方式,基本上用户已经成为互联网的内容创造者,其数据具有海量、多样、动态变化等特点,由此产生了海量的小文件,如日志文件,资料介绍,用户头像等。但是现在的系统已经无法满足海量小文件的支持,同时海量小文件对于系统的可扩展性和可用性也造成了一定影响,因此，如何设计一种高效的存储及查询Hadoop小文件的机制成为提升云计算平台处理能力的关键。

发明内容

本发明目的在于提供一种应用于Hadoop的小文件合并、索引及查询方法，主要解决Hadoop中小文件的存取效率问题。

技术方案:本发明包括文件合并，建立R树索引及倒排索引，预处理器端全局映射管理技术，以及依据文件元数据的查询技术。本发明的处理框架分为三层，分别为：用户界面层，业务逻辑层，数据存储层。其中用户界面层是与用户交互的界面，用户可通过用户界面层向系统上传文件或者提出查询请求，系统所返回的结果页面也显示在用户界面层。业务逻辑层主要是“预处理器”所组成。预处理器是介于用户界面层与存储层的Hadoop集群之间的中间件，主要负责对用户的操作做一个预处理，如文件的合并，R树及倒排索引的更新，映射的建立等，然后将处理结果交给下一层，也就是存储层。存储层是Hadoop集群所在的层，是实际负责文件存储的地方，并提供与业务逻辑层中预处理器的交互。

本发明的关键技术分述如下：

(1)队列技术

第一个队列是文件待合并队列，此队列存放于预处理器中。此队列用于存储用户上传的小文件。文件经用户界面层上传后，先进入业务逻辑层的预处理器中等待处理。预处理器对上传文件大小进行判断，符合小文件定义的文件将会放入到文件待合并队列，并生成合并文件。

第二个队列是文件待上传队列，此队列也是存放于预处理器中。此对列用于存储在预处理器中被处理过的、即将要上传到Hadoop集群的文件，这些文件中有经过文件待合并队列处理过的合并文件，也含有经判断不属于小文件定义范畴的“大文件”，系统定时将此队列中的文件上传到集群当中。

(2)文件映射技术：

本发明使用属性(properties)文件来实现小文件的映射机制。属性(properties)文件是指扩展名为properties的文件，此文件中的数据是以“键—值”对的形式存储的，而且这种文件本质上是一个哈希表(HashTable)，因此，对此文件中某条记录的查找不需要遍历整个映射文件，只需要提供要查找的“键”，其查询的速度相对其他文件格式来说有一定的优势。所以，本发明选用属性(properties)文件存储元数据到小文件名的映射和小文件到合并文件的全局映射。以全局映射为例，此时映射的“键”是小文件名，“值”是包含此小文件的合并文件的文件名，以及小文件在此合并文件当中的偏移量和小文件的长度。可以通过此映射文件快速定位到小文件所在的合并文件名及其在其中的确切偏移量和长度，以便快速切割出所需的小文件。

(3)小文件判断机制

第一个判断机制是上传文件大小判断。首先要判断用户上传的文件是否是小文件，如果不是小文件，则直接将文件插入到待上传队列中，与其他合并后的待上传的文件一起等待上传到Hadoop集群。

第二个判断机制是合并文件大小的判断。在将小文件合并时，要判断合并文件的大小是否已经超过Hadoop块的大小，本方案中块的大小采用的是Hadoop默认配置64MB。若合并文件大小超过64MB，则将其插入到待上传队列中，然后重新建立一个合并文件供小文件合并使用。

(4)倒排索引：

倒排索引(Inverted index)，也常被称为反向索引、置入档案或反向档案，是一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。它是文档检索系统中最常用的数据结构。通过倒排索引，可以根据单词快速获取包含这个单词的文档列表。倒排索引主要由两个部分组成：“单词词典”和“倒排文件”。“单词词典”是由文档集合中出现过的所有单词构成的字符串集合，单词词典内的每条索引项记载单词本身的一些信息及指向倒排列表的指针。“倒排文件”是存储倒排索引的物理文件。

传统的索引一般是记录某篇文档包含了哪些关键词，而倒排列表用来记录有哪些文档包含了某个关键词。一般在文档集合里会有很多文档包含某个单词，每个文档会记录文档编号(DocID)，单词在这个文档中出现的次数(TF)及单词在文档中哪些位置出现过等信息，这样与一个文档相关的信息被称做倒排索引项(Posting)，包含这个单词的一系列倒排索引项形成了列表结构，这就是某个单词对应的倒排列表。

现代搜索引擎的索引都是基于倒排索引。相比“签名文件”、“后缀树”等索引结构，“倒排索引”是实现单词到文档映射关系的最佳实现方式和最有效的索引结构。

本发明所解决问题如下：

(1)NameNode负载过重：

将批量小文件合并成一个文件，称为合并文件。为了提高Hadoop存储小文件的效率，最大的问题就是解决因文件数量过多而导致NameNode负载过重，本发明采用将小文件合并技术解决这一问题。

(2)范围查询：

提取每个小文件的元数据，对数值化和非数值化的元数据分开处理，并将数值化的元数据映射成空间坐标后插入R树中，对非数值化的元数据插入到倒排索引中。对数值化元数据来说，R树可解决拥有相似元数据的文件经映射后存储在空间中近似位置，并提供范围查询，可完成通过文件元数据查询文件。

(3)小文件的定位：

对每一个小文件建立存储在预处理器中的全局映射。文件合并技术用于提高小文件的存储效率，预处理器端全局映射管理技术用于管理合并后的小文件到合并文件名的映射以及在合并文件中的存储位置。

通过以上技术，提高了海量小文件的存取效率。本发明适用于通用场景下小文件的存储和管理。

有益效果：

1.本发明方便小文件存取的处理。

2.本发明解决了Hadoop因小文件数量巨大而对NameNode产生的负载，以致使NameNode的内存大小成为集群性能的瓶颈问题。

3.本发明解决了Hadoop自带处理方法中的一些问题。如：Hadoop Archive(HAR)中一旦创建归档文件就不可以改变,不能增加或移除里面的文件，必须重新创建归档文件；SequenceFile合并文件后没有索引，若要查询一个SequenceFile文件中某个小文件，必须遍历整个SequenceFile文件，效率较低。

附图说明：

图1是本发明系统体系架构图。

图2是文件上传流程图。

图3是文件查询流程图。

具体实施方式

以下结合说明书附图对本发明作进一步的详细说明。

Hadoop小文件存取三层架构：

本发明将Hadoop小文件存取过程分为三个层次，每个层次完成不同的处理过程。三层结构图见附图1所示。

本发明采用B/S模式，即“浏览器—服务器”模式。用户界面层即客户端机器，为普通的装有浏览器的PC机。业务逻辑层即预处理器，可以为单台服务器或者是服务器集群，其中运行着Web服务器，如Tomcat，用来处理客户机通过浏览器提交过来的请求以及对此请求作出响应的响应。预处理器是介于用户界面层与存储层的Hadoop集群之间的中间件，主要负责对用户的操作作一个预处理，如文件的合并，R树及倒排索引的更新，映射的建立等，然后将处理结果交给下一层，也就是存储层。存储层是真正存储数据的地方，采用Hadoop集群，集群大小依需求而定，生产环境下可以采用服务器，测试环境可以采用普通PC机。存储层还提供与业务逻辑层的预处理器的交互。

本发明的流程主要分为两部分：小文件上传与小文件查询。其中，小文件上传的流程图见附图2，小文件查询的流程图见附图3。

小文件上传流程：

小文件上传模块主要负责小文件的合并，即将批量小文件合并成与Hadoop块大小近似的合并文件，然后将合并后的文件以及经判断不属于小文件范畴的“大文件”上传到Hadoop集群。步骤如下：

步骤一：小文件判断

在用户界面层，文件经用户通过客户端浏览器上传，此次上传后的文件先被提交至业务逻辑层预处理器的Web服务器中。Web服务器中的业务处理逻辑先进行文件大小的判断，本发明所取Hadoop块大小为其默认值64MB，逻辑规定小于块长度的文件被判定为小文件，插入待合并队列中，如果文件长度大于块的长度，则被判定为大文件，直接放入待上传队列中。循环这一操作直至用户此次上传的所有文件处理完毕。

步骤二：元数据提取

小文件元数据提取出来分为两个部分，一是数值化的元数据，如上传时间，最后修改时间，文件大小；二是非数值化的元数据的，如上传者，文件名。文件提取出的元数据如下：

<上传者，文件名，上传时间，最后修改时间，大小等>

步骤三：元数据处理

依次取出待合并队列中的小文件，提取出其元数据。元数据处理分为两个部分，一是数值化元数据的处理，二是非数值化元数据的处理，二者特性不同，处理方法不同。

A：数值化元数据的处理

数值化的元数据有<上传时间，最后修改时间，大小>，如<20140712091020,20140610105316,32372>，这些数据的大小有比较意义，可放入R树中。在插入R树之前，做好此元数据到小文件名的映射，采用“键—值”对的形式存储在属性(properties)文件中。properties是这种文件的扩展名。此文件格式的优点在于：文件中的记录存放位置并不是按照插入顺序，而是按照键的哈希值存放，这大大地提高了查询速度。映射结构中，键是数值化的元数据，值为小文件名。因为R树的查询结果是一个点的坐标值，要将其映射为文件名才有意义。此处的映射结构可设计为：

20140712091020_20140610105316_32372＝filename

其中，“＝”号左边的数字以“_”隔开，分别为文件的上传时间，最后修改时间和大小，“＝”号右边的是对应此元数据的小文件名。

B：非数值化元数据的处理

非数值化的元数据有<上传者，文件名>，如<zhangsan,Thinking in Java>,这些数据不可比较大小，所以不应与数值化的元数据使用相同处理策略。本发明对这类元数据的处理方法是采用倒排索引，记录包含元数据中关键词的文件编号，在查询时可快速查到符合查询要求的文件集合。

步骤四：全局映射

经过上一步的处理之后，更新预处理器中的全局映射。此映射记录的是小文件名到包含它的合并文件及其在合并文件中的偏移量和长度的映射。全局映射也是采用“键—值”对的形式存储在属性(properties)文件中。具体的索引结构如下：

filename＝CombinedFileName_offset_length

其中：filename代表小文件的文件名，CombinedFileName代表包含此小文件的合并文件名，offset代表小文件在合并文件中的偏移量，length代表小文件的长度。索引的数据结构设计思路为：因为小文件是被包含在合并文件中上传至Hadoop文件系统上，所以Hadoop文件系统并不了解此合并文件内部的细节。在查询的时候，只能根据合并文件名去查询包含此小文件的合并文件，然后根据offset和length从合并文件中切割出小文件。根据此映射，可以切割出要查找的文件。

步骤五：文件合并

将待合并队列中的小文件依次取出，添加到合并文件中。合并时，先查看是否有未写满的合并文件，如果有，则取出此文件继续将其写满；否则，新建一个空的合并文件。合并完成后，再将合并文件添加到待上传队列中。

步骤六：文件上传

通过调用Hadoop文件系统的API将待上传队列中的合并文件上传到Hadoop文件系统中。

小文件查询流程：

此模块的设计思想分为两步：

1.用户首次提交查询请求，首先返回符合用户查询条件的文件的元数据，等待用户再次确认文件；

2.用户根据第一次返回的与其提交的查询请求匹配的结果，再次确认文件，并取回所需的小文件。

详细步骤如下：

步骤一：首次请求

用户通过用户界面层的客户端浏览器提出第一次查询请求。此请求可以是待查询的文件名，上传时间，最后修改时间，上传者，文件大小等等。请求可以是这其中一项或几项，可以是一些比较模糊的关键词。

步骤二：处理请求

请求处理分两部分，分别为数值化和非数值化关键词的处理。

A：数值化关键词的处理

请求提交到业务逻辑层预处理器的Web服务器中，服务器根据查询请求，Web将数值化的数据构造出空间坐标后查询R树。R树可以执行范围查询或Top-K查询，查询的的输出为与查询请求相吻合或相似的小文件的数值化元数据。查询元数据到小文件名的映射表，得到对应的小文件名。

B：非数值化关键词的处理

对于非数值化的数据，需查询倒排索引。首先将查询字符串进行分词操作，用分词的结果查询倒排索引，得到包含此关键词文件编号，根据文件编号查询映射表得到对应文件名。

将A，B两步所返回的处理结果做AND操作，即“&”操作，得到首次查询的结果。

步骤三：返回初步查询结果

预处理器将经过首次查询得到的符合条件的小文件根据与查询请求的相关性排名后返回给用户。

步骤四：文件选择

用户选择感兴趣的小文件，查询全局映射文件，得到包含此小文件的合并文件名和待查询小文件在此合并文件中的偏移量及长度。

步骤五：返回最终结果

根据合并文件名向Hadoop发起查询请求，Hadoop将文件返回给预处理器。然后根据前一步得到的偏移量和长度切割合并文件，将得到的小文件返回给用户。查询结束。

Claims (2)

1.一种Hadoop存取海量小文件的优化方法，其特征在于：处理架构分为三层，分别为：用户界面层，业务逻辑层，数据存储层；其中用户界面层是与用户交互的界面，用户通过用户界面层向系统上传文件或者提出查询请求，系统所返回的结果页面也显示在用户界面层；业务逻辑层主要是“预处理器”所组成；预处理器是介于用户界面层与存储层的Hadoop集群之间的中间件，负责对用户的操作作一个预处理，然后将处理结果交给下一层，也就是存储层；存储层是Hadoop集群所在的层，是实际负责文件存储的地方，并提供与业务逻辑层的预处理器的交互；分层次实现Hadoop小文件存取性能的优化；

处理Hadoop小文件存取的流程分为如下步骤：

(1)小文件存储：

文件存储模块是负责小文件的合并，即将批量小文件合并成与Hadoop块大小近似的合并文件，然后将合并后的文件以及经判断不属于小文件范畴的“大文件”上传到Hadoop集群；步骤如下：

步骤一：小文件判断

在用户界面层，文件经用户通过客户端浏览器上传，此次上传后的文件先被提交至业务逻辑层预处理器的Web服务器中；Web服务器中的业务处理逻辑先进行文件大小的判断，Hadoop块设定这一默认值，逻辑规定小于块长度的文件被判定为小文件，插入待合并队列中；如果文件长度大于块的长度，则被判定为大文件，直接放入待上传队列中；循环这一操作直至用户此次上传的所有文件处理完毕；

步骤二：元数据提取

小文件元数据提取出来分为两个部分，一是数值化的元数据，最后修改时间，文件大小；二是非数值化的元数据的；文件提取出的元数据如下：

<上传者，文件名，上传时间，最后修改时间，大小>

步骤三：元数据处理

经过上一步处理后，需要合并的文件都被放在待合并队列中，然后依次取出待合并队列中的小文件，提取出其元数据；元数据处理分为两个部分，一是数值化元数据的处理，二是非数值化元数据的处理，二者特性不同，处理方法不同；

A：数值化元数据的处理

数值化的元数据有<上传时间，最后修改时间，大小>，这些数据的大小有比较意义，可放入R树中；在插入R树之前，做好此元数据到小文件名的映射，采用“键—值”对的形式存储在属性(properties)文件中；properties是这种文件的扩展名；此文件格式的优点在于：文件中的记录存放位置并不是按照插入顺序，而是按照键的Hash值存放，这大大地提高了查询速度；映射结构中，键是数值化的元数据，值为小文件名；此处的映射结构可设计为：20140712091020_20140610105316_32372＝filename其中，“＝”号左边的数字以“_”隔开，分别为文件的上传时间，最后修改时间和大小，“＝”号右边的是对应此元数据的小文件名；

B：非数值化元数据的处理

非数值化的元数据有<上传者，文件名>，

这些数据不可比较大小，所以不应与数值化的元数据使用相同处理策略；对这类元数据的处理方法是采用倒排索引，记录包含元数据中关键词的文件编号，在查询时可快速查到符合查询要求的文件集合；

步骤四：全局映射

经过上一步的处理之后，更新预处理器中的全局映射；此映射记录的是小文件名到包含它的合并文件及其在合并文件中的偏移量和长度的映射；全局映射也是采用“键—值”对的形式存储在属性(properties)文件中；具体的索引结构如下：filename＝CombinedFileName_offset_length其中：filename代表小文件的文件名，CombinedFileName代表包含此小文件的合并文件名，offset代表小文件在合并文件中的偏移量，length代表小文件的长度；索引的数据结构设计思路为：因为小文件是被包含在合并文件中上传至Hadoop文件系统中，所以Hadoop文件系统并不了解此合并文件内部的细节；在查询的时候，只能根据合并文件名去查询包含此小文件的合并文件，然后根据offset和length从合并文件中切割出小文件；根据此映射，可以准确地切割出要查找的文件；

步骤五：文件合并

将待合并队列中的小文件依次取出；合并时，先查看是否有未写满的合并文件，如果有，则取出此文件继续将其写满；否则，新建一个空的合并文件；合并完成后，再将所有的合并文件添加到待上传队列中；

步骤六：文件上传

通过调用HDFS的API将待上传队列中的合并文件上传到HDFS中；

(2)小文件查询：

此模块的设计思想分为两步：

1.用户首次提交查询请求，首先返回符合用户查询条件的文件的元数据，等待用户选择所需文件；

2.确认文件：用户根据第一次返回的与其提交的查询请求匹配的结果，选择所需文件，系统处理后，返回所需的小文件；

详细步骤如下：

步骤一：查询请求

用户通过用户界面层的客户端浏览器提出第一次查询请求；此请求是待查询的文件名或上传时间或最后修改时间或上传者或文件大小一项或几项，或是一些比较模糊的关键词；

步骤二：处理请求

请求处理分两部分，分别为数值化和非数值化关键词的处理；

A：数值化关键词的处理

请求提交到业务逻辑层预处理器的Web服务器中，服务器根据查询请求，Web将数值化的元数据构造出空间坐标后查询R树；R树可以执行范围查询或Top-K查询，查询的的输出为符合查询条件的小文件的数值化元数据；用查询得到的元数据构造成映射中键的形式，查询元数据到小文件名的映射表，得到对应的小文件名；

B：非数值化关键词的处理

对于非数值化的数据，需查询倒排索引；首先将查询字符串进行分词操作，用分词的结果查询倒排索引，得到包含此关键词文件编号，根据文件编号查询映射表得到对应文件名；

将A，B两步所返回的处理结果做AND操作，即“&”操作，得到首次查询的结果；

步骤三：返回初步查询结果

预处理器将经过首次查询得到的符合条件的小文件集合根据与查询请求的相关性排名后返回给用户；

步骤四：选择小文件

用户选择某一条感兴趣的小文件，选择到达Web服务器后，查询全局映射文件，得到包含此小文件的合并文件名和待查询小文件在此合并文件中的偏移量及长度；

步骤五：返回最终结果

根据合并文件名向Hadoop发起查询请求，Hadoop将文件返回给预处理器；然后根据前一步得到的偏移量和长度切割合并文件，将得到的小文件返回给用户；查询结束。

2.根据权利要求1所述的一种Hadoop存取海量小文件的优化方法，其特征在于,Hadoop块大小设定为默认值64MB。