基于SQL脚本的数据关系分析方法和装置

技术领域

本发明涉及大数据的数据治理技术领域，尤其是涉及基于SQL脚本的数据关系分析方法和装置。

背景技术

随着各类数据的需求越来越多，比如实时业绩、监管报送等场景均需要开发人员更好地认识表之间的数据流向，理解业务，并且在需要做数据变更时去做影响分析。在任务调度时，也可以通过字段级别的血缘关系，反过来去审查、诊断、优化任务级别依赖关系的配置。以上工作需要分析大量不同类型数据库SQL脚本产生的数据血缘关系。

目前，对于数据血缘关系的获取方式，主要采用的技术为：SQL解析引擎JSqlParser，Java专业SQL解析工具，但这种方式只能获取到查询语句的结果字段集合和来源表集合，不能构建结果字段来源于哪些表的哪些字段；数据治理和元数据管理工具Atlas，不能直接解析SQL语句，而是依赖于Hooks对元数据信息的捕获。另外，还可以采用人工维护，但对人员专业技术要求较高，人力、时间成本高。

发明内容

有鉴于此，本发明的目的在于提供基于SQL脚本的数据关系分析方法和装置，通过数据血缘解析多种数据库SQL脚本中表、字段两种粒度的血缘关系，通过图形可视化提供跨数据库、自动化的数据血缘分析，帮助用户全面了解数据资产之间的数据流向和依赖性。

第一方面，本发明实施例提供了基于SQL脚本的数据关系分析方法，应用于服务器，所述方法包括：

接收客户端发送的所述SQL脚本；

将所述SQL脚本进行解析，得到血缘模型；

将所述血缘模型进行转换，得到图模型，其中，所述图模型为有向标签属性图，所述图模型包括库、表、SQL Process、字段和字段血缘Process；

将所述图模型存储至图数据库中；

通过Gremlin图遍历语句调用所述图数据库中的所述图模型，并进行计算，得到血缘关系图；

将所述血缘关系图发送给所述客户端，以使所述客户端显示所述血缘关系图。

第二方面，本发明实施例提供了基于SQL脚本的数据关系分析装置，应用于服务器，所述装置包括：

接收模块，用于接收客户端发送的所述SQL脚本；

解析模块，用于将所述SQL脚本进行解析，得到血缘模型；

转换模块，用于将所述血缘模型进行转换，得到图模型，其中，所述图模型为有向标签属性图，所述图模型包括库、表、SQL Process、字段和字段血缘Process；

存储模块，用于将所述图模型存储至图数据库中；

计算模块，用于通过Gremlin图遍历语句调用所述图数据库中的所述图模型，并进行计算，得到血缘关系图；

发送模块，用于将所述血缘关系图发送给所述客户端，以使所述客户端显示所述血缘关系图。

第三方面，本发明实施例提供了电子设备，包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上所述的方法。

第四方面，本发明实施例提供了具有处理器可执行的非易失的程序代码的计算机可读介质，所述程序代码使所述处理器执行如上所述的方法。

本发明实施例提供了基于SQL脚本的数据关系分析方法和装置，应用于服务器，包括：接收客户端发送的SQL脚本；将SQL脚本进行解析，得到血缘模型；将血缘模型进行转换，得到图模型，其中，图模型为有向标签属性图，图模型包括库、表、SQL Process、字段和字段血缘Process；将图模型存储至图数据库中；通过Gremlin图遍历语句调用图数据库中的图模型，并进行计算，得到血缘关系图；将血缘关系图发送给客户端，以使客户端显示血缘关系图；通过数据血缘解析多种数据库SQL脚本中表、字段两种粒度的血缘关系，通过图形可视化提供跨数据库、自动化的数据血缘分析，帮助用户全面了解数据资产之间的数据流向和依赖性。

本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例一提供的基于SQL脚本的数据关系分析方法流程图；

图2为本发明实施例一提供的基于SQL脚本的数据关系分析过程的架构图；

图3为本发明实施例一提供的字段血缘树的关系示意图；

图4为本发明实施例一提供的血缘的图模型示意图；

图5为本发明实施例二提供的基于SQL脚本的数据关系分析装置示意图。

具体实施方式

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

为便于对本实施例进行理解，下面对本发明实施例进行详细介绍。

实施例一：

图1为本发明实施例一提供的基于SQL脚本的数据关系分析方法流程图。

参照图1，应用于服务器，该方法包括以下步骤：

步骤S101，接收客户端发送的SQL脚本；

步骤S102，将SQL脚本进行解析，得到血缘模型；

步骤S103，将血缘模型进行转换，得到图模型，其中，图模型为有向标签属性图，图模型包括库、表、SQL Process、字段和字段血缘Process；

步骤S104，将图模型存储至图数据库中；

步骤S105，通过Gremlin图遍历语句调用图数据库中的图模型，并进行计算，得到血缘关系图；

步骤S106，将血缘关系图发送给客户端，以使客户端显示血缘关系图。

具体地，参照图2，本申请提供适配多种SQL脚本，可以对数据血缘进行分析、持久化、可视化追踪的工具。通过本申请的方法，可以解析多种数据库SQL脚本中表、字段两种粒度的血缘关系，进行可视化追踪。

本申请是一个使用Spring boot开发的Java Web应用，通过页面或REST/Kafka接口接收各种数据库的SQL脚本，解析表、字段两种粒度的血缘关系，字段级别的血缘根据SQL句法区分直接关系和间接关系，将血缘模型转换成图模型后存储至图数据库。

页面用图形化的方式为用户展示数据库中各个表、各个字段之间的血缘关系。支持多种展示形式，包括查询单个表或字段等实体指定深度的血缘图、单个或多个SQL涉及的所有字段的血缘图等。同时可以接收DDL支撑血缘的变化，也可以在页面直接更新血缘。

进一步的，步骤S102包括以下步骤：

步骤S201，将SQL脚本解析为抽象语法树；

这里，首先使用Druid将SQL脚本解析成抽象语法树(Abstract Syntax Tree，AST)，支持任意复杂语法之间的互相嵌套。然后对SQL脚本进行分类。其中，Druid是一个开源的数据库连接池。

对于create table as select、insert select，可进行表级、字段级血缘分析，其中，select部分作为血缘中的来源。

步骤S202，遍历抽象语法树递归解析不同的SQL句法，得到字段血缘树；

步骤S203，将字段血缘树根节点对应的每个子节点作为目标字段；其中，目标字段所在子树的叶节点为目标字段的源字段；

步骤S204，根据目标字段和所述源字段，构建字段级血缘关系；

步骤S205，将字段级血缘关系作为血缘模型。

进一步的，步骤S202包括以下步骤：

步骤S301，判断select item是否作为孩子节点加入字段血缘树；

步骤S302，当select item加入字段血缘树的情况下，根据目标字段是否为聚合字段和select所处位置判断where、group by、having或join条件是否也加入；

这里，对sql中查询进行分类(一直往前追溯，该查询属于最外层查询的哪一部分)：最外层查询、最外层查询的select item中的子查询、最外层查询的from中的子查询、最外层查询的where/group by中的子查询。

步骤S303，当select item加入字段血缘树的情况下，处理from将字段血缘树中字段的表别名更新为表名。

进一步的，步骤S301包括以下步骤：

步骤S401，如果select是最外层查询，或者来源于父select的select item、where、group by或having的任意位置，则加入；

步骤S402，如果select来源于父select的from处，则继续判断select item是否与字段血缘树的入参节点相关；

步骤S403，如果字段血缘树的入参节点的字段名为select item的别名，且入参节点的字段的归属表名为select item的所属子查询的别名，则相关且加入；

步骤S404，如果字段血缘树的入参节点的字段名不是select item的别名，且入参节点的字段的归属表名不是select item的所属子查询的别名，则不相关且不加入。

进一步的，步骤S302包括以下步骤：

步骤S501，当select item加入字段血缘树的情况下，如果select不是最外层查询，且追溯到最外层查询的select item，则加入；

步骤S502，如果select是最外层查询，或追溯到最外层查询的where、group by、having或from，则继续判断目标字段是否为聚合字段；

步骤S503，遍历字段血缘树中入参节点的父节点，如果路径中存在聚合，则加入；

步骤S504，如果路径中不存在聚合，则不加入。

进一步的，步骤S303包括以下步骤：

步骤S601，当select item加入字段血缘树的情况下，如果from是普通单表，遍历字段血缘树中入参节点的子树中未结束的叶子节点；

步骤S602，判断叶子节点的字段是否归属于from中的表；

步骤S603，如果是，则将表别名更新为表名，并标记为结束；

具体地，如果叶子节点字段的表别名非空，并且叶子节点字段的表别名为from中普通单表的别名，则更新叶子节点字段的表名、标记为结束；

如果叶子节点字段的表别名为空，则继续判断孤儿字段是否归属于from中的表；

当整体的from不是join时，孤儿字段归属于from中的表，此时进行更新和标记；

从外部获取from中表的元数据，判断孤儿字段是否归属于from中的表；

如果是，则进行更新和标记；

如果否，则跳过此叶子节点。

步骤S604，如果from是join，则递归处理join的各个部分；

步骤S605，如果from是子查询，则遍历字段血缘树中入参节点的子树中未结束的叶子节点，处理select；

步骤S606，如果from是union查询，则遍历字段血缘树中入参节点的子树中未结束的叶子节点，递归处理union查询的各个select。

为了精确定位SQL语句中的每个表和字段，需要根据源端表结构将AST中的select*替换为具体字段、判断孤儿字段(未指定表别名)归属的表；修正union结果集的字段名，以第一个查询结果集的字段别名为准。

源字段是否计入目标字段血缘的规则：最外层查询的select item中的所有子查询的where计入全部字段的血缘；其余查询(最外层查询、最外层查询的from/where中的子查询)的where仅计入聚合字段的血缘。

血缘属于直接关系还是间接关系的规则：where、group by、from中join条件、count函数参数、case when条件部分等涉及的字段计入间接字段血缘，其余情况计入直接血缘。

例如，该示例SQL的字段血缘树如图3所示：

CREATE TABLE temp

AS

SELECT

SELECT concat('test',department_name)FROM departments

b WHERE a.department_id＝b.department_id AS dept_name，

AVG(salary)AS average_salary

FROM

(SELECT

department_id,

salary

FROM

employees)AS a

GROUP BY department_id；

其中，表级血缘：

temp来源于departments

temp来源于employees

字段级血缘：

temp.dept_name来源于departments.department_name

temp.dept_name来源于employees.department_id//间接关系

temp.dept_name来源于departments.department_id//间接关系

temp.average_salary来源于employees.salary

temp.average_salary来源于employees.department_id//间接关系

对于影响血缘的DDL：更新维护图库中的元数据，用来支撑血缘的变化(如表、字段的rename、drop等)。

参照图4，中间一行表示血缘相关：

SQL Process：代表SQL这个过程；

SQL Process---process.outputs--->表：SQL生成(输出)了这个表；

SQL Process---process.inputs--->表：SQL查询(输入)了这个表；

表1<---process.inputs---SQL Process---process.outputs--->表2：SQL查询表1，生成表2。即表血缘为：表2来源于表1。

最后一行代表字段血缘相关：

字段血缘Process：代表SQL输出表的其中一个字段的血缘，具体为：SQL可以按字段拆成多个SQL片段，字段血缘Process是其中一个字段相关的SQL片段这个过程；

字段血缘Process---column_lineage.sql--->SQL Process：字段相关的SQL片段属于哪个SQL；

字段血缘Process---process.outputs--->字段：字段相关的SQL片段生成(输出)了这个字段；

字段血缘Process---process.inputs--->字段：字段相关的SQL片段查询(输入)了这个字段；

字段1---process.inputs--->字段血缘Process---process.outputs--->字段2：字段相关的SQL片段查询字段1，生成字段2，即字段血缘为：字段2来源于字段1。

进一步的，血缘关系图包括单个表或字段实体指定深度的血缘图、单个或多个SQL脚本涉及的所有字段的血缘图。

具体地，使用Gremlin图遍历语句进行图计算获取指定深度的表、字段血缘。前端使用dagre js库计算有向无环图的坐标，为用户提供层次、网格两种布局的血缘图。用户通过页面查看血缘关系图。

本申请具有以下优点：

1)支持Hive、Spark sql、Oracle、MySQL、OceanBase等多种SQL方言/数据库；

2)支持两种粒度的血缘分析：表级血缘、字段级血缘；

3)支持复杂的函数、case when、子查询、union查询、join等，以及它们之间的任意嵌套；

4)支持select*和未指明归属表的孤儿字段(客户端提供表结构或JDBC连接信息，或者图库中已维护该表元数据时)；

5)支持接收不涉及血缘的ddl，将元数据维护至图库，用来支撑血缘的变化(如表的rename等)；

6)字段级血缘区分直接关系、间接关系，如：case when中when中的字段为间接关系，then和else中的字段为直接关系；查询中where、group by中的字段为间接关系；

7)多种形式的血缘图展示：层次、网格两种布局；可查看单个元素深度可选的血缘或整个SQL的字段血缘。

实施例二：

图5为本发明实施例二提供的基于SQL脚本的数据关系分析装置示意图。

参照图5，该装置包括：

接收模块，用于接收客户端发送的SQL脚本；

解析模块，用于将SQL脚本进行解析，得到血缘模型；

转换模块，用于将血缘模型进行转换，得到图模型，其中，图模型为有向标签属性图，图模型包括库、表、SQL Process、字段和字段血缘Process；

存储模块，用于将图模型存储至图数据库中；

计算模块，用于通过Gremlin图遍历语句调用图数据库中的图模型，并进行计算，得到血缘关系图；

发送模块，用于将血缘关系图发送给客户端，以使客户端显示血缘关系图。

进一步的，解析模块具体用于：

将SQL脚本解析为抽象语法树；

遍历抽象语法树递归解析不同的SQL句法，得到字段血缘树；

将字段血缘树根节点对应的每个子节点作为目标字段；其中，目标字段所在子树的叶节点为目标字段的源字段；

根据目标字段和所述源字段，构建字段级血缘关系；

将字段级血缘关系作为血缘模型。

本发明实施例还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述实施例提供的基于SQL脚本的数据关系分析方法的步骤。

本发明实施例还提供一种具有处理器可执行的非易失的程序代码的计算机可读介质，计算机可读介质上存储有计算机程序，计算机程序被处理器运行时执行上述实施例的基于SQL脚本的数据关系分析方法的步骤。

本发明实施例所提供的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

另外，在本发明实施例的描述中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。