CN115510000A - 文件合并方法、装置、电子设备、存储介质及程序产品 - Google Patents

Abstract

本公开实施例公开了一种文件合并方法、装置、电子设备、存储介质及程序产品，所述方法包括：接收来自用户的小文件合并请求；所述小文件合并请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据；将所述多个待合并小文件的元数据进行合并；将携带有合并后的元数据的文件合并请求发送给所述HDFS存储系统，以便在所述HDFS存储系统利用所述合并后的元数据对所述多个待合并文件进行管理。该技术方案，能够减少NameNode在管理该多个小文件的元数据时产生的压力，能够降低对该多个小文件的元数据的读写开销。

Description

文件合并方法、装置、电子设备、存储介质及程序产品

技术领域

本公开实施例涉及计算机技术领域，具体涉及一种文件合并方法、装置、电子设备、存储介质及程序产品。

背景技术

在大数据时代，随着互联网技术的迅速崛起与普及，人们在不同领域采集到的数据量之大，达到了前所未有的程度。同时，数据的产生、存储和处理方式发生了革命性的变化，人们的工作和生活基本上都可以用数字化表示，数据的使用查询非常频繁。

Spark是专为大规模数据处理而设计的快速通用的计算引擎，是现在形成一个高速发展应用广泛的生态系统。Spark可完成各种各样的运算，包括SQL查询、文本处理、机器学习等。Spark还提供了大量的库，包括Spark Core、Spark SQL、Spark Streaming、MLlib、GraphX。然而，通过Spark SQL或者Spark Streaming写Hive或者直接写入HDFS时，过多的小文件会对NameNode内存管理等产生巨大的压力，会影响整个集群的稳定运行。因此，如何解决HDFS存储系统中由于存储过多小文件，而导致NameNode内存管理压力增大是本领域技术人员需要解决的主要问题之一。

发明内容

本公开实施例提供一种文件合并方法、装置、电子设备、存储介质及程序产品。

第一方面，本公开实施例中提供了一种文件合并方法，包括：

接收来自用户的小文件合并请求；所述小文件合并请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；

基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据；

将所述多个待合并小文件的元数据进行合并；

将携带有合并后的元数据的文件合并请求发送给所述HDFS存储系统，以便在所述HDFS存储系统利用所述合并后的元数据对所述多个待合并文件进行管理。

进一步地，基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据，包括：

从所述HDFS存储系统获取满足所述标识信息以及类型信息的待合并候选文件的元数据；

基于所述待合并候选文件的元数据将存储大小小于预设阈值的所述待合并候选文件确定为所述待合并小文件；

获取所述多个待合并小文件的元数据。

进一步地，所述标识信息包括所述待合并候选文件的存储目录；和/或，所述类型信息包括在所述HDFS存储系统中对应的存储块为独立内容的文件类型。

进一步地，将所述多个待合并小文件的元数据进行合并，包括：

将所述多个待合并小文件的元数据合并成一个合并文件的元数据，且合并后的元数据中的数据存储块信息包括所述多个待合并小文件的元数据中全部的数据存储块信息。

进一步地，接收来自用户的小文件合并请求，包括：

响应于用户的小文件合并操作，输出所述用户具有权限的文件目录信息；

基于所述用户对于所述文件目录信息的选择操作，触发所述小文件合并请求；其中，所述小文件合并请求中将所述用户所操作的文件目录信息作为所述待合并候选文件的标识信息，将所述用户所选择的文件类型作为所述类型信息。

进一步地，所述合并后的元数据中包括所述合并文件的文件标识与所述多个待合并小文件的文件标识之间的关联关系；和/或，所述合并后的元数据中包括所述多个待合并小文件的文件标识与数据存储块信息的映射关系。

第二方面，本公开实施例中提供了一种文件合并方法，其中，包括：

接收来自客户端的文件合并请求；所述文件合并请求包括多个待合并小文件的文件信息以及合并后的元数据；所述多个待合并小文件的文件内容存储在数据存储块中；

将所述多个待合并小文件的元数据从相应的文件信息管理结构中删除；

将所述合并后的元数据作为一个合并文件的元数据添加至所述文件信息管理结构中，以一个合并文件的形式管理所述多个待合并小文件的文件内容所在的所述数据存储块；所述合并后的元数据中包括所述多个待合并小文件的文件内容所在的所述数据存储块的信息。

进一步地，还包括：

接收所述客户端的文件元数据请求；所述文件元数据请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；

基于所述标识信息对应的文件目录下，符合所述类型信息的待合并候选文件的元数据返回给所述客户端。

进一步地，还包括：

获取客户端对所述合并文件的访问请求；所述访问请求中包括所述合并文件的文件标识；

基于所述合并文件的文件标识获取所述合并文件的元数据；

基于所述合并文件的元数据中的所述数据存储块的信息，从所述数据存储块读取所述合并文件的文件内容，并返回给所述客户端。

进一步地，还包括：

获取客户端对所述待合并小文件中目标小文件的访问请求；所述访问请求包括所述目标小文件的文件标识；

确定所述文件标识是否关联有合并文件的文件标识；

在所述文件标识关联有合并文件的文件标识时，获取所述合并文件的元数据；

基于所述合并文件的元数据中所述数据存储块的信息，确定所述目标小文件对应的目标存储块的信息；

基于所述目标存储块的信息从所述目标存储块读取所述目标小文件的文件内容，并返回给所述客户端。

第三方面，本公开实施例中提供了一种文件合并方法，其中，包括：

客户端接收来自用户的小文件合并请求；所述小文件合并请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；

客户端基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据；

客户端将所述多个待合并小文件的元数据进行合并，以及将携带有合并后的元数据的文件合并请求发送给所述HDFS存储系统；

HDFS存储系统接收来自客户端的文件合并请求；所述文件合并请求包括多个待合并小文件的文件信息以及合并后的元数据；所述多个待合并小文件的文件内容存储在数据存储块中；

HDFS存储系统将所述多个待合并小文件的元数据从相应的文件信息管理结构中删除，以及将所述合并后的元数据作为一个合并文件的元数据添加至所述文件信息管理结构中，以一个合并文件的形式管理所述多个待合并小文件的文件内容所在的所述数据存储块；所述合并后的元数据中包括所述多个待合并小文件的文件内容所在的所述数据存储块的信息。

进一步地，客户端基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据，包括：

客户端从所述HDFS存储系统获取满足所述标识信息以及类型信息的待合并候选文件的元数据；

客户端基于所述待合并候选文件的元数据将存储大小小于预设阈值的所述待合并候选文件确定为所述待合并小文件；

客户端获取所述多个待合并小文件的元数据。

进一步地，客户端将所述多个待合并小文件的元数据进行合并，包括：

客户端将所述多个待合并小文件的元数据合并成一个合并文件的元数据，且合并后的元数据中的数据存储块信息包括所述多个待合并小文件的元数据中全部的数据存储块信息。

进一步地，客户端接收来自用户的小文件合并请求，包括：

客户端响应于用户的小文件合并操作，输出所述用户具有权限的文件目录信息；

客户端基于所述用户对于所述文件目录信息的选择操作，触发所述小文件合并请求；其中，所述小文件合并请求中将所述用户所操作的文件目录信息作为所述待合并候选文件的标识信息，将所述用户所选择的文件类型作为所述类型信息。

进一步地，所述合并后的元数据中包括所述合并文件的文件标识与所述多个待合并小文件的文件标识之间的关联关系；和/或，所述合并后的元数据中包括所述多个待合并小文件的文件标识与数据存储块信息的映射关系。

进一步地，客户端接收来自用户的小文件合并请求，包括：

客户端响应于用户的小文件合并操作，输出所述用户具有权限的文件目录信息；

客户端基于所述用户对于所述文件目录信息的选择操作，触发所述小文件合并请求；其中，所述小文件合并请求中将所述用户所操作的文件目录信息作为所述待合并候选文件的标识信息，将所述用户所选择的文件类型作为所述类型信息。

进一步地，还包括：

HDFS存储系统接收所述客户端的文件元数据请求；所述文件元数据请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；

HDFS存储系统基于所述标识信息对应的文件目录下，符合所述类型信息的待合并候选文件的元数据返回给所述客户端。

进一步地，还包括：

HDFS存储系统获取客户端对所述合并文件的访问请求；所述访问请求中包括所述合并文件的文件标识；

HDFS存储系统基于所述合并文件的文件标识获取所述合并文件的元数据；

HDFS存储系统基于所述合并文件的元数据中所述数据存储块的信息，从所述数据存储块读取所述合并文件的文件内容，并返回给所述客户端。

进一步地，还包括：

HDFS存储系统获取客户端对所述待合并小文件中目标小文件的访问请求；所述访问请求包括所述目标小文件的文件标识；

HDFS存储系统确定所述文件标识是否关联有合并文件的文件标识；

HDFS存储系统在所述文件标识关联有合并文件的文件标识时，获取所述合并文件的元数据；

HDFS存储系统基于所述合并文件的元数据中所述数据存储块的信息，确定所述目标小文件对应的目标存储块的信息；

HDFS存储系统基于所述目标存储块的信息从所述目标存储块读取所述目标小文件的文件内容，并返回给所述客户端。

第四方面，本公开实施例中提供了一种文件合并装置，包括：

第一接收模块，被配置为接收来自用户的小文件合并请求；所述小文件合并请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；

获取模块，被配置为基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据；

合并模块，被配置为将所述多个待合并小文件的元数据进行合并；

发送模块，被配置为将携带有合并后的元数据的文件合并请求发送给所述HDFS存储系统，以便在所述HDFS存储系统利用所述合并后的元数据对所述多个待合并文件进行管理。

第五方面，本公开实施例中提供了一种文件合并装置，包括：

第二接收模块，被配置为接收来自客户端的文件合并请求；所述文件合并请求包括多个待合并小文件的文件信息以及合并后的元数据；所述多个待合并小文件的文件内容存储在数据存储块中；

删除模块，被配置为将所述多个待合并小文件的元数据从相应的文件信息管理结构中删除；

添加模块，被配置为将所述合并后的元数据作为一个合并文件的元数据添加至所述文件信息管理结构中，以一个合并文件的形式管理所述多个待合并小文件的文件内容所在的所述数据存储块；所述合并后的元数据中包括所述多个待合并小文件的文件内容所在的所述数据存储块的信息。

所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。

在一个可能的设计中，上述装置的结构中包括存储器和处理器，所述存储器用于存储一条或多条支持上述装置执行上述对应方法的计算机指令，所述处理器被配置为用于执行所述存储器中存储的计算机指令。上述装置还可以包括通信接口，用于上述装置与其他设备或通信网络通信。

第六方面，本公开实施例中提供了一种文件合并系统，包括：客户端和HDFS存储系统；其中，

所述客户端接收来自用户的小文件合并请求；所述小文件合并请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；所述客户端基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据；以及将所述多个待合并小文件的元数据进行合并，以及将携带有合并后的元数据的文件合并请求发送给所述HDFS存储系统；

所述HDFS存储系统接收来自客户端的文件合并请求；所述文件合并请求包括多个待合并小文件的文件信息以及合并后的元数据；所述多个待合并小文件的文件内容存储在数据存储块中；所述HDFS存储系统将所述多个待合并小文件的元数据从相应的文件信息管理结构中删除，以及将所述合并后的元数据作为一个合并文件的元数据添加至所述文件信息管理结构中，以一个合并文件的形式管理所述多个待合并小文件的文件内容所在的所述数据存储块；所述合并后的元数据中包括所述多个待合并小文件的文件内容所在的所述数据存储块的信息。

第七方面，本公开实施例提供了一种电子设备，包括存储器和处理器，所述存储器用于存储一条或多条支持上述任一装置执行上述对应方法的计算机指令，所述处理器被配置为用于执行所述存储器中存储的计算机指令。上述任一装置还可以包括通信接口，用于与其他设备或通信网络通信。

第八方面，本公开实施例提供了一种计算机可读存储介质，用于存储上述任一装置所用的计算机指令，其包含用于执行上述任一方法所涉及的计算机指令。

第九方面，本公开实施例提供了一种计算机程序产品，其包含计算机指令，该计算机指令被处理器执行时用于实现上述任一方面所述方法的步骤。

本公开实施例提供的技术方案可包括以下有益效果：

通过本公开实施例，在客户端将多个小文件的元数据进行合并，并发送给HDFS存储系统，HDFS存储系统的NameNode可以将该合并后的元数据存储下来，而删除多个小文件原来各自的元数据，该多个小文件对应的文件内容所在的数据块则保持原样，而不对其进行合并。NameNode在接收到合并后的元数据之后，执行类似管理一个大文件的方式管理该多个小文件，即使存在过多小文件，则通过本公开实施例的方式将多个小文件的元数据进行合并后，能够减少NameNode在管理该多个小文件的元数据时产生的压力，能够降低对该多个小文件的元数据的读写开销。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开实施例。

附图说明

结合附图，通过以下非限制性实施方式的详细描述，本公开实施例的其它特征、目的和优点将变得更加明显。在附图中：

图1示出根据本公开一实施方式的文件合并方法的流程图；

图2示出根据本公开另一实施方式的文件合并方法的流程图；

图3示出根据本公开再一实施方式的文件合并方法的流程图；

图4示出根据本公开一实施方式的文件合并方法的整体流程图；

图5示出根据本公开一实施方式的文件合并装置的结构框图；

图6示出根据本公开另一实施方式的文件合并装置的结构框图；

图7示出根据本公开一实施方式的文件合并系统的结构框图；

图8是适于用来实现根据本公开一实施方式的文件合并方法的计算机系统的结构示意图。

具体实施方式

下文中，将参考附图详细描述本公开实施例的示例性实施方式，以使本领域技术人员可容易地实现它们。此外，为了清楚起见，在附图中省略了与描述示例性实施方式无关的部分。

在本公开实施例中，应理解，诸如“包括”或“具有”等的术语旨在指示本说明书中所公开的特征、数字、步骤、行为、部件、部分或其组合的存在，并且不欲排除一个或多个其他特征、数字、步骤、行为、部件、部分或其组合存在或被添加的可能性。

另外还需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开实施例。

分布式文件系统(Hadoop Distributed File System，HDFS)凭借高可靠、高效、可伸缩的特点，在大规模计算领域得到广泛的应用；分布式文件系统包括一个NameNode和多个DataNode，是集群结构的重要组成部分。随着集群数据规模的不断增加，NameNode常驻内存也随着数据量的增加而增大，为此需要不断调整NameNode堆内存的大小，以适应不断增长的内存空间。但是NameNode堆空间又不能无止境增加。集群2亿数据块的NameNode总内存约占113G；每个小文件占用1个数据块；若将小文件合并，可以有效减少数据块数量。

目前常用的小文件合并方案有以下几种：

(1)将小文件存储到Hbase中通过文件合并与分解提高文件的存储效率，这种方案的缺点就是随着文件的增多会造成Hbase大量的合并与分解操作占用大量系统资源严重影响系统的性能，将小文件重写成大文件对系统的读写压力较大，并且Hbase只支持简单的字符类型，对其它的图片等类型支持不好还需用户单独的处理。

(2)还有一种文件合并的方案是利用Sequence File来进行文件的合并，SequenceFile是用来存储二进制key-value形式的文件，通常利用Sequence File来存储小文件时将文件名存入到key(键值)中，文件内容存储到value中，这种方式最大的缺点就是由于其中的键值是未排序的文件，随机读取效率较低，需要遍历整个文件才能进行读取，并且这种方式不支持文件追加操作，因此合并之前的小文件要在服务器进行缓存，这样文件的安全性就不能得到保障。

为此，本公开实施例提出了一种文件合并方案，该方案中用户针对HDFS中存储的小文件发起小文件合并请求，用户可以指定需要合并的小文件的文件信息；该文件信息可以包括待合并候选文件的标识信息以及待合并候选文件的类型信息。在接收到用户的小文件合并请求之后，客户端基于标识信息以及类型信息从HDFS存储系统中获取待合并小文件的元数据，该元数据可以包括但不限于文件标识、存储位置、存储类型、大小、偏移量等。客户端可以将多个待合并小文件的元数据进行合并，并将合并后的元数据发送给HDFS存储系统，以便HDFS存储系统利用合并后的元数据管理该多个待合并小文件。通过这种方式，在客户端将多个小文件的元数据进行合并，并发送给HDFS存储系统，HDFS存储系统的NameNode可以将该合并后的元数据存储下来，而删除多个小文件原来各自的元数据，该多个小文件对应的文件内容所在的数据块则保持原样，而不对其进行合并。NameNode在接收到合并后的元数据之后，执行类似管理一个大文件的方式管理该多个小文件，即使存在过多小文件，则通过本公开实施例的方式将多个小文件的元数据进行合并后，能够减少NameNode在管理该多个小文件的元数据时产生的压力，能够降低对该多个小文件的元数据的读写开销。

图1示出根据本公开一实施方式的文件合并方法的流程图，如图1所示，所述文件合并方法包括以下步骤：

在步骤S101中，接收来自用户的小文件合并请求；所述小文件合并请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；

在步骤S102中，基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据；

在步骤S103中，将所述多个待合并小文件的元数据进行合并；

在步骤S104中，将携带有合并后的元数据的文件合并请求发送给所述HDFS存储系统，以便在所述HDFS存储系统利用所述合并后的元数据对所述多个待合并文件进行管理。

上文提及，Spark是专为大规模数据处理而设计的快速通用的计算引擎，是现在形成一个高速发展应用广泛的生态系统。Spark可完成各种各样的运算，包括SQL查询、文本处理、机器学习等。Spark还提供了大量的库，包括Spark Core、Spark SQL、Spark Streaming、MLlib、GraphX。然而，通过Spark SQL或者Spark Streaming写Hive或者直接写入HDFS时，过多的小文件会对NameNode内存管理等产生巨大的压力，会影响整个集群的稳定运行。因此，如何解决HDFS存储系统中由于存储过多小文件，而导致NameNode内存管理压力增大是本领域技术人员需要解决的主要问题之一。

考虑到上述问题，在该实施方式中，提出一种文件合并方法，该方法用户针对HDFS中存储的小文件发起小文件合并请求，用户可以指定需要合并的小文件的文件信息；该文件信息可以包括待合并候选文件的标识信息以及待合并候选文件的类型信息。在接收到用户的小文件合并请求之后，客户端基于标识信息以及类型信息从HDFS存储系统中获取待合并小文件的元数据，该元数据可以包括但不限于文件标识、存储位置、存储类型、大小、偏移量等。客户端可以将多个待合并小文件的元数据进行合并，并将合并后的元数据发送给HDFS存储系统，以便HDFS存储系统利用合并后的元数据管理该多个待合并小文件。通过这种方式，在客户端将多个小文件的元数据进行合并，并发送给HDFS存储系统，HDFS存储系统的NameNode可以将该合并后的元数据存储下来，而删除多个小文件原来各自的元数据，该多个小文件对应的文件内容所在的数据块则保持原样，而不对其进行合并。NameNode在接收到合并后的元数据之后，执行类似管理一个大文件的方式管理该多个小文件，即使存在过多小文件，则通过本公开实施例的方式将多个小文件的元数据进行合并后，能够减少NameNode在管理该多个小文件的元数据时产生的压力，能够降低对该多个小文件的元数据的读写开销。

在本公开一实施方式中，该文件合并方法可适用于在分布式文件系统的客户端上执行。

在本公开一实施方式中，大数据处理分析引擎例如Spark所启动的任务执行完成之后，可以将数据写入磁盘文件中。磁盘文件可以是分布式文件系统中的磁盘文件。在大数据处理分析引擎中，通过将一个作业分配给多个不同的并行执行的任务执行，而每个任务在执行过程中会产生多个文件，因此针对一个作业，多个并行执行的任务会产生多个磁盘文件，而在并行任务较多的情况下，可能会产生较多较小的磁盘文件。在一些已有技术中，为了减少分布式文件系统中过多小文件，通过Namenode读取出分布式文件系统中的多个小文件，进而将该多个小文件进行合并后，重新写成一个大文件，这种方式在小文件较多的情况下，容易给Namenode造成较大的压力，并且过多小文件的读写开销也会增大。

因此，本公开实施例中，由用户查看存储在分布式存储系统中的小文件，如果发现某个或者某些目录下的小文件过多，则可以通过客户端请求对这些小文件进行合并。或者，用户也可以定期发起合并小文件的请求。用户可以提供需要合并的小文件的标识信息以及类型信息。在用户无法确定哪些是小文件的情况下，可以指定待合并候选文件的标识信息以及能够进行合并的类型信息。客户端可以基于用户指定的待合并候选文件的标识信息以及类型信息从HDFS存储系统获取待合并小文件的元数据。

在本公开一实施方式中，待合并候选文件的标识信息可以是包括多个待合并候选文件的目标标识。待合并候选文件可以是待合并下文件，也可以不是。用户通过提供待合并候选文件的标识信息以及类型信息，提出希望将符合该标识信息以及类型信息的小文件进行合并的请求。客户端或者HDFS存储系统可以来判断符合该标识信息以及类型信息的待合并小文件，从而从HDFS存储系统获取该多个待合并小文件的元数据。

在本公开一实施方式中，客户端从HDFS存储系统获取到多个待合并小文件的元数据之后，可以将该多个待合并小文件的元数据进行合并。合并后的元数据中至少存储了该多个待合并小文件的文件内容所在的存储块信息。通过该合并后的元数据依然能够访问到该些待合并小文件的文件内容。该合并后的元数据被发送至HDFS存储系统后，HDFS存储系统将其作为一个大文件的元数据进行存储与管理，而对应于该些多个待合并小文件的元数据则可以直接删除。这种情况下，在需要访问该多个待合并小文件中的文件内容时，直接可以读取该合并后的元数据，从中确定所要访问的小文件的文件内容所在的存储块信息，并从该存储块中获取响应的文件内容即可。通过这种方式，仅仅将小文件的元数据进行了合并，而对应的存储块依然没有发生变化，因此在合并过程中仅需要读取多个小文件的元数据，不需要读取对应的存储块，不会对HDFS存储系统产生较大压力，也不会产生较大的读取开销。

在本公开一实施方式中，步骤S102，即基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据的步骤，进一步包括以下步骤：

从所述HDFS存储系统获取满足所述标识信息以及类型信息的待合并候选文件的元数据；

基于所述待合并候选文件的元数据将存储大小小于预设阈值的所述待合并候选文件确定为所述待合并小文件；

获取所述多个待合并小文件的元数据。

该实施方式中，客户端可以从HDFS存储系统获取满足用户提供的标识信息以及类型信息的待合并候选文件的元数据，例如可以获取用户指定的目录下文件类型与该类型信息相符的所有文件的元数据。

由于每个文件的元数据中存储了文件大小，因此通过待合并候选文件的元数据可以确定每个待合并候选文件的大小，如果该待合并候选文件的大小小于预设阈值，则认为该待合并候选文件为待合并小文件，否则认为该待合并候选文件不为待合并小文件。该预设阈值可以基于实际需要进行设置，在此不做限制。

在本公开一实施方式中，在HDFS存储系统中，为了便于文件的管理和备份，引入存储块概念(block)。这里的存储块是HDFS存储系统中的最小存储单位，HDFS默认定义一个存储块的大小为64MB。当有文件上传到HDFS上时，若文件大小大于设置的存储块大小，则该文件会被切分存储为多个存储块，多个存储块可以存放在不同的DataNode上，整个过程中HDFS存储系统会保证一个存储块存储在一个DataNode上。但值得注意的是如果某文件大小没有到达64MB，该文件并不会占据整个存储块空间。HDFS中的NameNode会记录在上述文件分存储块中文件的各个存储块都存放在哪个DataNode上，这些信息一般也称为元数据(MetaInfo)。当一个作业提交到大数据处理分析引擎例如Spark来执行的时候，该过程中传输的数据可能会很多，Spark任务产生的数据经过分区等操作之后会产生多个文件，而该文件的大小可能会小于存储块的大小，这时就会造成一个存储块上存储的一个文件无法占据该磁盘存储块的整个空间，造成空间浪费，并且造成元数据过大，挤占NameNode内存。因此，本公开实施例中，可以将预设阈值基于分布式文件系统的存储块大小设置，例如设置为存储块的大小，将大小小于存储块大小的待合并候选文件文件确定为待合并小文件。

确定了哪些是待合并小文件后，将该些待合并小文件的元数据合并成一个大文件的元数据，并将合并后的元数据提供给HDFS存储系统，进而存储和管理。

在本公开一实施方式中，所述标识信息包括所述待合并候选文件的存储目录；和/或，所述类型信息包括在所述HDFS存储系统中对应的存储块为独立内容的文件类型。

该实施方式中，由于一些小文件可能是非独立存在的，类似于一个压缩文件被分割成多个文件进行存储的情况，这种文件是无法采用本公开实施例这种方式进行合并的。因此，本公开实施例中，可以将能够合并的待合并小文件的文件类型可以为存储块中的内容为独立内容的文件，也即该文件对应的存储块内容不依赖于其他任何文件。

在本公开一实施方式中，步骤S103，即将所述多个待合并小文件的元数据进行合并的步骤，进一步包括以下步骤：

将所述多个待合并小文件的元数据合并成一个合并文件的元数据，且合并后的元数据中的数据存储块信息包括所述多个待合并小文件的元数据中全部的数据存储块信息。

该实施方式中，多个待合并小文件中的元数据可以被合并成一个文件的元数据，多个待合并文件中重复的内容可以删除，而不重复的内容可以予以保留，并按照一个文件的元数据的结构进行组织。多个待合并文件中用于指示文件内容所在的存储块信息，在合并后的元数据中需要保留。在对其中一个待合并小文件中的文件内容进行访问时，可以从合并后的元数据中找到该待合并小文件的文件内容所在的存储块，进而从该存储块获取对应的文件内容进行访问。

在本公开一实施方式中，步骤S101，即接收来自用户的小文件合并请求的步骤，进一步包括以下步骤：

响应于用户的小文件合并操作，输出所述用户具有权限的文件目录信息；

基于所述用户对于所述文件目录信息的选择操作，触发所述小文件合并请求；其中，所述小文件合并请求中将所述用户所操作的文件目录信息作为所述待合并候选文件的标识信息，将所述用户所选择的文件类型作为所述类型信息。

该实施方式中，用户在合适的时间想要请求合并HDFS存储系统中存储的小文件时，可以基于客户端上提供的接口发起小文件合并操作，客户端检测到该小文件合并操作后，可以在客户端界面上输出该用户具有权限的文件目录等信息，该文件目录例如可以是其中一个目录，也可以是一个目录树结构。用户可以选择所输出的文件目录，进而触发客户端产生小文件合并请求。该小文件合并请求中可以包括用户所选择的文件目录，将该文件目录作为待合并候选文件的标识信息；此外，用户可以选择需要合并的文件类型，该小文件合并请求中还包括该文件类型的类型信息。

在本公开一实施方式中，所述合并后的元数据中包括所述合并文件的文件标识与所述多个待合并小文件的文件标识之间的关联关系；和/或，所述合并后的元数据中包括所述多个待合并小文件的文件标识与数据存储块信息的映射关系。

该实施方式中，合并后的元数据中除了存储有多个待合并小文件中各自文件内容对应的存储块信息外，还包括该合并后的元数据对应的合并文件的文件标识，以及该合并文件的文件标识与该多个待合并小文件的文件标识之间的映射关系。

此外，合并后的元数据中所存储的存储块信息，还可以建立其与相应的待合并小文件之间的映射关系，通过该映射关系可以基于合并文件的文件标识、待合并小文件的文件标识确定该待合并小文件的文件内容所在存储块信息。

图2示出根据本公开另一实施方式的文件合并方法的流程图，如图2所示，所述文件合并方法包括以下步骤S201-S203：

在步骤S201中，接收来自客户端的文件合并请求；所述文件合并请求包括多个待合并小文件的文件信息以及合并后的元数据；所述多个待合并小文件的文件内容存储在数据存储块中；

在步骤S202中，将所述多个待合并小文件的元数据从相应的文件信息管理结构中删除；

在步骤S203中，将所述合并后的元数据作为一个合并文件的元数据添加至所述文件信息管理结构中，以一个合并文件的形式管理所述多个待合并小文件的文件内容所在的所述数据存储块；所述合并后的元数据中包括所述多个待合并小文件的文件内容所在的所述数据存储块的信息。

上文提及，Spark是专为大规模数据处理而设计的快速通用的计算引擎，是现在形成一个高速发展应用广泛的生态系统。Spark可完成各种各样的运算，包括SQL查询、文本处理、机器学习等。Spark还提供了大量的库，包括Spark Core、Spark SQL、Spark Streaming、MLlib、GraphX。然而，通过Spark SQL或者Spark Streaming写Hive或者直接写入HDFS时，过多的小文件会对NameNode内存管理等产生巨大的压力，会影响整个集群的稳定运行。因此，如何解决HDFS存储系统中由于存储过多小文件，而导致NameNode内存管理压力增大是本领域技术人员需要解决的主要问题之一。

考虑到上述问题，在该实施方式中，提出一种文件合并方法，该方法用户针对HDFS中存储的小文件发起小文件合并请求，用户可以指定需要合并的小文件的文件信息；该文件信息可以包括待合并候选文件的标识信息以及待合并候选文件的类型信息。在接收到用户的小文件合并请求之后，客户端基于标识信息以及类型信息从HDFS存储系统中获取待合并小文件的元数据，该元数据可以包括但不限于文件标识、存储位置、存储类型、大小、偏移量等。客户端可以将多个待合并小文件的元数据进行合并，并将合并后的元数据发送给HDFS存储系统，以便HDFS存储系统利用合并后的元数据管理该多个待合并小文件。通过这种方式，在客户端将多个小文件的元数据进行合并，并发送给HDFS存储系统，HDFS存储系统的NameNode可以将该合并后的元数据存储下来，而删除多个小文件原来各自的元数据，该多个小文件对应的文件内容所在的数据块则保持原样，而不对其进行合并。NameNode在接收到合并后的元数据之后，执行类似管理一个大文件的方式管理该多个小文件，即使存在过多小文件，则通过本公开实施例的方式将多个小文件的元数据进行合并后，能够减少NameNode在管理该多个小文件的元数据时产生的压力，能够降低对该多个小文件的元数据的读写开销。

在本公开一实施方式中，该文件合并方法可适用于在HDFS存储系统上执行。

在本公开一实施方式中，大数据处理分析引擎例如Spark所启动的任务执行完成之后，可以将数据写入磁盘文件中。磁盘文件可以是分布式文件系统中的磁盘文件。在大数据处理分析引擎中，通过将一个作业分配给多个不同的并行执行的任务执行，而每个任务在执行过程中会产生多个文件，因此针对一个作业，多个并行执行的任务会产生多个磁盘文件，而在并行任务较多的情况下，可能会产生较多较小的磁盘文件。在一些已有技术中，为了减少分布式文件系统中过多小文件，通过Namenode读取出分布式文件系统中的多个小文件，进而将该多个小文件进行合并后，重新写成一个大文件，这种方式在小文件较多的情况下，容易给Namenode造成较大的压力，并且过多小文件的读写开销也会增大。

为此，客户端从HDFS存储系统获取到多个待合并小文件的元数据之后，可以将该多个待合并小文件的元数据进行合并。合并后的元数据中至少存储了该多个待合并小文件的文件内容所在的存储块信息。通过该合并后的元数据依然能够访问到该些待合并小文件的文件内容。该合并后的元数据被发送至HDFS存储系统后，HDFS存储系统将其作为一个大文件的元数据进行存储与管理，而对应于该些多个待合并小文件的元数据则可以直接删除。

HDFS存储系统接收到上述文件合并请求后，将文件信息管理结构中该多个待合并小文件的元数据删除，并将合并后的元数据作为一个合并文件的元数据添加至该文件信息管理结构中。该文件信息管理结构例如可以由HDFS存储系统中的Namenode管理，Namenode接收到文件合并请求后，可以将文件信息管理结构中相应目录下多个待合并小文件的元数据删除，并将该合并后的元数据添加到该相应目录下，在Namenode处相当于将多个待合并小文件合并成了一个合并文件。此外，该多个待合并小文件的文件内容存储在存储块中，存储块分布在不同的Datanode节点上，多个待合并小文件的文件内容所在的存储块并不进行任何改动，只是将这些存储块信息写入合并后的元数据中，作为合并文件对应的存储块，从而实现对多个小文件的合并，减轻在Namenode上对这些小文件的元数据的维护压力，以及降低对这些小文件的读写开销。

在Namenode中通过合并后的元数据代替多个待合并小文件的元数据的方式，将多个待合并小文件对应的数据存储块作为一个合并文件的数据存储块的形式进行管理，虽然该一个合并文件的数据存储块分布在多个不同的数据存储块中，但是其依然可以作为一个文件进行管理，达到了合并小文件的目的。

这种情况下，在需要访问该多个待合并小文件中的文件内容时，直接可以读取该合并后的元数据，从中确定所要访问的小文件的文件内容所在的存储块信息，并从该存储块中获取响应的文件内容即可。通过这种方式，仅仅将小文件的元数据进行了合并，而对应的存储块依然没有发生变化，因此在合并过程中仅需要读取多个小文件的元数据，不需要读取对应的存储块，不会对HDFS存储系统产生较大压力，也不会产生较大的读取开销。

在本公开一实施方式中，所述方法还包括以下步骤：

接收所述客户端的文件元数据请求；所述文件元数据请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；

基于所述标识信息对应的文件目录下，符合所述类型信息的待合并候选文件的元数据返回给所述客户端。

该实施方式中，客户端可以从HDFS存储系统获取满足用户提供的标识信息以及类型信息的待合并候选文件的元数据，例如可以获取用户指定的目录下文件类型与该类型信息相符的所有文件的元数据。

待合并候选文件的标识信息可以是包括多个待合并候选文件的目标标识。待合并候选文件可以是待合并下文件，也可以不是。用户通过提供待合并候选文件的标识信息以及类型信息，提出希望将符合该标识信息以及类型信息的小文件进行合并的请求。客户端或者HDFS存储系统可以来判断符合该标识信息以及类型信息的待合并小文件，从而从HDFS存储系统获取该多个待合并小文件的元数据。

HDFS存储系统接收到客户端的文件元数据请求后，基于标识信息从对应的文件目录下获取相应的待合并候选文件的元数据，该待合并候选文件为文件类型与文件元数据请求中的类型信息相吻合的文件，待合并候选文件的元数据可以返回给客户端。

由于每个文件的元数据中存储了文件大小，因此客户端可以通过待合并候选文件的元数据可以确定每个待合并候选文件的大小，如果该待合并候选文件的大小小于预设阈值，则认为该待合并候选文件为待合并小文件，否则认为该待合并候选文件不为待合并小文件。该预设阈值可以基于实际需要进行设置，在此不做限制。

在本公开一实施方式中，所述方法还包括以下步骤：

获取客户端对所述合并文件的访问请求；所述访问请求中包括所述合并文件的文件标识；

基于所述合并文件的文件标识获取所述合并文件的元数据；

基于所述合并文件的元数据中所述数据存储块的信息，从所述数据存储块读取所述合并文件的文件内容，并返回给所述客户端。

该可选的实现方式中，合并后的元数据中除了存储有多个待合并小文件中各自文件内容对应的存储块信息外，还包括该合并后的元数据对应的合并文件的文件标识，以及该合并文件的文件标识与该多个待合并小文件的文件标识之间的映射关系。

此外，合并后的元数据中所存储的存储块信息，还可以建立其与相应的待合并小文件之间的映射关系，通过该映射关系可以基于合并文件的文件标识、待合并小文件的文件标识确定该待合并小文件的文件内容所在存储块信息。

客户端可以针对合并文件进行数据访问，其向HDFS存储系统发送文件访问请求后，HDFS存储系统基于该文件访问请求中该合并文件的文件标识，从文件信息管理结构中获取对应的元数据，并从该元数据中记录的数据存储块信息读取该合并文件的文件内容。需要说明的是，该元数据中记录的是之前未合并之前多个待合并小文件的所有数据存储块的信息，并且基于该数据存储块的信息能够读取到各个待合并小文件对应的文件内容。

在本公开一实施方式中，所述方法还包括以下步骤：

获取客户端对所述待合并小文件中目标小文件的访问请求；所述访问请求包括所述目标小文件的文件标识；

确定所述文件标识是否关联有合并文件的文件标识；

在所述文件标识关联有合并文件的文件标识时，获取所述合并文件的元数据；

基于所述合并文件的元数据中所述数据存储块的信息，确定所述目标小文件对应的目标存储块的信息；

基于所述目标存储块的信息从所述目标存储块读取所述目标小文件的文件内容，并返回给所述客户端。

该实施方式中，如上文中所述，合并后的元数据中除了存储有多个待合并小文件中各自文件内容对应的存储块信息外，还包括该合并后的元数据对应的合并文件的文件标识，以及该合并文件的文件标识与该多个待合并小文件的文件标识之间的映射关系。

因此在客户端也可以基于原多个待合并小文件之一的文件标识对目标小文件的文件内容进行访问。HDFS存储系统接收到携带与目标小文件的文件标识的文件访问请求后，如果在文件信息管理结构中查询到该文件标识对应管理合并文件的文件标识，则基于该合并文件的文件标识获取该合并文件的元数据，从合并文件的元数据中匹配该目标小文件的文件标识所对应的数据存储块的信息，基于该数据存储块的信息从相应的数据存储块中读出该目标小文件的文件内容，从而将该文件内容返回给客户端。

图2所示及相关实施方式中涉及的技术术语和技术特征与图1所示及相关实施方式中提及的技术术语和技术特征相同或相似，对于图2所示及相关实施方式中涉及的技术术语和技术特征的解释和说明可参考上述对于图1所示及相关实施方式的解释的说明，此处不再赘述。

图3示出根据本公开另一实施方式的文件合并方法的流程图，如图3所示，所述文件合并方法包括以下步骤S301-S305：

在步骤S301中，客户端基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据；

在步骤S302中，所述分布式文件系统响应于文件信息读取请求，返回所述数据写入成功事件对应的数据写入操作涉及的分布式文件目录下的文件信息；

在步骤S303中，客户端将所述多个待合并小文件的元数据进行合并，以及将携带有合并后的元数据的文件合并请求发送给所述HDFS存储系统；

在步骤S304中，HDFS存储系统接收来自客户端的文件合并请求；所述文件合并请求包括多个待合并小文件的文件信息以及合并后的元数据；所述多个待合并小文件的文件内容存储在数据存储块中；

在步骤S305中，HDFS存储系统将所述多个待合并小文件的元数据从相应的文件信息管理结构中删除，以及将所述合并后的元数据作为一个合并文件的元数据添加至所述文件信息管理结构中，以一个合并文件的形式管理所述多个待合并小文件的文件内容所在的所述数据存储块；所述合并后的元数据中包括所述多个待合并小文件的文件内容所在的所述数据存储块的信息。

上文提及，Spark是专为大规模数据处理而设计的快速通用的计算引擎，是现在形成一个高速发展应用广泛的生态系统。Spark可完成各种各样的运算，包括SQL查询、文本处理、机器学习等。Spark还提供了大量的库，包括Spark Core、Spark SQL、Spark Streaming、MLlib、GraphX。然而，通过Spark SQL或者Spark Streaming写Hive或者直接写入HDFS时，过多的小文件会对NameNode内存管理等产生巨大的压力，会影响整个集群的稳定运行。因此，如何解决HDFS存储系统中由于存储过多小文件，而导致NameNode内存管理压力增大是本领域技术人员需要解决的主要问题之一。

考虑到上述问题，在该实施方式中，提出一种文件合并方法，该方法用户针对HDFS中存储的小文件发起小文件合并请求，用户可以指定需要合并的小文件的文件信息；该文件信息可以包括待合并候选文件的标识信息以及待合并候选文件的类型信息。在接收到用户的小文件合并请求之后，客户端基于标识信息以及类型信息从HDFS存储系统中获取待合并小文件的元数据，该元数据可以包括但不限于文件标识、存储位置、存储类型、大小、偏移量等。客户端可以将多个待合并小文件的元数据进行合并，并将合并后的元数据发送给HDFS存储系统，以便HDFS存储系统利用合并后的元数据管理该多个待合并小文件。通过这种方式，在客户端将多个小文件的元数据进行合并，并发送给HDFS存储系统，HDFS存储系统的NameNode可以将该合并后的元数据存储下来，而删除多个小文件原来各自的元数据，该多个小文件对应的文件内容所在的数据块则保持原样，而不对其进行合并。NameNode在接收到合并后的元数据之后，执行类似管理一个大文件的方式管理该多个小文件，即使存在过多小文件，则通过本公开实施例的方式将多个小文件的元数据进行合并后，能够减少NameNode在管理该多个小文件的元数据时产生的压力，能够降低对该多个小文件的元数据的读写开销。

在本公开一实施方式中，该文件合并方法可适用于在包括客户端和HDFS存储系统的系统上执行。

在本公开一实施方式中，步骤S302，即客户端基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据的步骤，进一步包括以下步骤：

客户端从所述HDFS存储系统获取满足所述标识信息以及类型信息的待合并候选文件的元数据；

客户端基于所述待合并候选文件的元数据将存储大小小于预设阈值的所述待合并候选文件确定为所述待合并小文件；

客户端获取所述多个待合并小文件的元数据。

该实施方式中，客户端可以从HDFS存储系统获取满足用户提供的标识信息以及类型信息的待合并候选文件的元数据，例如可以获取用户指定的目录下文件类型与该类型信息相符的所有文件的元数据。

由于每个文件的元数据中存储了文件大小，因此通过待合并候选文件的元数据可以确定每个待合并候选文件的大小，如果该待合并候选文件的大小小于预设阈值，则认为该待合并候选文件为待合并小文件，否则认为该待合并候选文件不为待合并小文件。该预设阈值可以基于实际需要进行设置，在此不做限制。

在本公开一实施方式中，在HDFS存储系统中，为了便于文件的管理和备份，引入存储块概念(block)。这里的存储块是HDFS存储系统中的最小存储单位，HDFS默认定义一个存储块的大小为64MB。当有文件上传到HDFS上时，若文件大小大于设置的存储块大小，则该文件会被切分存储为多个存储块，多个存储块可以存放在不同的DataNode上，整个过程中HDFS存储系统会保证一个存储块存储在一个DataNode上。但值得注意的是如果某文件大小没有到达64MB，该文件并不会占据整个存储块空间。HDFS中的NameNode会记录在上述文件分存储块中文件的各个存储块都存放在哪个DataNode上，这些信息一般也称为元数据(MetaInfo)。当一个作业提交到大数据处理分析引擎例如Spark来执行的时候，该过程中传输的数据可能会很多，Spark任务产生的数据经过分区等操作之后会产生多个文件，而该文件的大小可能会小于存储块的大小，这时就会造成一个存储块上存储的一个文件无法占据该磁盘存储块的整个空间，造成空间浪费，并且造成元数据过大，挤占NameNode内存。因此，本公开实施例中，可以将预设阈值基于分布式文件系统的存储块大小设置，例如设置为存储块的大小，将大小小于存储块大小的待合并候选文件文件确定为待合并小文件。

确定了哪些是待合并小文件后，将该些待合并小文件的元数据合并成一个大文件的元数据，并将合并后的元数据提供给HDFS存储系统，进而存储和管理。

在本公开一实施方式中，所述标识信息包括所述待合并候选文件的存储目录；和/或，所述类型信息包括在所述HDFS存储系统中对应的存储块为独立内容的文件类型。

该实施方式中，由于一些小文件可能是非独立存在的，类似于一个压缩文件被分割成多个文件进行存储的情况，这种文件是无法采用本公开实施例这种方式进行合并的。因此，本公开实施例中，可以将能够合并的待合并小文件的文件类型可以为存储块中的内容为独立内容的文件，也即该文件对应的存储块内容不依赖于其他任何文件。

在本公开一实施方式中，步骤S303中，客户端将所述多个待合并小文件的元数据进行合并的步骤，进一步包括以下步骤：

客户端将所述多个待合并小文件的元数据合并成一个合并文件的元数据，且合并后的元数据中的数据存储块信息包括所述多个待合并小文件的元数据中全部的数据存储块信息。

该实施方式中，多个待合并小文件中的元数据可以被合并成一个文件的元数据，多个待合并文件中重复的内容可以删除，而不重复的内容可以予以保留，并按照一个文件的元数据的结构进行组织。多个待合并文件中用于指示文件内容所在的存储块信息，在合并后的元数据中需要保留。在对其中一个待合并小文件中的文件内容进行访问时，可以从合并后的元数据中找到该待合并小文件的文件内容所在的存储块，进而从该存储块获取对应的文件内容进行访问。

在本公开一实施方式中，步骤S301，即客户端接收来自用户的小文件合并请求的步骤，进一步包括以下步骤：

客户端响应于用户的小文件合并操作，输出所述用户具有权限的文件目录信息；

客户端基于所述用户对于所述文件目录信息的选择操作，触发所述小文件合并请求；其中，所述小文件合并请求中将所述用户所操作的文件目录信息作为所述待合并候选文件的标识信息，将所述用户所选择的文件类型作为所述类型信息。

该实施方式中，用户在合适的时间想要请求合并HDFS存储系统中存储的小文件时，可以基于客户端上提供的接口发起小文件合并操作，客户端检测到该小文件合并操作后，可以在客户端界面上输出该用户具有权限的文件目录等信息，该文件目录例如可以是其中一个目录，也可以是一个目录树结构。用户可以选择所输出的文件目录，进而触发客户端产生小文件合并请求。该小文件合并请求中可以包括用户所选择的文件目录，将该文件目录作为待合并候选文件的标识信息；此外，用户可以选择需要合并的文件类型，该小文件合并请求中还包括该文件类型的类型信息。

在本公开一实施方式中，所述合并后的元数据中包括所述合并文件的文件标识与所述多个待合并小文件的文件标识之间的关联关系；和/或，所述合并后的元数据中包括所述多个待合并小文件的文件标识与数据存储块信息的映射关系。

该实施方式中，合并后的元数据中除了存储有多个待合并小文件中各自文件内容对应的存储块信息外，还包括该合并后的元数据对应的合并文件的文件标识，以及该合并文件的文件标识与该多个待合并小文件的文件标识之间的映射关系。

此外，合并后的元数据中所存储的存储块信息，还可以建立其与相应的待合并小文件之间的映射关系，通过该映射关系可以基于合并文件的文件标识、待合并小文件的文件标识确定该待合并小文件的文件内容所在存储块信息。

在本公开一实施方式中，所述方法还包括以下步骤：

HDFS存储系统接收所述客户端的文件元数据请求；所述文件元数据请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；

HDFS存储系统基于所述标识信息对应的文件目录下，符合所述类型信息的待合并候选文件的元数据返回给所述客户端。

该实施方式中，客户端可以从HDFS存储系统获取满足用户提供的标识信息以及类型信息的待合并候选文件的元数据，例如可以获取用户指定的目录下文件类型与该类型信息相符的所有文件的元数据。

待合并候选文件的标识信息可以是包括多个待合并候选文件的目标标识。待合并候选文件可以是待合并下文件，也可以不是。用户通过提供待合并候选文件的标识信息以及类型信息，提出希望将符合该标识信息以及类型信息的小文件进行合并的请求。客户端或者HDFS存储系统可以来判断符合该标识信息以及类型信息的待合并小文件，从而从HDFS存储系统获取该多个待合并小文件的元数据。

HDFS存储系统接收到客户端的文件元数据请求后，基于标识信息从对应的文件目录下获取相应的待合并候选文件的元数据，该待合并候选文件为文件类型与文件元数据请求中的类型信息相吻合的文件，待合并候选文件的元数据可以返回给客户端。

由于每个文件的元数据中存储了文件大小，因此客户端可以通过待合并候选文件的元数据可以确定每个待合并候选文件的大小，如果该待合并候选文件的大小小于预设阈值，则认为该待合并候选文件为待合并小文件，否则认为该待合并候选文件不为待合并小文件。该预设阈值可以基于实际需要进行设置，在此不做限制。

在本公开一实施方式中，所述方法还包括以下步骤：

HDFS存储系统获取客户端对所述合并文件的访问请求；所述访问请求中包括所述合并文件的文件标识；

HDFS存储系统基于所述合并文件的文件标识获取所述合并文件的元数据；

HDFS存储系统基于所述合并文件的元数据中所述数据存储块的信息，从所述数据存储块读取所述合并文件的文件内容，并返回给所述客户端。

该可选的实现方式中，合并后的元数据中除了存储有多个待合并小文件中各自文件内容对应的存储块信息外，还包括该合并后的元数据对应的合并文件的文件标识，以及该合并文件的文件标识与该多个待合并小文件的文件标识之间的映射关系。

此外，合并后的元数据中所存储的存储块信息，还可以建立其与相应的待合并小文件之间的映射关系，通过该映射关系可以基于合并文件的文件标识、待合并小文件的文件标识确定该待合并小文件的文件内容所在存储块信息。

客户端可以针对合并文件进行数据访问，其向HDFS存储系统发送文件访问请求后，HDFS存储系统基于该文件访问请求中该合并文件的文件标识，从文件信息管理结构中获取对应的元数据，并从该元数据中记录的数据存储块信息读取该合并文件的文件内容。需要说明的是，该元数据中记录的是之前未合并之前多个待合并小文件的所有数据存储块的信息，并且基于该数据存储块的信息能够读取到各个待合并小文件对应的文件内容。

在本公开一实施方式中，所述方法还包括以下步骤：

HDFS存储系统获取客户端对所述待合并小文件中目标小文件的访问请求；所述访问请求包括所述目标小文件的文件标识；

HDFS存储系统确定所述文件标识是否关联有合并文件的文件标识；

HDFS存储系统在所述文件标识关联有合并文件的文件标识时，获取所述合并文件的元数据；

HDFS存储系统基于所述合并文件的元数据中所述数据存储块的信息，确定所述目标小文件对应的目标存储块的信息；

HDFS存储系统基于所述目标存储块的信息从所述目标存储块读取所述目标小文件的文件内容，并返回给所述客户端。

该实施方式中，如上文中所述，合并后的元数据中除了存储有多个待合并小文件中各自文件内容对应的存储块信息外，还包括该合并后的元数据对应的合并文件的文件标识，以及该合并文件的文件标识与该多个待合并小文件的文件标识之间的映射关系。

因此在客户端也可以基于原多个待合并小文件之一的文件标识对目标小文件的文件内容进行访问。HDFS存储系统接收到携带与目标小文件的文件标识的文件访问请求后，如果在文件信息管理结构中查询到该文件标识对应管理合并文件的文件标识，则基于该合并文件的文件标识获取该合并文件的元数据，从合并文件的元数据中匹配该目标小文件的文件标识所对应的数据存储块的信息，基于该数据存储块的信息从相应的数据存储块中读出该目标小文件的文件内容，从而将该文件内容返回给客户端。

图3所示及相关实施方式中涉及的技术术语和技术特征与图1-图2所示及相关实施方式中提及的技术术语和技术特征相同或相似，对于图2所示及相关实施方式中涉及的技术术语和技术特征的解释和说明可参考上述对于图1-图2所示及相关实施方式的解释的说明，此处不再赘述。

图4示出根据本公开一实施方式的文件合并方法的整体流程图。如图4所示，用户通过客户端进行小文件合并操作，客户端检测到该小文件合并操作之后，向HDFS存储系统请求相关的目录文件，例如可以是用户具有权限的所有目录，也可以是用户指定的目录结构。客户端接收到HDFS存储系统返回的文件目录之后，将其展示给用户，用户可以从中选择想要进行小文件合并操作的一个或多个子目录，以及待合并文件的类型信息。客户端向HDFS发送元数据请求，HDFS将用户选中的子目录下文件类型与类型信息相吻合的待合并候选小文件的元数据返回给客户端，客户端从该些待合并候选小文件中筛选出能够执行小文件合并的待合并小文件，进而将该些待合并小文件的元数据合并成一个合并文件的元数据。该合并文件的元数据发送给HDFS存储系统，HDFS存储系统将该合并文件的元数据写入文件信息管理结构中，而将待合并小文件的元数据从该文件信息管理结构中删除，完成多个待合并小文件的合并操作。

下述为本公开装置实施例，可以用于执行本公开方法实施例。

图5示出根据本公开一实施方式的文件合并装置的结构框图，该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。如图5所示，所述文件合并装置包括：

第一接收模块501，被配置为接收来自用户的小文件合并请求；所述小文件合并请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；

获取模块502，被配置为基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据；

合并模块503，被配置为将所述多个待合并小文件的元数据进行合并；

发送模块504，被配置为将携带有合并后的元数据的文件合并请求发送给所述HDFS存储系统，以便在所述HDFS存储系统利用所述合并后的元数据对所述多个待合并文件进行管理。

在本公开一实施方式中，该文件合并装置可适用于在客户端上执行。

图6示出根据本公开另一实施方式的文件合并装置的结构框图，该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。如图6所示，所述文件合并装置包括：

第二接收模块601，被配置为接收来自客户端的文件合并请求；所述文件合并请求包括多个待合并小文件的文件信息以及合并后的元数据；所述多个待合并小文件的文件内容存储在数据存储块中；

删除模块602，被配置为将所述多个待合并小文件的元数据从相应的文件信息管理结构中删除；

添加模块603，被配置为将所述合并后的元数据作为一个合并文件的元数据添加至所述文件信息管理结构中，以一个合并文件的形式管理所述多个待合并小文件的文件内容所在的所述数据存储块；所述合并后的元数据中包括所述多个待合并小文件的文件内容所在的所述数据存储块的信息。

在本公开一实施方式中，该文件合并装置可适用于在HDFS存储系统上执行。

图7示出根据本公开一实施方式的文件合并系统的结构框图，该系统可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。如图7所示，所述文件合并系统包括：客户端701和HDFS存储系统702；

所述客户端701接收来自用户的小文件合并请求；所述小文件合并请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；所述客户端701基于所述标识信息以及类型信息从HDFS存储系统702获取多个待合并小文件的元数据；以及将所述多个待合并小文件的元数据进行合并，以及将携带有合并后的元数据的文件合并请求发送给所述HDFS存储系统702；

所述HDFS存储系统702接收来自客户端701的文件合并请求；所述文件合并请求包括多个待合并小文件的文件信息以及合并后的元数据；所述多个待合并小文件的文件内容存储在数据存储块中；所述HDFS存储系统702将所述多个待合并小文件的元数据从相应的文件信息管理结构中删除，以及将所述合并后的元数据作为一个合并文件的元数据添加至所述文件信息管理结构中，以一个合并文件的形式管理所述多个待合并小文件的文件内容所在的所述数据存储块；所述合并后的元数据中包括所述多个待合并小文件的文件内容所在的所述数据存储块的信息。

在本公开一实施方式中，该文件合并系统可适用于用户通过客户端对HDFS存储系统上的小文件进行合并的过程。

上述装置实施例所涉及的技术特征及其对应的解释和说明与上文所描述的方法实施例所涉及的技术特征及其对应的解释和说明相同、相应或相似，对于上述装置实施例所涉及的技术特征及其对应的解释和说明可参考上述方法实施例所涉及的技术特征及其对应的解释和说明，本公开在此不再赘述。

本公开实施例还公开了一种电子设备，所述电子设备包括存储器和处理器；其中，

所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行以实现上述任一方法步骤。

图8是适于用来实现根据本公开一实施方式的文件合并方法的计算机系统的结构示意图。

如图8所示，计算机系统800包括处理单元801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分808加载到随机访问存储器(RAM)803中的程序而执行上述实施方式中的各种处理。在RAM803中，还存储有计算机系统800操作所需的各种程序和数据。处理单元801、ROM802以及RAM803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。

以下部件连接至I/O接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。其中，所述处理单元801可实现为CPU、GPU、TPU、FPGA、NPU等处理单元。

特别地，根据本公开的实施方式，上文描述的方法可以被实现为计算机软件程序。例如，本公开的实施方式包括一种计算机程序产品，其包括有形地包含在及其可读介质上的计算机程序，所述计算机程序包含用于执行所述数据传输方法的程序代码。在这样的实施方式中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。

本公开实施例还公开了一种计算机程序产品，所述计算机程序产品包括计算机程序/指令，该计算机程序/指令被处理器执行时实现上述任一方法步骤。

附图中的流程图和框图，图示了按照本公开各种实施方式的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，路程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施方式中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定。

作为另一方面，本公开实施例还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施方式中所述装置中所包含的计算机可读存储介质；也可以是单独存在，未装配入设备中的计算机可读存储介质。计算机可读存储介质存储有一个或者一个以上程序，所述程序被一个或者一个以上的处理器用来执行描述于本公开实施例的方法。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开实施例中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离所述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开实施例中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (10)

1.一种文件合并方法，包括：

接收来自用户的小文件合并请求；所述小文件合并请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；

基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据；

将所述多个待合并小文件的元数据进行合并；

将携带有合并后的元数据的文件合并请求发送给所述HDFS存储系统，以便在所述HDFS存储系统利用所述合并后的元数据对所述多个待合并文件进行管理。

2.根据权利要求1所述的方法，其中，基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据，包括：

从所述HDFS存储系统获取满足所述标识信息以及类型信息的待合并候选文件的元数据；

基于所述待合并候选文件的元数据将存储大小小于预设阈值的所述待合并候选文件确定为所述待合并小文件；

获取所述多个待合并小文件的元数据。

3.一种文件合并方法，其中，包括：

接收来自客户端的文件合并请求；所述文件合并请求包括多个待合并小文件的文件信息以及合并后的元数据；所述多个待合并小文件的文件内容存储在数据存储块中；

将所述多个待合并小文件的元数据从相应的文件信息管理结构中删除；

将所述合并后的元数据作为一个合并文件的元数据添加至所述文件信息管理结构中，以一个合并文件的形式管理所述多个待合并小文件的文件内容所在的所述数据存储块；所述合并后的元数据中包括所述多个待合并小文件的文件内容所在的所述数据存储块的信息。

4.一种文件合并方法，其中，包括：

客户端接收来自用户的小文件合并请求；所述小文件合并请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；

客户端基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据；

客户端将所述多个待合并小文件的元数据进行合并，以及将携带有合并后的元数据的文件合并请求发送给所述HDFS存储系统；

HDFS存储系统接收来自客户端的文件合并请求；所述文件合并请求包括多个待合并小文件的文件信息以及合并后的元数据；所述多个待合并小文件的文件内容存储在数据存储块中；

HDFS存储系统将所述多个待合并小文件的元数据从相应的文件信息管理结构中删除，以及将所述合并后的元数据作为一个合并文件的元数据添加至所述文件信息管理结构中，以一个合并文件的形式管理所述多个待合并小文件的文件内容所在的所述数据存储块；所述合并后的元数据中包括所述多个待合并小文件的文件内容所在的所述数据存储块的信息。

5.一种文件合并装置，包括：

第一接收模块，被配置为接收来自用户的小文件合并请求；所述小文件合并请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；

获取模块，被配置为基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据；

合并模块，被配置为将所述多个待合并小文件的元数据进行合并；

发送模块，被配置为将携带有合并后的元数据的文件合并请求发送给所述HDFS存储系统，以便在所述HDFS存储系统利用所述合并后的元数据对所述多个待合并文件进行管理。

6.一种文件合并装置，包括：

第二接收模块，被配置为接收来自客户端的文件合并请求；所述文件合并请求包括多个待合并小文件的文件信息以及合并后的元数据；所述多个待合并小文件的文件内容存储在数据存储块中；

删除模块，被配置为将所述多个待合并小文件的元数据从相应的文件信息管理结构中删除；

添加模块，被配置为将所述合并后的元数据作为一个合并文件的元数据添加至所述文件信息管理结构中，以一个合并文件的形式管理所述多个待合并小文件的文件内容所在的所述数据存储块；所述合并后的元数据中包括所述多个待合并小文件的文件内容所在的所述数据存储块的信息。

7.一种文件合并系统，包括：客户端和HDFS存储系统；其中，

所述客户端接收来自用户的小文件合并请求；所述小文件合并请求包括待合并候选文件的标识信息以及所述待合并候选文件的类型信息；所述客户端基于所述标识信息以及类型信息从HDFS存储系统获取多个待合并小文件的元数据；以及将所述多个待合并小文件的元数据进行合并，以及将携带有合并后的元数据的文件合并请求发送给所述HDFS存储系统；

所述HDFS存储系统接收来自客户端的文件合并请求；所述文件合并请求包括多个待合并小文件的文件信息以及合并后的元数据；所述多个待合并小文件的文件内容存储在数据存储块中；所述HDFS存储系统将所述多个待合并小文件的元数据从相应的文件信息管理结构中删除，以及将所述合并后的元数据作为一个合并文件的元数据添加至所述文件信息管理结构中，以一个合并文件的形式管理所述多个待合并小文件的文件内容所在的所述数据存储块；所述合并后的元数据中包括所述多个待合并小文件的文件内容所在的所述数据存储块的信息。

8.一种电子设备，包括存储器和处理器；其中，

所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行以实现权利要求1-4任一项所述方法的步骤。

9.一种计算机可读存储介质，其上存储有计算机指令，其中，该计算机指令被处理器执行时实现权利要求1-4任一项所述方法的步骤。

10.一种计算机程序产品，包括计算机程序/指令，该计算机程序/指令被处理器执行时实现权利要求1-4任一项所述方法的步骤。

Images