CN114756469A - 数据关系分析方法、装置及电子设备 - Google Patents

Abstract

本申请实施例公开了数据关系分析方法、装置及电子设备，所述方法包括：针对待探测的目标链路，发起对所述目标链路的探测流程；在所述探测流程中，对所述应用接收到的带有所述探测标识的调用请求进行拦截处理；在响应所述调用请求的过程中，将涉及到的读取缓存请求进行缓存失效处理，以使得通过所述应用关联的数据库中进行数据查询；对数据库查询请求以及返回结果进行截获处理，以获取到数据库查询记录后，保存其与所述目标链路的链路标识之间的对应关系；通过对同一链路标识对应的多条数据库查询记录进行分析，确定所述目标链路相关的库表信息，以及存在数据血缘关系的字段。通过该方法，能够更高效更完整地获取数据血缘关系信息。

Description

数据关系分析方法、装置及电子设备

技术领域

本申请涉及数据分析技术领域，特别是涉及数据关系分析方法、装置及电子设备。

背景技术

在压力测试或者其他的测试场景中，都是需要有数据作为支撑，但是在实际测试过程中，经常会出现数据缺失或者不够丰富的问题。而由于线上运行了真实环境，会产生大量的数据，因此，一种解决方案是，将线上的相关数据同步到“影子库”，或者是同步到线下数据库，以用于压力测试，或者丰富线下测试数据。在此过程中，基于数据安全要求，将线上同步至其他地方的数据需要先进行脱敏处理。

但是，同一链路可能涉及到多个应用(例如，商品下单链路中可能涉及到详情应用，营销相关的应用，会员管理应用，等等)，每个应用中可能又会涉及到多个数据库中的多个数据表。其中，不同数据库的不同数据表中，可能存在具有数据血缘关系(是在数据溯源的过程中找到相关数据之间的联系，或指数据在产生、处理、流转到消亡过程中，数据之间形成的一种类似于人类社会血缘关系的关系)的字段，对于这种字段上的数据，在从线上同步到线下的过程中，需要使用相同的脱敏规则进行脱敏处理，否则在同步到线下之后可能也无法使用。但是，由于具体的数据库、数据表可能属于不同的域，通过不同的小组或者团队(通常可以称为BU)进行维护，因此，具体哪些数据库的哪些数据表中的哪些字段之间存在数据血缘关系，需要通过分析之后才能够进行确定。

其中，一种方式是多个域的专家根据经验人工输出数据库表的字段之间的血缘关系。例如，某些数据库中的某些数据表可能是某个专家设计的，则该专家知晓具体的库表逻辑，以及字段之间的血缘关系，因此，可以由这种专家输出数据血缘关系。但是，由于同一链路上可能涉及多个应用，每个应用中包括多个数据库表，因此，可能涉及到多个不同的BU的专家进行配合，才能获得关于同一链路上完整的数据血缘关系信息，对于大部分链路而言，整个过程的工作量会非常大。

另一种方式是，通过链路跟踪***保存的日志(会对具体链路上涉及了哪些应用，调用了哪些服务，使用了哪些数据库表，哪些缓存等等进行记录)进行数据血缘关系的分析。但是，由于很大部分情况下，具体链路上会通过缓存进行数据调用，而不会直接进行数据库调用，而缓存中的数据是通过对多个数据库表的数据调用结果进行聚合等运算处理之后的结果，因此，无法获知具体数据库表之间的调用情况，进而也就无法获得具体链路上完整的数据血缘关系信息。

因此，如何更高效更完整地获取数据血缘关系信息，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了数据关系分析方法、装置及电子设备，能够更高效更完整地获取数据血缘关系信息。

本申请提供了如下方案：

一种数据关系分析方法，包括：

针对待探测的目标链路，通过启动执行所述目标链路，并在启动请求中携带探测标识，发起对所述目标链路的探测流程；其中，所述目标链路上包括多个应用；

在所述探测流程中，对所述应用接收到的带有所述探测标识的调用请求进行拦截处理；

在响应所述调用请求的过程中，将涉及到的读取缓存请求进行缓存失效处理，以使得通过所述应用关联的数据库中进行数据查询；

对数据库查询请求以及返回结果进行截获处理，以获取到数据库查询记录后，保存其与所述目标链路的链路标识之间的对应关系；

通过对同一链路标识对应的多条数据库查询记录进行分析，确定所述目标链路相关的库表信息，以及所述目标链路上存在数据血缘关系的数据值及其所在的字段。

一种数据关系分析装置，包括：

探测流程启动单元，用于针对待探测的目标链路，通过启动执行所述目标链路，并在启动请求中携带探测标识，发起对所述目标链路的探测流程；其中，所述目标链路上包括多个应用；

请求拦截处理单元，用于在所述探测流程中，对所述应用接收到的带有所述探测标识的调用请求进行拦截处理；

缓存失效处理单元，用于在响应所述调用请求的过程中，将涉及到的读取缓存请求进行缓存失效处理，以使得通过所述应用关联的数据库中进行数据查询；

数据截获处理单元，用于对数据库查询请求以及返回结果进行截获处理，以获取到数据库查询记录后，保存其与所述目标链路的链路标识之间的对应关系；

分析单元，用于通过对同一链路标识对应的多条数据库查询记录进行分析，确定所述目标链路相关的库表信息，以及所述目标链路上存在数据血缘关系的数据值及其所在的字段。

一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述任一项所述的方法的步骤。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行前述任一项所述的方法的步骤。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例可以在执行具体链路的过程中，进行链路探测，具体在探测时，可以对链路中具体应用接收到的调用请求进行拦截，并在响应这种调用请求的过程中，对读取缓存请求进行缓存失效处理，以使得通过所述应用关联的数据库中进行数据查询，进而，再通过对数据库查询请求以及返回结果的截获，获取到数据库查询记录信息，其中可以包括查询条件信息，以及数据库返回的数据值及其所在的字段、库表标识信息。进而，就可以通过对同一链路标识对应的多条数据库查询记录进行分析，确定所述目标链路相关的库表信息，以及所述目标链路上存在数据血缘关系的数据值及其所在的字段。通过这种方式，可以通过自动化的方式确定出一条链路上关联有哪些数据库、数据表，以及这些数据库、数据表中哪些字段之间具有数据血缘关系，并且由于不需要借助专家经验，因此，准确性以及效率都更高。另外，由于是在具体执行链路过程中进行数据收集，因此，可以获取到关于具体链路上更完整的数据库相关的信息。

其中，为了避免入侵具体应用的代码，还可以提供插件程序，通过在应用的预发环境中部署这种插件程序，可以通过插件程序执行调用请求的拦截，缓存击穿，数据截获等处理。另外，具体的插件程序可以仅在同一应用对应的部分预发机器上部署，同时通过插件程序实现向这种机器设备的定向路由，以避免对预发环境下的正常流量造成过多影响。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的***架构的示意图；

图2是本申请实施例提供的方法的流程图；

图3是本申请实施例提供的探测启动界面的示意图；

图4是本申请实施例提供的装置的示意图；

图5是本申请实施例提供的电子设备的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

为了便于理解本申请实施例提供的具体技术方案，下面首先需要说明的是，在从线上向线下进行数据同步的过程中，由于同步的目的主要是为了进行压力测试或者其他的测试，而测试的过程中会涉及到以链路为单位的测试。例如，对下单链路进行压力测试，等等。但是，如背景技术部分所述，同一链路可能涉及到非常多的应用，每个应用中可能又会涉及到多个数据库中的多个数据表，每个数据表中存在多个字段，等等。为了能够实现对链路的测试，一方面，需要将同一链路涉及到的全部数据库、数据表中的数据同步到线下。另一方面，由于在将数据从线上同步到线下的过程中，需要对部分数据(例如涉及到用户隐私的数据等)进行脱敏处理，而不同数据表中的不同字段之间的数据值可能会具有数据血缘关系，在进行脱敏处理时，对于这种存在数据血缘关系的数据值，需要采用相同的脱敏规则进行处理。

例如，在同一链路执行的过程中，通过同一查询条件进行数据库查询时，可能会命中A两个数据表中的m字段上的数据值x，以及B数据表中的n字段上的数据值y，则数据值x与数据值y之间就属于存在数据血缘关系的数据值。对于上述存在数据血缘关系的数据值，在从线上同步到线下以提供给测试***使用的过程中，需要使用相同的脱敏规则进行脱敏处理。例如，上述例子中，具有血缘关系的数据值x与数据值y，是与某用户的手机号码相关的数据，其中，如果数据值x采用的脱敏规则是将后四位用“*”代替，则数据值y也需要将后四位用“*”代替，否则，如果数据值y使用的脱敏规则是将后八位都用“*”代替，则在线下的测试***中使用这种数据时可能会出错。

也就是说，本申请实施例中，一方面，需要获知同一链路具体涉及到哪些数据库中的哪些数据表，另一方面，需要确定出上述同一链路涉及到的数据库以及数据表中，哪些字段上的数据值之间是具有数据血缘关系的。而要做到这两个点是很难的，因为一些***(例如，商品信息服务等***)中一个场景往往涉及前中台多个(几十、几百很常见)应用，如果通过人工方式进行整理，则需要多个域的专家根据经验人工输出同一链路上涉及到的数据库表以及数据值之间的血缘关系，工作量巨大。如果基于链路跟踪***的日志来进行分级，则也存在一些问题，例如，一方面，链路跟踪***中记录的同一链路上的应用可能不全(例如，可能存在一些隐藏的应用无法被链路跟踪***跟踪到)，涉及到的数据库表也就会存在不够全面的问题；另一方面，由于具体的应用在实际运行过程中，为了提升效率，会存在大量的缓存读取，也即，在首次通过访问数据库的方式获取到一些数据之后，会保存在缓存中，之后再次使用时，直接从缓存中读取，而不再需要访问数据库。而由于缓存中保存的数据通常是将多个数据库返回的数据进行聚合之后的结果，因此，读缓存的过程无法确定具体的数据来自于哪些数据库哪些数据表，因此，链路跟踪***也就无法记录下具体数据来自哪些数据库的哪些数据表，进而也更加无法确定哪些数据值之间存在数据血缘关系。

针对上述情况，在本申请实施例提供了相应的解决方案，以期以更高的效率，获得关于链路上更完整的数据库表信息，以及数据值之间的数据血缘关系信息。具体的，本申请实施例可以在在线数据逻辑环境下执行具体链路的过程中，对具体涉及到的数据库读取情况进行截获。其中，由于具体链路上的应用在被调用过程中会涉及到大量的缓存读取请求，因此，在本申请实施例中，还可以进行“缓存击穿”处理，也即，将缓存读取进行失效处理，从而通过读取数据库的方式获取相关数据。这样可以获取到链路执行过程中，关于数据库调用的更完整的信息，进而通过对这些信息进行分析，可以确定出目标链路中具体涉及到哪些数据库表，以及哪些数据值之间存在数据血缘关系。

为了达到上述目的，一种方式下，可以通过修改具体应用的代码的方式来实现，也即，在应用的代码中加入对探测标识的识别，调用请求的拦截，缓存击穿，数据库返回结果的拦截等处理逻辑。或者，在另一种方式下，为了避免入侵具体应用的代码，还可以提供专门的插件程序，并在具体链路涉及到的多个应用中部署这种插件程序，从而可以通过该插件程序对探测标识的识别，调用请求的拦截，缓存击穿，数据库返回结果的拦截等处理逻辑。

从***架构角度而言，参见图1，本申请实施例中可以提供数据关系分析***，在可选的方式下，还可以提供插件程序，这种插件程序可以部署到具体链路相关的应用中。例如，图1所示的例子中，假设某目标链路中涉及到应用A、B、C、D，其中，应用A为链路的入口应用，在链路执行过程中，应用A调用应用B，应用B再调用应用C，应用C再调用应用D。在本申请实施例中，可以在上述四个应用中都部署具体的插件程序。这样，在启动对目标链路的探测流程之后，就可以通过插件程序截获具体应用被调用的调用请求，之后，如果在响应该调用请求的过程中，涉及到缓存读取，则该插件程序还可以进行缓存击穿，使得具体的数据请求能够直接到达数据库。之后，插件程序还可以根据数据库的返回结果，获取到数据库查询记录信息，并将这种数据库查询记录信息与当前目标链路的链路标识之间的对应关系，保存到数据关系分析***。在当前的目标链路的探测流程结束后，数据关系分析***就可以通过对插件程序提供的信息进行分析，确定出该目标链路具体涉及到哪些数据库，数据表，以及哪些数据库中哪些数据表在哪些字段上存在具有数据血缘关系的数据值，等等。其中，关于链路标识，具体可以由插件程序通过查询链路跟踪***来获得。

下面对本申请实施例提供的具体实现方案进行详细介绍。

首先，本申请实施例首先提供了一种获取数据关系信息的方法，参见图2，该方法具体可以包括：

S201：针对待探测的目标链路，通过启动执行所述目标链路，并在启动请求中携带探测标识，发起对所述目标链路的探测流程；其中，所述目标链路上包括多个应用。

在本申请实施例中，可以通过在链路执行的过程中，对具体链路进行探测的方式，确定出具体链路涉及到哪些数据库、数据表，以及这些数据库、表中哪些字段上的数据值之间具有数据血缘关系。

具体实现时，为了提升探测结果的准确度，可以在相关应用的线上数据逻辑环境下发起对目标链路的探测流程。其中，相关应用就是具体链路上涉及到的应用，通常为多个。线上数据逻辑环境可以有多种，例如，可以指是在应用实际在线上运行的环境，此时，具体的应用使用线上数据库的处理逻辑为用户提供服务，可以在此状态下对具体链路进行探测。或者，出于数据的安全性等考虑，在优选的实施方式下，可以在相关应用的预发环境下对具体的链路进行探测。其中，对于具体的应用***而言，在开发出具体的应用之后，通常会为应用提供多种运行环境，例如，包括测试环境，前述预发环境，以及实际上线发布后的真实环境。其中，测试环境下，主要利用一下线下的数据库对应用进行离线的测试，正式上线发布的真实环境就是用于为用户的实际访问等过程提供服务，而预发环境则主要用于对相关应用进行验证。但是，预发环境通常是直接使用线上数据逻辑，也即与正式上线发布的应用使用相同的数据逻辑，只不过在预发环境下发起具体请求时，使用的可能会是一些虚拟的参数，例如，在预发环境下发起下单链路时，具体的用户账号等可能是虚拟账号，而不是某个实际消费者用户的账号，等等。因此，在预发环境下更适合进行本申请实施例相关的链路探测。需要说明的是，对于具体的应用而言，预发环境是一直存在的，也即，即使某个应用已经正式上线发布，该环境也存在。

在上述预发环境下，具体的应用通常会被部署到一些机器上运行，如前文所述，在通过插件程序来实现本申请实施例相关的调用请求拦截、缓存击穿等处理，则具体就可以在这些应用所在的机器上部署具体的插件程序。当然，为了避免对预发环境下其他的正常流程造成过多影响，可以选择在部分机器上安装插件程序，例如，假设某应用被部署到5台机器上，可以仅在其中一台机器上为该应用部署插件程序。同时，具体的插件程序中还可以实现路由功能，也即，在一个应用需要对其下游应用进行调用时，可以通过该插件程序将具体的调用请求路由到该应用对应的部署有插件程序的机器上，对此，后文会有详细介绍。

其中，具体发起链路探测的方式可以有多种。例如，在一种方式下，由于可以部署数据关系分析***，在链路探测过程中获取到的相关数据就可以汇总到该数据关系分析***，以便通过该数据关系分析***对同一链路标识对应的多条数据库查询记录进行数据血缘关系分析。在这种情况下，可以通过所述数据关系分析***提供的启动界面，接收对所述目标链路的入口应用/服务以及参数的配置信息，以用于启动执行所述目标链路，并在启动请求中携带探测标识。其中，对于一个具体的目标链路而言，可以通过一些方式获取到其入口应用，也即，可以知晓该链路的起点，例如在图1所示的例子中，应用A就是对应链路的起点，当然，在具体实现时，一个应用通常关联多个服务，一个服务还可能关联多个方法，具体链路的起点可以具体到具体应用中的服务、方法等。因此，具体的数据关系分析***在提供上述启动界面时，如图3所示，可以提供用于输入具体链路入口应用、服务、方法等信息的控件，当然，如果具体的服务地址等已经包含应用的信息，则也可以不必单独提供用于输入具体应用信息的控件；另外还可以提供用于输入具体参数的控件，等等。这样，在指定具体链路的入口应用/服务、方法之后，可以通过设定具体的参数，来启动该链路在应用预发环境下的执行。并且，在具体的启动请求中，会携带具体的探测标识，使得后续下游应用获知当前的请求是用于进行链路探测，以便与普通链路进行区别处理。

也就是说，假设当前需要对下单链路进行探测，则可以在数据关系分析***提供的启动界面中，指定下单链路的入口服务、方法等信息，并设定具体的参数，之后，便可以发起对该链路的探测，相应的，数据关系分析***会自动在启动请求中添加探测标识。

或者，另一种方式下，还可以在通过网页浏览器展示所述目标链路的入口应用提供的目标页面的状态下，启动执行所述目标链路，其中，所述网页浏览器中部署有浏览器插件程序，以用于在所述启动请求中携带所述探测标识。也就是说，除了可以通过数据关系分析***启动对目标链路的探测，也可以直接在链路的入口应用的相关界面中进行发起，例如，某链路的入口应用是应用A，则可以在预发环境下应用A所在的机器上发起具体对该链路的探测。具体的，假设该链路是下单链路，则可以通过浏览器访问应用A，并在应用A的相关页面中发起下单操作。当然，由于在本申请实施例中，需要将探测流程与普通流程进行区分，因此需要在启动具体的链路时，在启动请求中添加探测标识。为了达到该目的，在具体实现时，本申请还可以提供浏览器插件，在浏览器中安装该浏览器插件后，通过该浏览器访问某应用并启动某个链路之后，具体的启动请求中就可以添加上具体的探测标识。

在一条目标链路被启动之后，相关的各个应用就会按照该链路中预先配置好的调用关系来执行调用，直到链路结束(在此期间，不再需要人工干预)，本申请实施例就是在上述各个应用被调用的过程中，进行相关数据的收集，以用于进行数据血缘关系的分析。

为了能够达到上述收集相关数据的目的，如前文所述，可以在相关应用中添加具体的代码，或者，为了避免对应用造成代码入侵，还可以通过在相关应用中部署具体插件程序的方式来实现。其中，无论何种方式，都可以预先获知具体链路上具体涉及哪些应用，具体的，由于多应用协同工作的场景下，通常会有部署有链路跟踪***，因此，可以通过该链路跟踪***的日志等，获知具体一条链路上涉及到哪些应用。然后，对应用进行代码改造或者安装相关插件程序即可。当然，可能存在一些隐藏的应用无法体现在链路跟踪***中的日志中的情况，但是，对于这种隐藏的应用，在通过线上数据逻辑执行具体链路的过程中是会被发现的，因此，在启动对一条链路的探测之后，如果发现某个应用尚未在代码中实现探测相关的逻辑，或者尚未部署具体的插件程序，则可以暂停当前的探测流程，提示用户对该应用进行代码改造或者插件部署之后，再重新启动对该链路的探测。

这里需要说明的是，对于一条目标链路而言，在理想的情况下，只需要启动一次链路探测流程即可，但是，如果存在链路中部分应用尚未完成代码改造或者插件部署等情况，则可能会需要针对该同一链路发起多次链路探测，才能够完成完整的探测。另外，还有可能存在一些情况是，同一条链路在使用不同的参数进行启动时，所涉及到的数据库、数据表等可能会有所不同，在这种情况下，也可以通过多次发起对该链路的探测，并变换参数类型等方式，获取到关于该链路更完整的数据探测结果，等等。

S202：在所述探测流程中，对所述应用接收到的带有所述探测标识的调用请求进行拦截处理。

在具体目标链路被启动，并在启动请求中携带探测标识后，对该链路的探测流程就被启动。之后，在链路上的各个应用之间按照设定好的逻辑进行调用的过程中，就可以通过应用中添加的代码或者部署的插件程序(为便于描述，下面均以通过插件程序实现为例进行介绍)，执行具体的数据收集过程。

其中，为了执行具体的数据收集，链路上的每个应用都可以执行如步骤S202至S204的处理。也即，在每个应用被调用，接收到具体的调用请求后，具体的插件程序都可以对请求进行拦截，判断请求是否带有探测标识，如果没有探测标识，则可以直接放行，按照普通流程处理即可，如果带有探测标识，则由该插件程序接管后续对该调用请求的响应工作。这里需要说明的是，在具体实现时，还可以在应用中为具体的插件程序配置开关功能，可以通过该功能控制插件程序的开启或者关闭。

这里需要说明的是，关于具体应用接收到的调用请求，通常是来自于链路中的上游应用，不同应用之间可以通过预先配置的协议进行通信，以用于发起具体的调用请求。例如，具体可以包括HSF(High-speed Service Framework，高速服务框架)协议等，各个应用可以在HSF***中对各自提供的服务进行注册，其他应用则可以通过该协议向其他应用注册的服务发起调用，以消费该服务，等等。在本申请实施例中，一条链路上的多个应用之间就是基于上述协议进行应用之间的服务调用。因此，在这种情况下，具体拦截到的调用请求就可以是这种HSF请求，等等。

S203：在响应所述调用请求的过程中，将涉及到的读取缓存请求进行缓存失效处理，以使得通过所述应用关联的数据库中进行数据查询。

在具体拦截到调用请求，并发现其带有探测标识后，可以由具体的插件程序来响应该调用请求。其中，具体的调用请求中，需要当前应用执行的处理可能分为以下几个方面：读取数据库操作，读取缓存操作，向下游应用发起进一步的调用请求相关的操作等。其中，如果涉及到直接读取数据库的请求，则可以将该请求放行，并拦截具体数据库的返回结果，当然，还可以记录具体请求中的查询条件等信息。

而如果涉及到读取缓存的请求，则本申请实施例中就可以执行缓存击穿处理，也即，通过一些方式，为该请求返回关于缓存失效的相关消息，以使其转为向具体的数据库发起请求。也就是说，在实际应用中，一个应用在访问缓存时，如果发现缓存数据已经失效(要么不存在想要的数据，要么数据已经超时，等等)，则会自动向相关的数据库发起读取数据请求。因此，本申请实施例中就是利用了该特点，不管缓存是否真正失效，都统一由插件程序返回关于缓存已失效的消息，从而直接通过访问数据库的方式获取具体的数据，这样才能够获取到关于当前目标链路具体涉及到哪些数据库、数据表、字段等完整的信息。

其中，具体在对缓存操作进行失效处理时，可以有多种方式，还可以根据不同缓存类型的特点，选择对应的失效处理方式。例如，如果当前的缓存***中，需要通过缓存ID等对具体的缓存数据进行标识，则可以返回无效的缓存ID；如果当前的缓存***中，在获取缓存数据之前需要首先确定缓存是否已超时，则统一返回已超时，等等。

具体如，对于Tair MDB(Message Driven Bean，信息驱动类)类的缓存***，可以修改所有Tair相关的get请求中的namespace参数，让其请求数据关系分析***设定的namespace，由于该namespace返回结果为空，因此，就会自动进入数据库逻辑。

或者，对于Guava类的缓存***，可以通过修改缓存数据是否已过期的结果，也即，让所有缓存数据都是过期的，那么就会自动触发数据库逻辑。当然，在具体实现时，还可以按应用做白名单控制，只有白名单内的才会进行Guava缓存击穿。

再或者，对于Tair3.0(Redis)类的缓存***，可以修改获取数据请求方法的参数值，让它找不到对应的数据，那么具体的请求就会走到数据库逻辑。在此情况下，可以按Redis地址和Key等参数进行白名单控制，只有白名单内的才会做Redis缓存击穿。

需要说明的是，虽然本申请实施例中在对链路进行探测的过程中，进行了缓存击穿处理，使得具体的数据请求统一走数据库逻辑，而这一过程无疑会使得数据读取的效率受到影响，但是，一方面，由于链路探测的目的主要是获取关于一条链路上完整的数据库表等信息，因此，时间因素不是首要考虑的问题；另一方面，由于链路探测的执行次数是很有限的，相对于其他走正常流程的流量而言，链路探测仅占其中很小的比例，而正常流程下，该走缓存的仍然会继续走缓存，不会受到插件程序的影响，尤其是仅在部分机器上部署插件程序的情况下，因此，也不会从整体上对***性能造成过多影响。

S204：对数据库查询请求以及返回结果进行截获处理，以获取到数据库查询记录后，保存其与所述目标链路的链路标识之间的对应关系；所述数据库查询记录包括：查询条件信息，以及数据库返回的数据值及其所在的字段、库表标识信息。

由于进行了缓存击穿处理，因此，具体的数据请求全部走数据库逻辑，之后，还可以通过插件程序等对具体数据库返回的结果进行截获，以此获取到具体的数据查询记录。在本申请实施例中，由于涉及到对链路上涉及到的数据库表的确定，以及对数据血缘关系的分析，因此，具体的数据查询记录可以包括：查询请求中的查询条件信息，以及数据库返回的数据值及其所在的字段、库表标识信息。

其中，关于查询条件信息，由于插件程序对应用接收到的调用请求进行了拦截，因此，可以从具体数据库访问相关的请求中获取查询条件信息。例如，具体通过SQL(Structured Query Language，结构化查询语言，是一种数据库语言)进行数据库查询的情况下，可以通过select语句来指定查询条件，也即，通过Select语句返回用指定的条件在一个数据库中查询的结果，因此，就可以对该Select语句中指定的查询条件值以及返回结果进行拦截，以得到具体的查询条件信息，以及返回的数据值。另外，还可以获取到该数据值所在的字段以及库表(也即，具***于哪个数据库中的哪个数据表)标识信息。

具体实现时，具体的应用***中针对分布式数据库产生的相关问题，可能会使用数据库中间件对数据库进行封装，使得分布式数据库具有多层结构，例如通过Group层对数据库进行分组，以实现数据库读写分离、主备切换等功能，通过Matrix层进行规则管理，SQL语句的解释等。在这种情况下，具体对数据库相关数据的拦截可以分为两部分，一部分可以是对中间层(例如，Group层)的拦截，用于获取数据库、表、以及分库分表相关的数据(包括数据库标识，数据表标识，字段标识等)，另一部分用于对Matrix层进行拦截，获取sql相关的请求数据和返回结果(也即具体的查询条件以及数据值)。

在获取到上述数据库查询记录信息后，由于一个应用中可能涉及到多次数据库查询，同一链路上又涉及到多个不同的应用，这些应用可能分布在不同的机器上，此时，可能会需要将各自获得数据库查询记录汇总到数据关系分析***进行分析处理。因此，为了便于数据关系分析***确定哪些数据库查询记录是同一链路中产生的，具体的插件程序还可以记录具体的数据库查询记录与链路标识之间的对应关系。其中，关于链路标识，具体可以是通过链路跟踪***获取到的，其中，对于一些大型的应用***，由于具体的应用数量众多，链路众多，每条链路上需要多个应用相互配合，因此，通常都会配备相应的链路跟踪***。这样，在一条链路被启动之后，链路跟踪***会自动为该链路产生链路标识，因此，可以通过查询链路跟踪***的方式获取到当前目标链路的链路标识。

当然除了进行缓存击穿处理之外，可能还会涉及到对下游应用的调用，此时，如果如前文所述是在应用的预发环境中进行的链路探测，并且仅在同一应用所在的部分机器中部署插件程序，则在对下游应用进行调用时，还可以首先查询出具体下游应用在哪台机器上部署了插件程序，然后可以将具体的调用请求路由到这台机器上。

具体实现时，可以在数据关系分析***中提供配置中心，通过该配置中心对具体应用进行插件程序配置，例如，针对某应用，可以指定在哪台机器上部署插件程序，并将该应用与具体部署有插件程序的机器设备的IP地址等之间的对应关系进行保存。这样，在具体某个应用的插件程序需要向下游应用发起调用时，就可以首先以该下游应用的标识等为参数，向上述配置中心发起查询，配置中心则可以返回该下游应用对应的配置有插件程序的机器设备的IP地址等信息。进而，当前应用的插件程序将对下游应用的调用请求路由到该IP地址即可。

另外，在向下游应用发送调用请求时，具体的插件程序还可以在调用请求中添加探测标识，以使得下游应用中的插件程序通过识别该探测标识，按照具体的探测流程进行处理。

S205：通过对同一链路标识对应的多条数据库查询记录进行分析，确定所述目标链路相关的库表信息，以及所述目标链路上存在数据血缘关系的数据值及其所在的字段。

当一条链路上的全部应用都已经完成调用，并相关的数据库也返回数据，则完成了对一条链路的探测，当然，如前文所述，同一条链路可能需要进行多次探测，才能够收集到完整的数据。总之，在对同一条链路探测完成后，可以收集到具体的数据，也即涉及到的数据库查询记录等，之后，便可以根据这些数据库查询记录进行分析，以确定所述目标链路相关的库表信息，以及所述目标链路上存在数据血缘关系的数据值及其所在的字段。

其中，如前文所述，由于同一链路上的多个应用可能分散在多个不同的机器设备上，因此，每个应用部署的插件程序可以统一将数据库查询记录与链路标识之间的对应关系保存到数据关系分析***，在该***对数据进行分析。其中，在进行分析时，可以针对当前目标链路，确定出对应的链路标识，然后，取出该链路标识对应的多条数据库查询记录进行分析。具体在进行分析时，由于每条数据库查询记录中可以记录有对应的数据库、数据表等标识，因此，通过将同一链路标识对应的多条数据库记录中分别记录的数据库、数据表标识进行汇总去重，即可得到该链路具体涉及哪些数据库表。另外，在进行数据血缘关系分析时，可以分别对多条数据库查询记录中分别包括的查询条件以及返回数据值进行分析，其中，如果所述同一链路标识关联的多条数据库查询记录中，存在同一查询条件对应的多个相同的数据值，则将所述多个相同的数据值确定为存在数据血缘关系的数据值。

具体实现时，可以通过以下步骤来进行：针对探测到的数据库查询记录中包括的SQL信息，可以首先将Update的SQL语句解析成Select语句；然后，解析SQL结果，按值聚合表字段，再便利Select的条件字段，获取与Select条件字段值一致的表字段。

例如，在同一链路标识对应的多条数据库查询记录中，同样以某个商品的商品ID作为查询条件，其中数据库A中，数据表m中x字段的某条具体数据值命中该查询条件，另外，数据库B中，数据表n中y字段的某条具体数据值也命中该查询条件，则这两个数据值之间存在数据血缘关系，从而确定数据库A中，数据表m中的x字段，与数据库B中，数据表n中的y字段之间存在数据血缘关系。

其中，在按照上述进行数据血缘分析的过程中，还可以按照一定的规则进行过滤。例如，数据值为数字类型且小于等于10，或者，布尔类型，或者字符串类型且长度小于等于3，或者，字段名中包含状态(status)、类型(type)等，都可以排除数据血缘关系。

在得到上述分析结果之后，可以通过数据关系分析***进行展示，例如，可以展示出当前链路关联的数据库、数据表清单，以及哪些数据库、数据表中的哪些字段之间存在数据血缘关系，等等。这样，用户可以根据这些信息，从线上数据库向线下进行数据同步，例如，可以将当前链路关联的全部数据库、数据表中的数据全量同步到线下，并且，在同步过程中，针对其中具有数据血缘关系的字段上的数据进行脱敏处理时，使用相同的脱敏规则。另外，还可以将具体数据血缘关系的推导过程，包括具体数据值关联的查询条件值等，展示给用户(需要使用数据血缘关系进行数据同步等处理的人员)，使得用户不仅可以获知哪些字段之间存在数据血缘关系，还可以知晓这些字段存在数据血缘关系的原因。

需要说明的是，在具体实现时，由于具体探测过程是读取线上的数据库，但是，由于插件程序的缺陷或者应用自身的代码缺陷等原因，在数据库读取过程中可能会出现死循环的情况，因此，还可以对数据库的读取做防死循环的处理。具体的，可以对一次调用过程中数据库读取次数进行记录，例如，某个数据库已反复读取数千次，且每次返回的数据值都相同，则可以发出告警，在后续的调用过程中，还可以限制该数据库的读取次数，等等。另外，关于具体的告警信息等还可以同步到相关云计算服务平台提供的日志***中，以用于进行标准化监测。

本申请实施例提供的具体方案可以在多种具体的应用场景中使用。例如，在社区团购***的部署前期，需要打通线下链路，此时，就可以使用本申请实施例提供的方法对各个链路进行探测，获取到商品创建发布、商详、基础资料等相关链路具体涉及到哪些数据建库、表，以及哪些字段，辅助了相关链路的线下打通

总之，通过本申请实施例可以在执行具体链路的过程中，进行链路探测，具体在探测时，可以对链路中具体应用接收到的调用请求进行拦截，并在响应这种调用请求的过程中，对读取缓存请求进行缓存失效处理，以使得通过所述应用关联的数据库中进行数据查询，进而，再通过对数据库查询请求以及返回结果的截获，获取到数据库查询记录信息，其中可以包括查询条件信息，以及数据库返回的数据值及其所在的字段、库表标识信息。进而，在链路探测结束后，就可以通过对同一链路标识对应的多条数据库查询记录进行分析，确定所述目标链路相关的库表信息，以及所述目标链路上存在数据血缘关系的数据值及其所在的字段。通过这种方式，可以通过自动化的方式确定出一条链路上关联有哪些数据库、数据表，以及这些数据库、数据表中哪些字段之间具有数据血缘关系，并且由于不需要借助专家经验，因此，准确性以及效率都更高。另外，由于是在具体执行链路过程中进行数据收集，因此，可以获取到关于具体链路上更完整的数据库相关的信息。

其中，为了避免入侵具体应用的代码，还可以提供插件程序，通过在应用的预发环境中部署这种插件程序，可以通过插件程序执行调用请求的拦截，缓存击穿，数据截获等处理。另外，具体的插件程序可以仅在同一应用对应的部分预发机器上部署，同时通过插件程序实现向这种机器设备的定向路由，以避免对预发环境下的正常流量造成过多影响。

需要说明的是，本申请实施例中可能会涉及到对用户数据的使用，在实际应用中，可以在符合所在国的适用法律法规要求的情况下(例如，用户明确同意，对用户切实通知，等)，在适用法律法规允许的范围内在本文描述的方案中使用用户特定的个人数据。

与前述方法实施例相对应，本申请实施例还提供了一种获取数据关系信息的装置，参见图4，该方法具体可以包括：

探测流程启动单元401，用于针对待探测的目标链路，通过启动执行所述目标链路，并在启动请求中携带探测标识，发起对所述目标链路的探测流程；其中，所述目标链路上包括多个应用；

请求拦截处理单元402，用于在所述探测流程中，对所述应用接收到的带有所述探测标识的调用请求进行拦截处理；

缓存失效处理单元403，用于在响应所述调用请求的过程中，将涉及到的读取缓存请求进行缓存失效处理，以使得通过所述应用关联的数据库中进行数据查询；

数据截获处理单元404，用于对数据库查询请求以及返回结果进行截获处理，以获取到数据库查询记录后，保存其与所述目标链路的链路标识之间的对应关系；所述数据库查询记录包括：查询条件信息，以及数据库返回的数据值及其所在的字段、库表标识信息；

分析单元405，用于在所述目标链路探测结束后，通过对同一链路标识对应的多条数据库查询记录进行分析，确定所述目标链路相关的库表信息，以及所述目标链路上存在数据血缘关系的数据值及其所在的字段。

具体实现时，所述探测流程启动单元具体可以用于：

在相关应用的线上数据逻辑环境下启动执行所述目标链路，并在启动请求中携带探测标识，以发起对所述目标链路的探测流程。

其中，所述相关应用的线上数据逻辑环境包括：所述相关应用的预发环境，所述预发环境是用于基于线上数据逻辑对相关应用进行验证的环境。

具体实现时，所述对应关系可以保存到数据关系分析***，以便通过所述数据关系分析***对同一链路标识对应的多条数据库查询记录进行分析；此时，所述探测流程启动单元具体可以用于：

通过所述数据关系分析***提供的启动界面，接收对所述目标链路的入口应用/服务以及参数的配置信息，以用于启动执行所述目标链路，并在启动请求中携带探测标识。

或者，所述探测流程启动单元具体可以用于：

在通过网页浏览器展示所述目标链路的入口应用提供的目标页面的状态下，启动执行所述目标链路，其中，所述网页浏览器中部署有浏览器插件程序，以用于在所述启动请求中携带所述探测标识。

其中，所述目标链路上包括的多个应用中可以部署有目标插件程序，以便通过所述插件程序执行所述拦截处理，并在响应所述调用请求的过程中进行缓存失效处理，以及截获数据库的返回结果，将数据库查询记录与所述目标链路的链路标识之间的对应关系保存到数据关系分析***的处理。

其中，如果在相关应用的预发环境发起对所述目标链路的探测流程，则在预发环境下，同一应用部署在多台机器设备上，并可以仅在其中部分机器设备中部署所述目标插件程序；

此时，该装置还可以包括：

请求路由单元，用于在通过所述插件程序响应所述调用请求的过程中，如果涉及到对下游应用的调用，则查询所述下游应用关联的部署有所述目标插件程序的目标机器设备，并将所述对下游应用的调用请求路由到所述目标机器设备上。

另外，还可以包括：

探测标识添加单元，用于在对所述调用请求进行拦截处理后，如果涉及到对下游应用的调用，则在对所述下游应用的调用请求中添加所述探测标识。

具体的，缓存失效处理单元具体可以用于：

在向所述读取缓存请求返回缓存地址信息时，返回无效地址，以进行所述缓存失效处理。

或者，缓存失效处理单元具体也可以用于：

在向所述读取缓存请求返回缓存状态信息时，返回缓存已超时信息，以进行所述缓存失效处理。

具体的，所述分析单元具体可以用于：

如果所述同一链路标识关联的多条数据库查询记录中，存在同一查询条件对应的多个相同的数据值，则将所述多个相同的数据值确定为存在数据血缘关系的数据值。

另外，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述方法实施例中任一项所述的方法的步骤。

以及一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行前述方法实施例中任一项所述的方法的步骤。

其中，图5示例性的展示出了电子设备的架构，具体可以包括处理器510，视频显示适配器511，磁盘驱动器512，输入/输出接口513，网络接口514，以及存储器520。上述处理器510、视频显示适配器511、磁盘驱动器512、输入/输出接口513、网络接口514，与存储器520之间可以通过通信总线530进行通信连接。

其中，处理器510可以采用通用的CPU(Central Processing Unit，处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器520可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器520可以存储用于控制电子设备500运行的操作***521，用于控制电子设备500的低级别操作的基本输入输出***(BIOS)。另外，还可以存储网页浏览器523，数据存储管理***524，以及数据关系分析处理***525等等。上述数据关系分析处理***525就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器520中，并由处理器510来调用执行。

输入/输出接口513用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口514用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线530包括一通路，在设备的各个组件(例如处理器510、视频显示适配器511、磁盘驱动器512、输入/输出接口513、网络接口514，与存储器520)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器510、视频显示适配器511、磁盘驱动器512、输入/输出接口513、网络接口514，存储器520，总线530等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***或***实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的***及***实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的数据关系分析方法、装置及电子设备，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (14)

1.一种数据关系分析方法，其特征在于，包括：

针对待探测的目标链路，通过启动执行所述目标链路，并在启动请求中携带探测标识，发起对所述目标链路的探测流程；其中，所述目标链路上包括多个应用；

在所述探测流程中，对所述应用接收到的带有所述探测标识的调用请求进行拦截处理；

在响应所述调用请求的过程中，将涉及到的读取缓存请求进行缓存失效处理，以使得通过所述应用关联的数据库中进行数据查询；

对数据库查询请求以及返回结果进行截获处理，以获取到数据库查询记录后，保存其与所述目标链路的链路标识之间的对应关系；

通过对同一链路标识对应的多条数据库查询记录进行分析，确定所述目标链路相关的库表信息，以及所述目标链路上存在数据血缘关系的数据值及其所在的字段。

2.根据权利要求1所述的方法，其特征在于，

所述通过启动执行所述目标链路，并在启动请求中携带探测标识，发起对所述目标链路的探测流程，包括：

在相关应用的线上数据逻辑环境下启动执行所述目标链路，并在启动请求中携带探测标识，以发起对所述目标链路的探测流程。

3.根据权利要求2所述的方法，其特征在于，

所述相关应用的线上数据逻辑环境包括：所述相关应用的预发环境，所述预发环境是用于基于线上数据逻辑对相关应用进行验证的环境。

4.根据权利要求1所述的方法，其特征在于，

所述对应关系用于保存到数据关系分析***，以便通过所述数据关系分析***对同一链路标识对应的多条数据库查询记录进行分析；

所述通过启动执行所述目标链路，并在启动请求中携带探测标识，发起对所述目标链路的探测流程，包括：

通过所述数据关系分析***提供的启动界面，接收对所述目标链路的入口应用/服务以及参数的配置信息，以用于启动执行所述目标链路，并在启动请求中携带探测标识。

5.根据权利要求1所述的方法，其特征在于，

所述通过启动执行所述目标链路，并在启动请求中携带探测标识，发起对所述目标链路的探测流程，包括：

在通过网页浏览器展示所述目标链路的入口应用提供的目标页面的状态下，启动执行所述目标链路，其中，所述网页浏览器中部署有浏览器插件程序，以用于在所述启动请求中携带所述探测标识。

6.根据权利要求1所述的方法，其特征在于，

所述目标链路上包括的多个应用中部署有目标插件程序，以便通过所述插件程序执行所述拦截处理，并在响应所述调用请求的过程中进行缓存失效处理，以及截获数据库的返回结果，将数据库查询记录与所述目标链路的链路标识之间的对应关系保存到数据关系分析***的处理。

7.根据权利要求6所述的方法，其特征在于，

在相关应用的预发环境发起对所述目标链路的探测流程；其中，在预发环境下，同一应用部署在多台机器设备上，并在其中部分机器设备中部署所述目标插件程序；

所述方法还包括：

在通过所述插件程序响应所述调用请求的过程中，如果涉及到对下游应用的调用，则查询所述下游应用关联的部署有所述目标插件程序的目标机器设备，并将所述对下游应用的调用请求路由到所述目标机器设备上。

8.根据权利要求1所述的方法，其特征在于，还包括：

在对所述调用请求进行拦截处理后，如果涉及到对下游应用的调用，则在对所述下游应用的调用请求中添加所述探测标识。

9.根据权利要求1至8任一项所述的方法，其特征在于，

所述将涉及到的读取缓存请求进行缓存失效处理，包括：

在向所述读取缓存请求返回缓存地址信息时，返回无效地址，以进行所述缓存失效处理。

10.根据权利要求1至8任一项所述的方法，其特征在于，

所述将涉及到的读取缓存请求进行缓存失效处理，包括：

在向所述读取缓存请求返回缓存状态信息时，返回缓存已超时信息，以进行所述缓存失效处理。

11.根据权利要求1至8任一项所述的方法，其特征在于，

所述数据库查询记录包括：查询条件信息，以及数据库返回的数据值及其所在的字段、库表标识信息；

所述通过对同一链路标识对应的多条数据库查询记录进行分析，确定所述目标链路相关的库表信息，以及所述目标链路上存在数据血缘关系的数据值及其所在的字段，包括：

如果所述同一链路标识关联的多条数据库查询记录中，存在同一查询条件对应的多个相同的数据值，则将所述多个相同的数据值确定为存在数据血缘关系的数据值。

12.一种数据关系分析装置，其特征在于，包括：

探测流程启动单元，用于针对待探测的目标链路，通过启动执行所述目标链路，并在启动请求中携带探测标识，发起对所述目标链路的探测流程；其中，所述目标链路上包括多个应用；

请求拦截处理单元，用于在所述探测流程中，对所述应用接收到的带有所述探测标识的调用请求进行拦截处理；

缓存失效处理单元，用于在响应所述调用请求的过程中，将涉及到的读取缓存请求进行缓存失效处理，以使得通过所述应用关联的数据库中进行数据查询；

数据截获处理单元，用于对数据库查询请求以及返回结果进行截获处理，以获取到数据库查询记录后，保存其与所述目标链路的链路标识之间的对应关系；

分析单元，用于通过对同一链路标识对应的多条数据库查询记录进行分析，确定所述目标链路相关的库表信息，以及所述目标链路上存在数据血缘关系的数据值及其所在的字段。

13.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现权利要求1至11任一项所述的方法的步骤。

14.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行权利要求1至11任一项所述的方法的步骤。

Images