CN118260244A - 一种分布式小文件的治理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种分布式小文件的治理方法、装置、设备及存储介质，涉及大数据技术领域，包括：将各个分区中的全部待治理小文件分组得到N个文件组；基于各个分区的目录路径和文件组构建哈希表；将每个分区对应的所有文件组分别读到内存中得到若干原始数据集，并在每个原始数据集中新增字段名为组号的列；合并同一分区对应的所有原始数据集得到合并数据集，并将每个合并数据集中具有同一组号的数据写到同一文件中得到合并文件；用合并文件替换对应分区中的全部待治理小文件，并根据替换结果确定是否进行数据回滚。本申请针对小文件治理失败的情况，提供了备份和回滚机制，保证即使治理失败，也可以恢复数据，不会影响原有的数据文件。

Description

一种分布式小文件的治理方法、装置、设备及存储介质

技术领域

本申请涉及大数据技术领域，尤其涉及一种分布式小文件的治理方法、装置、设备及存储介质。

背景技术

Apache Spark是一个分布式计算引擎，具有高性能、易用、容错、可以与Hadoop生态无缝集成、社区活跃等特点，因此，常被应用于小文件治理，同时，在现有技术中对小文件进行治理的方法主要包括以下几种：

1.对于tableA即数据库表A，先通过CTAS（Create Table As Select，创建表作为选择）语句将tableA的数据插入到临时表tableTmp，再获取tableTmp的总大小size，同时执行SQL语句insert overwrite table tableA select /*+ coalesce(size / 128m) */ *from tableTmp在tableTmp下生成size/128m个文件，最后再执行drop table tableTmp语句将tableTmp删除；

2.将Spark升级到3.2版本，并开启其AQE（Adaptive Query Execution）特性，这样只要SQL语句中包含shuffle操作，Spark在执行该SQL语句的过程中就会自动进行小文件合并，而且在执行insert插入操作时也会尽可能的不产生小文件，其中，在Spark中，Shuffle是重新分布数据的机制，但shuffle过后，合并任务的数据分布可能参差不齐，此时，AQE会自动合并过小的数据分区，以提高处理效率，该方案是从源头端控制小文件的生成；

3.专门开发一个应用或者是在应用内部开启一个进程，根据条件遍历集群中的小文件，并且对识别出来的小文件进行合并。

但是这几种方法都各有不足，如第一种方法只能对小文件进行粗粒度合并；第二种方法需要将Spark升级到高版本，且如果SQL语句中不包含shuffle操作，AQE就不会发挥作用；第三种方法中由于是单进程或单个应用，内存的大小已经在应用启动的时候确定，如果有很多小文件需要合并，很容易导致应用00M。除此之外，现有的技术方案中也都没有考虑到小文件治理失败后的回滚恢复操作，容错性较差，且一般都是单机进行合并，性能较低。

发明内容

本申请提供的一种分布式小文件的治理方法，旨在解决现有技术中对小文件的合并处理容错性差、性能低且粗粒度的问题。

为实现上述目的，本申请采用以下技术方案：

本申请的一种分布式小文件的治理方法，包括以下步骤：

确定各个分区中的全部待治理小文件，并分别对每个分区中的全部待治理小文件进行分组得到N个包含组号的文件组，N为非零自然数；

基于各个分区的目录路径和N个文件组构建哈希表，并根据所述哈希表确定各个分区分别对应的所有文件组；

使用Spark将每个分区对应的所有文件组分别读到内存中得到若干原始数据集，并在每个原始数据集中新增字段名为组号的列；

将同一分区对应的所有原始数据集合并得到多个合并数据集，并将每个合并数据集中具有同一组号的数据写到同一文件中得到N个合并文件；

用各个合并文件分别替换对应分区中的全部待治理小文件，并对比替换前后各个分区中的数据总条数以判断是否进行数据回滚。

作为优选，所述方法还包括：

配置Spark小文件治理任务的提交参数，所述提交参数包括Driver可用的CPU核数和内存大小、集群内Executor的个数、每个Executor可用的CPU核数和内存大小，并将所述治理任务提交到Yarn上运行。

作为优选，所述确定各个分区中的全部待治理小文件，并分别对每个分区中的全部待治理小文件进行分组得到N个包含组号的文件组，N为非零自然数，包括：

获取分布式文件系统中每个分区的目录路径，并根据所述目录路径获取每个分区中所有文件的大小；

设定第一阈值和第二阈值，将每个文件的大小与所述第一阈值进行比对，并将大小不超过所述第一阈值的文件作为待治理小文件；

基于所述第二阈值，利用FFD近似算法分别对每个分区中的全部待治理小文件进行分组得到N个包含组号的文件组，N为非零自然数，每个文件组的大小不超过所述第二阈值。

作为优选，所述基于各个分区的目录路径和N个文件组构建哈希表，并根据所述哈希表确定各个分区分别对应的所有文件组，包括：

以每个分区的目录路径为键、文件组列表为值构造键值对，并将所有键值对存储在哈希表中；

遍历所述哈希表，得到每个分区各自对应的所有文件组。

作为优选，所述将每个合并数据集中具有同一组号的数据写到同一文件中得到N个合并文件，包括：

根据组号对每个合并数据集进行分批操作得到M个分批结果，M为大于1的整数；

基于coalesce算子对同一分批结果中的数据进行合并，得到N个合并文件，并将所有合并文件保存到临时目录下。

作为优选，在使用Spark将每个分区对应的所有文件组分别读到内存中得到若干原始数据集，并在每个原始数据集中新增字段名为组号的列之前还包括：

将各个分区中的所有文件拷贝到备份目录下，所述所有文件中包含待治理小文件。

作为优选，所述用各个合并文件分别替换对应分区中的全部待治理小文件，并对比替换前后各个分区中的数据总条数以判断是否进行数据回滚，包括：

删除各个分区中的全部待治理小文件，并将所述N个合并文件移动到对应的分区下；

分别获取替换前后各个分区中的数据总条数并进行比对；

于每个分区替换后的数据总条数均等于其替换前的数据总条数时，全部治理成功，则清理所述备份目录和临时目录；

于存在分区替换后的数据总条数不等于其替换前的数据总条数时，部分治理成功，则进行数据回滚，删除治理失败分区目录下的所有文件，并将其对应的拷贝数据移动到其目录路径上，同时清理所述临时目录和治理成功分区所对应的拷贝数据。

一种分布式小文件的治理装置，包括：

分组模块，用于确定各个分区中的全部待治理小文件，并分别对每个分区中的全部待治理小文件进行分组得到N个包含组号的文件组，N为非零自然数；

构建模块，用于基于各个分区的目录路径和N个文件组构建哈希表，并根据所述哈希表确定各个分区分别对应的所有文件组；

转换模块，用于使用Spark将每个分区对应的所有文件组分别读到内存中得到若干原始数据集，并在每个原始数据集中新增字段名为组号的列；

合并模块，用于将同一分区对应的所有原始数据集合并得到多个合并数据集，并将每个合并数据集中具有同一组号的数据写到同一文件中得到N个合并文件；

清理模块，用于用各个合并文件分别替换对应分区中的全部待治理小文件，并对比替换前后各个分区中的数据总条数以判断是否进行数据回滚。

一种电子设备，包括存储器和处理器，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行以实现如上述中任一项所述的一种分布式小文件的治理方法。

一种存储有计算机程序的计算机可读存储介质，所述计算机程序使计算机执行时实现如上述中任一项所述的一种分布式小文件的治理方法。

本发明具有如下有益效果：

本申请可以动态的调整Spark任务的资源参数来加速小文件治理任务的完成或避免因小文件过多、资源不够导致治理失败的问题，同时，针对小文件治理失败的情况，提供了备份和回滚机制，保证即使治理失败，也可以恢复数据，不会影响原有的数据文件。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请中一种分布式小文件的治理方法的流程图；

图2是本申请中一种分布式小文件的治理装置示意图；

图3是本申请中实现一种分布式小文件的治理方法的电子设备示意图。

具体实施方式

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

本申请的权利要求书和说明书的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序，应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式，此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其他单元。

HDFS（Hadoop distributed file system，Hadoop分布式文件系统）：是集群的重要组成部分，由一个管理节点和多个数据节点组成，它提供了高容错性、可扩展性和透明性，使得用户能够轻松地存储和处理海量数据。

dataset：在 Spark 的大数据处理框架中，dataset是一个分布式的强类型的数据结构，类似于关系数据库中的表，它提供了高性能的数据处理和查询功能。

如图1所示，本实施例提供一种分布式小文件的治理方法，包括以下步骤：

S110、确定各个分区中的全部待治理小文件，并分别对每个分区中的全部待治理小文件进行分组得到N个包含组号的文件组，N为非零自然数；

S120、基于各个分区的目录路径和N个文件组构建哈希表，并根据所述哈希表确定各个分区分别对应的所有文件组；

S130、使用Spark将每个分区对应的所有文件组分别读到内存中得到若干原始数据集，并在每个原始数据集中新增字段名为组号的列；

S140、将同一分区对应的所有原始数据集合并得到多个合并数据集，并将每个合并数据集中具有同一组号的数据写到同一文件中得到N个合并文件；

S150、用各个合并文件分别替换对应分区中的全部待治理小文件，并对比替换前后各个分区中的数据总条数以判断是否进行数据回滚。

在实施例1中，用户可以根据实际情况先动态调整Spark相关的资源参数，如将Driver可用的CPU核数调整为2即spark.driver.cores=2，将Driver可用的内存大小设置为2g即spark.driver.memory=2g，将集群内Executor 的个数设置为2即spark.executor.instances=2，将每个Executor可用的CPU核数也设置为2即spark.executor.cores=2，同时将Executor可用的内存大小也设置为2g即spark.executor.memory=2g，然后离线平台将这些资源参数作为Spark小文件治理任务的提交参数，并将该治理任务提交到Yarn上运行。

在 Spark 分布式计算环境中，或者说在将Spark任务提交到Yarn上运行后，Spark会根据资源参数在Yarn上启动一个Driver进程和n个Executor进程，n为spark.executor.instances的值，在本实施例中n为2，Driver 最核心的作用在于，解析用户代码、构建计算流图，然后将计算流图转化为分布式任务，并把任务分发给集群中的Executors运行；Driver相当于一主多从的控制器；运行中的Executor也会和Driver进行通信；真正执行任务的是Executor，Driver拆解出分布式任务，将分布式任务分发到Executors 中去执行；如果Spark要处理的数据量很大，那就根据实际情况调整上面的资源参数，比如增加Executor的个数，这样处理任务的对象就多了；增大每个Executor的内存，这样每个Executor就能处理更多的数据，或者增大Executor的core，那就可以增大每个Executor并发处理任务的能力。即当需要治理的小文件很多时，可通过适当调整资源参数来增大参数，减少任务执行时间，也避免因为资源不够导致00M或者其他任务失败问题。

同时还需初始化SparkSession对象，SparkSession是Apache Spark 2.0 之后引入的新概念，其作为Spark应用程序的单一切入点，允许用户通过它调用DataFrame和Dataset相关API来编写Spark程序。

进一步地，获取分布式文件系统中每个分区的目录路径，并根据所述目录路径获取每个分区中所有文件的大小；

设定第一阈值和第二阈值，将每个文件的大小与所述第一阈值进行比对，并将大小不超过所述第一阈值的文件作为待治理小文件；

基于所述第二阈值，利用FFD近似算法分别对每个分区中的全部待治理小文件进行分组得到N个包含组号的文件组，N为非零自然数，每个文件组的大小不超过所述第二阈值。

开始小文件治理，先获取HDFS中各个分区即partition的目录路径，这里需要说明的是，若HDFS中Hive表均没有partition，则此处获取的应是表的目录路径，若HDFS中有部分Hive表没有partition，则此处获取的应是表或partition的目录路径，即没有partition的Hive表就获取表的目录路径，有partition的Hive表就获取其partition的目录路径，在本实施例中，假设所有Hive表均有partition，并通过HDFS提供的FileSystem类的listStatus方法获取到这个partition下的所有文件信息，这些文件信息包括文件的目录路径、文件的大小和文件名等，同时设定第一阈值minimumFileSize和第二阈值mergedTargetSize，在本实施例中，minimumFileSize为40MB，即将大小不超过40MB的文件均视为小文件，mergedTargetSize为64MB，即对小文件治理后得到的文件大小不超过64MB，再将第一阈值与每个文件的大小进行比对，便可确定每个partition中的全部待治理小文件。

基于mergedTargetSize使用FFD（First Fit Decreasing，降序首次适应算法）对每个partition下的待治理小文件进行分组，使得分组数近似最优，FFD近似算法是一种解决装箱问题的启发式算法，其先对物品按大小降序排序，然后依次尝试将每个物品放入已打开的箱子中，直到找到一个足够大的箱子为止，如果找不到，则打开一个新箱子来放置该物品，在本实施例中，待治理小文件的分组方式与装箱方式本质相同，只是将物品替换为待治理小文件，箱子替换为文件组，故这里不再赘述具体分组流程，假设某一partition内共有19个待治理小文件，这些待治理小文件的大小分别为23、45、12、34、5、9、11、23、33、22、48、 2、11、1、43、12、1、7和12，利用FFD近似算法进行分组得到的结果是[[48, 12, 2, 1,1], [45, 12, 7], [43, 12, 9], [34, 23, 5], [33, 23], [22, 11, 11]]，即该partition内所有待治理小文件一共被分为六个文件组FileGroup，从第一文件组至第六文件组的组号分别是0、1、2、3、4和5，且每一文件组中所有待治理小文件的大小之和小于等于64MB。

分组完成后便可得到N个文件组，N为非零自然数，即当分区中所有待治理小文件的大小之和小于等于64MB时只有一个文件组，每一文件组都具有组号，且每个文件组中均包含至少1个待治理小文件，需要注意的是，在本实施例中，是对不同partition中的待治理小文件分别进行分组的，因此，最终得到的任一文件组中的待治理小文件都属于同一partition，然后根据分组结果构建一个用来存储以partition的目录路径为key、文件组列表List<FileGroup>为value的键值对的哈希表HashMap，该哈希表名为partitionToFileGroups。

遍历partitionToFileGroups，得到每个partition以及每个partition下的所有FileGroup，将各个partition中的所有文件均拷贝到备份目录backupDir，这里的所有文件中是包含全部待治理小文件的，以在待治理小文件治理失败后通过备份数据进行回滚操作。

进一步地，根据组号对每个合并数据集进行分批操作得到M个分批结果，M为大于1的整数；

基于coalesce算子对同一分批结果中的数据进行合并，得到N个合并文件，并将所有合并文件保存到临时目录下。

备份完成，分别使用Spark将每个FileGroup下全部的待治理小文件读取到内存中，生成与FileGroup一一对应的原始数据集dataset，即一个FileGroup对应生成一个dataset，并在每个dataset中新增一个字段为组名即dt_small_files_group的列，再对同一partition下的所有dataset执行unionAll操作得到合并数据集allDataset，其中，unionAll表示将两个查询的结果合并为一个结果集，并保留重复的行，在本实施例中，就是将一个partition下所有待治理小文件的所有数据合并到一个allDataset中，并按照组名对每个allDataset中的数据进行分批操作得到M个分批结果，M为大于1的整数，优选地，调用dataset的partitionBy算子对每个allDataset进行分批操作，并基于coalesce算子将同一分批结果中的数据写到一个单独的文件中得到合并文件mergedFile，同时将其保存到mergeDataMd5Dir的临时目录下，即先计算每一分区路径的md5值，再根据其md5值确定临时目录具体值，例如，一分区路径为String partitionPath= “hdfs://ns1/hive.db/my_table/day=20240520”，那么就对partitionPath 的值进行md5操作，即StringpartitionPathMd5Value = md5(partitionPath )，此时mergeDataMd5Dir=mergeDataDir+“/”+partitionPathMd5Value。

假设使用FFD近似算法得到3个文件组，group-0即第0组中有3个待治理小文件file1、file2和file3，group-1即第1组中有2个待治理小文件 file4和file5，group-2即第1组中有2个待治理小文件 file6和file7，其中，file1中有3条数据，分别是a、b、c、d1，a、b、c、d2，以及a、b、c、d3，file2中有4条数据，分别是a、b、c、d4，a、b、c、d5，a、b、c、d6，以及a、b、c、d7，file3中有2条数据，分别是a、b、c、d8，以及a、b、c、d9，file4中有3条数据，分别是a、b、c、d10，a、b、c、d11，以及a、b、c、d12，file5中有6条数据，分别是a、b、c、d13，a、b、c、d14，a、b、c、d15，a、b、c、d16，a、b、c、d17，以及a、b、c、d18， file6中有3条数据，分别是a、b、c、d19，a、b、c、d20，以及a、b、c、d21，file7中有3条数据，分别是a、b、c、d22，a、b、c、d23，以及a、b、c、d24，使用Spark将第0组中的file1、file2和file3读取到内存中得到data1，将第1组中的file4和file5读取到内存中得到data2，将第2组中的file6和file7读取到内存中得到data3，在每个dataset中新增一个字段为组名即dt_small_files_group的列后，data1中的9条数据分别是a、b、c、d1、0，a、b、c、d2、0，a、b、c、d3、0，a、b、c、d4、0，a、b、c、d5、0，a、b、c、d6、0，a、b、c、d7、0，a、b、c、d8、0，以及a、b、c、d9、0，data2中的9条数据分别是a、b、c、d10、1，a、b、c、d11、1，a、b、c、d12、1，a、b、c、d13、1，a、b、c、d14、1，a、b、c、d15、1，a、b、c、d16、1，a、b、c、d17、1，以及a、b、c、d18、1，data3中的6条数据分别是a、b、c、d19、2，a、b、c、d20、2，a、b、c、d21、2，a、b、c、d22、2，其中每条数据中最后的数字代表的就是组名即dt_small_files_group，执行unionAll后allDataset中则有data1+data2+data3=9+9+6=24条数据，再根据dt_small_files_group将allDataset中数据分成3部分，即组名为0的数据为第一部分，组名为1的数据为第二部分，组名为2的数据为第三部分，最后，利用coalesce算子分别对第一部分、第二部分和第三部分进行处理，得到3个合并文件mergedFile1、mergedFile2和mergedFile3，其中，mergedFile1中的数据有9条分别对应data1中的数据，mergedFile2中也有9条数据分别对应data2中的数据，mergedFile3中有6条数据分别对应data3中的数据，然后将mergedFile1、mergedFile2和mergedFile3保存到其临时目录下。

进一步地，删除各个分区中的全部待治理小文件，并将所述N个合并文件移动到对应的分区下；

分别获取替换前后各个分区中的数据总条数并进行比对；

于每个分区替换后的数据总条数均等于其替换前的数据总条数时，全部治理成功，则清理所述备份目录和临时目录；

于存在分区替换后的数据总条数不等于其替换前的数据总条数时，部分治理成功，则进行数据回滚，删除治理失败分区目录下的所有文件，并将其对应的拷贝数据移动到其目录路径上，同时清理所述临时目录和治理成功分区所对应的拷贝数据。

删除每个partition下的全部待治理小文件，并将mergedFile移动到对应的partition下，同时使用Spark分别读取修改前后每个partition的数据总条数，并进行比对，如果该partition修改后的数据总条数等于其修改前的数据总条数，则该partition中的小文件治理成功，如果不等于，则该partition中的小文件治理失败，执行回滚操作，即删除治理失败的partition的目录，再将其对应的拷贝数据移动到其目录路径下，最后，将每个partition的治理结果写到HDFS的结果文件中，治理结果包括治理前分区总大小、治理后分区总大小、治理前文件个数、治理后文件个数、治理状态等，如果所有的治理结果均为成功，那么清理mergeDataDir和backupDir，如果有部分partition治理失败，则删除治理失败partition目录下的所有文件，并将其对应的拷贝数据移动到其目录路径上，同时清理mergeDataDir和治理成功分区所对应的拷贝数据。

在本实施例中，为了提升合并小文件的性能，在对小文件进行分组的时候，采用了FFD近似算法，使得分组数量最小、分组结果最优；并且可以动态的调整Spark任务的资源参数来加速小文件治理任务的完成或避免因小文件过多、资源不够导致治理失败的问题，同时，针对小文件治理失败的情况，提供了备份和回滚机制，保证即使治理失败，也可以恢复数据，不会影响原有的数据文件，最后将治理结果写到HDFS，通过离线平台读取结果文件并且展示到前端，用户可以直观地了解到每个小文件治理任务的具体情况。

如图2所示，一种分布式小文件的治理装置，包括：

分组模块10，用于确定各个分区中的全部待治理小文件，并分别对每个分区中的全部待治理小文件进行分组得到N个包含组号的文件组，N为非零自然数；

构建模块20，用于基于各个分区的目录路径和N个文件组构建哈希表，并根据所述哈希表确定各个分区分别对应的所有文件组；

转换模块30，用于使用Spark将每个分区对应的所有文件组分别读到内存中得到若干原始数据集，并在每个原始数据集中新增字段名为组号的列；

合并模块40，用于将同一分区对应的所有原始数据集合并得到多个合并数据集，并将每个合并数据集中具有同一组号的数据写到同一文件中得到N个合并文件；

清理模块50，用于用各个合并文件分别替换对应分区中的全部待治理小文件，并对比替换前后各个分区中的数据总条数以判断是否进行数据回滚。

上述装置的一种实施方式可为：分组模块10确定各个分区中的全部待治理小文件，并分别对每个分区中的全部待治理小文件进行分组得到N个包含组号的文件组，N为非零自然数；构建模块20基于各个分区的目录路径和N个文件组构建哈希表，并根据所述哈希表确定各个分区分别对应的所有文件组；转换模块30使用Spark将每个分区对应的所有文件组分别读到内存中得到若干原始数据集，并在每个原始数据集中新增字段名为组号的列；合并模块40将同一分区对应的所有原始数据集合并得到多个合并数据集，并将每个合并数据集中具有同一组号的数据写到同一文件中得到N个合并文件；清理模块50用各个合并文件分别替换对应分区中的全部待治理小文件，并对比替换前后各个分区中的数据总条数以判断是否进行数据回滚。

如图3所示，一种电子设备，包括存储器301和处理器302，所述存储器301用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器302执行以实现上述的一种分布式小文件的治理方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的电子设备的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

一种存储有计算机程序的计算机可读存储介质，所述计算机程序使计算机执行时实现如上述的一种分布式小文件的治理方法。

示例性的，计算机程序可以被分割成一个或多个模块/单元，一个或者多个模块/单元被存储在存储器301中，并由处理器302执行，并由输入接口305和输出接口306完成数据的I/O接口传输，以完成本发明,一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序在计算机设备中的执行过程。

计算机设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。计算机设备可包括，但不仅限于，存储器301、处理器302,本领域技术人员可以理解，本实施例仅仅是计算机设备的示例，并不构成对计算机设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件，例如计算机设备还可以包括输入器307、网络接入设备、总线等。

处理器302可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器302、数字信号处理器302(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器302可以是微处理器302或者该处理器302也可以是任何常规的处理器302等。

存储器301可以是计算机设备的内部存储单元，例如计算机设备的硬盘或内存。存储器301也可以是计算机设备的外部存储设备，例如计算机设备上配备的插接式硬盘，智能存储卡（Smart Media Card,SMC），安全数字（Secure Digital,SD）卡，闪存卡（Flash Card）等,进一步地，存储器301还可以既包括计算机设备的内部存储单元也包括外部存储设备,存储器301用于存储计算机程序以及计算机设备所需的其他程序和数据,存储器301还可以用于暂时地存储在输出器308，而前述的存储介质包括U盘、移动硬盘、只读存储器ROM303、随机存储器RAM304、碟盘或光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何在本发明揭露的技术范围内的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种分布式小文件的治理方法，其特征在于，包括以下步骤：

确定各个分区中的全部待治理小文件，并分别对每个分区中的全部待治理小文件进行分组得到N个包含组号的文件组，N为非零自然数；

基于各个分区的目录路径和N个文件组构建哈希表，并根据所述哈希表确定各个分区分别对应的所有文件组；

使用Spark将每个分区对应的所有文件组分别读到内存中得到若干原始数据集，并在每个原始数据集中新增字段名为组号的列；

将同一分区对应的所有原始数据集合并得到多个合并数据集，并将每个合并数据集中具有同一组号的数据写到同一文件中得到N个合并文件；

用各个合并文件分别替换对应分区中的全部待治理小文件，并对比替换前后各个分区中的数据总条数以判断是否进行数据回滚。

2.根据权利要求1所述的一种分布式小文件的治理方法，其特征在于，所述方法还包括：

配置Spark小文件治理任务的提交参数，所述提交参数包括Driver可用的CPU核数和内存大小、集群内Executor的个数、每个Executor可用的CPU核数和内存大小，并将所述治理任务提交到Yarn上运行。

3.根据权利要求1所述的一种分布式小文件的治理方法，其特征在于，所述确定各个分区中的全部待治理小文件，并分别对每个分区中的全部待治理小文件进行分组得到N个包含组号的文件组，N为非零自然数，包括：

获取分布式文件系统中每个分区的目录路径，并根据所述目录路径获取每个分区中所有文件的大小；

设定第一阈值和第二阈值，将每个文件的大小与所述第一阈值进行比对，并将大小不超过所述第一阈值的文件作为待治理小文件；

基于所述第二阈值，利用FFD近似算法分别对每个分区中的全部待治理小文件进行分组得到N个包含组号的文件组，N为非零自然数，每个文件组的大小不超过所述第二阈值。

4.根据权利要求1所述的一种分布式小文件的治理方法，其特征在于，所述基于各个分区的目录路径和N个文件组构建哈希表，并根据所述哈希表确定各个分区分别对应的所有文件组，包括：

以每个分区的目录路径为键、文件组列表为值构造键值对，并将所有键值对存储在哈希表中；

遍历所述哈希表，得到每个分区各自对应的所有文件组。

5.根据权利要求1所述的一种分布式小文件的治理方法，其特征在于，所述将每个合并数据集中具有同一组号的数据写到同一文件中得到N个合并文件，包括：

根据组号对每个合并数据集进行分批操作得到M个分批结果，M为大于1的整数；

基于coalesce算子对同一分批结果中的数据进行合并，得到N个合并文件，并将所有合并文件保存到临时目录下。

6.根据权利要求1所述的一种分布式小文件的治理方法，其特征在于，在使用Spark将每个分区对应的所有文件组分别读到内存中得到若干原始数据集，并在每个原始数据集中新增字段名为组号的列之前还包括：

将各个分区中的所有文件拷贝到备份目录下，所述所有文件中包含待治理小文件。

7.根据权利要求6所述的一种分布式小文件的治理方法，其特征在于，所述用各个合并文件分别替换对应分区中的全部待治理小文件，并对比替换前后各个分区中的数据总条数以判断是否进行数据回滚，包括：

删除各个分区中的全部待治理小文件，并将所述N个合并文件移动到对应的分区下；

分别获取替换前后各个分区中的数据总条数并进行比对；

于每个分区替换后的数据总条数均等于其替换前的数据总条数时，全部治理成功，则清理所述备份目录和临时目录；

于存在分区替换后的数据总条数不等于其替换前的数据总条数时，部分治理成功，则进行数据回滚，删除治理失败分区目录下的所有文件，并将其对应的拷贝数据移动到其目录路径上，同时清理所述临时目录和治理成功分区所对应的拷贝数据。

8.一种分布式小文件的治理装置，其特征在于，包括：

分组模块，用于确定各个分区中的全部待治理小文件，并分别对每个分区中的全部待治理小文件进行分组得到N个包含组号的文件组，N为非零自然数；

构建模块，用于基于各个分区的目录路径和N个文件组构建哈希表，并根据所述哈希表确定各个分区分别对应的所有文件组；

转换模块，用于使用Spark将每个分区对应的所有文件组分别读到内存中得到若干原始数据集，并在每个原始数据集中新增字段名为组号的列；

合并模块，用于将同一分区对应的所有原始数据集合并得到多个合并数据集，并将每个合并数据集中具有同一组号的数据写到同一文件中得到N个合并文件；

清理模块，用于用各个合并文件分别替换对应分区中的全部待治理小文件，并对比替换前后各个分区中的数据总条数以判断是否进行数据回滚。

9.一种电子设备，其特征在于，包括存储器和处理器，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行以实现如权利要求1～7中任一项所述的一种分布式小文件的治理方法。

10.一种存储有计算机程序的计算机可读存储介质，其特征在于，所述计算机程序使计算机执行时实现如权利要求1～7中任一项所述的一种分布式小文件的治理方法。