CN115062028A

CN115062028A - 一种OLTP领域多表join查询的方法

Info

Publication number: CN115062028A
Application number: CN202210890452.6A
Authority: CN
Inventors: 韩雷; 马洋
Original assignee: China State Construction eCommerce Co Ltd
Current assignee: China State Construction eCommerce Co Ltd
Priority date: 2022-07-27
Filing date: 2022-07-27
Publication date: 2022-09-16
Anticipated expiration: 2042-07-27
Also published as: CN115062028B

Abstract

本发明公开了一种OLTP领域多表join查询的方法，属于数据查询技术领域，包括在业务系统中发布宽表生成的配置规则并保存；对Mysql数据库中的Binlog数据进行抓取、转化并写入kafka处理平台中；加载配置规则，从kafka处理平台中获取数据，由flink流处理引擎实时计算并生成宽表数据；将生成的宽表数据存储至服务器中并经搜索引擎提供数据查询。本发明设计科学合理，使用方便，在业务系统进行数据库的增改查的过程中，无需关注宽表的逻辑，仅需宽表生成的配置规则，从kafka处理平台中获取数据，由flink流处理引擎实时计算，借助服务器的海量存储能力，形成业务数据以供查询。

Description

一种OLTP领域多表join查询的方法

技术领域

本发明属于数据查询技术领域，具体涉及一种OLTP领域多表join查询的方法。

背景技术

在传统的OLTP领域，即关系型数据库中，系统需要实现大的列表查询，在需要列表查询时，运行驱动表 join连接多个被驱动表，然后在内存中生成所需的列表数据。如果关联的数据表少、列表的字段少、表中的数据体量不大、QPS（每秒查询率）不高的场景下，这种处理方式还可以支撑。但是在关联的数据表多、表中的数据体量较大的情况下，以此种这种方式支撑的系统查询对于硬件资源要求及系统运维人员的要求就会很高。

虽然在业界，也有很多基于Elasticsearch分布式搜索工具来存储大宽表，但是在OLTP领域里面，对于Elasticsearch的document构建来说，还是基于传统业务代码的硬编码处理。如此，导致宽表生成代码和真正的业务逻辑代码耦合，系统维护成本非常高，并且在难以维系超大数据量，成为所属技术领域技术人员亟待解决的技术问题。

因此，本发明提供了一种OLTP领域多表join查询的方法，以至少解决上述部分技术问题。

发明内容

本发明要解决的技术问题是：提供一种OLTP领域多表join查询的方法，以至少解决上述部分技术问题。

为实现上述目的，本发明采用的技术方案如下：

一种OLTP领域多表join查询的方法，包括以下步骤：

步骤S1、在业务系统中发布宽表生成的配置规则并保存；

步骤S2、对Mysql数据库中的Binlog数据进行抓取、转化并写入kafka处理平台中；

步骤S3、加载配置规则，从kafka处理平台中获取Binlog数据，由flink流处理引擎实时计算并生成宽表数据；

步骤S4、将生成的宽表数据存储至服务器中并经搜索引擎提供数据查询。

进一步地，所述步骤S2中，将抓取的binlog数据转化为json格式并写入kafka处理平台中。

进一步地，所述步骤S1中，配置规则包括驱动表的存储结构和被驱动表的存储结构，驱动表的存储结构包括宽表名称、宽表中各驱动表、驱动表对应的关联键、驱动表需要查询的字段以及join引起的数据延迟时间，被驱动表的存储结构包括宽表名称、宽表中各被驱动表、被驱动表对应的关联键以及被驱动表需要查询的字段。

进一步地，所述步骤S2中，一个Mysql数据库的数据表对应kafka处理平台的一个数据流集合，并建立Mysql数据库的数据表和数据流集合的映射关系。

进一步地，所述步骤S3具体包括：步骤S31、由配置规则解析出Binlog数据对应的驱动表和被驱动表，根据映射关系在flink流处理引擎中生成数据源，由数据源形成多个数据流；步骤S32、由配置规则中的关联键将数据流依次连接形成一个链式的join流程，形成多流join的逻辑计划，由flink流处理引擎将逻辑计划转化为物理执行计划；步骤S33、通过自定义数据Sink，将物理执行计划生成的数据写入搜索服务器中以供数据查询。

进一步地，所述一个链式的join流程的形成方法具体包括：步骤S321，将输入的驱动表的数据流与第一个被驱动表的数据流关联形成连接流，再通过关联键进行hash分区，将数据流中基于相同关联键的数据分发至数据流集合的同一个patition中；步骤S322、采用延迟关联技术处理所述驱动表和被驱动表的数据，处理驱动表的数据时将驱动表和与驱动表相关联的被驱动表数据同时存放至flink流处理引擎的存储后端中，然后在驱动表的数据上注册一个定时器，当定时器触发时对驱动表的数据流和被驱动表的数据流关联并将关联好的连接流数据发送至下游；步骤S323、所述关联好的连接流继续关联被驱动表的数据直至关联至最后一个被驱动表，最终形成一个大宽表的逻辑构建。

进一步地，所述存储后端为RocksDB存储引擎。

进一步地，所述搜索引擎为Elasticsearch搜索引擎。

与现有技术相比，本发明具有以下有益效果：

本发明设计科学合理，使用方便，解决了现有宽表生成代码易与业务逻辑代码耦合、系统维护成本高、以及其维系数据量大的技术问题。业务系统在进行数据库的增删改差的过程中，无需关注宽表的逻辑，仅需宽表生成的配置规则，从kafka处理平台中获取数据，由flink流处理引擎实时计算，借助服务器的海量存储能力，形成业务数据以供查询。本发明基于配置规则，用于清晰管理数据源与宽表的逻辑关系；基于flink流处理引擎天然的流式计算能力，具有较高的系统吞吐量，实现任务的横向扩展能力，提高整个系统的数据处理能力；借助服务器的海量分布式存储能力完成数据表全生命周期的数据存储业务；借助搜索引擎的全文索引能力，实现对宽表任意字段搜索，具有多维度的查询能力，避免了业务系统对查询维度的限制。

附图说明

图1为本发明方法流程图。

图2为本发明实施例中的一个驱动表的存储结构示意图。

图3为本发明实施例中的一个被驱动表的存储结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图，对本发明进一步详细说明。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

术语解释：

OLTP为On-Line Transaction Processing，表示联机事务处理过程；

Join为程序语言，表示字符串，该字符串由包含在数组中的许多子字符串联接创建；

MySQL为一种关系型数据库管理系统；

Binlog为二进制日志；

flink为一种开源流处理框架；

Kafka为一种开源流处理平台；

kafka-connector为一种流式传输数据的框架；

debezium为一种捕获数据更改的平台；

JSON为JavaScript Object Notation，为一种轻量级的数据交换格式；

RichSinkFunction为flink框架中的一种抽象的数据输出函数;

Elasticsearch为一个搜索服务器；

hash为散列函数；

partition为一种计算机编程函数；

RocksDB 是一种可嵌入式的支持持久化的存储系统；

document为计算机术语，每一个载入浏览器的超文本标记语言文档都会成为document 对象。

如图1所示，本发明提供的一种OLTP领域多表join查询的方法，包括以下步骤：

步骤S1、在业务系统中发布宽表生成的配置规则并保存；

所述步骤S1中，配置规则包括驱动表的存储结构和被驱动表的存储结构，驱动表的存储结构包括宽表名称、宽表中各驱动表、驱动表对应的关联键、驱动表需要查询的字段以及join引起的数据延迟时间，被驱动表的存储结构包括宽表名称、宽表中各被驱动表、被驱动表对应的关联键以及被驱动表需要查询的字段。

实施例中的一个驱动表的存储结构如图2所示，实施例中的一个被驱动表的存储结构如图3所示。

所述步骤S2中，采用抓取工具kafka-connector和debezium对Mysql数据库中的Binlog数据抓取，所述抓取方法为现有技术，故此不做赘述。然后将抓取的binlog数据转化为json格式并写入kafka处理平台中。特别地，一个Mysql数据库的数据表对应kafka处理平台的一个数据流集合，并建立Mysql数据库的数据表和数据流集合的映射关系，即一个Mysql数据库的数据表和kafka处理平台的一个数据流集合一一对应。其中，Mysql数据库的数据表包括驱动表和被驱动表。

所述步骤S3具体包括：步骤S31、由配置规则解析出对应的驱动表和被驱动表，根据映射关系在flink流处理引擎中生成数据源，进一步形成数据流；步骤S32、由配置规则中的关联键将数据流依次连接形成一个链式的join流程，形成多流join的逻辑计划，再由flink流处理引擎转化为物理执行计划；步骤S33、由配置规则通过继承RichSinkFunction实现自定义数据sink，通过自定义数据Sink，将物理执行计划生成的数据写入搜索服务器中以供数据查询。所述搜索引擎为Elasticsearch搜索引擎，Elasticsearch搜索引擎具有全文索引能力和多维度的查询能力，可实现对宽表的任意字段搜索，避免业务系统对查询维度的限制。

所述一个链式的join流程的形成方法具体包括：步骤S321，将输入的驱动表的数据流与第一个被驱动表的数据流关联形成连接流，再通过关联键进行hash分区，将数据流中基于相同关联键的数据分发至数据流集合的同一个patition中；步骤S322、采用延迟关联技术处理所述驱动表和被驱动表的数据，处理驱动表的数据时将驱动表和与驱动表相关联的被驱动表数据同时存放至flink流处理引擎的存储后端中，然后在驱动表的数据上注册一个定时器，当定时器触发时对驱动表的数据流和被驱动表的数据流关联并将关联好的连接流数据发送至下游；步骤S323、所述关联好的连接流继续关联被驱动表的数据直至关联至最后一个被驱动表，最终形成一个大宽表的逻辑构建。其中，所述定时器为系统自有功能，定时器触发的时间间隔根据不同业务场景不同而动态配置。所述存储后端为RocksDB存储引擎，具有海量分布式存储能力，可实现数据表全生命周期的数据存储业务。

最后应说明的是：以上各实施例仅仅为本发明的较优实施例用以说明本发明的技术方案，而非对其限制，当然更不是限制本发明的专利范围；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围；也就是说，但凡在本发明的主体设计思想和精神上作出的毫无实质意义的改动或润色，其所解决的技术问题仍然与本发明一致的，均应当包含在本发明的保护范围之内；另外，将本发明的技术方案直接或间接的运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims

1.一种OLTP领域多表join查询的方法，其特征在于，包括以下步骤：

步骤S1、在业务系统中发布宽表生成的配置规则并保存；

2.根据权利要求1所述的一种OLTP领域多表join查询的方法，其特征在于，所述步骤S2中，将抓取的binlog数据转化为json格式并写入kafka处理平台中。

3.根据权利要求1所述的一种OLTP领域多表join查询的方法，其特征在于，所述步骤S1中，配置规则包括驱动表的存储结构和被驱动表的存储结构，驱动表的存储结构包括宽表名称、宽表中各驱动表、驱动表对应的关联键、驱动表需要查询的字段以及join引起的数据延迟时间，被驱动表的存储结构包括宽表名称、宽表中各被驱动表、被驱动表对应的关联键以及被驱动表需要查询的字段。

4.根据权利要求3所述的一种OLTP领域多表join查询的方法，其特征在于，所述步骤S2中，一个Mysql数据库的数据表对应kafka处理平台的一个数据流集合，并建立Mysql数据库的数据表和数据流集合的映射关系。

5.根据权利要求4所述的一种OLTP领域多表join查询的方法，其特征在于，所述步骤S3具体包括：步骤S31、由配置规则解析出Binlog数据对应的驱动表和被驱动表，根据映射关系在flink流处理引擎中生成数据源，由数据源形成多个数据流；步骤S32、由配置规则中的关联键将数据流依次连接形成一个链式的join流程，形成多流join的逻辑计划，由flink流处理引擎将逻辑计划转化为物理执行计划；步骤S33、通过自定义数据Sink，将物理执行计划生成的数据写入搜索服务器中以供数据查询。

6.根据权利要求5所述的一种OLTP领域多表join查询的方法，其特征在于，所述一个链式的join流程的形成方法具体包括：步骤S321，将输入的驱动表的数据流与第一个被驱动表的数据流关联形成连接流，再通过关联键进行hash分区，将数据流中基于相同关联键的数据分发至数据流集合的同一个patition中；步骤S322、采用延迟关联技术处理所述驱动表和被驱动表的数据，处理驱动表的数据时将驱动表和与驱动表相关联的被驱动表数据同时存放至flink流处理引擎的存储后端中，然后在驱动表的数据上注册一个定时器，当定时器触发时对驱动表的数据流和被驱动表的数据流关联并将关联好的连接流数据发送至下游；步骤S323、所述关联好的连接流继续关联被驱动表的数据直至关联至最后一个被驱动表，最终形成一个大宽表的逻辑构建。

7.根据权利要求6所述的一种OLTP领域多表join查询的方法，其特征在于，所述存储后端为RocksDB存储引擎。

8.根据权利要求1所述的一种OLTP领域多表join查询的方法，其特征在于，所述搜索引擎为Elasticsearch搜索引擎。