[发明专利]Hive文件处理方法及装置、计算机设备与存储介质

说明书

本发明公开了一种Hive文件处理方法及装置、计算机设备与存储介质，方法包括：获取目标分区，目标分区包括文件数量大于第一设定值且存在文件大小未达到第二设定值的待合并文件的分区；对目标分区的待合并文件进行合并处理，并对进行合并处理中的目标分区添加合并锁以禁止对目标分区进行读取操作。应用本发明方案，在流式数据接入场景下，通过扫描并合并Hive小文件，减小NameNode内存压力，从而加快Hive查询速度，在Hive进行文件合并的替换文件阶段，给正在合并的数据加锁，不允许此时查询这些数据，避免了此时查询数据不准确的问题，并且，合并锁仅仅限制数据的读取，并不限定数据的写入，能够适应于流式数据接入的场景。

技术领域

本发明涉及Hadoop数据仓储技术领域，尤其涉及一种Hive文件处理方法及装置、计算机设备与存储介质。

背景技术

在当前数据爆炸的时代，数据量的累积与增长超出了一般单机运行的数据库所能承受的极限，在这种情况下基于分布式计算的大数据应运而生。现如今较为流行的大数据解决方案通常基于Hadoop生态圈，分布式文件系统HDFS实现了文件的分布式存储，而数据仓储工具Hive可以将HDFS中存储的结构化数据抽象成一张表，并保存文件路径和表元信息的对应关系，并利用计算框架做到HDFS文件的分布式并行读取计算到达Hive表查询的效果。

然而，HDFS存在一个比较致命的缺点：无法存储大量的小文件。HDFS将文件按照固定大小(一般为64m或128m)将数据切割成Block块，同一个文件的不同Block块分布在不同的主机上，从而实现分布式存储。并且，HDFS使用一台主机NameNode来保存每个文件和块的对应关系以及块到主机的对应关系，高读写文件的响应速度，这些信息都被保存在NameNode的内存中。可见，NameNode的内存成为限制HDFS存储上限的瓶颈，而解决办法是：要突破瓶颈要么增大NameNode的内存，要么减少Block块的数量。很显然，主机的内存是不能无限提高的，因此，只能减少Block块的数量。举例而言，假设存在总大小为256M的n个文件。假如按照128M切分，那么会有两个Block块产生；但是，如果文件数量为256个，总共产生的Block块的数量就是256个，要使用的内存就是前面的128倍。在上述场景下，虽然总数据量大小相同，但是文件所占用的内存却是天差地别。而对于Hive而言，同一张表指向的结构化数据文件都是相同结构的，这些文件是可以被合并的。因此，通过将Hive的小文件合并到一起，便可以减少NameNode的内存压力。

现有技术提供了如下的Hive文件合并方法，基于文件分桶的方式将合并前文件大小和达到分割上限的多个文件划分成一个桶，以桶为单位来进行文件的合并。而该方案的缺点是：使用合并前的文件大小预估合并后的文件大小，这样是不准确的。例如，由于列式存储的压缩性，可能导致合并后的文件依然比较小。而且以整个表的文件为基础不适用分区表的文件合并，因为分区表的文件是不能跨分区合并的。

现有技术还提供了如下Hive文件结合方式，基于Hive的分区为单位，基于合并效果优先级来对分区的合并任务进行排序，然后执行合并任务。然而该方案不是在流式数据接入的场景下进行的，由于Hive的文件接入速度和查询频率都很高，因而在文件合并后期的文件替换阶段会影响到数据查询的准确性的，也就是替换时查询结果是不准确的，这对上层的数据使用是致命的。

大数据场景下的数据计算按照实时性可以被分为批处理和流处理，所谓批处理可以理解为数据按照一定时间间隔(如天、周、月)对一批数据进行处理，而流处理需要更高的时效性，基本上数据要在短时间内(如分钟)就被处理。数据接入也是数据处理的一种，也因此，Hive并不太适合于直接应用于流式数据接入，因为高时效性意味着更频繁的查询与计算，数据每来一条都要被写成文件存入HDFS供Hive查询，而不能等待一段时间，将多条数据批量写入一个文件中。所以在Hive用于流式数据接入，对小文件的处理将至关重要。然而，流式数据场景下，Hive的小文件过多，会导致NameNode的内存不足，影响集群的正常运转速度以及Hive的查询速度。

因此，有必要提出一种改进的可应用于流式数据的Hive文件处理方案。