CN112035057B - 一种hive文件合并的方法和装置 - Google Patents

Abstract

本发明涉及数据仓库领域，特别是涉及一种hive文件合并的方法和装置。主要包括：获取一个hive表的元数据定义的目录下的所有文件作为需合并的文件；按照需合并的文件的总容量大小和预设的大文件最大容量估算合并文件时需要的桶的数量；根据估算所得的桶的数量建立相应数量的桶；将需合并的文件按照每个文件的容量从大到小依次放入空闲容量最大的桶中，直至所有文件都放入桶中；将放入每个桶内的文件分别合并为一个大文件。本发明可以合理分配待合并的小文件合并成一个大文件，过滤无意义的合并，同时减少额外产生的小文件数量，并且通过并行合并的方式提高合并效率。

Description

一种hive文件合并的方法和装置

【技术领域】

本发明涉及数据仓库领域，特别是涉及一种hive文件合并的方法和装置。

【背景技术】

Hive是基于Hadoop架构的一个数据仓库工具，实际生产环境中，每个 hive表下存在很多文件，并且可能存在大量的小文件。在Hadoop中，文件按照固定块大小进行存储，小于一个默认块大小的文件也占据一个块的存储空间，当小文件数量较多时，会占用较多额外的存储空间。另一方面，Hadoop处理大量小文件速度远远小于处理同等大小的大文件的速度，小文件较多时会严重影响处理性能。因此，需要将大量小文件合并为少量大文件进行处理。

目前，Hadoop架构下一般使用CombineFileInputFormat进行小文件合并。但是这种合并方法可能会进行一些不必要的合并，并且合并后可能产生更小的文件。另一方面，这种合并方法一次仅能合并一个hive分区表的一个分区内的文件，必须启动多个map reduce对分区表内各个分区的文件同时合并，导致合并效率较低。

鉴于此，如何克服该现有技术所存在的缺陷，解决现有hive小文件合并方法导致的可能产生不必要的合并，以及合并效率较低的问题，是本技术领域待解决的问题。

【发明内容】

针对现有技术的以上缺陷或改进需求，本发明解决了现有hive小文件合并时无法合理分配待合并的小文件，以及多个分区同时进行合并的效率问题。

本发明实施例采用如下技术方案:

第一方面，本发明提供了一种hive文件合并的方法，具体为：获取一个hive表的元数据定义的目录下的所有文件作为需合并的文件；按照需合并的文件的总容量大小和预设的大文件最大容量估算合并文件时需要的桶的数量；根据估算所得的桶的数量建立相应数量的桶；将需合并的文件按照每个文件的容量从大到小依次放入空闲容量最大的桶中，直至所有文件都放入桶中；将放入每个桶内的文件分别合并为一个大文件。

优选的，将需合并的文件按照每个文件的容量从大到小依次放入空闲容量最大的桶中，具体包括：将需合并的文件按照每个文件的容量从大到小排序，放入文件列表中；将桶按照空闲容量的大小从大到小排序，放入桶列表中；取出桶列表中的第一个桶，取出文件列表中的第一个文件，将取出的文件放入取出的桶中；计算取出的桶的空闲容量，根据空闲容量把取出的桶***桶列表中合适的排序位置，保持桶列表中的桶按照空闲容量的大小从大到小排序。

优选的，根据空闲容量把取出的桶***桶列表中合适的排序位置，具体包括：按照桶列表的顺序，将取出的桶的空闲容量依次和桶列表中每个桶的空闲容量比较；查找桶列表中最后一个空闲容量大于取出的桶的空闲容量的桶，将取出的桶***查找到的桶之后。

优选的，估算合并文件时需要的桶的数量具体包括：获取需合并的文件的总容量大小；根据需合并的文件的总容量大小和预设的大文件最大容量估算合并后的大文件的数量，合并文件时需要的桶的数量与合并后的大文件的数量相同。

优选的，预设的大文件最大容量大于一个***数据块的容量。

优选的，将放入每个桶内的文件分别合并为一个大文件，具体包括：以map reducejob方式提交桶列表中所有的桶到Hadoop下进行文件合并，每个reduce任务中进行至少一个桶内的文件的合并。

优选的，每个reduce任务中进行至少一个桶内的文件的合并，具体包括：将桶列表中的桶按照空闲容量从小到大排序；取出桶列表中的第一个桶，放入已放入的桶的总容量最小的reduce分区中，直至所有桶都放入对应的reduce分区中。

优选的，将放入每个桶内的文件分别合并为一个大文件之前，还包括：移除仅放入一个需合并的文件的桶。

优选的，将放入每个桶内的文件分别合并为一个大文件后，删除原有的需合并的文件。

另一方面，本发明提供了一种hive文件合并的装置，具体为：包括至少一个处理器和存储器，至少一个处理器和存储器之间通过数据总线连接，存储器存储能被至少一个处理器执行的指令，指令在被处理器执行后，用于完成第一方面提供的hive文件合并的方法。

与现有技术相比，本发明实施例的有益效果在于：通过向桶中均衡放置需合并的文件，使每个大文件中包含的小文件容量更合理，合理分配待合并的小文件合并成一个大文件，过滤无意义的合并，同时减少额外产生的小文件数量，并且通过并行合并的方式提高分区表各个分区文件合并的效率，以及多个表文件同时合并的效率。

进一步的，在本发明的优选方案中，对本发明是合理提供的小文件合并方法进行优化，通过文件过滤去除不需要合并的文件、通过自定义 mapreduce job及reduce负载均衡进一步提高合并效率。

【附图说明】

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

图1为本发明实施例提供的一种hive文件合并的方法流程图；

图2为本发明实施例提供的另一种hive文件合并的方法流程图；

图3为本发明实施例提供的另一种hive文件合并的方法流程示意图；

图4为本发明实施例提供的另一种hive文件合并的方法流程示意图；

图5为本发明实施例提供的另一种hive文件合并的方法流程图；

图6为本发明实施例提供的另一种hive文件合并的方法流程图；

图7为本发明实施例提供的另一种hive文件合并的方法流程图；

图8为本发明实施例提供的另一种hive文件合并的方法流程图；

图9为本发明实施例提供的一种hive文件合并的装置结构示意图。

【具体实施方式】

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明是一种特定功能***的体系结构，因此在具体实施例中主要说明各结构模组的功能逻辑关系，并不对具体软件和硬件实施方式做限定。

此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。下面就参考附图和实施例结合来详细说明本发明。

实施例1：

在Hadoop中，由于处理大量小文件速度远远小于处理同等大小的大文件的速度，小文件较多时会严重影响处理性能。因此，需要将大量小文件合并为少量大文件进行处理。为了将大量小文件合并为少量大文件，提高文件处理效率，可以使用CombineFileInputFormat进行小文件合并，CombineFileInputFormat可能会出现不必要的合并，例如预设的大文件最大容量为1G，有两个待合并的文件的容量分别为600M和700M，如果使用 CombineFileInputFormat进行合并，会生成一个1G左右的大文件，和另一个300M左右的小文件，或更多个小文件，而实际需求中这两个文件没有必要合并，应不予合并。并且，使用CombineFileInputFormat合并分区表文件时，需要对每个分区启动一个map reducejob来合并该分区内的文件，合并效率较低。本实施例提供了一种新的hive文件合并方法，将待合并的小文件根据文件大小进行较为均衡的组合，使得合并后的大文件容量更合适；并且通过MapReduce任务同时合并多个大文件，提高了合并效率。

Hive中的数据都在Hadoop分布式文件***(Hadoop Distributed File System，简写为：HDFS)上以文件形式保存，hive中的数据库、表、分区都是以文件的形式存在，可以在HDFS找到对应的文件。

Hive中用于组织数据的数据单元包括以下层次：

Database：数据库。概念等同于关系型数据库的schema，schema是元数据的一个抽象集合，用于保存数据元素与属性的声明、复杂与简单数据类型的定义。

Table：表。概念等同于关系型数据库的表，表中包含数据库中所有数据的数据库对象。

Partition：分区。概念类似于关系型数据库的表分区，hive只支持固定分区，将同一组数据存放至一个固定的分区中。

Bucket(or Clusters):桶。同一个分区内的数据还可以细分，将相同类型的数据再划分至一个桶中。

如图1所示，本发明实施例提供的hive文件合并的方法具体步骤如下：

步骤101：获取一个hive元数据表定义的目录下的所有文件作为需合并的文件。

由于hive文件存放在HDFS上，需要通过元数据表来对HDFS上的数据进行管理。在hive中，通过元数据表保存数据库、表、分区或者表字段等基本属性，以及这些属性与HDFS文件对应关系的映射。每个元数据表定义的目录下包括多个文件，同一个目录下的文件属性一致，可以任意组合进行合并，因此在进行合并时获取同一目录下的所有文件后，不需要对每个需合并的文件属性进行区分。

步骤102：按照需合并的文件的总容量大小和预设的大文件最大容量估算合并文件时需要的桶的数量。

本发明的实施例中，利用桶作为需合并的文件的虚拟容器，将需合并的文件分散放入各个桶中，每个桶中放入的小文件最终合并为一个大文件。将需合并的小文件全部放入合适的桶中之后，可以同时对多个桶中的文件并行进行合并，提高文件合并的效率。在实际使用中，合并后的大文件最大容量根据实际进行预设，每个桶中放入的小文件总容量不超过预设的大文件最大容量，可以避免合并后的小文件超过大文件的最大容量，再次产生小文件。在实际使用中，由于数据是以***数据块为单位进行存储，因此合并后的大文件容量一般大于一个hdfs***默认的数据块容量，所以预设的大文件最大容量需要大于***数据块的容量。

进行文件合并时，如图2所示，需要的桶的数量具体可以根据以下步骤进行估算：

步骤201：获取需合并的文件的总容量大小。

步骤202：根据预设的大文件最大容量，估算合并后的大文件的数量，合并文件时需要的桶的数量与合并后的大文件的数量相同。

进行文件合并时，需要将需合并的文件的放入不同的桶中，并保证每个桶中放入小文件后容量较为均衡，为了均衡分配容量，并且保证每个桶的容量不大于预设的大文件最大容量，桶的数量可以简单使用下述公式进行估算：桶的数量＝需合并的文件的总容量/预设的大文件最大容量。为了保证所有的小文件都能够放入桶中，桶的总容量需要大于需合并的小文件总容量，所以根据上述公式计算出的桶的数量不为整数时需要向上取整。由于每个桶中放入的小文件都会合并为一个大文件，因此合并文件时需要的桶的数量即为合并后的大文件的数量。

步骤103：根据计算所得的桶的数量建立相应数量的桶。

桶是一个虚拟的文件容器，并不存放实际的文件内容，仅通过存放具有包括文件名的文件路径和文件大小这两个属性的文件关联对象列表对文件进行关联。桶的属性有：名字name、内容content和大小size。桶名字为目录加编号的字符串，编号为目录下桶的顺序编号，桶名字具有唯一性；桶内容为桶内所有文件关联对象列表；桶大小为文件关联对象列表对应的实际文件总的大小。本实施例中将文件放入桶中的过程，表示将文件关联对象添加至桶的内容content中，即将文件的关联对象添加进桶的文件关联列表中。

步骤104：将需合并的文件按照每个文件的容量从大到小依次放入空闲容量最大，且放入文件后总容量不超过预设的大文件最大容量的桶中，直至所有文件都放入桶中。

将需合并的小文件放入桶时，可以将小文件封装为桶元素。具体的，桶元素的属性可以包括小文件的容量size和小文件包括文件名的文件路径，以便于对桶的空闲容量进行计算，并对关联的文件进行读取。桶的空闲容量＝预设的大文件最大容量-已放入桶中的文件总容量。为了使每个桶中放入的小文件总容量较为均衡，将需合并的文件中容量较大的文件放入空闲容量较大的桶中，从而放入的文件总容量较小的桶的容量进行较多提升。同时，桶中放入文件的总容量不能超过预设的大文件最大容量。

步骤105：将放入每个桶内的文件分别合并为一个大文件。

经过步骤104将所有需合并的文件放入桶中之后，每个桶中放入的文件总容量都不超过预设的大文件最大容量，并且每个桶中放入的文件总容量较为均衡，将每个桶内的文件分别合并为一个大文件后，生成的大文件容量也较为均衡。同时，由于每个桶的合并过程互不干涉，因此可以采用并行执行的方式同时对多个桶中的文件进行合并，甚至对所有桶中的文件同时进行合并，以提高文件合并的效率。

进一步的，将放入每个桶内的文件分别合并为一个大文件后，大量的需合并的文件合并少量的大文件，***中存在原有的需合并的文件和合并后的大文件两份相同的数据，此时原有的需合并的文件不再被使用，仅使用合并后的大文件，删除原有的需合并的文件。

在本实施例的具体应用场景中，如图3所示，步骤104中将需合并的文件按照每个文件的容量从大到小依次放入空闲容量最大的桶中具体可以使用以下步骤，其中，文件队列中文件的容量从大到小依次为文件1＝300M、文件2＝600M、文件3＝500M,文件4＝400M，文件5＝100M，桶队列中桶为桶1、桶2、桶3，预设的大文件的最大容量为700M：

步骤301：将需合并的文件按照每个文件的容量从大到小排序，放入文件列表中。

对需合并的文件排序按照文件容量降序排列后，只需按照文件列表的顺序依次取出文件，就可以完成步骤104中按照每个文件的容量从大到小获取文件的操作，文件列表中第一个文件即为容量最大的文件。

步骤302：将桶按照空闲容量的大小从大到小排序，放入桶列表中。

对桶按照空闲容量降序排序后，桶列表中的第一个桶为目前空闲容量最大的一个桶。

步骤303：取出桶列表中的第一个桶，取出文件列表中的第一个文件，将取出的文件放入取出的桶中。

桶列表中第一个桶为空闲容量最大的桶，文件列表中第一个文件为容量最大的文件，符合步骤104中对于文件和桶容量的要求。可见，通过对文件的排序和对桶的排序，可以方便的安排文件放入桶中的顺序，并方便的查找到需放入的桶。

步骤304：计算取出的桶的空闲容量，根据空闲容量把取出的桶***桶列表中合适的排序位置。

将文件放入桶中之后，桶中的空闲容量发生了变化，此时需要对桶的空闲容量重新进行计算，并根据变化后的桶空闲容量将桶放回桶列表中，将桶放回桶列表时，需要确保桶列表中的桶依然保证按照桶空闲容量降序排列。

同样的，如图4所示，可以按照上述步骤301-步骤304完成所有文件的放入。需合并的文件全部放入桶中后，桶1中放入文件1，共600M，合并后的大文件大小为700M；桶2中放入文件3和文件5，共600M，合并后的大文件大小为700M；桶3中放入文件4和文件3，共700M，合并后的大文件大小为700M。可见，使用步骤301-304的方法，可以方便的将容量合适的需合并的文件合并为大文件，合并后的文件剩余容量最小，且不会超过预设大文件的最大容量，达到了优化的合并效果。

为了保证每次放入一个文件后，桶列表中的桶依然保证按照桶空闲容量降序排列，在具体实施场景汇总，如图5所示，步骤204可以按照使用下述步骤完成：

步骤401：按照桶列表的顺序，将取出的桶的空闲容量依次和桶列表中每个桶的空闲容量比较。

步骤402：查找桶列表中最后一个空闲容量大于取出的桶的空闲容量的桶，将取出的桶***查找到的桶之后。

由于桶列表中的桶已按照桶的空闲容量降序排列，因此只需要按照桶列表的顺序将取出的桶和桶列表中的每个桶的空闲容量逐次比较，找到桶列表中最后一个空闲容量大于取出的桶的位置，该位置之前的桶空闲容量都大于取出的桶，该位置之后的桶空闲容量都小于取出的桶，将取出的桶***该位置即可保证桶列表中的桶依然按照桶的空闲容量降序排列。进一步的，若桶列表中第一个桶的空闲容量小于或等于取出的桶，在桶列表中找不到空闲容量大于取出的桶的桶，表示取出的桶空闲容量最大，将取出的桶***桶列表头部；若桶列表中最后一个桶的空闲容量大于取出的桶，表示取出的桶空闲容量最小，将取出的桶***桶列表尾部。

在具体实施场景中，文件列表和桶列表可以采用有向队列结构进行存储，便于进行顺序查找和***。

按照步骤301-步骤304的方法，将文件列表中的文件逐个取出放入相应的桶中，即可方便快速的完成步骤104中的操作，将需合并的文件按照每个文件的容量从大到小依次放入空闲容量最大的桶中，直至所有文件都放入桶中。

进一步的，由于步骤102中设置的桶数量是根据预设的大文件最大容量以及需合并的文件的总容量进行估算，因此可能与实际需使用的桶数量存在偏差，导致桶的数量不够，需要添加新的桶。在本实施例的某些场景中，若某一个文件的容量大于每一个桶的剩余容量，即该文件放入任意一个桶后都会导致桶容量超过桶设置的最大容量，这时需要增加一个新的桶存放该文件。比如预设的大文件最大容量为1G＝1024M，有三个文件分别是700M，800M，400M，估算得到的桶数是(700M+800M+400M)/1024M＝2个桶，每个桶容量设置为和预设的大文件最大容量相同的1024M，但两个桶内各放入800M和700M的文件后，剩余容量分别为224M和324M，余下的容量为 400M的文件无法放入任意一个桶中。所以需要添加第三个桶来放400M这个文件。所有文件都放入桶中后，每个桶中只包括一个文件，因此文件不需要任何合并。对桶数量增加的处理，避免了合并后的文件超过预设的大文件最大容量，保证了每个合并后的大文件大小合适。

本实施例对hive文件进行合并，因此可以使用Hadoop的特性提高步骤104和步骤105的执行效率。在具体实施场景中，在步骤104中将需合并的文件都放入相应的桶中后，将步骤105以map reduce Job方式执行，提交桶列表中所有的桶到Hadoop下进行文件合并，每个reduce中进行至少一个桶内的文件的合并。

具体的，本实施例中使用的桶bucket具有name、content以及size 等属性。name为目录加编号的字符串，编号为目录下桶的顺序编号，name 具有唯一性。content为桶内文件关联对象列表。size为桶中已放入的文件总容量，每向桶中放入一个文件关联对象，就根据放入的文件容量修改 size的值，使用size可以方便的计算桶的空余容量。

如图6所示，使用mapreduce job方式进行文件合并的具体步骤如下：

步骤501：自定义SequenceFile写入。

将已放入文件的桶bucket写入SequenceFile，以方便map reduce的 mapper读取。SequenceFile的key为bucket的name，value为需合并的文件名，例如，bucket1内的contentlist包含的文件为path1,path2和 path3，SequenceFile写入的key/value分别为bucket1/path1, bucket1/path2,bucket1/path3。

步骤502：自定义reduce任务的均衡。

为了更均衡的分配文件合并时使用的reduce资源，map reduce Job 中可以使用Partitioner，尽量使每个reduce任务处理文件桶的容量接近。根据job reduce数量，在每个reduce中较为平均的分配bucket的数量， Partitioner确保组合后的文件桶提交到同一个reduce合并。

步骤503：自定义reduce合并。

reduce的key为桶bucket的name,从name中取出文件路径path； reduce的value为待合并文件名的Iterator。根据Configuration中的 InputFormat以及OutputFormat进行文件的读写，reduce成功后，新写入的文件已经存在目录下，将原有的需合并的文件进行删除。

在步骤502中，为了方便准确的向每个reduce中均衡的分配桶，可以利用步骤201-步骤204同样的思想向各reduce中分配桶，将每一个桶依次放入已放入的桶的总容量最小的reduce分区中，直至所有桶都放入对应的reduce分区中。具体的，如图7所示，可以使用如下步骤自定义Partitioner，对每个reduce分区中的桶进行分配：

步骤601：根据reduce任务数，确定分区桶partition bucket的数量， partitionbucket的数量和任务数相同，每个partition bucket容量不限制，创建partition bucket列表，每个partition bucket对应一个reduce partition。

步骤602：将文件bucket按照放入文件的总容量从大到小排序，放入文件bucket列表中；

步骤603：取出partition bucket列表中的第一个partition bucket，取出文件bucket列表中的第一个文件bucket，将取出的文件bucket放入取出的partition bucket中，作为partition bucket的一个元素；

步骤604：计算取出的partition bucket中已放入的文件bucket的总文件大小，根据总文件大小把取出的partition bucket***partition bucket列表中合适的排序位置，分区bucket按照已放入文件bucket的总文件大小从小到大排序。

步骤605：根据partition bucket列表，生成每一个文件bucket名与 partition编号的对应关系bucketPartitionMap。

步骤606：自定义partitioner中的getPartition方法，根据 bucketPartitionMap确定SequenceFile中获取的key/value对应的 reduce分区。

经过步骤601-步骤606，每个reduce job中需合并的文件数量大致均衡，可以实现reduce任务的均衡。进一步的，在reduce任务均衡的过程中，也可以使用本发明各实施例中与步骤104相关的各种优化方式相同的思想进行具体实施步骤的优化。

在进行文件合并时，若某个桶中仅包含一个文件，则不需进行文件合并，直接将这一个文件作为合并后的大文件。因此，在以map reduce job 方式提交所有的桶到Hadoop下进行文件合并之前，可以先从桶列表中移除仅放入一个需合并的文件的桶，避免影响步骤502的reduce均衡时每个 reduce的任务负荷。如图4中所示合并完成后的文件，桶1中仅包含文件 2，因此桶1不需要进行合并，从桶列表中移除桶1，仅需合并桶2和桶3 中放入的文件，节省了***资源。

经过本实施例中提供的步骤101-步骤105后，即可将每个hive中的大量小文件合并为少量大小较为均衡、且每个文件的容量不超过预设的大文件最大容量的大文件。还可以通过步骤301-步骤304，以及实施例1中提供的各种优化方法简化合并步骤、提高合并效率。进一步的，由于本实施例提供的文件合并方法使用场景为Hadoop，因此可以使用mapreduce过程并行执行文件合并，提高文件合并的效率。

实施例2：

基于实施例1提供的hive文件合并的方法，在不同的具体应用场景中，还可以根据使用需求或实际场景的不同进行补充和调整。

为了提高实施例1步骤304和步骤604中将取出的文件桶和取出的分区桶插回文件桶队列和分区桶队列时的查找速度，可以采用二分查找、插值查找等查找算法提高查找速度。进一步的，在文件桶和分区桶数量较大的情况下，如图4所示，文件桶列表和分区桶列表可以使用B-Tree等数据结构进行存储，通过数据结构的特性减少放入文件关联对象或放入分区桶后再次排序时比较数量，减少将取出的文件桶和分区插回文件桶队列和分区桶队列时耗费的总时间。

为了避免合并文件出错导致数据错误，步骤105之后，删除原需合并的文件之前，可以增加数据校验步骤。若通过校验确认文件合并正确，再对原需合并的文件进行删除；若文件合并不正确，对于该桶内的文件重新获取并重新合并。具体的，如图8所示，增加文件校验后的步骤如下：

步骤701：获取一个hive表的元数据定义的目录下的所有文件作为需合并的文件；

步骤702：按照需合并的文件的总容量大小和预设的大文件最大容量计算合并文件时需要的桶的数量。

步骤703：根据计算所得的桶的数量建立相应数量的桶。

步骤704：将需合并的文件按照每个文件的容量从大到小依次放入空闲容量最大，且放入文件后总容量不超过预设的大文件最大容量的桶中，直至所有文件都放入桶中。

步骤705：将放入每个桶内的文件分别合并为一个大文件。

步骤706：对合并后的大文件进行数据校验，判断大文件是否合并正确，若合并不正确，重新进行合并。

步骤707：若合并正确，删除原有的需合并的文件。

增加校验步骤提高了文件合并的安全性，避免了因合并出错导致的原始数据被破坏。

本实施例提供的优化方法，通过优化文件分配至桶中的过程进一步提高了文件合并的效率，并通过数据校验提高了文件合并的安全性。

实施例3：

在上述实施例1至实施例2提供的hive文件合并的方法的基础上，本发明还提供了一种可用于实现上述方法的hive文件合并的装置，如图9所示，是本发明实施例的装置架构示意图。本实施例的hive文件合并的装置包括一个或多个处理器21以及存储器22。其中，图9中以一个处理器21 为例。

处理器21和存储器22可以通过总线或者其他方式连接，图9中以通过总线连接为例。

存储器22作为一种hive文件合并方法非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如实施例1至实施例2中的hive文件合并方法。处理器21通过运行存储在存储器22中的非易失性软件程序、指令以及模块，从而执行hive文件合并的装置的各种功能应用以及数据处理，即实现实施例1至实施例2的hive 文件合并的方法。

存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器22可选包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

程序指令/模块存储在存储器22中，当被一个或者多个处理器21执行时，执行上述实施例1至实施例2中的hive文件合并的方法，例如，执行以上描述的图1-图8所示的各个步骤。

本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取存储器(RAM，Random AccessMemory)、磁盘或光盘等。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (10)

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

获取一个hive表的元数据定义的目录下的所有文件作为需合并的文件；

按照需合并的文件的总容量大小和预设的大文件最大容量估算合并文件时需要的桶的数量；

根据估算所得的桶的数量建立相应数量的桶；

将需合并的文件按照每个文件的容量从大到小依次放入空闲容量最大，且放入文件后总容量不超过预设的大文件最大容量的桶中，直至所有文件都放入桶中；

将放入每个桶内的文件分别合并为一个大文件。

2.根据权利要求1所述的hive文件合并的方法，其特征在于，所述将需合并的文件按照每个文件的容量从大到小依次放入空闲容量最大的桶中，具体包括：

将需合并的文件按照每个文件的容量从大到小排序，放入文件列表中；

将桶按照空闲容量的大小从大到小排序，放入桶列表中；

取出桶列表中的第一个桶，取出文件列表中的第一个文件，将取出的文件放入取出的桶中；

计算取出的桶的空闲容量，根据空闲容量把取出的桶***桶列表中合适的排序位置，保持桶列表中的桶按照空闲容量的大小从大到小排序。

3.根据权利要求2所述的hive文件合并的方法，其特征在于，所述根据空闲容量把取出的桶***桶列表中合适的排序位置，具体包括：

按照桶列表的顺序，将取出的桶的空闲容量依次和桶列表中每个桶的空闲容量比较；

查找桶列表中最后一个空闲容量大于取出的桶的空闲容量的桶，将取出的桶***查找到的桶之后。

4.根据权利要求1所述的hive文件合并的方法，其特征在于，所述估算合并文件时需要的桶的数量具体包括：

获取需合并的文件的总容量大小；

根据需合并的文件的总容量大小和预设的大文件最大容量估算合并后的大文件的数量，合并文件时需要的桶的数量与合并后的大文件的数量相同。

5.根据权利要求1所述的hive文件合并的方法，其特征在于：所述预设的大文件最大容量大于一个***数据块的容量。

6.根据权利要求1所述的hive文件合并的方法，其特征在于，所述将放入每个桶内的文件分别合并为一个大文件，具体包括：以map reduce job方式提交桶列表中所有的桶到Hadoop下进行文件合并，每个reduce任务中进行至少一个桶内的文件的合并。

7.根据权利要求6所述的hive文件合并的方法，其特征在于，所述每个reduce任务中进行至少一个桶内的文件的合并，具体包括：

将桶列表中的桶按照空闲容量从小到大排序；

取出桶列表中的第一个桶，放入已放入的桶的总容量最小的reduce分区中，直至所有桶都放入对应的reduce分区中。

8.根据权利要求1所述的hive文件合并的方法，其特征在于，所述将放入每个桶内的文件分别合并为一个大文件之前，还包括：移除仅放入一个需合并的文件的桶。

9.根据权利要求1所述的hive文件合并的方法，其特征在于：

所述将放入每个桶内的文件分别合并为一个大文件后，删除原有的需合并的文件。

10.一种hive文件合并的装置，其特征在于：

包括至少一个处理器和存储器，所述至少一个处理器和存储器之间通过数据总线连接，所述存储器存储能被所述至少一个处理器执行的指令，所述指令在被所述处理器执行后，用于完成权利要求1-9任一所述的hive文件合并的方法。

Images