📚 课程目录第4章数据血缘核心概念

4. 数据血缘核心概念

在模型训练的数据治理体系中，数据血缘不是一张“好看的流程图”，而是一套可计算、可查询、可审计的元数据关系网络。要真正用好它，必须先拆解六个核心概念：血缘节点、边、方向、粒度、正向与反向追溯、影响分析。它们共同决定了血缘系统能回答什么问题、以多快速度回答、以及答案是否可信。

一、核心原理：血缘是一张有向属性图

数据血缘在工程实现上通常被建模为有向无环图（DAG）或更一般的有向图。图中每个节点（Node）代表一个数据实体或处理实体，每条边（Edge）代表一次数据流动或转换关系。边带有方向（Direction），从上游指向下游，表达“谁产生了谁”。

节点类型：原始数据表、特征表、样本集、训练任务、模型版本、评估报告、线上服务接口等。
边类型：读取、写入、转换、聚合、采样、标注、合并、派生等。
方向语义：A → B 表示 A 是 B 的上游，B 依赖 A；方向一旦定义错误，追溯结果会完全反转。
粒度（Granularity）：血缘可以记录在表级、字段级、分区级、文件级甚至行级。粒度越细，审计能力越强，但存储与计算成本也越高。

关键判断：血缘系统的价值 = 节点覆盖度 × 边准确率 × 粒度适配度 × 查询响应速度。任何一项缺失，都会让“影响分析”退化为人工猜测。

二、方法流程：从采集到追溯的完整链路

一个可落地的血缘系统通常按以下流程建设：

元数据采集：从 SQL 解析、任务调度日志、SDK 埋点、文件系统事件中提取节点与边。
图模型构建：将采集结果标准化为“节点-边-属性”三元组，写入图数据库或关系型血缘表。
方向校验：通过任务依赖、时间戳、数据版本比对，确保边方向与真实数据流一致。
粒度对齐：表级血缘用于快速定位，字段级血缘用于精确审计，二者通过映射表关联。
正向追溯：从源头节点出发，沿边方向向下游遍历，回答“这份数据流向了哪些样本和模型”。
反向追溯：从问题节点出发，逆边方向向上游遍历，回答“这个模型用了哪些数据、经过哪些处理”。
影响分析：在反向追溯基础上，计算受影响的下游节点集合、影响路径、影响深度与影响权重。

下面是一个字段级血缘的简化配置示例，用于描述“用户特征表 → 样本表 → 训练任务”的派生关系：

{
  "nodes": [
    {"id": "dwd_user_feature", "type": "table", "layer": "dwd"},
    {"id": "dws_train_sample", "type": "sample", "layer": "dws"},
    {"id": "train_job_ctr_v3", "type": "job", "layer": "train"}
  ],
  "edges": [
    {"from": "dwd_user_feature.user_age", "to": "dws_train_sample.age_bucket", "op": "bucketize"},
    {"from": "dwd_user_feature.click_cnt_7d", "to": "dws_train_sample.ctr_feature", "op": "normalize"},
    {"from": "dws_train_sample", "to": "train_job_ctr_v3", "op": "read"}
  ],
  "direction": "upstream_to_downstream",
  "granularity": "column"
}

三、案例场景：一次样本污染的影响分析

假设审计发现 dwd_user_feature 中 user_age 字段在 3 月 12 日出现空值率异常。我们需要快速回答三个问题：

反向追溯：user_age 来自哪个上游业务库？经过哪些 ETL 任务？
正向追溯：它进入了哪些样本表、哪些训练任务、哪些模型版本？
影响分析：受影响的模型是否需要回滚？评估指标是否可信？线上服务是否受影响？

通过血缘图，可以沿 user_age → age_bucket → dws_train_sample → train_job_ctr_v3 → model_ctr_v3 这条路径快速定位。若粒度只到表级，则只能知道“样本表受影响”；若到字段级，则能精确判断“只有 age_bucket 特征受影响，其他特征正常”。

实战建议：影响分析不要只输出“受影响节点列表”，还应输出影响路径、影响深度、是否跨层、是否涉及线上模型四个维度，便于审计人员排优先级。

四、误区与复盘：血缘建设中最容易踩的坑

误区	表现	后果	修正方式
方向定义混乱	有的边上游指向下游，有的反过来	追溯结果反转，影响分析失效	统一约定“上游 → 下游”，并在采集层强制校验
粒度一刀切	全系统只做表级血缘	无法定位字段级污染，审计精度不足	核心链路做字段级，边缘链路保留表级
只建正向血缘	能查下游，不能查上游	问题定位慢，无法回答“数据从哪来”	正反向查询能力必须同时建设
忽略任务节点	只记录表与表的关系	无法定位是哪个 ETL 任务引入的问题	将 Job、Task、Model 作为一等节点纳入图
血缘更新滞后	任务已变更，血缘仍是旧版本	影响分析基于过期关系，结论错误	血缘采集与调度发布联动，变更即更新

复盘要点：血缘系统的准确性比覆盖率更重要。一条错误的边，可能导致整个影响分析结论被推翻。建议对核心链路建立“血缘质量分”，定期抽样比对真实数据流与血缘记录。

五、正向与反向追溯的查询语义

正向追溯与反向追溯在查询语义上是对偶的：

正向追溯：给定上游节点集合，求所有可达下游节点。常用于“数据发布影响面评估”。
反向追溯：给定下游节点，求所有可达上游节点。常用于“模型数据来源审计”。
影响分析：在反向追溯基础上，叠加时间窗口、节点类型过滤、路径权重，输出受影响对象及优先级。

在实现上，正向追溯通常使用广度优先遍历，反向追溯使用逆向邻接表。若图规模较大，需要引入分层索引或预计算可达性，否则查询延迟会随深度指数上升。