2022数据血缘关系详解

在数据资产管理与数据治理领域，数据之间的血缘关系是一个绕不开的话题，数据血缘的完备程度也是评价一个企业数据中台成熟度的重要度量之一。到底什么是数据血缘，它对于数据工作者和数据使用者有哪些举足轻重的作用呢？

一、从数据应用场景看什么是数据血缘

1.数据问题排查与运维

工作日早上上班，业务人员打开电脑看到昨日数据报表同比下降60%，于是找到数据部门“你们数据是不是有问题？”。

常见数据异常的原因包括：

1. 及时性问题，大数据集群资源不足或者平台系统故障导致任务延迟
2. 代码质量问题，开发修改逻辑，导致数据清洗逻辑有误带来数据不准
3. 业务规则变更，业务变动数据加工代码未及时更新
4. 源端脏数据问题，业务开发系统发布数据源问题导致结果错误

数据人员的排查路径如下：

第一步：找到报表指标来源的API接口，确定来源数据表（可能是GP表或者ClickHouse表）

第二步：查找GP表对应的数据同步任务，以及Hive表的产出任务，查看任务是否正常执行完毕

第三步：找到Hive表加工任务的上游，逐层向上排查，先保证整个链路的任务都是正常执行的，因为及时性问题是最高频、常见且容易处理的问题

第四步：检查数据加工流程各项正常后，再看指标产出表的加工代码，一是看是否近期有人为变更，二是翻代码校验对应的逻辑，按照指标加工的代码层级逐级定位有问题的数据表。

第五步：通过层层排查，定位了问题，但是问题的修复和数据重跑需要些时间，得赶紧通知下游，避免错误数据给业务带来的错误决策和应用，比如错把老客算成新客，带来营销费用损失，数据开发就要背锅了。

2.数据治理与成本优化

数据部门通常是一个企业的成本中心（toB商业化数据产品除外），一个中大型数据驱动的互联网企业大数据集群服务器一般会占公司服务器比例在15%~30%，一台服务器成本4W，每天10PB数据存储和计算处理量，大概需要1000+服务器节点，机器折旧周期3年算，平均个月也需要大几十万的硬件成本。

所以，数据部门除了做增量的业务支撑外，还要常态化的数据治理，把长期没人使用的冷数据进行删除，释放存储和计算资源。直接删库跑路肯定不行，删除或归档任何一个数据，都需要尽可能全面的确认到底有没有下游的业务方在使用。

3.数据血缘的定义

数据血缘，顾名思义，数据之间的血缘关系，好比人之间亲情远近亲疏一样。百科定义：数据血缘关系是指数据在产生、处理、流转到消亡过程中，数据之间形成的一种类似于人类社会血缘关系的关系。

数据血缘从数据角度可以是数据库、表、字段、系统、应用程序，即数据存储在什么数据库的什么表，对应的字段是什么以及字段的属性。从业务角度主要是数据所属业务线，涉及到业务便要梳理清楚数据的产生逻辑、数据的使用逻辑以及业务线之间的关联关系。

因为数据的生产加工最终是要回归和赋能业务，什么数据，被哪个业务场景使用，需要血缘关系进行串联。

二、数据血缘作用与表现形式

1.数据血缘的作用

开篇的场景中的案例是数据血缘的两个典型的作用，总结成一句话就是数据血缘可以帮助数据生产者以及消费者更好地对数据进行追根溯源，提升数据运维、数据治理的效率。

(1)提升数据问题排查效率

数据从生产到赋能业务应用经过很多的处理环节，业务端报表或数据应用服务异常时，需要第一时间定位问题，排查修复。

如果靠一层一层的人肉翻代码效率非常低下，一方面数据开发人力花费在排查上，另一方面定位问题时间越长业务影响和损失越大，基于血缘数据加以可视化的展现形式，可以直观地发现数据生产链路，以及各个环节有无异常。

(2)有助于优化数据资产成本

随着业务地发展数据不断增长，任务、数据表只增不减会不断膨胀大数据资源成本。很多时候不是不愿意做数据、服务治理，二是不敢。

也就是不知道对应的服务有哪些业务在使用，缺少治理的依据，与其直接下线带来业务影响，倒不如一直维持现状。构建全面准确的全链路数据血缘，就可以找出数据下游应用方，做好沟通和信息同步，长期没有调用的服务，及时做下线处理，节省数据成本。

(3)提升数据产品及应用体验

数据部门经常被业务Diss数据是不是有问题，长此以往，会降低业务对数据准确度的信任，搞数据的天天被打上数据不准的标签还是很无奈的。

在数据产出任务层面对数据质量的准确性、一致性、及时性、完整性等维度进行监控覆盖，触发报警机制后，利用数据血缘关系，对下游应用进行通知提醒。业务看到后，至少知道数据部门在处理问题了，不会利用错的数据做错误的决策，或者形成每次都是业务先发现问题的认知。

(4)方便确认数据处理逻辑

业务部门在使用数据时，有时候需要确认数据口径和加工逻辑是什么，是否符合自己的需求，通过血缘的可视化展示，可以方便业务部门查看数据的处理过程。

2.血缘的表现形式

每个数据表、字段、指标都可以认为是一个数据实体，而生产它的上游，以及使用它的下游，都是对应的数据实体之间的关系，因此，在血缘数据的可视化展示时，主要采用可以直观表示数据生产链路的形态，每个节点需要包含以下要素：

当前节点信息：名称、类型、状态

上游：关系、上游名称、类型、状态

下游：关系、上游名称、类型、状态

三、血缘数据获取与数据存储

1.血缘数据的获取方式

数据血缘的获取主要有程序解析与人工采集两种方式。比如流式数据处理的flink任务，从哪个源（source）的Kafka topic，加工清洗后，存储到哪个Sink，离线批处理任务Hive数仓模型，也可以基于SQL输入输出表进行解析得到。

数据开发调度任务之间的依赖关系等。一般早期时因技术和实现成本问题，血缘会以Hive数据源为主，但实际应用时，只有构建成全链路的数据血缘，才能最大发挥其价值。所以在相关数据平台、系统建设时，要有意识的进行血缘数据的采集。

人工采集主要是程序解析的辅助形式，毕竟从统计的概率上看，人比机器更容易犯错。对于一些Jar包短期难以解析的流程，可以辅以人工输入的形式。

2.血缘数据的存储演进

虽然传统的MySQL数据库也可以存储血缘数据，但是由于血缘数据的形态以及查询使用的场景对性能要求更高，所以在实际应用时，主要采用图数据库存储的方式。常见的图数据库的特点对比如下：

图片来源网络

四、总结

数据血缘是数据开发者效能提升利器，同时也是贯通数据采、存、管、用全链路流程的纽带，建立完善的数据血缘关系，数据应用的成熟度才会更高。针对数据血缘这一领域，也可以构建独立的数据产品模块，以数据产品提升血缘应用的效率。

从技术角度来讲，数据a通过ETL处理生成了数据b，那么，我们会说，数据a与数据b具有血缘关系。不过与人类的血缘关系略有不同，数据血缘关系还具有一些个性化的特征。

• 归属性数据是被特定组织或个人拥有所有权的，拥有数据的组织或个人具备数据的使用权，实现营销、风险控制等目的。
• 多源性这个特性与人类的血缘关系有本质上的差异，同一个数据可以有多个来源（即多个父亲），来源包括，数据是由多个数据加工生成，或者由多种加工方式或加工步骤生成。
• 可追溯数据的血缘关系体现了数据的全生命周期，从数据生成到废弃的整个过程，均可追溯。
• 层次性数据的血缘关系是具备层级关系的，就如同传统关系型数据库中，用户是级别最高的，之后依次是数据库、表、字段，他们自上而下，一个用户拥有多个数据库，一个数据库中存储着多张表，而一张表中有多个字段。它们有机地结合在一起，形成完整的数据血缘关系。如下图中某学校学生管理系统后台数据库的ER图示例，学生的学号、姓名、性别、出生日期、年级、班级等字段组成了学生信息表，学生信息表、教师信息表、选课表之间通过一个或多个关联字段组成了整个学生管理系统后台的数据库。

不管是结构化数据，还是非结构化数据，都具有数据血缘关系，他们的血缘关系或简单直接，或错综复杂，都是可以通过科学的方法追溯的。

以某银行财务指标为例，利息净收入的计算公式为利息收入减去利息支出，而利息收入又可以拆分为对客业务利息收入、资本市场业务利息收入和其他业务利息收入，对客业务利息收入又可以细分为信贷业务利息收入和其他业务利息收入，信贷业务利息收入还可以细分为多个业务条线和业务板块的利息收入。

如此细分下去，一直可以从财务指标追溯到原始业务数据，如，客户加权平均贷款利率和新发放贷款余额。如果利息净收入指标发现数据质量问题，其根因可以通过下图一目了然发现。

数据血缘追溯不只体现在指标计算上，同样可以应用到数据集的血缘分析上。不管是数据字段、数据表，还是数据库，都有可能与其他数据集存在着血缘关系，分析血缘关系对数据质量提升有帮助的同时，对数据价值评估、数据质量评估以及后续对数据生命周期管理也有较大的帮助和提高。

从数据价值评估角度来看，通过对数据血缘关系的梳理，我们不难发现，数据的拥有者和使用者，简单地来看，在数据拥有者较少且使用者（数据需求方）较多时，数据的价值较高。在数据流转中，对最终目标数据影响较大的数据源价值相对较高。同样，更新、变化频率较高的数据源，一般情况下，也在目标数据的计算、汇总中发挥着更高的作用，那可以判断为这部分数据源具有较高的价值。

从数据质量评估角度来看，清晰的数据源和加工处理方法，可以明确每个节点数据质量的好坏。

从数据生命周期管理角度来看，数据的血缘关系有助于我们判断数据的生命周期，是数据的归档和销毁操作的参考。

考虑到数据血缘的重要性和特性，以一般来讲，我们在血缘分析时，会关注应用（系统）级、程序级、字段级三个层次间数据间的关系。比较常见的是，数据通过系统间的接口进行交换和传输。

例如下图，银行业务系统中的数据，由统一数据交换平台进行流转分发给传统关系型数据库和非关系型大数据平台，数据仓库和大数据平台汇总后，交流各个应用集市分析使用。其中涉及大量的数据处理和数据交换工作：

在分析其中的血缘关系时，主要考虑以下几个方面：

1、全面性

如上图所示，数据处理过程实际上是程序对数据进行传递、运算演绎和归档的过程，即使归档的数据也有可能通过其他方式影响系统的结果或流转到其他系统中。为了确保数据流跟踪的连贯性，必须将整个系统集作为分析的对象。

2、静态分析法

本方法的优势是，避免受人为因素的影响，精度不受文档描述的详细程度、测试案例和抽样数据的影响，本方法基于编译原理，通过对源代码进行扫描和语法分析，以及对程序逻辑涉及的路径进行静态分析和罗列，实现对数据流转的客观反映。

3、接触****感染式分析法

通过对数据传输和映射相关的程序命令进行筛选，获取关键信息，进行深度分析。

4、逻辑时序性分析法

为避免冗余信息的干扰，根据程序处理流程，将与数据库、文件、通信接口数据字段没有直接关系的传递和映射的间接过程和程序中间变量，转换为数据库、文件、通信接口数据字段之间的直接传递和映射。

5、及时性

为了确保数据字段关联关系信息的可用性和及时性，必须确保查询版本更新与数据字段关联信息的同步，在整个系统范围内做到“所见即所得”。

一般来说，数据血缘的用途主要体现以下几个方面：

1、合规需求，这是监管部门的需求，为了监管合规，数据流动的各点和来源，都是重点需要监管的。

2、影响分析和质量问题分析，这个数据开发部们的核心需求，随着数据应用越来越多，数据的流动链越来越长，一个源头的核心业务的改动，下游各分析应用必须保持同步，没有影响分析，就会各个数据服务造成异常访问的情况。

3、数据安全和隐私****，这个是数据合规部门的需求，哪些数据是需要脱敏的，这个要保持全流通所有域的管控。

4、迁移项目，这个出现在特定老项目终止需要新项目接管的情况下，没有数据流动映射表，就会大量花时间去整理，也很难保证迁移的完整性和正确性。

5、自服务分析，数据分析团队为了确定数据可信程度，那么数据的来源是数据可信的重要依据。

数据血缘系统的构建和维护是一个较重的系统工程，笔者认为其是数据治理工作中的流沙之地，不小心会陷入这个坑之中，尤其是技术完美人格类型的负责人，这是因为数据血缘的工作需要考虑的因素很多。

为了最大程度降低项目失败的风险，我们需要考虑数据血缘的服务用户对象，确定业务方面和技术方面的血缘优先，需要考虑到细节程度，覆盖率，变化频率，同时还要考虑人员流动，组织部门，技术架构等情况，制定最适合我们自己的策略。

数据血缘的收集方法主要有以下几种：

1、自动解析

自动解析当前主要的收集方法，具体就是解析SQL语句，存储过程，ETL过程等文件。因为复杂代码和应用环境等原因，根据国际厂商的经验，自动解析可以覆盖到企业数据的70-95%，目前无法做到100%，因此患有技术洁癖的负责人容易犯下这个错误，即追求极高的覆盖率。

2、系统跟踪

这个方法就是通过数据加工流动过程中，加工主体工具负责发送数据映射，这样做的极大好处是收集精准，及时，细粒度可支持，不过限制就是不是每个工具都可以集成。这种方法一般鉴于统一的加工平台，比如Informatica可以管理自己的全数据血缘周期。

3、机器学习方法

这个方法是基于数据集之间的依赖关系，计算数据的相似度。这个方法的好处是对工具和业务没有依赖，缺点准确率需要人工确认，一般可以做到3-8的数据可以分析发现。

4、手工的收集

在整个项目中，一般有5%是需要手工来做的。

目前的数据血缘大多是基于技术的梳理，一般服务技术人员的需求。随着数据服务走向前台，服务业务分析和CDO的业务数据血缘，目前已经有相关产品，通过数据的语义分析，将技术元数据映射到业务元数据上，将血缘以业务流程方式发布共享出来，辅助商务决策，这是未来的发展方向之一。