数据血缘：从数据治理到影响分析的设计与落地

Words 3754Read Time≈ 10 min
2020-6-3
2026-2-11
cover
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 曾发表过一篇论文，详细描述其实践：
Goods：Google Dataset Search
Google 将元数据管理拆成多个部分（下图为原文示意）：
谷歌将元数据管理分为了几个部分
把“血缘”类比到现实世界会更直观：
我们每个人都来自一代代的生育关系，因此形成血缘；在数据信息时代，数据不断产生、清洗、聚合、拼接、落表、再被下游消费，因此天然存在一张“亲缘关系网”。
更直白地说：数据血缘就是数据产生的链路，描述“这个数据怎么来的，经过哪些过程与阶段”。

特性

  • 归属性：一份数据通常归属于特定的团队或负责人。
  • 多源性：同一份数据可以有多个来源（多个父节点），也可能由多个加工过程共同生成。
  • 可追溯性：血缘关系覆盖数据的生命周期，有助于从“异常结果”回溯到“上游原因”。
  • 层次性：从原始数据到主题、指标、标签、画像，不同抽象层形成不同层次的血缘。

数据血缘的作用

🧭
数据血缘的价值通常体现在：定位问题更快、评估影响更准、治理更可持续。

数据溯源

溯源指探寻事物的根本与源头。
在企业场景中，数据可能来自政府、互联网、第三方数据交易、自有业务系统等多种渠道。来源不同，质量差异大，最终会影响分析结果。
当数据发生异常，你需要追踪异常从哪里引入，并把风险控制在可接受范围。
血缘可视化图上，主节点上游是来源节点，下游是消费节点，能快速定位：
  • 这张表/这个指标来自哪些系统与表
  • 中间有哪些清洗、聚合、Join、去重等转换
  • 异常可能由哪一个环节引入

评估数据价值

数据交易或内部资源分配中，数据定价与优先级判断都离不开“价值评估”。血缘可以提供更客观的依据：
  • 数据受众：下游消费方越多，潜在价值越高。
  • 数据更新量级：链路越“粗”，更新规模越大，往往代表业务更核心。
  • 数据更新频次：更新越频繁，数据越“新鲜”，价值通常越高。

数据质量评估

血缘图能让你一眼看到：
  • 上游口径是否统一
  • 哪些步骤执行了清洗规则
  • 哪些节点是质量风险放大器（例如错误聚合、重复去重、错误 Join 键）

数据归档与销毁的参考

当数据长期没有下游受众，就可能失去使用价值。
血缘图上，如果主节点下游几乎没有消费节点，通常意味着可以进入“评估归档或销毁”的流程。

数据血缘的级别

广义上，血缘分析通常分为 3 个级别（越往下越精细、成本也越高）：
  • 作业级别：
      • 大数据平台数据由作业生成，例如 Kettle、Spark、MapReduce。
      你可以获取服务器、运行时长、等待时长、任务流状态等更偏“运行态”的信息。
  • 数据集级别（表级）：
      • 数据集即表，广义包含 HDFS、HBase、关系型数据库、Kafka、FTP、本地文件等。
      你可以获取表的生成链路、使用频率、表的基础信息。
  • 字段级别：
      • 最苛刻、也最有价值。
      你可以追踪某张表的字段来自哪里，是否做过聚合（sum/max/min 等），字段重要性排序等。
⚖️
实践建议：大多数团队从“表级血缘”起步性价比最高；字段级血缘适合关键域、关键指标、合规强约束场景。

数据血缘的采集

要构建血缘，通常需要分析：
  • 各类存储媒介（关系型数据库、NoSQL、Kafka、HDFS 等）
  • 各类作业/计算工具（Flink、Spark、Pentaho 等）
并通过解析元信息或日志，生成血缘记录。

数据源信息

数据源基础信息通常包括：数据源名、类型、配置、状态、所属等。
常见采集方式：
  1. 通过 SQL 脚本或程序脚本录入
  1. 在 ETL/任务采集血缘时顺带录入
  1. 人工录入

数据集信息

不同媒介的提取方式不同，示例：
  • 关系型数据库：
      1. 从 DDL 或 SQL 语句提取表结构
      1. 通过触发器或审计日志提取变更
  • Kafka：
      • 当 Kafka 作为 ODS 时，每个 topic 名往往就是“表名”或数据集标识

数据流转线路

不同工具的提取方式不同，示例：
  • Pentaho（Kettle）：
      • Kettle 分为 KJB（控制作业流程）与 KTR（控制转换）。KTR 本质上是 XML。
      1. 解析 KJB 获取作业信息
      1. 解析 KTR 获取数据流转线路

数据量与频率

常见获取方式：
  • 解析作业日志
  • 在 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 字段区分。
✅
这样做的好处：
  • 血缘“亲疏”可用数据量级辅助判断，关系更贴近真实使用
  • 更容易观察血缘的动态变化（新链路、旧链路消亡）
  • 可结合作业运行监控，提前发现链路断裂风险

血缘关系可视化

血缘可视化能让你更直观地分析数据平台的上下游关系。
常见图形：桑基图与关系图。

桑基图

桑基图也叫能量分流图或能量平衡图。
它最典型的特征是：始末端分支宽度总和相等，适合表达“流量”与“路径”。
下面是桑基图示意：
notion image
在血缘桑基图里，通常用三个元素表达信息：数据节点、流转线路、血缘亲疏。
notion image

数据节点

用于表现数据所有者、数据层次信息或终端信息。
  • 数据流入节点：主节点的父节点，表示数据来源（可多个）。
  • 数据流出节点：主节点的子节点，表示数据去向（可多个）。
  • 终端节点：特殊的数据流出节点，表示数据不再继续流转（常用于展示或对外输出）。

流转线路

从左到右的流转路径，体现两个维度：
  • 方向：默认从左到右
  • 量级：线条越粗，表示数据量级越大

血缘亲疏

两个节点之间间隔的节点越少，血缘关系越“近”。
例如 table3 与 table6 都来源于 table1，但 table3 中间隔了 table5，因此 table6 与 table1 的数据更相似。
该概念可用于数据质量评估与数据销毁评估。
notion image
notion image

图表数据结构

图表数据结构与前面关系表一致，核心是通过递归查询节点与边：

关系图

关系图用于表达相关性与关联性，也由节点与连线组成。
它能展示血缘关系，但对“量级”的表达不如桑基图直观，因此常用于字段级血缘。
关系图

数据节点

数据节点上可显示当前节点的数据量总计、负责人、层级等信息。

流转线路

表示数据的流转路径，并可在连线标注方向。

图表数据结构

结尾

数据血缘不是“画一张图”这么简单，而是把元数据、作业运行、质量规则、消费画像串成一套可持续运转的体系。
当你把血缘跑起来，很多治理问题会从“靠人肉排查”变成“按图索骥”。
🚀
如果把数据平台看成城市：
  • 任务与表是建筑
  • 指标是商圈
  • 血缘就是道路与导航，决定了你能不能在堵车时快速找到替代路线。

参考

Loading...