在数据资产管理与数据治理领域，数据之间的血缘关系是一个绕不开的话题，数据血缘的完备程度也是评价一个企业数据中台成熟度的重要度量之一。到底什么是数据血缘，它对于数据工作者和数据使用者有哪些举足轻重的作用呢？
一、从数据应用场景看什么是数据血缘
1.数据问题排查与运维
工作日早上上班，业务人员打开电脑看到昨日数据报表同比下降60%，于是找到数据部门“你们数据是不是有问题？”。
常见数据异常的原因包括：
- 及时性问题，大数据集群资源不足或者平台系统故障导致任务延迟
- 代码质量问题，开发修改逻辑，导致数据清洗逻辑有误带来数据不准
- 业务规则变更，业务变动数据加工代码未及时更新
- 源端脏数据问题，业务开发系统发布数据源问题导致结果错误
数据人员的排查路径如下：
第一步：找到报表指标来源的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数据库也可以存储血缘数据，但是由于血缘数据的形态以及查询使用的场景对性能要求更高，所以在实际应用时，主要采用图数据库存储的方式。常见的图数据库的特点对比如下：
图片来源网络
四、总结
数据血缘是数据开发者效能提升利器，同时也是贯通数据采、存、管、用全链路流程的纽带，建立完善的数据血缘关系，数据应用的成熟度才会更高。针对数据血缘这一领域，也可以构建独立的数据产品模块，以数据产品提升血缘应用的效率。
