type
Post
status
Published
date
Jun 3, 2020 09:01
slug
summary
数据血缘（Data Lineage）是数据治理的核心能力：追溯数据来源、定位异常根因、评估影响范围。本文覆盖三级血缘（作业/表/字段）、采集方案、可视化（桑基图/关系图）、数据模型设计，并深入影响分析、版本管理、权限控制、质量信号集成等工程实践，助你构建可落地的血缘体系。
tags
Data Warehouse
ETL
category
Data Engineering
icon
password
wordCount
1502
前言
数据血缘（Data Lineage）是数据治理里最容易被低估、但最能救火的能力之一。
当指标突然“跳变”、报表出现“对不上”、或者上游字段被人悄悄改了类型，你需要一条清晰的链路回答三个问题：
- 这份数据从哪里来？
- 中间经历了什么加工？
- 最终被谁在用？
一句话：数据血缘就是“数据从产生到被消费的全过程地图”。
什么是数据血缘
数据血缘是数据治理中元数据管理的重要概念。
数据治理通常包含：数据标准、数据质量、主数据、元数据、数据安全等多个方面。
在元数据管理领域，Google 曾发表过一篇论文，详细描述其实践：
Google 将元数据管理拆成多个部分（下图为原文示意）：
把“血缘”类比到现实世界会更直观：
我们每个人都来自一代代的生育关系，因此形成血缘；在数据信息时代，数据不断产生、清洗、聚合、拼接、落表、再被下游消费，因此天然存在一张“亲缘关系网”。
更直白地说：数据血缘就是数据产生的链路，描述“这个数据怎么来的，经过哪些过程与阶段”。
特性
- 归属性：一份数据通常归属于特定的团队或负责人。
- 多源性：同一份数据可以有多个来源（多个父节点），也可能由多个加工过程共同生成。
- 可追溯性：血缘关系覆盖数据的生命周期，有助于从“异常结果”回溯到“上游原因”。
- 层次性：从原始数据到主题、指标、标签、画像，不同抽象层形成不同层次的血缘。
数据血缘的作用
数据血缘的价值通常体现在：定位问题更快、评估影响更准、治理更可持续。
数据溯源
溯源指探寻事物的根本与源头。
在企业场景中，数据可能来自政府、互联网、第三方数据交易、自有业务系统等多种渠道。来源不同，质量差异大，最终会影响分析结果。
当数据发生异常，你需要追踪异常从哪里引入，并把风险控制在可接受范围。
血缘可视化图上，主节点上游是来源节点，下游是消费节点，能快速定位：
- 这张表/这个指标来自哪些系统与表
- 中间有哪些清洗、聚合、Join、去重等转换
- 异常可能由哪一个环节引入
评估数据价值
数据交易或内部资源分配中，数据定价与优先级判断都离不开“价值评估”。血缘可以提供更客观的依据：
- 数据受众：下游消费方越多，潜在价值越高。
- 数据更新量级：链路越“粗”，更新规模越大，往往代表业务更核心。
- 数据更新频次：更新越频繁，数据越“新鲜”，价值通常越高。
数据质量评估
血缘图能让你一眼看到：
- 上游口径是否统一
- 哪些步骤执行了清洗规则
- 哪些节点是质量风险放大器（例如错误聚合、重复去重、错误 Join 键）
数据归档与销毁的参考
当数据长期没有下游受众，就可能失去使用价值。
血缘图上，如果主节点下游几乎没有消费节点，通常意味着可以进入“评估归档或销毁”的流程。
数据血缘的级别
广义上，血缘分析通常分为 3 个级别（越往下越精细、成本也越高）：
- 作业级别：
大数据平台数据由作业生成，例如 Kettle、Spark、MapReduce。
你可以获取服务器、运行时长、等待时长、任务流状态等更偏“运行态”的信息。
- 数据集级别（表级）：
数据集即表，广义包含 HDFS、HBase、关系型数据库、Kafka、FTP、本地文件等。
你可以获取表的生成链路、使用频率、表的基础信息。
- 字段级别：
最苛刻、也最有价值。
你可以追踪某张表的字段来自哪里，是否做过聚合（sum/max/min 等），字段重要性排序等。
实践建议：大多数团队从“表级血缘”起步性价比最高；字段级血缘适合关键域、关键指标、合规强约束场景。
数据血缘的采集
要构建血缘，通常需要分析：
- 各类存储媒介（关系型数据库、NoSQL、Kafka、HDFS 等）
- 各类作业/计算工具（Flink、Spark、Pentaho 等）
并通过解析元信息或日志，生成血缘记录。
数据源信息
数据源基础信息通常包括：数据源名、类型、配置、状态、所属等。
常见采集方式：
- 通过 SQL 脚本或程序脚本录入
- 在 ETL/任务采集血缘时顺带录入
- 人工录入
数据集信息
不同媒介的提取方式不同，示例：
- 关系型数据库：
- 从 DDL 或 SQL 语句提取表结构
- 通过触发器或审计日志提取变更
- Kafka：
当 Kafka 作为 ODS 时，每个 topic 名往往就是“表名”或数据集标识
数据流转线路
不同工具的提取方式不同，示例：
- Pentaho（Kettle）：
- 解析 KJB 获取作业信息
- 解析 KTR 获取数据流转线路
Kettle 分为 KJB（控制作业流程）与 KTR（控制转换）。KTR 本质上是 XML。
数据量与频率
常见获取方式：
- 解析作业日志
- 在 ETL 中埋点，将量级/频次上报到血缘服务
血缘系统的边界与能力
很多团队做血缘，第一目标不是“画图”，而是把定位、影响分析、审计变成可查询的能力。要做到这一点，建议先定义系统的输入与输出边界。
输入与输出边界
- 输入（系统从哪里拿信息）
- 元数据：库/表/字段、分区、owner、标签、口径说明
- 作业编排：Airflow / DolphinScheduler / Argo 等 DAG 与依赖
- SQL/ETL 定义：SQL、Kettle/Flink/Spark 作业配置
- 运行与质量信号：作业实例、影响行数、耗时、失败原因、质量规则结果
- 输出（系统要服务什么场景）
- 面向人：血缘图、影响分析清单、变更追踪、质量告警定位
- 面向系统：上/下游查询 API、导出、权限审计
建议先定 MVP：先把“表级血缘 + 影响分析 + 权限控制”跑通，再逐步补齐字段级与质量信号。
影响分析：血缘的高频用法
把影响分析显式写出来，会让读者立刻理解血缘的工程价值。
问题 | 查询方向 | 依赖的数据 | 典型产出 |
我改了上游表/字段，会影响谁？ | 向下游（downstream） | lineage 边 + 消费信息（报表/指标/任务/负责人） | 影响清单、owner、优先级、回滚建议 |
我这里异常，上游谁最可疑？ | 向上游（upstream） | lineage 边 + 运行/质量信号 | 候选根因路径、最近变更点、关联作业失败记录 |
版本与时间维度（拉链表如何用）
你在模型里用 version + date_from/date_to 做拉链表是正确方向。建议在文字里明确两类“时间”，避免读者把它当成普通历史表。
- 生效时间（valid time）：这条血缘在业务上何时成立（date_from/date_to）
- 记录时间（system time）：系统何时观测到这条关系（采集/入库时间，可单独加字段）
当需要“回放历史口径”（例如对账或事故复盘），用 valid time 过滤；当需要“审计谁改了什么”，用 system time 追踪采集与变更。
字段级血缘的关键难点
字段级血缘通常不是“把 SQL parse 一下”就结束，难点集中在：
- 别名、CTE、多层子查询的展开
- Join 键与条件下推导致的来源歧义
- 聚合与窗口函数（group by / over）如何映射字段依赖
- UDF/自定义函数的黑盒（需要约束或额外元数据）
经验：先定义字段级血缘的“精度目标”。例如先支持常见 select/join/group by 模式，再逐步覆盖窗口函数与 UDF。
权限与脱敏（不要忽略）
血缘本质是“元数据地图”，会暴露表的存在与使用关系，通常属于敏感信息。建议补充最基本的安全策略：
- 血缘查询与展示继承数据权限（至少做到表级/域级）
- 对敏感字段仅展示字段名或打码，不展示样例
- 血缘查询本身要留审计日志（谁在什么时间查了哪些链路）
质量信号与血缘结合（让“救火”更快）
如果把质量结果挂到节点/边上，血缘图就从“关系图”升级为“风险图”。
- 节点（表/指标）：行数突增突减、延迟、空值率、重复率
- 边（链路）：volume（你已有）、更新频次、失败次数、最近一次成功时间
事故排查时，优先沿着“最近变更 + 质量异常 + 失败作业”的路径向上游收敛，通常比纯看依赖关系快很多。
数据模型设计
表结构总览
表名 | 描述 |
provenance_job | 作业信息表 |
provenance_dataset | 数据集信息表（表级） |
provenance_field | 字段信息表 |
provenance_datasource | 数据源信息表 |
ref_job_lineage | 作业级别血缘关系表 |
ref_dataset_lineage | 数据集级别血缘关系表 |
ref_field_lineage | 字段级别血缘关系表（记录聚合方式等） |
provenance_job（作业表）
字段名 | 类型 | 描述 |
id | bint | 自增主键 |
name | varchar(128) | 作业名 |
owner | varchar(64) | 所属团队 |
type | varchar(64) | 作业类型 |
comment | varchar(256) | 备注 |
status | int | 状态（1 正常，0 失效） |
create_time | timestamp | 创建时间 |
update_time | timestamp | 更新时间 |
provenance_dataset（数据集表）
字段名 | 类型 | 描述 |
id | bint | 自增主键 |
name | varchar(128) | 数据集名（表名/数据集标识） |
datasource_id | bint | 数据源 id |
job_id | bint | 作业 id |
type | varchar(64) | 数据类型 |
comment | varchar(256) | 备注 |
status | int | 状态（1 正常，0 失效） |
create_time | timestamp | 创建时间 |
update_time | timestamp | 更新时间 |
provenance_field（字段表）
字段名 | 类型 | 描述 |
id | bint | 自增主键 |
name | varchar(128) | 字段名 |
dataset_id | bint | 数据集 id |
type | varchar(64) | 字段类型 |
comment | varchar(256) | 备注 |
status | int | 状态（1 正常，0 失效） |
create_time | timestamp | 创建时间 |
update_time | timestamp | 更新时间 |
provenance_datasource（数据源表）
字段名 | 类型 | 描述 |
id | bint | 自增主键 |
name | varchar(128) | 数据源名 |
owner | varchar(64) | 所属团队 |
type | varchar(64) | 数据源类型 |
scheme | varchar(64) | 模式名 |
comment | varchar(256) | 备注 |
status | int | 状态（1 正常，0 失效） |
create_time | timestamp | 创建时间 |
update_time | timestamp | 更新时间 |
ref_job_lineage（作业链路表）
字段名 | 类型 | 描述 |
id | bint | 自增主键 |
source | bint | 流出作业节点 id |
target | bint | 流入作业节点 id |
volume | int | 更新量级 |
version | bint | 版本号 |
date_from | timestamp | 数据有效开始时间 |
date_to | timestamp | 数据有效截止时间 |
ref_dataset_lineage（数据链路表）
字段名 | 类型 | 描述 |
id | bint | 自增主键 |
source | bint | 流出数据节点 id |
target | bint | 流入数据节点 id |
volume | int | 更新量级 |
version | bint | 版本号 |
date_from | timestamp | 数据有效开始时间 |
date_to | timestamp | 数据有效截止时间 |
ref_field_lineage（字段链路表）
字段名 | 类型 | 描述 |
id | bint | 自增主键 |
source | bint | 源字段 id |
target | bint | 目标字段 id |
type | varchar(64) | 聚合类型（max/min/sum/avg 等） |
version | bint | 版本号 |
date_from | timestamp | 数据有效开始时间 |
date_to | timestamp | 数据有效截止时间 |
建立好数据表后，需要建立对应的 ETL/采集任务把数据装载进表中。
由于作业与数据处于持续变动状态，三张关系表可以设计为拉链表：每天生成新记录，用 version 字段区分。
这样做的好处：
- 血缘“亲疏”可用数据量级辅助判断，关系更贴近真实使用
- 更容易观察血缘的动态变化（新链路、旧链路消亡）
- 可结合作业运行监控，提前发现链路断裂风险
血缘关系可视化
血缘可视化能让你更直观地分析数据平台的上下游关系。
常见图形：桑基图与关系图。
桑基图
桑基图也叫能量分流图或能量平衡图。
它最典型的特征是：始末端分支宽度总和相等，适合表达“流量”与“路径”。
下面是桑基图示意：
在血缘桑基图里，通常用三个元素表达信息：数据节点、流转线路、血缘亲疏。
数据节点
用于表现数据所有者、数据层次信息或终端信息。
- 数据流入节点：主节点的父节点，表示数据来源（可多个）。
- 数据流出节点：主节点的子节点，表示数据去向（可多个）。
- 终端节点：特殊的数据流出节点，表示数据不再继续流转（常用于展示或对外输出）。
流转线路
从左到右的流转路径，体现两个维度：
- 方向：默认从左到右
- 量级：线条越粗，表示数据量级越大
血缘亲疏
两个节点之间间隔的节点越少，血缘关系越“近”。
例如 table3 与 table6 都来源于 table1，但 table3 中间隔了 table5，因此 table6 与 table1 的数据更相似。
该概念可用于数据质量评估与数据销毁评估。
图表数据结构
图表数据结构与前面关系表一致，核心是通过递归查询节点与边：
关系图
关系图用于表达相关性与关联性，也由节点与连线组成。
它能展示血缘关系，但对“量级”的表达不如桑基图直观，因此常用于字段级血缘。
数据节点
数据节点上可显示当前节点的数据量总计、负责人、层级等信息。
流转线路
表示数据的流转路径，并可在连线标注方向。
图表数据结构
结尾
数据血缘不是“画一张图”这么简单，而是把元数据、作业运行、质量规则、消费画像串成一套可持续运转的体系。
当你把血缘跑起来，很多治理问题会从“靠人肉排查”变成“按图索骥”。
如果把数据平台看成城市：
- 任务与表是建筑
- 指标是商圈
- 血缘就是道路与导航，决定了你能不能在堵车时快速找到替代路线。
参考
- Goods：Google Dataset Search（论文）http://people.cs.uchicago.edu/~aelmore/class/topics17/goods.pdf