[发明专利]基于MapFile的小文件管理服务SFMS系统及其使用方法

说明书

技术领域

本发明涉及由Apache基金会开发的Hadoop中，基于MapFile的小文件管理服务SFMS系统及其使用方法。

背景技术

Hadoop是一个分布式系统基础架构，由Apache基金会开发。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。Hadoop实现了一个分布式文件系统，简称HDFS。HDFS有着高容错性的特点，并且设计用来部署在低廉的硬件上。而且它提供高传输率来访问应用程序的数据，适合那些有着超大数据集的应用程序。

Hadoop是被设计用来处理大文件的，它将到来的大文件存储在不同datanode的不同数据块上，并在namenode上记录大文件的元数据。当要对某个文件进行操作时，首先访问namenode，根据namenode的反馈信息定位到各个块置，找到这个文件，然后使用相应的命令对进行操作。需要说明是，这些操作都是按块进行的。而对于小文件，Hadoop便不再那么高效，甚至会因为文件数量的增多而崩溃。由于每个独立的小文件中所含有数据量是非常少，只能作为一块（远小于数据块的默认大）存储或操作，且海量文件就意味着元数据也是海量的。

Hadoop在处理海量小文件问题上的不足主要体现在HDFS和MapReduce两个方面：

在HDFS中，HDFS是针对大文件设计的，在存储大文件时能够体现性能上的优势，但没有很好的优化小文件的方法，这一点在我们使用HDFS存储大量小文件的过程中得到了体现。一个现象是文件的存储时间过长。原因在于系统需要为每一个小文件保存元数据信息，并且由于存在多个副本，需要为其分配多个存储节点。大部分的时间都花费在了系统开销上，真正用于传输文件内容的时间所占的比例非常小，导致小文件数目过多时存储速度变慢。另一个现象是集群内部节点内存占用率过高。原因在于不论是namenode服务器还是datanode服务器，都需要保存小文件的元数据信息。在HDFS的实现中，这部分信息是常驻内存的，因而当文件数目变得庞大时，所占用的内存也急剧增加。如果将这些文件元数据信息保存在磁盘中，那么可以预见，由于需要频繁地进行磁盘I/O访问，访问性能将急剧下降。

在MapReduce过程中，map任务通常是每次处理一个Block的数据，而且每一个map任务都会消耗一定量的bookkeeping资源。

发明内容

本发明的目的在于提供一种基于MapFile的小文件管理服务SFMS系统及其使用方法，以解决在Hadoop上的分布式文件系统HDFS上存储海量小文件时会占用master节点过多内存的问题。

为实现上述目的，本发明提供如下技术方案：

一种基于MapFile的小文件管理服务SFMS系统，包括：

客户端：客户端使用jar包编写程序，向SFMS发送管理小文件的请求；客户端还用于接收SFMS反馈的操作结果；

SFMS：SFMS（Small File Management Service）为小文件管理服务器，其使用Hadoop中自带的MapFile机制，采用基于时间合并的小文件合并方法，将海量小文件合并成有限个数的大文件，并将客户端发送的请求转化为对Hadoop集群中的MapFile的操作；还将操作结果反馈给客户端；

Hadoop集群：Hadoop集群用于存储MapFile；

所述的MapFile为Map容器的持久化文件，将一个个Key-Value对存储到文件中；给定一个Key即可快速定位到一个Value；MapFile是先将Key-Value按Key的字典序升序依次存储到data文件中，然后再将Key抽样取出，与该Key-Value对在data文件中的偏移量组成新的Key-Value对，存储到另一个文件index中；当需要读取某个Key对应的Value时，先将index文件读取到内存中，然后二分查找，找到该Key对应的偏移量，从而快速定位到该Key-Value对在data文件中的位置；

所述SFMS采用了小文件合并方法；小文件合并方法：以MapFile中存储的是Key-Value对为小文件合并为大文件的基础；以小文件的全路径为Key，小文件的内容为Value来构建Key-Value对，然后将该Key-Value对存储到MapFile，从而实现了小文件的合并；