CN109902101A - 基于SparkSQL的透明分区方法及装置 - Google Patents

Abstract

本发明公开了一种基于SparkSQL的透明分区方法及装置，所述方法包括：在建表语句提交后，获取用户在创建分区表时指定分区字段和采用的分区策略，通过SQL解析器确定透明分区并将透明分区信息进行保存；当用户通过SQL查询数据时，通过SQL解析生成逻辑执行计划；根据逻辑执行计划中的查询条件，并结合保存的透明分区信息计算出本次查询的数据分区，然后通过改写逻辑执行计划并生成优化后的物理执行计划；根据生成的物理执行计划的执行步骤划分出具体的任务，通过所述任务从所述数据分区中读取数据。

Description

基于SparkSQL的透明分区方法及装置

技术领域

本发明涉及计算机领域，尤其涉及一种基于SparkSQL的透明分区方法及装置。

背景技术

目前，公知的SparkSQL分区技术是在创建数据表时指定专门的分区字段，数据表映射成HDFS上的一个目录，该表的数据都存放在这个目录下，分区字段数据并不与非分区字段一起存储在HDFS上的数据文件中，而是作为数据表目录的子目录存在于HDFS上。SparkSQL是使用标准的SQL来处理和分析大数据的开源技术，通过创建表来存储结构化数据，使用分区来细化数据存储，将数据划分到不同分区后存储在HDFS上不同的子目录中，子分区名就是子目录名。本专利设计一种基于现有SparkSQL分区的透明分区技术，能将用户SQL中的非分区过滤条件自动转换成分区过滤条件，从而优化SparkSQL的查询速度。

现有的SparkSQL分区技术存在如下的缺陷：

1.无法将非分区过滤条件自动映射成分区过滤条件。使用数据的业务人员在不了解Spark Partition技术，或者知道Spark Partition技术但是不知道自己要查询的数据究竟落在那些分区目录中，这时候业务人员只能通过全表扫描的方式把表中所有的数据都取出来过滤一遍才能准确找到自己需要的数据，每一次用户提交SQL查询分析数据时，不能充分使用数据分区缩小数据的查询范围从而导致查询响应慢，并且当表中数据量过大时容易耗尽系统计算资源。

2.分区格式不一致容易导致数据存储和管理不规范。现有的分区技术只对分区字段类型进行定义，并不会进一步规范分区的具体格式，比如分区字段类型为String,则任何String类型的分区都能作为HDFS上的子目录而存在，混乱的分区格式会严重增加大数据管理成本。

3.不方便过期数据删除。数据的日益增长必将导致历史数据的清除以释放存储空间，传统SparkSQL分区因分区格式不规范会导致后期删除过期数据时经常需要人工干预，而不能很好的定义一套规则来定期删除过期的数据，经常性的人工删除数据会给数据的安全性造成很大影响，甚至可能造成不可挽回的损失。

发明内容

本发明实施例提供一种基于SparkSQL的透明分区方法及装置，用以解决现有技术中的上述问题。

本发明实施例提供一种基于SparkSQL的透明分区方法，包括：

在建表语句提交后，获取用户在创建分区表时指定分区字段和采用的分区策略，通过SQL解析器确定透明分区并将透明分区信息进行保存；

当用户通过SQL查询数据时，通过SQL解析生成逻辑执行计划；

根据逻辑执行计划中的查询条件，并结合保存的透明分区信息计算出本次查询的数据分区，然后通过改写逻辑执行计划并生成优化后的物理执行计划；

根据生成的物理执行计划的执行步骤划分出具体的任务，通过所述任务从所述数据分区中读取数据。

优选地，通过SQL解析器将分区信息保存具体包括：

通过SQL解析器将分区信息保存至Hive Metastore中。

优选地，通过SQL解析生成逻辑执行计划具体包括：

通过SQL解析进行语法检查、语义分析、和逻辑计划优化，生成逻辑执行计划。

优选地，所述分区策略具体包括：

按照时间间隔来划分分区；

直接截取date_field字段value值的前N位作为分区名称；

将data_field按照指定的格式作为分区名称；

将data_field按照hash取模的方式存储到对应的分区中。

优选地，上述方法进一步包括：

在用户写入数据到分区表时，首先根据透明分区策略计算每条数据所在分区，然后将数据写入对应分区中；

将透明分区数据接入的功能嵌入到数据接入组件Flume中，通过Flume根据透明分区策略中关联的字段数据直接计算得出数据所在分区，自动创建透明分区并将接入系统的数据存储在分区目录中。

本发明实施例还提供一种基于SparkSQL的透明分区装置，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现上述方法的步骤。

采用本发明实施例的基于现有SparkSQL分区的透明分区技术，通过解析用户提交的SQL中的非分区过滤条件，并根据提前定义好的规则将非分区过滤条件自动映射成分区过滤条件，从而完成对用户SQL执行计划的优化，极大缩小了需要查询的数据范围，加快了SQL查询速度的同时节省了大数据集群宝贵的计算资源。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1是本发明实施例中SparkSQL透明分区原理图；

图2是本发明实施例中SparkSQL透明分区数据流图；

图3是本发明实施例中通过SparkSQL创建表时定义透明分区示意图。

具体实施方式

如上所述，使用SparkSQL对存储在HDFS上的大数据进行分析时，由于数据量大导致用户提交的应用经常需要很长的时间才能执行完，但用户每次分析的数据很可能只是落在某一个或几个分区内，现有的分区技术无法实现根据用户的非分区过滤条件来定位到数据所在的分区从而快速的减少数据搜索的范围，而使用和分析数据的业务人员不熟悉SparkSQL分区技术或者不知道使用的数据表具体的分区情况时就无法使用分区来缩小数据的搜索范围，从而造成集群计算资源的浪费及非常差的数据查询分析体验。为了克服现有分区技术无法自动转换非分区过滤条件、分区格式不统一、过期数据删除不易各方面的不足，本发明实现了一种基于现有的SparkSQL分区的透明分区技术，该透明分区技术通过解析用户提交的SQL中的非分区过滤条件，并根据提前定义好的规则将非分区过滤条件自动映射成分区过滤条件，从而完成对用户SQL的执行计划的优化，极大的缩小了需要查询的数据范围，加快了SQL查询速度的同时节省了大数据集群宝贵的计算资源；同时在增加新分区时规范分区格式，进而方便过期数据定期的批量删除，减少人工干预，降低数据的安全风险。

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明采用的技术方案如图1所示，具体包括如下处理：

1.用户在创建分区表时指定分区字段和采用的分区策略，建表语句提交后SQL解析器会将分区信息保存至Hive Metastore中。

2.当用户通过SQL查询数据时，通过SQL解析(语法检查、语义分析、逻辑计划优化)生成逻辑执行计划。

3.根据逻辑执行计划中的查询条件，并结合Hive Metastore中分区表的分区信息计算出本次查询的数据所在分区；然后通过改写逻辑执行计划并生成优化后的物理执行计划。通过过滤条件计算数据所在分区的代码片段如下：

4.最后根据生成的物理执行计划的执行步骤划分出具体的Tasks，这些task只会从第3步中锁定的数据分区中读取数据，从而达到只查询数据所在分区，缩小查询范围的目的。

下面结合附图，对本发明实施例进行详细说明。

使用本发明优化查询的详细操作步骤如下，如图2所示：

1.通过SparkSQL创建表时定义透明分区，如图3所示:

透明分区支持4种分区策略，interval(date_field,86400)，precise(date_field,10)，date(date_field,yyyyMMdd)，hash(date_field,10):

1)interval(data_field,86400)按照时间间隔来划分分区，86400代表前后两个分区间隔的时长(单位：秒)，用户可自行定义间隔大小，在HDFS上生成的子分区目录名为date_field字段表示的时间距离1970-01-01 00:00:00的秒数与时间间隔的比值；

2)precise(date_field,10)直接截取date_field字段value值的前10位作为分区名称，比如date_field＝‘2017-10-01 09:00:00’的数据将会存储在2017-10-01这个分区目录中；

3)date(date_field,yyyyMMdd)将data_field按照指定的yyyyMMdd格式作为分区名称；

4)hash(date_field,10)将data_field按照hash取模的方式存储到对应的分区中。

2.用户写入数据到分区表时，首先根据分区策略计算每条数据所在分区，然后将数据写入对应分区中。本发明将透明分区数据接入的功能嵌入到数据接入组件Flume中，Flume会根据透明分区策略中关联的字段数据直接计算得出数据所在分区，自动创建透明分区并将接入系统的数据存储在分区目录中。

3.业务人员使用SparkSQL查询分析数据时，无需知道数据是否分区也不用关心所要查询的数据分布在哪些分区中，只需根据实际情况指定查询过滤条件即可，SparkSQL解析器会自动识别用户设置的Where条件并解析计算出透明分区值后就能够直接定位到数据所在的分区，进一步缩小查询范围，加快SQL查询速度。

综上所述，本发明实施例的有益效果如下：

1.自动检索分区，缩小数据查询范围，极大的提高sparkSQL查询速度；

2.规范数据的管理和存储，数据按照不同分区存储在HDFS的不同目录中；

3.方便后期删除存储系统中过期的数据。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (6)

1.一种基于SparkSQL的透明分区方法，其特征在于，包括：

在建表语句提交后，获取用户在创建分区表时指定分区字段和采用的分区策略，通过SQL解析器确定透明分区并将透明分区信息进行保存；

当用户通过SQL查询数据时，通过SQL解析生成逻辑执行计划；

根据逻辑执行计划中的查询条件，并结合保存的透明分区信息计算出本次查询的数据分区，然后通过改写逻辑执行计划并生成优化后的物理执行计划；

根据生成的物理执行计划的执行步骤划分出具体的任务，通过所述任务从所述数据分区中读取数据。

2.如权利要求1所述的方法，其特征在于，通过SQL解析器将分区信息保存具体包括：

通过SQL解析器将分区信息保存至Hive Metastore中。

3.如权利要求1所述的方法，其特征在于，通过SQL解析生成逻辑执行计划具体包括：

通过SQL解析进行语法检查、语义分析、和逻辑计划优化，生成逻辑执行计划。

4.如权利要求1所述的方法，其特征在于，所述分区策略具体包括：

按照时间间隔来划分分区；

直接截取date_field字段value值的前N位作为分区名称；

将data_field按照指定的格式作为分区名称；

将data_field按照hash取模的方式存储到对应的分区中。

5.如权利要求1所述的方法，其特征在于，所述方法进一步包括：

在用户写入数据到分区表时，首先根据透明分区策略计算每条数据所在分区，然后将数据写入对应分区中；

将透明分区数据接入的功能嵌入到数据接入组件Flume中，通过Flume根据透明分区策略中关联的字段数据直接计算得出数据所在分区，自动创建透明分区并将接入系统的数据存储在分区目录中。

6.一种基于SparkSQL的透明分区装置，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至5中任一项所述方法的步骤。