本公开涉及数据处理
技术领域：
：，具体涉及一种基于结构数据的数据血缘确定方法、装置、电子设备及计算机可读存储介质。
背景技术：
：：数据血缘目前没有统一的定义，可以大致理解为数据产生的链路。数据血缘描述了一张表依赖了哪些表，以及表里的字段是如何生成的，更进一步甚至描述了这些字段又依赖于其它表的哪些字段。通过数据血缘可以知道数据生产的上下游依赖关系。数据血缘主要应用在大数据领域，作为背景知识，先来了解一下大数据的整个生产流程。大数据的整体生产流程一般分为数据源、生产、仓库、数据应用四层，数据源以业务库的mysql为主，其次是hdfs或ftp的文件、kafka或mq等，生产层面以etl系统为主。数据的例行生产由底层事实表和维度表开始，基于事实和维度生产一些中间表，然后再生成聚合表。当业务体量很大的时候，整个系统会用到上千上万张表，表与表之间会形成非常复杂的依赖关系。数据血缘主要用来解决大数据领域的数据可解释性问题，数据可解释是所有大数据团队需要面临的一个难题，数据可解释性主要包含两个方面：数据口径和数据依赖关系。etl开发者经常面临的一个问题就是要向数据使用方解释你的数据是如何生产出来的。在业内常见的生产依赖关系都是数据表和生产任务之间的依赖，对于生产任务具体用到了上游数据表中的哪些字段只有在编码逻辑中才能体现，是无法暴露给数据使用方的。即数据使用方仅仅看到了数据生产的结果，但是对于数据生产的流程完全是黑盒子，并不了解，一种解决办法是把数据生产中使用的sql语句(一般是select和插入语句)从代码中抽离出来，做成可配置项，这样通过对配置文件(主要是sql语句)的解析即可得出数据上下游的生产依赖关系，也即数据的血缘，这样就可以做到数据的可解释、生产过程的可解释，极大降低了数据解释成本。现有数据血缘实现方案一般都只做到了表级别粒度的解析，即对于一张目标表可以追溯得出它的来源于某张表或者某几张表。可以通过一个具体的示例来了解一下现有的技术方案，设想一个外卖的场景，每个月都想统计一下商户的月订单量，那么一般会对订单明细表(t_order)和配送信息表(t_order_logistics_info)做一个关联查询，然后将查询的结果存入一个名称叫商户月订单的表(t_order_shop_all_daily)中，之所以要关联查询是因为在系统设计阶段，为了便于系统的开发和维护，会对业务进行分库分表的拆分，例如跟订单相关的业务数据会被拆分后分别存入订单表、用户表、商户表、商品表、物流配送表等，如此一来要得出商户的月订单量就要去查询订单表和配送信息表，这样生产出的商户月订单表就和订单表和配送信息表产生了上下游依赖关系。现有的数据血缘实现方案可以实现这种依赖关系的解析，通过解析选择(select)语句可以得到源表表名t_order和t_order_logistics_info，通过插入语句得到目标表表名t_order_shop_all_daily，然后可以得到表与表之间的依赖关系，但是如果想了解商户月订单表到底依赖了订单表和物流信息表的哪些字段，现有的技术方案就解决不了了。设想一个这样的使用场景，某张表t由于在当初设计阶段的不合理现在已不能满足当前的使用需求，需要对表结构进行调整，可能会删除字段c，但是该表已经在生产环境运行了一段时间，是很多表的上游依赖，这时就需要明确有哪些表的哪些字段依赖于t表将要删除的字段c，但是现有的数据血缘实现，只能得出表级别的依赖关系，对于字段级别的依赖无能为力，所以只能依靠人工的手段去筛选和查找，如果系统中有上千张表，会耗费非常多的人力成本，而且也无法避免统计出现差错和疏漏。再设想一个场景，每天分析人员都会使用sql到大数据平台查询种指标以进行分析使用，如果每一个查询系统都能在秒级时间进行响应会有非常好的用户体验，但是不可避免有些查询会花费很长时间，为了提升数据产出效率，需要针对用户的使用习惯对系统的表结构进行优化，这就需要对用户使用的sql中的表和字段进行统计，得到表的热度和字段热度信息，首先要关注和优化的就是那些用户使用频繁的表和字段，而现有技术是无法满足这一需求的。随着互联网的飞速发展，因为网络应用而产生的数据也在呈爆发式增长，如何有效得管理大数据的生产，做到数据的可解释就成为一个迫切要解决的问题，但是针对数据的生产现有的数据血缘实现方案只能做到表粒度级别的解析，这就无法做到数据的精细化管理，因此，亟待提出一种能对基于结构数据的数据血缘实现字段级别粒度的解析。技术实现要素：本公开实施例提供一种基于结构数据的数据血缘确定方法、装置、电子设备及计算机可读存储介质，以实现对基于结构数据的数据血缘在字段级别粒度的解析。第一方面，本公开实施例中提供了一种基于结构数据的数据血缘确定方法。具体的，所述基于结构数据的数据血缘确定方法，包括：解析结构数据中的选择语句得到源抽象语法树，并将遍历所述源抽象语法树得到的表信息和字段信息逐层组织到源清单中；所述源清单中的表称为源表；解析结构数据中的插入语句得到目标抽象语法树，并将遍历所述目标抽象语法树得到的表信息和字段信息逐层组织到目标清单中；所述目标清单中的表称为目标表；遍历源清单获取源表信息，并遍历目标清单获取目标表信息，得到表粒度的数据血缘关系；从所述目标清单中取出目标表的目标字段信息，从所述源清单的第一层开始逐层找到与所述目标表的目标字段信息同名的源表中的源字段，直到所述源字段所属的源表不再来源于子查询时将对应的源字段确定为目标字段信息对应的具有血缘关系的源字段；所述目标字段信息的数量为至少一个。结合第一方面，本公开在第一方面的第一种实现方式中，所述源清单及目标清单包括至少一个层，每个层至少包括一张表，每张表至少包括一个字段，所述结构数据在所述源清单或所述目标清单的层数为所嵌套子查询的层数与预设阈值的和值，关联查询与联合查询的表与主表均在同一层。结合第一方面和第一方面的第一种实现方式，本公开在第一方面的第二种实现方式中，所述从所述源清单的第一层开始逐层找到与所述目标表的目标字段信息同名的源表中的源字段，直到所述源字段所属的源表不再来源于子查询时将对应的源字段确定为目标字段信息对应的具有血缘关系的源字段包括：将所述目标表的目标字段信息与所述源清单的第一层的源表中的字段进行匹配，找到同名的源字段；判断所述同名的源字段所属的源表是否来源于子查询；若所述同名的源字段所属的源表不来源于子查询，则将所述同名的源字段确定为所述目标字段信息对应的具有血缘关系的源字段；若所述同名的源字段所属的源表来源于子查询，则将所述同名的源字段与所述源清单中从第二层开始逐层的源表中的源字段进行匹配，找到同名的另一源字段，直到所述另一源字段所属的源表不再来源于子查询时将对应的源字段确定为目标字段信息对应的具有血缘关系的源字段。结合第一方面、第一方面的第一种实现方式和第一方面的第二种实现方式，本公开在第一方面的第三种实现方式中，所述源清单及目标清单中每一层的表的名称包含其所属表的名称信息。结合第一方面、第一方面的第一种实现方式、第一方面的第二种实现方式和第一方面的第三种实现方式，本公开在第一方面的第四种实现方式中，所述解析结构数据中的选择语句得到源抽象语法树包括：若所述选择语句为第一类型的语句，则使用与第一类型的语句相关联的解析器生成第一抽象语法树；若所述选择语句为第二类型的语句，则使用与第二类型的语句相关联的解析器生成第二抽象语法树；若所述选择语句为第三类型的语句，则使用与第三类型的语句相关联的解析器生成第三抽象语法树；所述源抽象语法树包括第一抽象语法树、第二抽象语法树及第三抽象语法树。结合第一方面、第一方面的第一种实现方式、第一方面的第二种实现方式、第一方面的第三种实现方式和第一方面的第四种实现方式，本公开在第一方面的第五种实现方式中，所述解析结构数据中的插入语句得到源抽象语法树包括：若所述插入语句为第一类型的语句，则使用与第一类型的语句相关联的解析器生成第四抽象语法树；若所述插入语句为第二类型的语句，则使用与第二类型的语句相关联的解析器生成第五抽象语法树；若所述插入语句为第三类型的语句，则使用与第三类型的语句相关联的解析器生成第六抽象语法树；所述目标抽象语法树包括第四抽象语法树、第五抽象语法树及第六抽象语法树。第二方面，本公开实施例中提供了一种基于结构数据的数据血缘确定装置。具体的，所述基于结构数据的数据血缘确定装置，包括：源清单生成模块，被配置为解析结构数据中的选择语句得到源抽象语法树，并将遍历所述源抽象语法树得到的表信息和字段信息逐层组织到源清单中；所述源清单中的表称为源表；目标清单生成模块，被配置为解析结构数据中的插入语句得到目标抽象语法树，并将遍历所述目标抽象语法树得到的表信息和字段信息逐层组织到目标清单中；所述目标清单中的表称为目标表；数据血缘关系确定模块，被配置为遍历源清单获取源表信息，并遍历目标清单获取目标表信息，得到表粒度的数据血缘关系；从所述目标清单中取出目标表的目标字段信息，从所述源清单的第一层开始逐层找到与所述目标表的目标字段信息同名的源表中的源字段，直到所述源字段所属的源表不再来源于子查询时将对应的源字段确定为目标字段信息对应的具有血缘关系的源字段；所述目标字段信息的数量为至少一个。结合第二方面，本公开在第二方面的第一种实现方式中，所述源清单及目标清单包括至少一个层，每个层至少包括一张表，每张表至少包括一个字段，所述结构数据在所述源清单或所述目标清单的层数为所嵌套子查询的层数与预设阈值的和值，关联查询与联合查询的表与主表均在同一层。结合第二方面和第二方面的第一种实现方式，本公开在第二方面的第二种实现方式中，所述数据血缘关系确定模块进一步被配置为：将所述目标表的目标字段信息与所述源清单的第一层的源表中的字段进行匹配，找到同名的源字段；判断所述同名的源字段所属的源表是否来源于子查询；若所述同名的源字段所属的源表不来源于子查询，则将所述同名的源字段确定为所述目标字段信息对应的具有血缘关系的源字段；若所述同名的源字段所属的源表来源于子查询，则将所述同名的源字段与所述源清单中从第二层开始逐层的源表中的源字段进行匹配，找到同名的另一源字段，直到所述另一源字段所属的源表不再来源于子查询时将对应的源字段确定为目标字段信息对应的具有血缘关系的源字段。结合第二方面和第二方面的第一种实现方式，本公开在第二方面的第三种实现方式中，所述源清单及目标清单中每一层的表的名称包含其所属表的名称信息。结合第二方面和第二方面的第一种实现方式，本公开在第二方面的第四种实现方式中，所述源清单生成模块被配置为：若所述选择语句为第一类型的语句，则使用与第一类型的语句相关联的解析器生成第一抽象语法树；若所述选择语句为第二类型的语句，则使用与第二类型的语句相关联的解析器生成第二抽象语法树；若所述选择语句为第三类型的语句，则使用与第三类型的语句相关联的解析器生成第三抽象语法树；将所述第一抽象语法树、第二抽象语法树及第三抽象语法树组成所述源抽象语法树；将遍历所述源抽象语法树得到的表信息和字段信息逐层组织到源清单中。结合第二方面和第二方面的第一种实现方式，本公开在第二方面的第五种实现方式中，所述源清单生成模块被配置为：所述目标清单生成模块被配置为：若所述插入语句为第一类型的语句，则使用与第一类型的语句相关联的解析器生成第四抽象语法树；若所述插入语句为第二类型的语句，则使用与第二类型的语句相关联的解析器生成第五抽象语法树；若所述插入语句为第三类型的语句，则使用与第三类型的语句相关联的解析器生成第六抽象语法树；将所述第四抽象语法树、第五抽象语法树及第六抽象语法树组成所述目标抽象语法树；将遍历所述目标抽象语法树得到的表信息和字段信息逐层组织到目标清单中。第三方面，本公开实施例提供了一种电子设备，包括存储器和处理器，所述存储器用于存储一条或多条支持基于结构数据的数据血缘确定装置执行上述第一方面中基于结构数据的数据血缘确定方法的计算机指令，所述处理器被配置为用于执行所述存储器中存储的计算机指令。所述基于结构数据的数据血缘确定装置还可以包括通信接口，用于基于结构数据的数据血缘确定装置与其他设备或通信网络通信。第四方面，本公开实施例提供了一种计算机可读存储介质，用于存储基于结构数据的数据血缘确定装置所用的计算机指令，其包含用于执行上述第一方面中基于结构数据的数据血缘确定方法为基于结构数据的数据血缘确定装置所涉及的计算机指令。本公开实施例提供的技术方案可以包括以下有益效果：上述技术方案，通过源清单和目标清单中对表信息和字段信息进行分层管理，实现基于结构数据能查找字段间的依赖关系，实现基于结构数据的数据血缘实现字段级别粒度的解析。应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。附图说明结合附图，通过以下非限制性实施方式的详细描述，本公开的其它特征、目的和优点将变得更加明显。在附图中：图1示出根据本公开一实施方式的基于结构数据的数据血缘确定方法的流程图；图2示出根据图1所示实施方式的基于结构数据的数据血缘确定方法中的源清单及目标清单的数据结构的层次关系示意图；图3示出根据本公开另一实施方式的基于结构数据的数据血缘确定方法的流程图；图4示出根据本公开一实施方式的待分析的结构数据示意图；图5示出根据本公开一实施方式的基于结构数据的数据血缘确定方法对图4所示结构数据建立的分层清单示意图；图6示出根据本公开一实施方式的一种基于结构数据的数据血缘确定方法确定的结构数据对应的清单；图7示出根据本公开一实施方式的基于结构数据的数据血缘确定方法对图6所示清单调整表名之后的清单；图8示出根据本公开另一实施方式的待分析的结构数据中的选择语句；图9示出根据本公开一实施方式的基于结构数据的数据血缘确定方法对图8处理之后的清单；图10示出本公开另一实施方式的待分析的结构数据中的插入语句；图11示出根据本公开一实施方式的基于结构数据的数据血缘确定方法对图10处理之后的清单；图12示出根据本公开一实施方式的基于结构数据的数据血缘确定方法对图10处理之后的清单及对图8处理之后的清单处理之后得到的表粒度的数据血缘关系；图13示出根据本公开一实施方式的基于结构数据的数据血缘确定方法对图10处理之后的清单及对图8处理之后的清单处理之后得到的字段粒度的数据血缘关系；图14示出根据本公开一实施方式的结构数据的数据血缘确定装置的结构框图；图15示出根据本公开一实施方式的电子设备的结构框图；图16是适于用来实现根据本公开一实施方式的基于结构数据的数据血缘确定方法的计算机系统的结构示意图。具体实施方式下文中，将参考附图详细描述本公开的示例性实施方式，以使本领域技术人员可容易地实现它们。此外，为了清楚起见，在附图中省略了与描述示例性实施方式无关的部分。在本公开中，应理解，诸如“包括”或“具有”等的术语旨在指示本说明书中所公开的特征、数字、步骤、行为、部件、部分或其组合的存在，并且不欲排除一个或多个其他特征、数字、步骤、行为、部件、部分或其组合存在或被添加的可能性。另外还需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开。本公开实施例提供的技术方案通过针对数据血缘经常要解析的包含子查询、关联查询和联合查询的复杂结构数据(例如，sql语句)，采用分层的思想对解析器的ast信息进行重新组织，然后根据字段名称逐层向下匹配查找源字段的目标字段，从而实现字段粒度级别的数据血缘解析，在用户需要知道某个字段的生产链路的情况下就可以给出精确的说明，解决了数据的可解释性问题，这也为大数据的生产过程提供了更精细化的管理和调控手段，具有巨大的实用价值。图1示出根据本公开一实施方式的基于结构数据的数据血缘确定方法的流程图。其中结构数据可以包括各种类型的结构化数据、结构化语言、结构化表述方式等。为了清楚起见，本申请以结构化查询语言sql语句作为结构数据的实例进行说明，但所属领域技术人员应当了解的是，本申请并不限于sql语言。此外，本申请将mysql、hive和impala工具和相应的解析器作为具体实例进行说明，同样地，所属领域技术人员应当了解的是，本申请并不限于使用mysql、hive和impala工具和相应的解析器，而是可以使用任何数据处理工具和相应的解析器。如图1所示，所述基于结构数据的数据血缘确定方法包括以下步骤s101-s103：在步骤s101中，解析结构数据中的选择语句得到源抽象语法树，并将遍历所述源抽象语法树得到的表信息和字段信息逐层组织到源清单中；所述源清单中的表称为源表；在步骤s102中，解析结构数据中的插入语句得到目标抽象语法树，并将遍历所述目标抽象语法树得到的表信息和字段信息逐层组织到目标清单中；所述目标清单中的表称为目标表；在步骤s103中，遍历源清单获取源表信息，并遍历目标清单获取目标表信息，得到表粒度的数据血缘关系；从所述目标清单中取出目标表的目标字段信息，从所述源清单的第一层开始逐层找到与所述目标表的目标字段信息同名的源表中的源字段，直到所述源字段所属的源表不再来源于子查询时将对应的源字段确定为目标字段信息对应的具有血缘关系的源字段；所述目标字段信息的数量为至少一个。该方法采用了一种分层的思想，即源清单和目标清单中对表信息和字段信息进行分层管理使得查找字段间的依赖关系成为可能，并能有效的解决字段热度的统计问题。本实施例采用的分层的数据结构，其数据结构的层次关系如图2所示：其中，所述源清单及目标清单包括至少一个层，每个层至少包括一张表，每张表至少包括一个字段，结构数据(例如，sql语句)在所述源清单或所述目标清单的层数为所嵌套子查询的层数与预设阈值(该预设阈值可以但不限定为1)的和值，关联查询与联合查询的表与主表均在同一层。具体如图2所示，从上至下依次为层、表、字段，每一层可以包含一张或多张表，每张表可以包含一个或多个字段，对于某条sql，如果该sql不包含子查询，则该sql的层数为一层，如果嵌套了一层子查询，则层数为二层，以此类推，关联查询(join)的表与主表在同一层，联合查询(union)的表与主表也在同一层。在本实施例的一个可选实现方式中，如图3所示，所述步骤s101，即解析sql语句中的选择语句得到源抽象语法树的步骤，包括以下步骤：(1)判断所述选择语句是否为mysql语句；(2)若所述选择语句为mysql语句，则使用druid解析器生成第一抽象语法树；(3)判断所述选择语句是否为hive语句；(4)若所述选择语句为hive语句，则使用hive解析器生成第二抽象语法树；(5)判断所述选择语句是否为impala语句；(6)若所述选择语句为impala语句，则使用impala解析器生成第三抽象语法树。继续图3所示，所述步骤s102，即解析sql语句中的插入语句得到目标抽象语法树的步骤，包括以下步骤：(1)判断所述插入语句是否为mysql语句；(2)若所述插入语句为mysql语句，则使用druid解析器生成第一抽象语法树；(3)判断所述插入语句是否为hive语句；(4)若所述插入语句为hive语句，则使用hive解析器生成第二抽象语法树；(5)判断所述插入语句是否为impala语句；(6)若所述插入语句为impala语句，则使用impala解析器生成第三抽象语法树。所述步骤s103，即从所述目标清单中取出目标表的目标字段信息，从所述源清单的第一层开始逐层找到与所述目标表的目标字段信息同名的源表中的源字段，直到所述源字段所属的源表不再来源于子查询时将对应的源字段确定为目标字段信息对应的具有血缘关系的源字段；所述目标字段信息的数量为至少一个的步骤，包括以下步骤：将所述目标表的目标字段信息与所述源清单的第一层的源表中的字段进行匹配，找到同名的源字段；判断所述同名的源字段所属的源表是否来源于子查询；若所述同名的源字段所属的源表不来源于子查询，则将所述同名的源字段确定为所述目标字段信息对应的具有血缘关系的源字段；若所述同名的源字段所属的源表来源于子查询，则将所述同名的源字段与所述源清单中从第二层开始逐层的源表中的源字段进行匹配，找到同名的另一源字段，直到所述另一源字段所属的源表不再来源于子查询时将对应的源字段确定为目标字段信息对应的具有血缘关系的源字段。在本实施方式中，对sql解析之前，会对sql语句的类型进行判断，针对mysql、hive和impala三种类型分别使用不同的sql解析器进行解析，虽然三种解析器生成的ast结构不同，但是最终会将表和字段的信息统一组织到sqllayer中，这样表和字段级血缘依赖分析以及表和字段热度统计的代码只需针对sqllayer编程即可，降低了程序的实现难度。以具有多层嵌套查询和关联查询的复杂sql语句为例，解释分层实现方案，sql语句如图4所示，该sql语句运用上面的分层思想可以抽象表示成如图5所示的形式。从图5可以清晰的看出图4所示的复杂sql语句可以分成上图所示的3层，第一层包含1张表t，第二层包含3张表，第三层包含6张表，第二层的s1与s2，s3之间是leftjoin关联关系，用图中带加号的绿色圆圈表示。向下的箭头表示该表还有子查询，通过分层之后，可以清晰看出该条sql的组织结构，从而便于下一步的血缘分析。在真正开始字段级依赖分析之前，还需要解决一个问题，问题如下图6所示，从图6可以看出，这条sql语句也是分了3层，这条语句的问题在于在不同的层之间存在同名的表，例如在3层中都存在表名为a的表，这样在做字段级依赖解析的时候就会出现混淆，设想一个字段来源于第三层的a表，如果不对3个a表进行区分，如果按照表名查找，就可能将该字段解析到第二层的a表(如果恰巧这两个不同的a表含有同名字段)，解决的办法如图7所示，在sqltable类中定义了一个parent属性，用来保存该表所属的上一层的路径名，第二层的a表的parent为b，即第一层的b表，第三层的a表的parent为e.t，即第一层e表下的b表，因为同一层不会关联查询同名的表，所以parent加上表名就会成为一张表的唯一标识，如上图所示，第一层的a表为a，第二层的a表为b.a，第三层的a表为e.t.a，这样就可以唯一区分同名的表了。为了说明如何做到字段级血缘依赖的解析，再举一个例子，这次有两条sql，一条选择语句，一条插入语句，选择语句负责从源表查询出所需的字段，为了说明如何进行逐层查找，利用具有两层结构然后不算复杂的选择语句，插入语句负责向目标表插入字段，目标是找出插入语句中所插入的字段是来源于选择语句的哪一张表，选择语句如图8所示，该选择语句用分层思想可以表示成如图9所示结构。这次的分层结构图中包含每个表下的select字段的信息，可以看到第一层由aleftjoinb构成，a表包含一个子查询，b表也包含一个子查询，子查询都位于第二层。接下来再看插入语句，如图10所示。插入语句比较简单，分层结构图如图11所示。插入语句只包含一层结构，里面只有一张表，该表下包含3个字段，下面以business_num字段为例来说明如何进行血缘关系的查找。首次会从选择语句的第一层开始查找business_num的同名字段，查询结果为：sum(a.business_num)asbusiness_num即business_num来源于表a的business_num，逐层查找的关键点是，找到匹配字段后要对表的类型做判断，即要判断表a是否包含子查询，sqltable类有一个属性issubquery是用来表征该表是否包含子查询，如果不包含则停止查找，认为表a的business_num即为插入语句business_num的源字段，如果包含子查询则需要继续向下一层查找，因为这里表a包含子查询，所以需要继续查找，在第二层parent＝a的表中继续查找能匹配表a的business_num的字段，注意这里需要匹配的字段已经由t_district_result表的business_num替换成了a表的business_num，即每向下一层都会做源字段的替换，在第二层查找的结果是：count(if(flag＝3,shop_id,null))asbusiness_num即business_num来源于表t_business的flag和shop_id字段，注意这里也会将if判断条件中的flag字段算作business_num的源字段，因为business_num在生产的时候的确用到了flag字段，然后继续判断表t_business是否包含子查询，因为t_business是一张实表，所以business_num的血缘解析就结束了，它的源字段就是表t_business的flag和shop_id字段。同理可以继续解析t_district_result表的district_id和business_rate字段，最终会得到如下图12的数据表级依赖和如图13的数据字段级依赖关系。下述为本公开装置实施例，可以用于执行本公开方法实施例。图14示出根据本公开一实施方式的基于结构数据的数据血缘确定装置的结构框图，该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。如图14所示，所述基于结构数据的数据血缘确定装置包括：源清单生成模块1401，被配置为解析结构数据中的选择语句得到源抽象语法树，并将遍历所述源抽象语法树得到的表信息和字段信息逐层组织到源清单中；所述源清单中的表称为源表；目标清单生成模块1402，被配置为解析结构数据中的插入语句得到目标抽象语法树，并将遍历所述目标抽象语法树得到的表信息和字段信息逐层组织到目标清单中；所述目标清单中的表称为目标表；数据血缘关系确定模块1403，被配置为遍历源清单获取源表信息，并遍历目标清单获取目标表信息，得到表粒度的数据血缘关系；从所述目标清单中取出目标表的目标字段信息，从所述源清单的第一层开始逐层找到与所述目标表的目标字段信息同名的源表中的源字段，直到所述源字段所属的源表不再来源于子查询时将对应的源字段确定为目标字段信息对应的具有血缘关系的源字段；所述目标字段信息的数量为至少一个。这里需要说明：上述实施例提供的基于结构数据(例如，sql语句)的数据血缘确定装置可实现上述各方法实施例中描述的技术方案，上述各模块或子模块具体实现的原理可参见上述各方法实施例中的相应内容，此处不再赘述。本公开还公开了一种电子设备，图15示出根据本公开一实施方式的电子设备的结构框图，如图15所示，所述电子设备1500包括存储器1501和处理器1502；其中，所述存储器1501用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器1502执行以实现上述任一方法步骤。图16适于用来实现根据本公开实施方式的结构数据的数据血缘确定方法的计算机系统的结构示意图。如图16所示，计算机系统1600包括中央处理单元(cpu)1601，其可以根据存储在只读存储器(rom)1602中的程序或者从存储部分1608加载到随机访问存储器(ram)1603中的程序而执行上述实施方式中的种处理。在ram1603中，还存储有系统1600操作所需的程序和数据。cpu1601、rom1602以及ram1603通过总线1604彼此相连。输入/输出(i/o)接口1605也连接至总线1604。以下部件连接至i/o接口1605：包括键盘、鼠标等的输入部分1606；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分1607；包括硬盘等的存储部分1608；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分1609。通信部分1609经由诸如因特网的网络执行通信处理。驱动器1610也根据需要连接至i/o接口1605。可拆卸介质1611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1610上，以便于从其上读出的计算机程序根据需要被安装入存储部分1608。特别地，根据本公开的实施方式，上文描述的方法可以被实现为计算机软件程序。例如，本公开的实施方式包括一种计算机程序产品，其包括有形地包含在及其可读介质上的计算机程序，所述计算机程序包含用于执行所述sql语句的数据血缘确定方法的程序代码。在这样的实施方式中，该计算机程序可以通过通信部分1609从网络上被下载和安装，和/或从可拆卸介质1611被安装。附图中的流程图和框图，图示了按照本公开种实施方式的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，路程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。描述于本公开实施方式中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定。作为另一方面，本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施方式中所述装置中所包含的计算机可读存储介质；也可以是单独存在，未装配入设备中的计算机可读存储介质。计算机可读存储介质存储有一个或者一个以上程序，所述程序被一个或者一个以上的处理器用来执行描述于本公开的方法。以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离所述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。当前第1页12当前第1页12