CN115470217A

CN115470217A - 一种实时解决数仓模型变化响应问题的方法

Info

Publication number: CN115470217A
Application number: CN202211417468.1A
Authority: CN
Inventors: 于鹏
Original assignee: Yunzhu Information Technology Chengdu Co ltd
Current assignee: Yunzhu Information Technology Chengdu Co ltd
Priority date: 2022-11-14
Filing date: 2022-11-14
Publication date: 2022-12-13
Anticipated expiration: 2042-11-14
Also published as: CN115470217B

Abstract

本发明公开了一种实时解决数仓模型变化响应问题的方法，属于大数据技术领域，包括获取数仓模型的所有元数据表信息，创建与每个元数据表信息对应的Hive数据表；监听元数据表的二进制日志，生成监听数据并发送至Kafka，通过流处理引擎实时消费Kafka的数据并写入至对应的Hive数据表中；查询任务定义表获取Hive模型的SQL语句并解析；基于其它Hive模型更新Hive模型的SQL语句；由步骤2中写入Kafka数据的Hive数据表创建拉链表，并基于监听数据更新拉链表；对所述其它Hive模型，提供所述其它Hive模型的变更通知信息。本发明解决数仓模型历史变更无法追溯问题。

Description

一种实时解决数仓模型变化响应问题的方法

技术领域

本发明属于大数据技术领域，具体涉及一种实时解决数仓模型变化响应问题的方法。

背景技术

现在很多企业都在进行数字化转型，进行数据仓库或者数据中台建设，其中最主要的就是etl过程。通俗讲etl就是通过大数据技术，从业务系统获取数据然后存储到分布式存储系统中，再在此基础上建设数仓。

大数据数仓领域常用建模方式是基于Hive的维度分层建模，整个数仓依次会分成原始数据层（ODS，Operation Data Store）、明细数据层（DWD，Data Warehouse Detail）、数据汇总层（DWS，Data Warehouse Summary）和数据应用层（ADS，Application Data Store）。后一层的模型会依赖前面层的模型，所以每当前面业务数据库发生变更或者某一层Hive表的优化变更时，对于该表后续依赖的表同时发生变更。随着时间的推移和业务的发展，整个数仓模型会持续增加并且模型之间的依赖也会很复杂，所以每次Hive表的变更都需要人工去调整，不仅耗时费力，并且人为还可能出现漏改的情况，严重情况下就会导致整个数仓模型不可用。除此之外，数仓的最后一层数据应用层一般提供下游使用系统（如：OLAP、推荐、搜索系统等）使用，所以数据应用层的变更还可能会对其他使用系统造成影响，成为所属技术领域技术人员亟待解决的技术问题。

因此，本发明提供了一种实时解决数仓模型变化响应问题的方法，以至少解决上述部分技术问题。

发明内容

本发明要解决的技术问题是：提供一种实时解决数仓模型变化响应问题的方法，以至少解决上述部分技术问题。

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

一种实时解决数仓模型变化响应问题的方法，包括以下步骤：

步骤1、获取数仓模型的所有元数据表信息，创建与每个元数据表信息对应的Hive数据表；

步骤2、监听元数据表的二进制日志，生成监听数据并发送至Kafka，通过流处理引擎实时消费Kafka的数据并写入至对应的Hive数据表中；

步骤3、通过任务调度平台获取系统后台数据库，查询任务定义表获取Hive模型的SQL语句，然后解析出Hive模型的SQL语句中包含的该Hive模型以外的其它Hive模型；当所述其它Hive模型发生变更时，更新Hive模型的SQL语句；

步骤4、基于步骤2中写入Kafka数据的Hive数据表创建拉链表，并基于监听数据更新拉链表；

步骤5、对所述其它Hive模型，提供所述其它Hive模型的变更通知信息。

进一步地，所述元数据表信息包括但不限于存储元数据表的数据库信息、存储元数据表的名称信息、存储元数据表的格式信息、存储元数据表的字段信息、存储元数据表的分区信息、存储元数据表的批注信息。

进一步地，所述Hive数据表的创建方法为：获取对应元数据表信息的所有字段，并获取每一个字段对应的说明和实例数据；在元数据表信息的所有字段中添加变更时间字段和变更类型字段，获取对应的变更时间数据和变更类型数据并写入，得到Hive数据表。

进一步地，所述步骤3中，任务调度平台在设计调度任务时，每个Hive模型设置一个加工节点任务，将加工节点任务中Hive模型的SQL语句保存于任务定义表的字段中。

进一步地，所述步骤3中，解析采用python库中的程序。

进一步地，所述步骤3中，在python库中输入SQL语言，python库输出与Hive模型以及Hive模型中包含的该Hive模型以外的其它Hive模型。

进一步地，所述步骤4包括：将写入Kafka数据的Hive数据表增加生效时间字段和失效时间字段并创建拉链表，然后将Hive数据表对应的元数据表信息写入对应的拉链表中并初始化，最后基于监听数据每日更新拉链表。

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

本发明利用大数据实时处理技术，监控数仓模型的变更信息，在开源的SQL解析基础上，自动调整数仓模型加工的能力，并创建拉链表以获取数仓模型数据的变更信息，解决数仓模型历史变更无法追溯问题。

附图说明

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

具体实施方式

技术名词：

Maxwell ：实时读取 MySQL二进制日志binlog，并生成 JSON 格式的消息，作为生产者发送给Kafka、Kinesis、RabbitMQ、Redis、Google CloudPub/Sub、文件或其它平台的应用程序。

Binlog：二进制日志；

Kafka：分布式发布订阅消息系统；

Struct Streaming：流处理引擎；

DolphinScheduler：分布式去中心化、易扩展的可视化DAG工作流任务调度系统。

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图，对本发明进一步详细说明。

如图1所示，本发明提供的一种实时解决数仓模型变化响应问题的方法，包括以下步骤：

所述步骤1中，元数据表信息包括但不限于存储元数据表的数据库信息（DBS）、存储元数据表的名称信息（TBLS）、存储元数据表的格式信息（SDS）、存储元数据表的字段信息（COLUMNS_V2）、存储元数据表的分区信息（PARTITION_KEYS）、存储元数据表的批注信息（TABLE_PARAMS）。表1为存储元数据表的数据库信息（DBS）。

表1

所述步骤1中，Hive数据表的创建方法为：获取对应元数据表信息的所有字段，并获取每一个字段对应的说明和实例数据；在元数据表信息的所有字段中添加变更时间字段和变更类型字段，获取对应的变更时间数据和变更类型数据并写入，得到Hive数据表。表2为存储元数据表的数据库信息（DBS）对应的Hive数据表。

表2

所述步骤2，作为优选，采用Maxwell监听元数据表的二进制日志（binlog），生成监听数据并发送至Kafka，所述二进制日志实时记录了元数据表的变化信息；然后通过流处理引擎（Struct Streaming）将监听数据发送至Kafka并写入至对应的Hive数据表中。

所述步骤3，通过链接任务调度平台（dolphinscheduler）调度系统后台数据库，查询任务定义表（t_ds_process_definition）获取Hive模型的SQL语句，所述SQL语句包含了对应Hive模型的加工逻辑，Hive模型是指数仓业务上的Hive模型，Hive模型的获取是现有方法。任务调度平台在设计调度任务时，每个Hive模型设置一个加工节点任务，将加工节点任务中Hive模型的SQL语句保存于任务定义表的字段中。然后采用python库中的程序解析Hive模型的SQL语句：在python库中输入SQL语言，python库输出与Hive模型以及Hive模型中包含的该Hive模型以外的其它Hive模型。并且，当所述其它Hive模型发生变更时，更新Hive模型的SQL语句，由此实现数仓模型加工的自动调整。采用所述自动调整，当一层Hive模型发生变化时，后续相关联的Hive模型即可自动更新，无需人工调整。例如：test_a 的Hive模型的SQL语句为：

Insert overwrite table test_a

Select a.id,b.name

from test_b as a

left join test_c as b

on a.id=b.id

解析结果为：test_a 模型，依赖test_b 模型的id字段，依赖test_c 模型的id和name字段。

当test_b 模型字段id的字段名称变更为idt时，test_a 的Hive模型的SQL语句更新为：

Insert overwrite table test_a

Select a.idt,b.name

from test_b as a

left join test_c as b

on a.idt=b.id

所述步骤4包括：将写入Kafka数据的Hive数据表增加生效时间字段和失效时间字段并创建拉链表，然后将Hive数据表对应的元数据表信息写入对应的拉链表中并初始化，最后基于监听数据每日更新拉链表。所述拉链表可保留每次变化的记录，解决数仓本身无法保留模型变化信息问题。拉链表每日更新时间优选每日凌晨零时。表3为存储元数据表的数据库信息（DBS）对应的拉链表。

表3

所述步骤5中，对所述其它Hive模型，提供所述其它Hive模型的变更通知信息。为此对下游业务中使用的其它Hive模型，可与Hive模型一样，记录模型的变化信息。

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

Claims

1.一种实时解决数仓模型变化响应问题的方法，其特征在于，包括以下步骤：

2.根据权利要求1所述的一种实时解决数仓模型变化响应问题的方法，其特征在于，所述元数据表信息包括但不限于存储元数据表的数据库信息、存储元数据表的名称信息、存储元数据表的格式信息、存储元数据表的字段信息、存储元数据表的分区信息、存储元数据表的批注信息。

3.根据权利要求1所述的一种实时解决数仓模型变化响应问题的方法，其特征在于，所述Hive数据表的创建方法为：获取对应元数据表信息的所有字段，并获取每一个字段对应的说明和实例数据；在元数据表信息的所有字段中添加变更时间字段和变更类型字段，获取对应的变更时间数据和变更类型数据并写入，得到Hive数据表。

4.根据权利要求1所述的一种实时解决数仓模型变化响应问题的方法，其特征在于，所述步骤3中，任务调度平台在设计调度任务时，每个Hive模型设置一个加工节点任务，将加工节点任务中Hive模型的SQL语句保存于任务定义表的字段中。

5.根据权利要求1所述的一种实时解决数仓模型变化响应问题的方法，其特征在于，所述步骤3中，解析采用python库中的程序。

6.根据权利要求5所述的一种实时解决数仓模型变化响应问题的方法，其特征在于，所述步骤3中，在python库中输入SQL语言，python库输出与Hive模型以及Hive模型中包含的该Hive模型以外的其它Hive模型。

7.根据权利要求1所述的一种实时解决数仓模型变化响应问题的方法，其特征在于，所述步骤4包括：将写入Kafka数据的Hive数据表增加生效时间字段和失效时间字段并创建拉链表，然后将Hive数据表对应的元数据表信息写入对应的拉链表中并初始化，最后基于监听数据每日更新拉链表。