CN116821098A - 数据仓库管理方法、服务系统和存储介质 - Google Patents

Abstract

本申请提供一种数据仓库管理方法、服务系统和存储介质，响应于数据仓库写入日志记录，基于预设同步策略获取对应所述日志记录的同步记录；对所述同步记录进行筛选，获取目标语句；分析所述目标语句，获取所述目标语句中的血缘数据元素；根据所述血缘数据元素，基于预设血缘分析策略，获取所述血缘数据元素的血缘关系；根据所述血缘关系，更新所述数据仓库的血缘数据。本申请基于预设同步策略获取目标语句，提取血缘数据元素分析血缘关系，无需在数据仓库节点上增加额外的服务，处理架构简单有效，降低了系统部署成本，能够支持复杂的数据仓库系统，有效保障了血缘关系处理的准确度和及时性。

Description

数据仓库管理方法、服务系统和存储介质

技术领域

本申请涉及数据库技术领域，具体涉及一种数据仓库管理方法、服务系统和存储介质。

背景技术

在数据库的运行过程中，历史数据使用频率过低，堆积在业务数据库中，会导致查询性能下降。因此需要建立数据仓库以将数据给统一管理起来。数据仓库，英文名称为DataWarehouse，可简写为DW或DWH。数据仓库顾名思义，是一个很大的数据存储集合，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

数据仓库将各个异构的数据源数据库的数据给统一管理起来，并且完成了质量较差的数据的剔除、格式转换，最终按照一种合理的建模方式来完成源数据组织形式的转变，以更好的支持到前端的可视化分析。数据仓库的输入方式是各种各样的数据源，最终的输出用于企业的数据分析、数据挖掘、数据报表等方向。数据仓库血缘关系是指数据仓库中数据元素之间的关系。这些关系可以用来追踪数据元素的来源、变换、存储和使用，以及它们之间的依赖关系。血缘关系可帮助用户了解数据元素的相关信息，从而更好地理解数据仓库中的数据。数据仓库血缘关系通常是在数据仓库建模和设计阶段定义的。在建模阶段，数据仓库开发人员会确定数据元素之间的关系，并在数据仓库架构图中进行记录。

申请人在构思和形成本申请的过程中，至少发现以下技术问题：目前，针对表或者字段的血缘关系的处理包括传统的人工方式和系统方式。传统的人工处理的方式，需要人工拿到代码来逐级分析代码，检查代码语意，然后通过手动维护每一层的关系做到维护血缘关系，费时费力，无法确保准确度。而系统方式往往耦合程度过高，部署成本太大。系统架构复杂，对已有系统耦合过高，需要在已有数据仓库上的节点增加额外的服务获取血缘关系，无法支持复杂的数据仓库系统。

发明内容

为了缓解以上问题，本申请提供一种数据仓库管理方法，包括：

响应于数据仓库写入日志记录，基于预设同步策略获取对应所述日志记录的同步记录；

对所述同步记录进行筛选，获取目标语句；

分析所述目标语句，获取所述目标语句中的血缘数据元素；

根据所述血缘数据元素，基于预设血缘分析策略，获取所述血缘数据元素的血缘关系；

根据所述血缘关系，更新所述数据仓库的血缘数据。

可选地，所述基于预设同步策略获取对应所述日志记录的同步记录的步骤包括以下至少一项：

通过IO线程向所述数据仓库请求所述日志记录；

接收源数据库的触发器发送的数据变化信息；

基于数据库中间件同步所述日志记录；

基于消息队列部署，通过消息队列传递源数据库的数据变化信息。

可选地，所述对所述同步记录进行筛选，获取目标语句的步骤包括：

按照预设筛选策略，匹配所述同步记录中的血缘语句为所述目标语句，并写入待处理队列。

可选地，所述分析所述目标语句，获取所述目标语句中的血缘数据元素的步骤包括：

对所述目标语句进行数据分析，获取所述数据分析过程中的SQL语句；

使用语法分析模型对所述SQL语句进行语法分析。

可选地，所述使用语法分析模型对所述SQL语句进行语法分析的步骤包括：

对所述SQL语句进行拆解分词，生成目标序列；

基于所述目标序列进行语法分析，生成目标语法树。

可选地，所述根据所述血缘数据元素，基于预设血缘分析策略，获取所述血缘数据元素的血缘关系的步骤包括：

基于所述目标语法树，确定所述目标语句中血缘数据元素的上下游关系；

根据所述上下游关系，构建所述血缘数据元素的血缘关系。

可选地，所述血缘关系包括表级血缘关系，所述血缘数据元素包括目标表，所述目标语句包括create语句和insert语句；所述根据所述上下游关系，构建所述血缘数据元素的血缘关系的过程中，通过分析所述create语句和所述insert语句，确定所述目标表的上下游关系；和/或，

所述血缘关系包括字段级血缘关系，所述血缘关系元素包括字段名，所述目标语句包括select语句；所述根据所述上下游关系，构建所述血缘数据元素的血缘关系的过程中，通过分析所述select语句，并结合所述数据仓库的系统设置，确定所述字段名对应的目标字段的上下游关系。

可选地，所述根据所述血缘关系，更新所述数据仓库的血缘数据的过程中，将所述上下游关系在当前存储的血缘关系库中进行检索对比；

所述数据仓库管理方法还包括以下至少一项：

如果所述上下游关系的关系数据已存在则直接跳过；

如果所述上下游关系发生变化，则更新所述上下游关系的关系数据；

如果未检索到所述上下游关系的关系数据，则新建所述上下游关系的关系数据。

本申请还提供一种服务系统，所述服务系统包括处理器和存储器；

所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时实现如上述的数据仓库管理方法的步骤。

本申请还提供一种存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述的数据仓库管理方法的步骤。

如上所述，本申请提供的数据仓库管理方法、服务系统和存储介质，基于预设同步策略获取目标语句，提取血缘数据元素分析血缘关系，无需在数据仓库节点上增加额外的服务，处理架构简单有效，降低了系统部署成本，能够支持复杂的数据仓库系统，有效保障了血缘关系处理的准确度和及时性。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。为了更清楚地说明本申请实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请一实施例的数据仓库管理方法流程图。

图2为本申请一实施例的服务系统架构示意图。

图3为本申请的服务系统工作流程图。

图4为本申请一实施例的表级血缘关系示意图。

图5为本申请一实施例的字段级血缘关系示意图。

图6为本申请一实施例的服务系统方框图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素，此外，本申请不同实施例中具有同样命名的部件、特征、要素可能具有相同含义，也可能具有不同含义，其具体含义需以其在该具体实施例中的解释或者进一步结合该具体实施例中上下文进行确定。

应该理解的是，虽然本申请实施例中的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

需要说明的是，在本文中，采用了诸如S10、S20等步骤代号，其目的是为了更清楚简要地表述相应内容，不构成顺序上的实质性限制，本领域技术人员在具体实施时，可能会先执行S20后执行S10等，但这些均应在本申请的保护范围之内。

应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

以下结合各个附图对本申请提出的内容进行详细的说明。

第一实施例

本申请首先提供一种数据仓库管理方法，图1为本申请一实施例的数据仓库管理方法流程图。

请参考图1，在一实施例中，数据仓库管理方法包括：

S10：响应于数据仓库写入日志记录，基于预设同步策略获取对应所述日志记录的同步记录。

数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。系统日志是记录系统中硬件、软件和系统问题的信息，同时还可以监视系统中发生的事件。除了发现错误，日志在数据复制、数据恢复、操作审计，以及确保数据的永久性和一致性等方面有着不可替代的作用。通过日志同步获取同步记录的方式，为系统构建旁路式的血缘分析模块，避免影响数据仓库的运行，简化系统架构，降低了系统部署成本，能够支持复杂的数据仓库系统，从而提高系统运行的安全性和可扩展性。

MySQL的Binlog是二进制格式的日志文件。Binlog是用来记录MySQL内部对数据库的改动(只记录对数据的修改操作)，主要用于数据库的主从复制以及增量恢复。示例性地，Binlog是作为MySQL操作记录归档的日志，这个日志记录了所有对数据库的数据、表结构、索引更的操作。也就是说只要是对数据库有变更的操作都会记录到Binlog里面来。在MySQL里我们就是通过Binlog来归档、验证、恢复、同步数据。可选地，MySQL日志同步的底层实现方式是基于二进制日志(Binlog)的。当数据仓库的数据发生变更时，MySQL会将对应的变更记录写入到二进制日志中，从而触发同步操作。通过IO线程不断向数据仓库请求二进制日志，并将二进制日志中的变更记录写入到重做的日志同步记录中，从而实现日志同步，获取同步记录。

S20：对所述同步记录进行筛选，获取目标语句。

目标语句是进行血缘关系分析所涉及的数据库描述语句。示例性地，收到Binlog的同步信息后，程序解析后进行基础的筛选，只将create、alter、drop、insert这些语句写入待处理的队列中。

S30：分析所述目标语句，获取所述目标语句中的血缘数据元素。

示例性地，目标语句中包含了操作相关的血缘数据元素。而数据仓库的血缘关系可以是依赖这些血缘数据元素之间的关系限定而确定的。

S40：根据所述血缘数据元素，基于预设血缘分析策略，获取所述血缘数据元素的血缘关系。

不同的血缘数据元素可以对应不同的血缘分析策略。示例性地，数据仓库的血缘关系包括系统级的血缘关系、表级血缘关系以及字段级血缘关系。对数据仓库进行血缘关系的分析过程中，可能涉及不同层级的血缘关系，从而对应不同的血缘数据元素。

S50：根据所述血缘关系，更新所述数据仓库的血缘数据。

示例性地，通过对同步记录中目标语句的血缘数据元素的关系分析，获取了不同层级的血缘关系，可以写入数据仓库进行存储，以供后续调用。

本实施例通过预设同步策略获取目标语句，提取血缘数据元素分析血缘关系，无需在数据仓库节点上增加额外的服务，处理架构简单有效，降低了系统部署成本，能够支持复杂的数据仓库系统，有效保障了血缘关系处理的准确度和及时性。

可选地，所述基于预设同步策略获取对应所述日志记录的同步记录的步骤可以包括：

通过IO线程向所述数据仓库请求所述日志记录。

MySQLreplication：是一个开源的MySQL复制library，可以实现MySQLBinlog的同步。对于旁路式的实现核心采用的是MySQL-Binlog的方式。由于MySQL-Binlog可以将所有执行的SQL语句自动同步到相应从库上，所以本申请也可以模拟了从库Binlog同步的实现，技术上采用了MySQL的replication库。使用前首先需要在数据计算的MySQL上打开Binlog，这里只需要修改配置即可。

示例性地，如果数据仓库配置了MySQL主从同步，SQL语句会立即通过Binlog自动进行同步到MySQL从库，也就是当前系统里。可选地，MySQL日志同步的底层实现方式是基于二进制日志(Binlog)的。当数据仓库的数据发生变更时，MySQL会将对应的变更记录写入到二进制日志中，从而触发同步操作。通过IO线程不断向数据仓库请求二进制日志，并将二进制日志中的变更记录写入到重做的日志同步记录中，从而实现日志同步，获取同步记录。

可选地，所述基于预设同步策略获取对应所述日志记录的同步记录的步骤可以包括：

接收源数据库的触发器发送的数据变化信息。

示例性地，在源数据库上创建触发器，当有数据发生变化时，触发器会将变化同步到目标数据库上。

可选地，所述基于预设同步策略获取对应所述日志记录的同步记录的步骤可以包括：

基于数据库中间件同步所述日志记录。

示例性地，可以基于中间件部署和维护，使用数据库中间件，比如Alibaba的Canal、蚂蚁金服的DataX等，将数据同步到目标数据库中。这种方式可以减轻数据库负担。

可选地，所述基于预设同步策略获取对应所述日志记录的同步记录的步骤可以包括：

基于消息队列部署，通过消息队列传递源数据库的数据变化信息。

示例性地，可以基于消息队列部署和维护，将源数据库的变化通过消息队列传递到目标数据库，目标数据库通过消费消息的方式来同步数据，这种方式可以实现高可用性、低延迟的数据同步。

可选地，所述对所述同步记录进行筛选，获取目标语句的步骤包括：

按照预设筛选策略，匹配所述同步记录中的血缘语句为所述目标语句，并写入待处理队列。

示例性地，收到Binlog后，程序解析后进行基础的筛选，只将create，alter，drop，insert这些语句写入待处理的队列中，由于上述语句是insert语句，那符合条件会写入到待处理队列中。

可选地，所述分析所述目标语句，获取所述目标语句中的血缘数据元素的步骤包括：

对所述目标语句进行数据分析，获取所述数据分析过程中的SQL语句；使用语法分析模型对所述SQL语句进行语法分析。

数据分析是指从各种数据源中获取数据，并对其进行整理、清洗、转换、处理、建模和可视化等一系列工作，以获取对业务问题的深刻理解和洞见，从而帮助企业或组织做出更好的决策。示例性地，数据分析是业务需求和目标。

数据分析模块从队列中捞待分析的SQL，开始通过特定的语法分析模型分析SQL，并将分析结果写入系统。示例性地，在通过数据分析时，会使用SQL语句，当系统获取到数据分析时使用的SQL后，由系统通过分析程序对SQL语句进行拆解分析。表是数据库中用于集中存储某种特定类型数据的结构化清单。表的一列叫做字段，字段描述了某一个特征或者叫数据项。分析程序主要负责解析SQL，然后通过解析获得的表名和字段名写入到分析后到结果表中，交由后续的血缘分析模块进行处理。

可选地，所述使用语法分析模型对所述SQL语句进行语法分析的步骤包括：

对所述SQL语句进行拆解分词，生成目标序列；基于所述目标序列进行语法分析，生成目标语法树。

示例性地，在进行SQL语法分析时，通常会采用词法分析器(Lexer)和语法分析器(Parser)两个工具。词法分析器会将SQL语句按照预定义的规则进行分词，生成对应的Token序列；语法分析器则会根据语法规则对Token序列进行解析，生成语法树或抽象语法树。使用ANTLR来实现对SQL的语法分析，从SQL获取需要的信息。其中，语法树是根据SQL语句的语法规则生成的一种树形结构，用于表示SQL语句的语法结构和语义信息。语法树包含了SQL语句中的各个语法元素(如关键字、表名、列名、运算符等)以及它们之间的关系。语法树在后续血缘关系分析中核心作用就是获取SQL中的表名，列名等。ANTLR，全称是AnotherTool for Language Recognition，是一种强大的语言识别工具，用于生成语法解析器、词法分析器和语法树等。它能够根据输入的文本生成语法树或抽象语法树，并提供许多功能和选项来自定义语法解析过程。

可选地，所述根据所述血缘数据元素，基于预设血缘分析策略，获取所述血缘数据元素的血缘关系的步骤包括：

基于所述目标语法树，确定所述目标语句中血缘数据元素的上下游关系；根据所述上下游关系，构建所述血缘数据元素的血缘关系。

血缘分析是数据管理中的一种技术，可以追溯数据的来源、流向和变化历史，从而保证数据的准确性、可靠性和完整性。血缘分析可以记录数据的创建、修改、删除等操作。血缘分析可以帮助数据管理人员了解数据的使用情况，防止数据误用和滥用，保障数据安全。示例性地，血缘分析是为了更好的实现数据分析做的基础保障，是数据分析过程中的一种技术。血缘关系除了表级和字段级，还有系统级，层级关系是从大到小，依次是系统级，表级，字段级。可选地，这里不对系统级血缘做分析，因为当前涉及的系统是固定的。

可选地，所述血缘关系包括表级血缘关系，所述血缘数据元素包括目标表，所述目标语句包括create语句和insert语句。所述根据所述上下游关系，构建所述血缘数据元素的血缘关系的过程中，通过分析所述create语句和所述insert语句，确定所述目标表的上下游关系。

示例性地，对于表级的血缘关系主要是通过分析create语句和insert语句来确定目标表的上下游关系。

可选地，所述血缘关系包括字段级血缘关系，所述血缘关系元素包括字段名，所述目标语句包括select语句。所述根据所述上下游关系，构建所述血缘数据元素的血缘关系的过程中，通过分析所述select语句，并结合所述数据仓库的系统设置，确定所述字段名对应的目标字段的上下游关系。

示例性地，对于字段级的血缘关系分析，是通过select语句的方式来实现，并且需要结合系统中的设置。

可选地，所述根据所述血缘关系，更新所述数据仓库的血缘数据的过程中，将所述上下游关系在当前存储的血缘关系库中进行检索对比。

示例性地，血缘关系维护可以比对该目标字段或该目标表的上下游是否和当前分析计算的结果是一致的，如果是一致的就不需要更新，不然就进行更新操作。这就是维护了血缘关系，表级或字段级的上下游关系便确立了。

可选地，所述数据仓库管理方法还可以包括：

如果所述上下游关系的关系数据已存在则直接跳过。

示例性地，如果系统已经存在该上下游关系那么可以直接跳过不用做新的处理。已经存在该上下游关系的情况下，是给定目标表或目标字段的上游已经是同一个上游了，或者给定目标表或目标字段的下游已经是同一个下游了，这样就不需要再进行更新了，是完全一样的。

可选地，所述数据仓库管理方法还可以包括：

如果所述上下游关系发生变化，则更新所述上下游关系的关系数据。

示例性地，比对该目标表或目标字段的上下游是否和当前分析计算的结果是一致的，如果是一致的就不需要更新，不然就进行更新操作。

可选地，所述数据仓库管理方法还可以包括：

如果未检索到所述上下游关系的关系数据，则新建所述上下游关系的关系数据。

示例性地，如果系统没有这个关系，就需要建立这个上下游关系。或者上下游关系有所不同的，那就需要进行更新，并且在系统中标注来源SQL和SQL执行时间。

示例性地，当血缘关系的自动维护出现了异常，则需要由人工进行维护。这里的异常是指，上下游关系在指定时间内频繁改变，则系统认为需要有人工进行干预，系统将列出血缘关系变更的历史记录，供操作人员进行参考。

第二实施例

本申请还提供一种服务系统，所述服务系统包括处理器和存储器；

所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时实现如上述的数据仓库管理方法的步骤。

图2为本申请一实施例的服务系统架构示意图。

请参考图2，示例性地，本申请的服务系统，通过旁路的方式，在不修改已有数据仓库架构和代码的前提下，实现对数据仓库中血缘关系的获取与更新。旁路的含义是指在系统接入后不对原有系统架构产生影响，不需要调整原有系统中节点位置，数据传输方式，程序代码逻辑等；并且即使接入的系统出现异常也不会影响到原有系统的正常运行。

示例性地，对于旁路式的实现核心采用的是MySQL-Binlog的方式。由于MySQL-Binlog可以将所有执行的SQL语句自动同步到相应从库上，所以我们这里也模拟了从库Binlog同步的实现，技术上采用了MySQL的replication库。使用前首先需要在数据计算的MySQL上打开Binlog，这里只需要修改配置即可。

MySQL主从同步的底层实现方式是基于二进制日志(Binlog)的。当主库的数据发生变更时，MySQL会将对应的变更记录写入到二进制日志中，从而触发从库同步。从库会通过IO线程不断向主库请求二进制日志，并将二进制日志中的变更记录写入到自己的重做日志中，然后再通过重做日志应用线程将变更记录应用到自己的数据上，从而完成主从同步。整个过程是实时的，可以保证从库和主库的数据是一致的。这里系统通过程序模拟了从库，从而实现将MySQL主库的SQL执行记录自动同步到系统中。

至于在系统中如何确保数据一致性，如何保证系统不会重复或遗漏SQL，是由MySQL同步本身的机制来决定的。

在MySQL的主从同步中，日志记录位置log position表示Binlog中的一个位置，表示MySQL主库已经成功地将日志写入到Binlog中，而从库正在等待读取该位置之后的Binlog日志。每个Binlog文件有唯一的编号和名称，并由一个或多个日志事件组成。

log position的作用是在主库和从库之间同步Binlog时进行定位，以便从库可以正确地复制来自主库的Binlog事件。主库会将每个Binlog事件记录到Binlog中，并记录该事件的log position。从库通过读取主库的Binlog，并跟踪其在Binlog中读取的位置，来确保它已经复制了所有主库的操作。

在主从复制中，从库会向主库请求Binlog日志，并从指定的log position开始读取日志。主库将相应的Binlog日志发送给从库，从库会将日志应用于自己的数据库中。每次从库读取一条Binlog日志并成功应用到本地数据库后，就会将其对应的log position更新为自己已经同步的位置，以便下次请求Binlog时从该位置开始读取。这样，主库和从库之间始终保持着log position的同步，从而确保了数据的一致性。

图3为本申请的服务系统工作流程图。

请参考图3，以下举例一条SQL执行到服务系统中的过程：

MySQL主库上执行了如下SQL语句:

INSERT INTO rpt.`rpt_total_due_d`

(due_day,

product_type,

user_category,

due_cnt)

SELECT

due_day,

product_type,

user_category,

due_cnt

FROM tmp.tmp_rpt_new_collect；

可选地，本实施例的服务系统由于配置了MySQL主从同步，SQL语句会立即通过Binlog自动同步到MySQL从库，也就是当前系统里。当然除了Binlog的同步机制以外，MySQL还支持以下数据同步机制：

1.基于触发器的同步：在源数据库上创建触发器，当有数据发生变化时，触发器会将变化同步到目标数据库上。但是，这种方式的性能相对较差，不适合大规模的同步场景。

2.数据库中间件：使用数据库中间件，比如Alibaba的Canal、蚂蚁金服的DataX等，将数据同步到目标数据库中。这种方式可以减轻数据库负担，但是需要额外的中间件部署和维护。

3.使用消息队列：将源数据库的变化通过消息队列传递到目标数据库，目标数据库通过消费消息的方式来同步数据。这种方式可以实现高可用性、低延迟的数据同步，但是需要额外的消息队列部署和维护。

4.在当前系统中因为通过程序模拟了MySQL从库的机制，会立即收到Binlog的推送。

收到Binlog后，程序解析后进行基础的筛选，只将create，alter，drop，insert这些语句写入待处理的队列中，由于上述语句是insert语句，那符合条件会写入到待处理队列中。

数据分析模块从队列中捞待分析的SQL，开始分析SQL，并将分析结果写入系统。

血缘分析模块从系统中获取还未处理的记录，开始自动更新维护表和字段的血缘关系。

更新完成后，服务系统就可以系统展示最新的血缘关系。

数据分析是指从各种数据源中获取数据，并对其进行整理、清洗、转换、处理、建模和可视化等一系列工作，以获取对业务问题的深刻理解和洞见，从而帮助企业或组织做出更好的决策。

血缘分析是数据管理中的一种技术，可以追溯数据的来源、流向和变化历史，从而保证数据的准确性、可靠性和完整性。血缘分析可以记录数据的创建、修改、删除等操作。血缘分析可以帮助数据管理人员了解数据的使用情况，防止数据误用和滥用，保障数据安全。

数据分析是业务需求和目标，而血缘分析是为了更好的实现数据分析做的基础保障，是数据分析过程中的一种技术。

可选地，在通过数据分析时，会使用SQL语句，当系统获取到数据分析时使用的SQL后，由系统通过分析程序对SQL语句进行拆解分析。分析程序主要负责解析SQL，然后通过解析获得的表名和字段名写入到分析后的结果表中，交由后续的血缘分析模块进行处理。

在进行SQL语法分析时，通常会采用词法分析器(Lexer)和语法分析器(Parser)两个工具。词法分析器会将SQL语句按照预定义的规则进行分词，生成对应的Token序列；语法分析器则会根据语法规则对Token序列进行解析，生成语法树或抽象语法树。使用ANTLR来实现对SQL的语法分析，从SQL获取需要的信息。

以上操作是对数据分析过程中产生的SQL进行分析，用于做血缘分析。

仍然以上述insert语句为例。系统通过对SQL进行语法分析，可以获得如下信息：

数据来源：表tmp.tmp_rpt_new_collect

数据输出：表rpt.rpt_total_due_d

数据字段：

表tmp.tmp_rpt_new_collect：due_day,product_type,user_category,due_cnt

表rpt.rpt_total_due_d：due_day,product_type,user_category,due_cnt

血缘关系除了表级和字段级，还有系统级，层级关系是从大到小，依次是系统级，表级，字段级。可选地，当涉及的系统是固定的情况下，可以不对系统级血缘做分析。图4为本申请一实施例的表级血缘关系示意图。图5为本申请一实施例的字段级血缘关系示意图。

请参考图4，在服务系统进行血缘分析以及对血缘关系的维护的过程中，对于表级的血缘关系主要是通过分析create语句和insert语句来确定目标表的上下游关系。上例中表rpt.rpt_total_due_d的上游是tmp.tmp_rpt_new_collect，将该关系放到系统中进行查询对比，如果系统已经存在该上下游关系那么直接跳过。已经存在该上下游关系的意思是给定表的上游已经是同一个上游了，或者给定表的下游已经是同一个下游了，这样就不需要再进行更新了，是完全一样的。如果系统没有这个关系，就需要建立这个上下游关系。或者上下游关系有所不同的，那就需要进行更新，并且在系统中标注来源SQL和SQL执行时间。对于如果是字段级的血缘关系维护也是同样的比对该字段的上下游是否和当前分析计算的结果是一致的，如果是一致的就不需要更新，不然就进行更新操作。这就是维护了血缘关系，表级的上下游关系便确立了。

如图5所示，对于字段级的血缘关系更新，是通过select语句的方式来实现，并且需要结合系统中的设置。该设置功能需要表记具体的表名，以及该表下的具体字段名，另外标注字段的说明。这样来确定该字段需要被记录上下游关系。并且所有和这个字段有关系的字段都会自动记录下。注：上述内容属于血缘分析以及对血缘关系的维护。

对于上例，假设在系统中已提前设定表rpt.rpt_total_due_d的due_cnt字段是一个指标字段，那该字段就需要记录血缘关系。通过SQL语句分析后得到的字段关系，rpt.rpt_total_due_d的due_cnt数据来源于tmp.tmp_rpt_new_collect的due_cnt。同样的将该关系维护到系统里，这样就对字段级的血缘关系做到了维护。

上述举例部分不是存储过程，只是SQL语句的执行，不属于任何过程。

可选地，当血缘关系的自动维护出现了异常，则需要由人工进行维护。这里的异常是指，上下游关系在指定时间内频繁改变，则系统认为需要有人工进行干预，系统将列出血缘关系变更的历史记录，供操作人员进行参考。

MySQL存储过程是一种预定义的SQL语句集合，它们被保存在MySQL数据库中并可以在需要时被调用执行。存储过程可以接受参数、返回值和输出参数，可以包含流程控制语句(例如条件、循环语句)和SQL语句，还可以使用变量和临时表等功能。存储过程可以方便地重复执行复杂的任务，可以提高数据库性能并提高应用程序的可维护性。MySQL存储过程的执行也会自动同步到二进制日志(Binlog)中，以便能够在主从复制的场景下进行数据同步。MySQL会将存储过程的创建语句和执行语句都通过Binlog进行同步。示例性地，MySQL常用的语句有：

用于创建对象的创建语句：

CREATE PROCEDURE GetProductCount(IN category VARCHAR(255),OUTproduct_count INT)BEGIN

SELECT COUNT(*)INTO product_count

FROM products

WHERE category＝category；

END；

用于执行对象的执行语句：

SET@category＝'Electronics'；

SET@product_count＝0；

CALL GetProductCount(@category,@product_count)；

数据定义语句(DDL)：用于创建、删除和修改数据库对象(例如表、视图、索引等)。常见的DDL语句包括CREATE、ALTER和DROP。

数据操纵语句(DML)：用于操作表中的数据，例如SELECT、INSERT、UPDATE和DELETE。

数据查询语句(DQL)：用于查询表中的数据，最常见的是SELECT。

数据控制语句(DCL)：用于授权、取消授权和管理数据库用户权限。常见的DCL语句包括GRANT、REVOKE和DENY。

事务控制语句(TCL)：用于控制事务的处理。常见的TCL语句包括COMMIT、ROLLBACK和SAVEPOINT。

上述例子属于DML(insert)和DQL(select)语句)写入Binlog中，这些语句在从库上被执行，以确保从库与主库上的数据保持一致。

可选地，但以下场景服务系统可以不同步：

1.执行存储过程的事务没有启用Binlog：如果当前的事务没有启用Binlog，那么存储过程的执行过程也不会被记录在二进制日志中。

2.存储过程中使用了不支持Binlog记录的语句：在存储过程中，如果使用了不支持Binlog记录的语句，比如CREATE TEMPORARY TABLE语句，那么存储过程的执行过程也不会被记录在二进制日志中。

3.存储过程中使用了不支持Binlog记录的存储引擎：如果存储过程中使用了不支持Binlog记录的存储引擎，那么存储过程的执行过程也不会被记录在二进制日志中。比如，如果存储过程中使用了Memory存储引擎，那么执行过程就不会被记录在Binlog中。

除上述情况外，服务系统存储过程和标准的SQL执行没有区别，所有存储过程的执行语句也会以SQL方式同步到当前系统中。

在本实施例中，基于预设同步策略获取目标语句，提取血缘数据元素分析血缘关系，无需在数据仓库节点上增加额外的服务，处理架构简单有效，降低了系统部署成本，能够支持复杂的数据仓库系统，有效保障了血缘关系处理的准确度和及时性。

第三实施例

图6为本申请一实施例的服务系统方框图。

请参考图6，示例性地，当前服务系统主要可以分为4个模块，包括数据监听模块，数据分析模块，血缘分析模块，展示模块。

数据监听模块用于监听数据仓库中在数据计算过程产生SQL日志，这里会提前将create，alter，drop，insert这些语句存入待处理队列中。其中create，alter，drop都属于DDL语句，insert属于DML语句。

数据分析模块会对存入队列中的语句逐条分析，并将分析结果分门别类的写入相应结果表，包括表级和字段级。

血缘分析模块，会将当前已保存的关系和最新分析的结果进行对比处理，并更新当前的血缘关系。同时将更新记录保留下来，以供之后的查询处理。

展示模块，主要以系统方式展示当前数据仓库的血缘关系，支持查询指定表的上下游关系，查询表中相关字段的上下游关系；查看血缘关系图。

本申请提出的服务系统，通过旁路的方式，在不修改已有数据仓库架构和代码的前提下，实现对数据仓库中血缘关系的获取与更新，并且对于MySQL中存储过程也进行了支持，解决目前已有技术部署复杂，系统耦合度过高，以及无法支持MySQL存储过程的问题。

第四实施例

本申请还提供一种存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述的数据仓库管理方法的步骤。

上述实施例中，基于Binlog方式同步，可以将SQL语句通过Binlog同步。使用SQL语句分析的方法分析SQL语句，并抽取出对应表和字段的上下游关系。在血缘关系分析过程中，将最新分析的上下游关系，结合已存储的关系进行更新和维护。

如上所述，本申请提供的数据仓库管理方法、服务系统和存储介质，基于预设同步策略获取目标语句，提取血缘数据元素分析血缘关系，无需在数据仓库节点上增加额外的服务，处理架构简单有效，降低了系统部署成本，能够支持复杂的数据仓库系统，有效保障了血缘关系处理的准确度和及时性。

在本申请提供的服务系统和存储介质的实施例中，可以包含任一上述交互方法实施例的全部技术特征，说明书拓展和解释内容与上述方法的各实施例基本相同，在此不再做赘述。

本申请实施例还提供一种计算机程序产品，计算机程序产品包括计算机程序代码，当计算机程序代码在计算机上运行时，使得计算机执行如上各种可能的实施方式中的方法。

本申请实施例还提供一种芯片，包括存储器和处理器，存储器用于存储计算机程序，处理器用于从存储器中调用并运行计算机程序，使得安装有芯片的设备执行如上各种可能的实施方式中的方法。

可以理解，上述场景仅是作为示例，并不构成对于本申请实施例提供的技术方案的应用场景的限定，本申请的技术方案还可应用于其他场景。例如，本领域普通技术人员可知，随着系统架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。

本申请实施例设备中的单元可以根据实际需要进行合并、划分和删减。

在本申请中，对于相同或相似的术语概念、技术方案和/或应用场景描述，一般只在第一次出现时进行详细描述，后面再重复出现时，为了简洁，一般未再重复阐述，在理解本申请技术方案等内容时，对于在后未详细描述的相同或相似的术语概念、技术方案和/或应用场景描述等，可以参考其之前的相关详细描述。

在本申请中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本申请技术方案的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本申请记载的范围。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，被控终端，或者网络设备等)执行本申请每个实施例的方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络，或者其他可编程装置。计算机指令可以存储在存储介质中，或者从一个存储介质向另一个存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、存储盘、磁带)、光介质(例如，DVD)，或者半导体介质(例如固态存储盘Solid State Disk(SSD))等。

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (10)

1.一种数据仓库管理方法，其特征在于，包括：

响应于数据仓库写入日志记录，基于预设同步策略获取对应所述日志记录的同步记录；

对所述同步记录进行筛选，获取目标语句；

分析所述目标语句，获取所述目标语句中的血缘数据元素；

根据所述血缘数据元素，基于预设血缘分析策略，获取所述血缘数据元素的血缘关系；

根据所述血缘关系，更新所述数据仓库的血缘数据。

2.根据权利要求1数据仓库管理方法，其特征在于，所述基于预设同步策略获取对应所述日志记录的同步记录的步骤包括以下至少一项：

通过IO线程向所述数据仓库请求所述日志记录；

接收源数据库的触发器发送的数据变化信息；

基于数据库中间件同步所述日志记录；

基于消息队列部署，通过消息队列传递源数据库的数据变化信息。

3.根据权利要求2数据仓库管理方法，其特征在于，所述对所述同步记录进行筛选，获取目标语句的步骤包括：

按照预设筛选策略，匹配所述同步记录中的血缘语句为所述目标语句，并写入待处理队列。

4.根据权利要求2数据仓库管理方法，其特征在于，所述分析所述目标语句，获取所述目标语句中的血缘数据元素的步骤包括：

对所述目标语句进行数据分析，获取所述数据分析过程中的SQL语句；

使用语法分析模型对所述SQL语句进行语法分析。

5.根据权利要求4数据仓库管理方法，其特征在于，所述使用语法分析模型对所述SQL语句进行语法分析的步骤包括：

对所述SQL语句进行拆解分词，生成目标序列；

基于所述目标序列进行语法分析，生成目标语法树。

6.根据权利要求5所述的数据仓库管理方法，其特征在于，所述根据所述血缘数据元素，基于预设血缘分析策略，获取所述血缘数据元素的血缘关系的步骤包括：

基于所述目标语法树，确定所述目标语句中血缘数据元素的上下游关系；

根据所述上下游关系，构建所述血缘数据元素的血缘关系。

7.根据权利要求6数据仓库管理方法，其特征在于，所述血缘关系包括表级血缘关系，所述血缘数据元素包括目标表，所述目标语句包括create语句和insert语句；所述根据所述上下游关系，构建所述血缘数据元素的血缘关系的过程中，通过分析所述create语句和所述insert语句，确定所述目标表的上下游关系；和/或，

所述血缘关系包括字段级血缘关系，所述血缘关系元素包括字段名，所述目标语句包括select语句；所述根据所述上下游关系，构建所述血缘数据元素的血缘关系的过程中，通过分析所述select语句，并结合所述数据仓库的系统设置，确定所述字段名对应的目标字段的上下游关系。

8.根据权利要求6或7所述的数据仓库管理方法，其特征在于，所述根据所述血缘关系，更新所述数据仓库的血缘数据的过程中，将所述上下游关系进行检索对比；

所述数据仓库管理方法还包括以下至少一项：

如果所述上下游关系的关系数据已存在则直接跳过；

如果所述上下游关系发生变化，则更新所述上下游关系的关系数据；

如果未检索到所述上下游关系的关系数据，则新建所述上下游关系的关系数据。

9.一种服务系统，其特征在于，所述服务系统包括处理器和存储器；

所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1-8任一项所述的数据仓库管理方法的步骤。

10.一种存储介质，其特征在于，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1-8任一项所述的数据仓库管理方法的步骤。