CN116795790A - 小文件合并的方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请实施例提供了一种小文件合并的方法、装置、设备以及存储介质，涉及云技术的文件存储领域。该小文件合并的方法包括：将至少两个小文件进行分组；确定每个分组的小文件等级；其中，该小文件等级表示对小文件进行合并的优先级；确定每个分组的小文件索引，其中，该小文件索引的关键字包括所述小文件等级；根据每个分组中小文件的统计信息，确定满足合并条件；根据每个分组中的小文件索引，对每个分组中的相同等级的小文件进行合并。本申请实施例根据小文件等级进行合并能够避免重复合并，从而有助于减少合并所需内存资源，并且通过根据小文件等级创建小文件索引，能够有助于更快找到待合并的小文件，有助于加快合并速度。

Description

小文件合并的方法、装置、电子设备及存储介质

技术领域

本申请涉及云技术的文件存储领域，并且更具体地，涉及小文件合并的方法、装置、设备以及存储介质。

背景技术

数据湖(Data Lake)是一个以原始格式存储数据的存储库或系统，可以按原样存储数据而无需事先对数据进行结构化处理。一个数据湖可以存储结构化数据、半结构化数据、非结构化数据以及二进制数据。数据湖的中的数据可以存储在基于可向外扩展的Hadoop分布式文件系统(Hadoop Distributed File System，HDFS)上。HDFS可以将一个完整的大文件平均分块存储到不同设备上，从而在读取文件时可以同时从多个主机取不同区块的文件。并且，HDFS支持流式数据访问，即一次写入多次读取，不支持随机写和追加写。

通常，HDFS可存储的文件数受限于名字节点(Namenode)的内存大小。一个块(block)在NameNode中对应一条记录。数据湖的提交(commit)会产生对应的数据文件和元数据文件，元数据中包括数据文件的统计信息和目录等。在分区(Partition)个数较多或者commit间隔较短或并发较大时容易产生小文件。大量小文件会造成NameNode压力变大和慢查询。

因此，如何高效的进行小文件合并是亟待解决的问题。

发明内容

本申请实施例提供了一种小文件合并的方法、装置、设备以及存储介质，能够有助于减少合并所需内存资源，并加快合并速度。

第一方面，提供了一种小文件合并的方法，包括：

将至少两个小文件进行分组；

确定每个分组的小文件等级；其中，所述小文件等级表示对小文件进行合并的优先级；

确定所述每个分组的小文件索引，其中，所述小文件索引的关键字包括所述小文件等级；

根据所述每个分组中小文件的统计信息，确定满足合并条件；

根据所述每个分组中的小文件索引，对所述每个分组中的相同等级的小文件进行合并。

第二方面，提供了一种小文件合并的装置，包括：

分组单元，用于将至少两个小文件进行分组；

确定单元，用于确定每个分组的小文件等级；其中，所述小文件等级表示对小文件进行合并的优先级；

所述确定单元还用于确定所述每个分组的小文件索引，其中，所述小文件索引的关键字包括所述小文件等级；

所述确定单元还用于根据所述每个分组中小文件的统计信息，确定满足合并条件；

合并单元，用于根据所述每个分组中的小文件索引，对所述每个分组中的相同等级的小文件进行合并。

第三方面，本申请提供了一种电子设备，包括：

处理器，适于实现计算机指令；以及，

存储器，存储有计算机指令，计算机指令适于由处理器加载并执行上述第一方面的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机指令，该计算机指令被计算机设备的处理器读取并执行时，使得计算机设备执行上述第一方面的方法。

第五方面，本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述第一方面的方法。

通过上述技术方案，能够实现对至少两个小文件进行分组，并确定分组中的小文件的等级，进而能够在该至少两个小文件满足合并条件时对同一分组中相同等级的小文件进行合并。由于本申请实施例根据小文件等级对小文件进行了分级，根据小文件等级进行合并能够避免重复合并，从而有助于减少合并所需内存资源。另外，通过根据小文件等级创建小文件索引，能够有助于更快找到待合并的小文件，有助于加快合并速度。

附图说明

图1为元数据文件结构的一个示意图；

图2为本申请实施例涉及的一种网络架构的示意图；

图3为本申请实施例提供的一种小文件合并的方法的示意性流程图；

图4为本申请实施例提供的另一种小文件合并的方法的示意性流程图；

图5为本申请实施例提供的一种小文件合并的装置的示意性框图；

图6为本申请实施例提供的电子设备的示意性框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

应理解，在本申请实施例中，“与A对应的B”表示B与A相关联。在一种实现方式中，可以根据A确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。

在本申请的描述中，除非另有说明，“至少一个”是指一个或多个，“多个”是指两个或多于两个。另外，“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：a,b,c,a-b,a-c,b-c,或a-b-c，其中a,b,c可以是单个，也可以是多个。

还应理解，本申请实施例中出现的第一、第二等描述，仅作示意与区分描述对象之用，没有次序之分，也不表示本申请实施例中对设备个数的特别限定，不能构成对本申请实施例的任何限制。

还应理解，说明书中与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。

此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本申请提供的方案可涉及云技术。

云技术(Cloud technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。

云技术基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

云计算(cloud computing)是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。

作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为IaaS(Infrastructure as a Service，基础设施即服务)平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。

按照逻辑功能划分,在IaaS(Infrastructure as a Service，基础设施即服务)层上可以部署PaaS(Platform as a Service,平台即服务)层，PaaS层之上再部署SaaS(Software as a Service,软件即服务)层，也可以直接将SaaS部署在IaaS上。PaaS为软件运行的平台，如数据库、web容器等。SaaS为各式各样的业务软件，如web门户网站、短信群发器等。一般来说，SaaS和PaaS相对于IaaS是上层。

云存储(cloud storage)是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

目前，存储系统的存储方法为：创建逻辑卷，在创建逻辑卷时，就为每个逻辑卷分配物理存储空间，该物理存储空间可能是某个存储设备或者某几个存储设备的磁盘组成。客户端在某一逻辑卷上存储数据，也就是将数据存储在文件系统上，文件系统将数据分成许多部分，每一部分是一个对象，对象不仅包含数据而且还包含数据标识(ID，ID entity)等额外的信息，文件系统将每个对象分别写入该逻辑卷的物理存储空间，且文件系统会记录每个对象的存储位置信息，从而当客户端请求访问数据时，文件系统能够根据每个对象的存储位置信息让客户端对数据进行访问。

存储系统为逻辑卷分配物理存储空间的过程，具体为：按照对存储于逻辑卷的对象的容量估量(该估量往往相对于实际要存储的对象的容量有很大余量)和独立冗余磁盘阵列(RAID，Redundant Array of Independent Disk)的组别，预先将物理存储空间划分成分条，一个逻辑卷可以理解为一个分条，从而为逻辑卷分配了物理存储空间。

本申请具体涉及云存储中的小文件合并技术。

首先，对本申请实施例涉及的相关术语进行描述。

Hadoop分布式文件系统(Hadoop Distributed File System，HDFS)：是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，适合那些有着超大数据集(largedata set)的应用程序。HDFS适合大数据文件(大文件)存储，例如T级别的大文件或者一堆大数据文件的存储。HDFS可以将一个完整的大文件平均分块存储到不同设备上，从而在读取文件时可以同时从多个主机取不同区块的文件，读取效率较高。

HDFS的文件在物理上是分块存储，即以块为基本存储单位，块的大小按照版本不同可以为64MB或128MB，因此生成的文件的大小在64MB的倍数时最有利于存储。

小文件：小于块大小的文件可以称为小文件，例如可以为小于64MB的文件，或小于128MB的文件。小文件合并的目标为将数据文件合并为预期的大小，例如当前数据湖文件一般设定为512MB，且不浪费资源重复合并。

元数据文件结构：参见图1，元数据文件结构可以包括至少一个清单列表(manifest list)，每个manifest list下包括至少一个清单文件(manifest file)，manifest file中存储每次commit产生的数据文件的元数据信息，例如统计信息等。以数据湖为iceberg为例，元数据存储在avro格式的行存文件manifest file中，每一行代表一个文件，每次执行小文件合并前可以扫描manifest file获取小文件。

图2为本申请实施例涉及的一种网络架构的示意图。

如图2所示，包括内核201、消息队列(MessageQueue，MQ)、合并规则单元203、任务调度单元204和存储单元205。其中，内核201可以处理用户的写入对应的commit操作，生成接收事件(event)。接收event根据合并规则将合并任务(task)写在MQ202中，例如可以以表的形式。合并规则单元203用于生成小文件合并的规则，例如可以根据任务的历史执行情况生成合并规则。任务调度204可以用于根据合并规则，从MQ中拉取需要执行合并的表，并根据一定的配置执行合并，例如可以为spark任务。作为示例，任务调度可以根据任务执行频率(例如5min/次、10min/次或60min/次)进行资源分配和任务组装。存储205可以存储文件或文件的相关信息，任务调度204可以从存储205中读取需要合并的小文件，或者将合并得到的大文件写入存储205，MQ也可以对存储205中的文件或数据进行读取/写入。

示例性地，图2所述的网络结构整体可以为服务器。服务器可以是一台或多台。服务器是多台时，存在至少两台服务器用于提供不同的服务，和/或，存在至少两台服务器用于提供相同的服务，比如以负载均衡方式提供同一种服务，本申请实施例对此不加以限定。

其中，上述服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。服务器也可以成为区块链的节点。

图3示出了本申请实施例提供的一种小文件合并的方法300的示意性流程图。方法300可以由任何具有数据处理能力的电子设备执行，该电子设备例如可以实施为服务器，比如图2所示的网络架构。如图3所示，方法300包括步骤310至350。

示例性的，方法300可以应用于HDFS中，即待合并的小文件为HDFS中的小文件。

310，将至少两个小文件进行分组。

示例性的，可以按照预定特征对该至少两个小文件进行分组，得到一组或多组小文件。这里，小文件可以为文件大小小于预设值的文件，例如小于64MB，128MB，或其他值的文件，不做限定。

在一些可选的实施例中，可以按照小文件存储的分区，对该至少两个小文件进行分组。此时，一组小文件的所存储的分区是相同的。

具体而言，分区可以是逻辑概念。当多个小文件存储在存储设备(例如磁盘)中的不同分区(partition)中时，可以将相同分区的小文件分为同一组。示例性的，在磁盘中分区可以表现为目录结构，某一个目录下的所有文件即为一个分区。

在一些可选的实施例中，该至少两个小文件可以包括第一时间段内写入的小文件，例如5min、10min或60min内写入的小文件。也就是说，该至少两个小文件可以是产生时间接近(例如均在该第一时间段内)的文件。

在一些可选的实施例中，在方法300中，还可以在元数据文件结构中记录小文件等级，其中，该小文件等级可以表示对小文件进行合并的优先级。

示例性的，在用户进行数据写入并commit时，元数据文件结构中的manifest file中的datafile(小文件的一个示例)可以按照分区(partition)进行分组(group by)。例如manifest file1中的datafile1、datafile2存储在P2分区，datafile3、datafile4存储在P1分区，datafile5存储在P3分区，此时可以将datafile1、datafile2分为一组，datafile3、datafile4分为一组，datafile5分为一组。

可选的，不同manifest file中的datafile如果在相同的分区，那么这些datafile也可以分为一组。例如，manifest file2中的datafile6也存储在P2分区时，可以将datafile1、datafile2和datafile6分为一组。

作为一种可能的实现方式，可以对一个manifest file中的datafile记录相同的等级(level)，换言之manifest file对应的等级即为manifest file中的所有datafile的等级。例如manifest file1对应的等级记为1，manifest file2对应的等级记为3，manifestfile3对应的等级记为1，manifest file4对应的等级记为1等等。

示例性的，datafile的等级可以表示对该datafile进行合并的优先级，例如，等级为1的datafile的优先级高于等级为2的datafile的优先级，等级为2的datafile的优先级高于等级为3的datafile的优先级，以此类推。在合并小文件时，可以优先合并同一等级下的文件。

在一些实施例中，第一时间段内写入同一分区的小文件的等级可以相同，这样通过对相同等级的小文件进行合并，可以有助于将产生时间接近(例如均在该第一时间段内)的文件进行合并。

在一些可选的实施例中，在方法300中，还可以在元数据文件结构中记录分区的偏移量，该分区的偏移量可以表示该分区在存储设备中的位置，例如元数据文件中，起始位置为分区1，偏移量为0，当分区1中有10个文件时，那么分区2的偏移量为10，表示该元数据文件的开始位置与起始位置的偏移量。这里，通过分区的偏移量，可以有助于快速找到分区中的待合并的小文件，从而提高小文件合并的效率。

示例性的，在元数据文件中可以记录manifest file1对应的分区偏移为(P2，0)、(P1，2)和(P3，4)，表示manifest file1中的datefile分别存储在分区P2、P1和P3中，其中P1的起始位置相对起始位置的偏移量为0，P2的起始位置相对起始位置的偏移量为2，P3的起始位置相对起始位置的偏移量为4。也就是说，以起始位置为参考起点时，P2占第0、1行的位置(例如可以分别存储manifest file1中的datafile1和datafile2)，P1占第2、3行的位置(例如可以分别存储manifest file1中的datafile3和datafile3)，P3占第4行的位置(例如可以存储manifest file1中的datafile5)。

320，确定每个分组中的小文件等级，其中，该小文件等级表示对小文件进行合并的优先级。其中，同一分组(例如分区)中的一组小文件的等级相同或不同，不做限定。

在一些可选的实施例中，可以根据元数据文件结构中记录的分组中小文件等级，获取每个分组中的小文件的等级。

继续上文中的例子，当P2分区中的datafile1、datafile2和datafile6分为一组时，同一分区中的一组小文件的等级是不同的，其中datafile1、datafile2的等级对应manifest file1的等级1，datafile6的等级对应manifest file2的等级3。当P1分区中的datafile3、datafile4分为一组时，同一分区中的一组小文件的等级是相同的，均对应manifest file1的等级1。

330，确定每个分组的小文件索引，其中，小文件索引的关键字(key)包括该小文件等级。

示例性的，可以在manifest list中的文件(例如manifest file或datafile)添加哈希(hash)索引，索引的key可以为level，以使可以根据hash索引找到对应的需要合并的小文件。

340，根据每个分组中小文件的统计信息，确定满足合并条件。

示例性的，当用户进行数据写入并commit时，常驻服务可以接收event，获取commit操作产生的元数据中的数据文件的信息，以及获取至少两个小文件的文件信息的统计信息。

在一些可选的实施例中，上述统计信息可以包括上述至少两个小文件的大小信息、数量信息和MSE中的至少一种。例如，可以获取各分区的统计信息，例如分区中的小文件的平均文件大小(avg-file-size)、文件数量(num-files)，以及均方差(mean squareerror，MSE)。

示例性的，MSE可以根据以下公式获得：

其中，N表示文件的数量，N为正整数，Target为可以max(compaction.target.size，actual)，compaction.target.size表示设置的目标合并大小，actual表示生成文件的实际大小。

在一些可选的实施例中，可以累积小文件的统计信息。例如，数据湖微服务计算平台DLA侧初次接收到event时，N个小文件的MSE可以为公式(1)所示，并且不满足合并条件，并未对该N个小文件进行合并。DAL侧收到第二次event时，其中包含M个小文件，此时MSE可以更新为MSE'，如下公式(2)所示：

MSE'＝(MSE*N+MSE2*M)/(N+M) (2)

其中，MSE如公式(1)所示，M为正整数。

示例性的，可以将统计信息与阈值比较，确定小文件是否满足合并条件。例如可以分别设置小文件的大小阈值、数量阈值和MSE阈值。枚举event的各种类型的阈值，可以基于如下规则：

1)阈值与分区的个数无关；

2)MSE与文件的顺序无关；

3)多次累计event和一次event产生的若干个文件的MSE值是相同的。示例性的，MSE阈值可以根据以下公式(3)确定：

T²＝(Target_i-α×Target_i)² (3)

其中，T²表示偏离目标大小的程度，代表文件的大小的实际分布是否满足合并要求；α为平均偏离目标文件大小的阈值系数。例如，假设α为0.25，target为512MB，那么计算得到的T为0.25*512＝128MB，即所有文件均为128MB以下时合并，或者个别大于128MB，几个小文件为1MB时合并。

350，根据每个分组中的小文件索引，对所述每个分组中的相同等级的小文件进行合并。

示例性的，当至少两个小文件的文件信息的统计信息，例如该至少两个小文件的大小信息、数量信息和MSE中的至少一种满足阈值时，可以确定满足合并条件，此时可以根据每个分组中的小文件索引，对所述每个分组中的相同等级的小文件进行合并。例如，可以根据分组中的小文件索引，对该分组中相同等级的小文件进行合并。

作为一种可能的实现方式，当接收event判断需要执行合并时，可以将合并任务写在MQ中，在spark中启动常驻服务，定时从MQ中拉取需要执行合并的表(其中包括需要合并的小文件)，根据预先配置异步执行合并。

因此，本申请实施例通过将至少两个小文件进行分组，并确定分组中的小文件的等级，进而能够在该至少两个小文件满足合并条件时对同一分组中相同等级的小文件进行合并。由于本申请实施例根据小文件等级对小文件进行了分级，根据小文件等级进行合并能够避免重复合并，从而有助于减少合并所需内存资源。另外，通过根据小文件等级创建小文件索引，能够有助于更快找到待合并的小文件，有助于加快合并速度。

另外，当本申请实施例根据小文件存储的分区对小文件进行分组时，能够有助于减少由于各分区的文件大小不均衡导致的某些分区的不必要的合并的可能性，从而仅对适当的分区中的小文件进行合并。

在一些可选的实施例中，在方法300中，还可以根据分区的偏移量，获取同一分区中相同等级的小文件。

在一些可选的实施例中，在所述每个分组中相同等级的小文件的总大小大于预设值时，将所述同一分区中相同等级的小文件合并为至少一个所述预设值大小的文件。

示例性的，该预设值表示合并的大小，例如可以表示为compaction.target.size，满足此大小即可合并。作为一个具体的例子，compaction.target.size＝128MB，此时当分组中相同等级的小文件的总大小大于128MB，例如为210MB时，可以将该分组中的该等级的小文件合并为2个128MB大小的文件。这样，在小文件的总大小达到目标合并大小时可以合并一次，从而可以避免重复合并。

可以理解的是，不同取值的compaction.target.size触发的合并速度和次数是不同的，例如，当compaction.target.size设置较大时，触发的合并速度较慢，合并次数较少；当compaction.target.size设置较小时，触发的合并速度较快，合并次数较多。可选的，该compaction.target.size可以由用户设置，例如用户根据各自数据量的大小和/或查询的模式确定，从而满足其不同的查询需求。

可选的，在一些实施例中，还可以设置总的写入大小，例如write.target.size，从而使得最终合并后的文件大小小于该总的写入大小。例如可以设置write.target.size＝512MB，这样最终合并的文件大小总是小于512MB。在一些实施例中，可以对4个合并后的128MB的文件进行再一次合并，得到512MB大小的文件。

在一些可选的实施例中，在上述步骤310中，至少两个小文件还可以包括对同一分区中相同等级的小文件进行合并后的文件。也就是说，合并后的文件如果还是小文件的话，可以对合并后的文件继续进行小文件合并，例如按照上述步骤310至350的步骤进行小文件合并。

可选的，在方法300中，还可以根据合并前的小文件的等级，确定合并后的文件的等级，其中，合并后文件的等级高于合并前的小文件的等级。示例性的，合并后的文件的等级可以是合并前的小文件的等级加1，例如，当对至少两个level为1的小文件进行合并时，得到的合并后的文件的level为2。示例性的，等级高的小文件在合并时优先级低。

示例性的，当至少两个小文件包括合并后的文件，例如level2等级的文件时，可以进一步对至少两个level2等级的文件进行合并，例如对4个合并后的level2等级的128MB的文件进行再一次合并，得到512MB大小的文件。可选的，可以将该512MB大小的文件的level定义为max，表示后续不再对该512MB大小的文件进行合并。

在一些实施例中，还可以根据预设大小的块，将合并后的大文件分割为数据块进行存储，例如可以存储到至少一个存储设备上。例如，在块的大小为128MB时，可以将最终合并的512MB的大文件分割为4个128MB的数据块进行存储。

图4示出了本申请实施例提供的另一种小文件合并的方法400的示意性流程图。应理解，图4示出了小文件合并的方法的步骤或操作，但这些步骤或操作仅是示例，本申请实施例还可以执行其他操作或者图4中的各个操作的变形。此外，图4中的各个步骤可以按照与图4呈现的不同的顺序来执行，并且有可能并非要执行图4中的全部操作。

401，数据写入表，产生file1,2,3,4,5，level为1。

示例性的，file可以为上文中的datafile，本申请对此不做限定。

402，按照分区对文件进行分组。

例如，分区1中的file为一组，分区2中的file为一组，以此类推。

403，记录分区偏移量和level。同时，还可以确定分区的小文件索引，其关键字包括小文件level。

示例性的，可以记录manifest file的level，那么该manifest file中的所有datafile对应的level即为该manifest file的level。具体的，分区偏移量和level可以参见上文中的描述，这里不再赘述。

作为一个具体的例子，表1示出了元数据文件manifest list记录的一个示例：

表1

其中，P1、P2、P3分别表示分区1、分区2和分区3，P2的偏移量为0，P1的偏移量为2，P3的偏移量为4。

表2示出了元数据文件manifest记录的一个示例：

表2

文件名称	分区
		File1	P2
File2	P2
		File3	P1
File4	P1
		File5	P3

404，提交(commit)并发送event。

405，服务接收event。

406，设置目标压缩大小(记为compaction.target.size，例如可以为128MB)。

407，接收服务event。

408，服务接收event。这里，该接收event与步骤405中的服务接收event类似，其对应的写入表产生的file可以为与file1～5不同的文件。

409，写入类型的event。即，由写入数据产生的event。

410，读取累加值，累加本次event。

示例性的，可以从数据库(例如mysql)中读取event的累加值，并将本次event的值累加到累加值上。例如，当初次接收event对应的小文件不满足合并条件时，可以将该event对应的值记录到数据库，当第二次接收event时，可以将第二次接收event对应的小文件的值累加到初次接收event对应的值上。

示例性的，event对应的值例如为分区中小文件的统计信息，比如分区中小文件的大小信息(file size)、数量信息和方差信息(MSE)中的至少一种。作为示例，MSE的计算方式可以参见上文公式(1)和(2)，这里不再赘述。

作为一个具体的例子，该event中各分区的统计信息如下表3所示：

表3

步骤410中得到的该累计结果可以用于触发合并服务，即判断是否需要启动合并的规则(rule)。可选的，该累计结果可以存入数据库中。在一些实施例中，可以根据如下步骤411至413判断是否触发合并服务。

411，是否满足总文件大小大于目标压缩大小，例如可以判断file1～5的文件大小的总和是否大于compaction.target.size。继续上面表3中的例子，本次event的总文件大小为num-fles*avg-file-size。

412，是否满足MSE大于阈值0.25T²。

示例性的，T²可以参见上文中公式(3)的描述，不再赘述。表4示出了枚举产生合并MSE阈值的一个示例：

表4

由表4可知，规定MSE阈值为0.25时，可配置文件平均大小约为128MB时触发合并服务。

413，是否满足文件个数大于设定值。

414，触发分区级level合并。

当步骤411-413均满足时判断为需要触发小文件合并服务，即触发分区级level合并。此时，可以将合并task及该task的配置信息写入MQ，并将小文件的统计信息(例如MSE、文件大小、文件数量等)置为0。

415，引擎侧找到待合并文件。

示例性的，spark引擎侧可以起long running任务拉取MQ，对满足条件的表执行合并服务。引擎侧可以根据元数据文件中分区的偏移量，以及该分区中文件的level，迅速找到该分区中待合并的文件。在合并文件时，可以对同一分区中相同level(例如分区1中level1)的小文件进行合并。

需要说明的是，本申请实施例可以对多个表启动一个合并任务，从而减小任务数量，减少驱动程序(driver)造成压力。在一些实施例中，还可以对每个表单独启用合并任务，本申请对此不做限定。

416，file1，file2，file3总大小大于目标压缩大小compaction.target.size。

示例性的，内核侧可以将同一分区中同一level的数据文件合并。可选的，将判断可以合并为compaction.target.size倍数大小的文件合并，并且可以设置目标写入大小(write.target.size)，以对合并后的文件的最大尺寸进行限定。

417，合并为file9，即将file1，file2，file3进行合并，得到合并后的文件file9。

418，file4，file5总大小大于目标压缩大小compaction.target.size。

419，合并为file10，即将file4，file5进行合并，得到合并后的文件file10。

可选的，在其他小文件满足合并条件时，还可以对写入的其他小文件进行合并，得到合并后的文件，例如file7、file8等。

可选的，如果剩余某些文件不满足合并条件，则可以不合并这些文件。

420，元数据记录file7,8,9,10，level为2。

这里，对于合并后的文件，其level可以比合并前的小文件的增加1，例如由合并前的level1,变为合并后的level2。

421，记录到数据库。

示例性的，当411-413任一步骤不满足时，可以将累加的event的值记录到数据库。

422，合并分区1中level1得到4个文件。

423，服务接收event。其中，该event对应的数据为步骤422中的待合并文件的信息。

424，合并类型的event。即，由合并后的文件产生的event。

425，触发分区级level2的合并。

426，根据元数据中level找到待合并文件。

示例性的，引擎侧可以根据元数据文件中分区的偏移量，以及该分区中文件的level，迅速找到该分区中待合并的文件。在合并文件时，可以对同一分区中相同level(例如分区1中level2)的小文件进行合并。

427，file7,8,9,10总大小大于目标写入大小write.target.size。

428，合并为file11，level为max。

这里，level为max，表示不再继续合并文件。

示例性的，表5示出了对分区1中的file1～8进行合并的一个示例，其中最终合并目标大小为512MB，即write.target.size＝512MB，compaction.target.size＝128MB。

表5

示例性的，表6示出了对分区1中的file1～8进行合并的另一个示例，其中write.target.size＝512MB，compaction.target.size＝128MB，每次commit产生的文件都较小，或者文件个数少。

表6

表7示出了表6中进行一次合并后产生的两个manifest file的一个示例。

表7

因此，本申请实施例通过将至少两个小文件进行分组，并确定分组中的小文件的等级，进而能够在该至少两个小文件满足合并条件时对同一分组中相同等级的小文件进行合并。由于本申请实施例根据小文件等级对小文件进行了分级，根据小文件等级进行合并能够避免重复合并，从而有助于减少合并所需内存资源。另外，通过根据小文件等级创建小文件索引，能够有助于更快找到待合并的小文件，有助于加快合并速度。

另外，当根据小文件存储的分区对小文件进行分组时，能够有助于减少由于各分区的文件大小不均衡导致的某些分区的不必要的合并的可能性，从而仅对适当的分区中的小文件进行合并。

以上结合附图详细描述了本申请的具体实施方式，但是，本申请并不限于上述实施方式中的具体细节，在本申请的技术构思范围内，可以对本申请的技术方案进行多种简单变型，这些简单变型均属于本申请的保护范围。例如，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合，为了避免不必要的重复，本申请对各种可能的组合方式不再另行说明。又例如，本申请的各种不同的实施方式之间也可以进行任意组合，只要其不违背本申请的思想，其同样应当视为本申请所公开的内容。

还应理解，在本申请的各种方法实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。应理解这些序号在适当情况下可以互换，以便描述的本申请的实施例能够以除了在图示或描述的那些以外的顺序实施。

上文详细描述了本申请的方法实施例，下文结合图5至图6，描述本申请的装置实施例。

图5是本申请实施例的小文件合并的装置700的示意性框图。如图5所示，所述小文件合并的装置700可包括分组单元710、确定单元720和合并单元730。

分组单元710，用于将至少两个小文件进行分组；

确定单元720，用于确定每个分组的小文件等级；其中，所述小文件等级表示对小文件进行合并的优先级；

所述确定单元720还用于确定所述每个分组的小文件索引，其中，所述小文件索引的关键字包括所述小文件等级；

所述确定单元720还用于根据所述每个分组中小文件的统计信息，确定满足合并条件；

合并单元730，用于根据所述每个分组中的小文件索引，对所述每个分组中的相同等级的小文件进行合并。

在一些可选的实施例中，所述分组单元710具体用于：

按照所述小文件存储的分区，对所述至少两个小文件进行分组。

在一些可选的实施例中，所述至少两个小文件包括第一时间段内写入的小文件，所述第一时间段内写入同一分区的小文件的等级相同。

在一些可选的实施例中，还包括获取单元，用于：

根据分区的偏移量和所述小文件索引，获取所述每个分组中相同等级的小文件。

在一些可选的实施例中，还包括记录单元，用于：在元数据文件结构中记录所述分区的偏移量。

在一些可选的实施例中，所述记录单元还用于：在元数据文件结构中记录所述小文件的等级。

在一些可选的实施例中，所述至少两个小文件包括对小文件进行合并后的文件。

在一些可选的实施例中，所述合并单元730还用于：

在所述每个分组中相同等级的小文件的总大小大于预设值时，将所述每个分组中相同等级的小文件合并为至少一个所述预设值大小的文件。

在一些可选的实施例中，所述确定单元720还用于：

根据合并前的小文件的等级，确定合并后的文件的等级，其中，所述合并后的文件的等级高于所述合并前的小文件的等级。

在一些可选的实施例中，所述统计信息包括大小信息、数量信息和均方差信息中的至少一种。

在一些可选的实施例中，所述至少两个小文件包括Hadoop分布式文件系统HDFS中的小文件。

应理解，装置实施例与方法实施例可以相互对应，类似的描述可以参照方法实施例。为避免重复，此处不再赘述。具体地，在该实施例中小文件合并的装置700可以对应于执行本申请实施例的方法300或400的相应主体，并且装置700中的各个模块的前述和其它操作和/或功能分别为了实现上文中的各个方法，或各个方法中的相应流程，为了简洁，在此不再赘述。

上文中结合附图从功能模块的角度描述了本申请实施例的装置和系统。应理解，该功能模块可以通过硬件形式实现，也可以通过软件形式的指令实现，还可以通过硬件和软件模块组合实现。具体地，本申请实施例中的方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路和/或软件形式的指令完成，结合本申请实施例公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。可选地，软件模块可以位于随机存储器，闪存、只读存储器、可编程只读存储器、电可擦写可编程存储器、寄存器等本领域的成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法实施例中的步骤。

如图6是本申请实施例提供的电子设备800的示意性框图。

如图6所示，该电子设备800可包括：

存储器810和处理器820，该存储器810用于存储计算机程序，并将该程序代码传输给该处理器820。换言之，该处理器820可以从存储器810中调用并运行计算机程序，以实现本申请实施例中的方法。

例如，该处理器820可用于根据该计算机程序中的指令执行上述方法300或400中的步骤。

在本申请的一些实施例中，该处理器820可以包括但不限于：

通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(FieldProgrammable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等等。

在本申请的一些实施例中，该存储器810包括但不限于：

易失性存储器和/或非易失性存储器。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double DataRate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synch link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DR RAM)。

在本申请的一些实施例中，该计算机程序可以被分割成一个或多个模块，该一个或者多个模块被存储在该存储器810中，并由该处理器820执行，以完成本申请提供的编码方法。该一个或多个模块可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述该计算机程序在该电子设备800中的执行过程。

可选的，该电子设备800还可包括：

收发器830，该收发器830可连接至该处理器820或存储器810。

其中，处理器820可以控制该收发器830与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。收发器830可以包括发射机和接收机。收发器830还可以进一步包括天线，天线的数量可以为一个或多个。

应当理解，该电子设备800中的各个组件通过总线系统相连，其中，总线系统除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。

根据本申请的一个方面，提供了一种通信装置，包括处理器和存储器，该存储器用于存储计算机程序，该处理器用于调用并运行所述存储器中存储的计算机程序，使得所述编码器执行上述方法实施例的方法。

根据本申请的一个方面，提供了一种计算机存储介质，其上存储有计算机程序，该计算机程序被计算机执行时使得该计算机能够执行上述方法实施例的方法。或者说，本申请实施例还提供一种包含指令的计算机程序产品，该指令被计算机执行时使得计算机执行上述方法实施例的方法。

根据本申请的另一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述方法实施例的方法。

换言之，当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本申请实施例该的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如数字视频光盘(digital video disc，DVD))、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的模块及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，该模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。例如，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以该权利要求的保护范围为准。

Claims (15)

1.一种小文件合并的方法，其特征在于，包括：

将至少两个小文件进行分组；

确定每个分组的小文件等级；其中，所述小文件等级表示对小文件进行合并的优先级；

确定所述每个分组的小文件索引，其中，所述小文件索引的关键字包括所述小文件等级；

根据所述每个分组中小文件的统计信息，确定满足合并条件；

根据所述每个分组中的小文件索引，对所述每个分组中的相同等级的小文件进行合并。

2.根据权利要求1所述的方法，其特征在于，所述将至少两个小文件进行分组，包括：

按照所述小文件存储的分区，对所述至少两个小文件进行分组。

3.根据权利要求2所述的方法，其特征在于，所述至少两个小文件包括第一时间段内写入的小文件，所述第一时间段内写入同一分区的小文件的等级相同。

4.根据权利要求2或3所述的方法，其特征在于，所述根据所述每个分组中的小文件索引，对所述每个分组中的相同等级的小文件进行合并之前，还包括：

根据分区的偏移量和所述小文件索引，获取所述每个分组中相同等级的小文件。

5.根据权利要求4所述的方法，其特征在于，还包括：

在元数据文件结构中记录所述分区的偏移量。

6.根据权利要求1-5任一项所述的方法，其特征在于，还包括：

在元数据文件结构中记录所述小文件的等级。

7.根据权利要求1-6任一项所述的方法，其特征在于，所述至少两个小文件包括对小文件进行合并后的文件。

8.根据权利要求1-7任一项所述的方法，其特征在于，所述根据所述每个分组中的小文件索引，对所述每个分组中的相同等级的小文件进行合并，包括：

在所述每个分组中相同等级的小文件的总大小大于预设值时，将所述每个分组中相同等级的小文件合并为至少一个所述预设值大小的文件。

9.根据权利要求1-8任一项所述的方法，其特征在于，还包括：

根据合并前的小文件的等级，确定合并后的文件的等级，其中，所述合并后的文件的等级高于所述合并前的小文件的等级。

10.根据权利要求1-9任一项所述的方法，其特征在于，所述统计信息包括大小信息、数量信息和均方差信息中的至少一种。

11.根据权利要求1-10任一项所述的方法，其特征在于，所述至少两个小文件包括Hadoop分布式文件系统HDFS中的小文件。

12.一种小文件合并的装置，其特征在于，包括：

分组单元，用于将至少两个小文件进行分组；

确定单元，用于确定每个分组的小文件等级；其中，所述小文件等级表示对小文件进行合并的优先级；

所述确定单元还用于确定所述每个分组的小文件索引，其中，所述小文件索引的关键字包括所述小文件等级；

所述确定单元还用于根据所述每个分组中小文件的统计信息，确定满足合并条件；

合并单元，用于根据所述每个分组中的小文件索引，对所述每个分组中的相同等级的小文件进行合并。

13.一种电子设备，其特征在于，包括处理器和存储器，所述存储器中存储有指令，所述处理器执行所述指令时，使得所述处理器执行权利要求1-11任一项所述的方法。

14.一种计算机存储介质，其特征在于，用于存储计算机程序，所述计算机程序包括用于执行权利要求1-11中任一项所述的方法。

15.一种计算机程序产品，其特征在于，包括计算机程序代码，当所述计算机程序代码被电子设备运行时，使得所述电子设备执行权利要求1-11中任一项所述的方法。