中国银联作为一家科技型金融支付公司，除了完成自己的本质清算和支付职责外，每天还会产生大量的宝贵业务数据。这些数据按业务类型分类可以划分成一千多张表，在一些复杂场景中，有的表可能会有数百个字段。许多表与表、字段与字段之间的关系，并不是相互独立的。在分析一张表的时候，很容易联想到一个问题，是哪几张表生成了这张表，其中的某个字段又是怎么加工得来的。
为了回答这个问题，有做出各种尝试，最直接的就是找一个精通各个业务数据的人，把所有数据间的关系整理出来。但是这种人工的方式，在实际操作之中，会遇到各种困难：1、整理人员可能精通几类业务数据，银联数据规模庞大，很难找到精通所有数据的人；2、数据结构和逻辑不是一成不变的，会随着业务变动而更新，需要大量人力去做后期维护，并且这样数据关系变动体现出来具有滞后性；3、人工整理出来的文档形式，基本上会以Excel表格的形式为主，实战中在查看一张表在血缘追溯的时候，效率会变得低下，需要花费大量的时间来回反转索引表名以及字段名。
所以本文给大家展示一种数据血缘技术方案，通过定期扫描离线库所有的批量代码脚本，提取SQL并对SQL进行词法语法解析，并把解析结果存储到图数据库，并以可视化的界面展示出来。
1 现有技术方案
1.1现有技术实现的方法和现有技术架构
现有血缘跟踪方案主要是依靠解析一条通用SQL语句，如果是复杂SQL语句的话，会依次解析出每个select结构，再对每个select结构提取输入表（可能多个）和输出表（包括中间表），最后对所有的select结构进行结果的整合（整理去除中间表的过程）。
1.2现有技术存在的缺点或问题
1）现有方案是通用SQL方案，并不完全适用于大数据领域，目前绝大多数科技公司所使用的大数据生态是Hadoop和Hive。而Hive语法允许中间表重名，所以无法按照表名来索引（填写和读取）每个select结构的局部血缘。
2）现有方案只能针对表做血缘跟踪，对于这个结果并不是很满意。研究希望除了表的血缘跟踪，还能够了解到字段级的信息。
3）现有方案解决单句SQL的血缘分析，但是对所有数据资产仍然缺乏全局统一管理【1】。
2 数据血缘技术方案的技术效果
1）数据血缘技术方案是针对大数据领域的血缘追溯，对Hive Sql有天然的良好适应性。
2）数据血缘技术方案不仅有对表信息的整理，还会对字段级信息进行规整，功能性更为强大。
3）在收集到所有单条Sql信息后，把数据放到图库（综合考虑最为合适的选型），把全部数据资产信息持久化并联系起来。
4）研究制定的是成套的大数据血缘追溯解决方案，最后会落实并形成一个实时服务。该服务一是会定时自动更新血缘关系；二是根据查询需求订制api访问接口，包括不限于数据治理和根因分析等业务场景【2】。
3 数据血缘技术方案的发明点
3.1大数据Hive Sql适配
首先是把Hive Sql解析成一棵AST抽象语法树。在Hive Sql中可以有同名表的存在，同名表的信息会在context中覆盖（用表名做key），上文提到去除中间字段过程会读取context内容，所以如果更新context表时机不对，就会影响到最终结果。最佳状态是按照sql执行计划来填充context，这里使用递归分析来解决这个问题：在遇到 select多层嵌套结构体中，先不要解析外层select，而是递归到内层优先分析内部select结构。例如select m.f3 from (select m.f1,b.f3 from (select f1 from a where a.partition = '20220519') m left join b on m.f1 = b.f1) m where m.f1 > 0 这句语句中优先解析select f1 from a where a.partition = '20220519'，然后再解析select m.f1,b.f3 from m left join b on m.f1 = b.f1,最后解析 select m.f3 from m where m.f1 > 0。
3.2设置全局context对中间数据索引
针对每句Sql分析设计了一个全局的context ,这个context的结构是 map的map。一级map的key是每个输入输出表的表名（包括涉及的中间表），二级map的key是输入表的字段名，二级map的value是个由表名和字段名组成的数据结构的数组，也就是存储了这个字段的上一级（在这句sql中的）血缘关系。
下面举例本研究程序是如何填充这个数组的：case a.f1 = 0 then b.f3 when a.f1 = 1 then concat(c.f3, d.f4) else '' as org_name。Q在这句sql中，org_name这个字段是由a.f1, b.f3, c.f3, d.f4决定的，所以这四个字段会同时填写在org_name字段的数组中。
在完成单个表的所有数组填写后。接下来要做的就是去除中间字段的过程：遍历当前表所有字段的结果数组，如果包含中间表的字段，必须在context中查找并替换成这个中间表的上一级血缘，假设（理论上不存在，因为是深度优先的递归分析，只是做为一种程序健壮性上的容错）上一级血缘中仍包含中间表字段，这个过程必须被重复，直到这个数组中的所有字段都是输入表字段为止。这个时候去除中间表的过程就结束了。
在分析Sql所有涉及表的情况时，会循环处理数组填充和去除中间字段这两个过程，直到所有分析完成。
3.3 Sql分析结果整合和持久化设备
市面上有很多种不同类型的数据库，图库是存储这些信息的最佳介质。相比于传统范式表结构，血缘信息更像是一种关系网络：表和字段做为实体，父子关系做为单向箭头。这一点完美契合了图数据库的存储特性。选择图数据库的理由有二：图库对于关系网络的分布式计算效率远远高于把数据从传统数据库里捞出来做单核内存计算，或直接在关系型数据库单表自连接（join）几十次。特别是一些拥有丰富数据资产的大公司，血缘查询的计算效率和响应时间是很重要的系统指标；在一些特定场景，表与表之间存在循环引用，图库在这方面有优化处理，允许设置最大搜索深度。
3.4 一体化解决方案
从一开始的数据搜集、分析处理、到最后的展示渠道，都有成熟的解决方案。
数据收集主要有两个来源：git定期下载开发代码获取sql；连接到hive实例获取元数据。本研究方案还是以从代码中获取和分析sql为主，hive元数据主要是为了解决一些特殊情况，例如select *。
数据存储到图库后会定时更新，不希望同时读和写引发数据的不一致性，所以在本研究方案引入了MVCC多版本控制。写只会新增一个新的版本，当新版本的数据全部导入完成时，会更新当前版本号到新版本，这样就可以读到最新的内容。另外有一个垃圾回收器，定时清理不需要的旧版本，释放资源。
展示端会根据查询需求订制api访问接口，例如输入表名正向追溯血缘、逆向追溯血缘、查看两表间是否存在关系等。用户访问服务接口即可获得结果，无需手动查阅字典【3】。
4 结语
综上所述，这种数据血缘技术方案不仅可以从宏观层面查看数据的集中分布情况、数据的热度、节点的冗余情况，还可以查看是否存在多余数据、重复数据、冗余链路、无效链路等问题，为数据管理者提供源端的数据汇总到数据中台的整个流程概况。此外，这种数据血缘技术方案还能追踪和定位问题所在、增加数据分析、提高数据处理的灵活性，从而保障数据加工过程的易用可控。
参考文献
[1] 叶天琦,沈春锋.数据血缘可视化分析平台研究与应用[J].信息技术与标准化,2020(11):17-20.
[2] 张岩,刘晓芸.商业银行信息系统中“血缘分析”技术的应用研究[J].信息技术与信息化,2017(06):147-149.
[3] 程世豪. 面向元数据血缘关系的映射技术及实现[D].西南财经大学,2020.
