先讲一个真实场景评测跑出一个 Badcase——某路口逆光下模型把静止的清扫车误判成可通行区域。算法同学第一反应不是改模型而是问三个问题这帧数据当初是哪个 clip 采回来的标注用的是哪个算法版本、什么参数同一批数据还喂给了哪些数据集和训练任务这三个问题靠翻日志、查表、口口相传是回答不了的——它需要一套能沿着数据流转链路正反向走通的血缘服务。系列二第 12 篇 智驾数据闭环湖仓实战Paimon Neo4j 湖图双引擎数据血缘追溯系统 讲过湖图双引擎「为什么这么设计」的架构原理。作为系列五「数据治理」开篇这一篇换一个视角把血缘当成一个对外提供能力的服务来拆——它能回答哪四类问题、背后靠什么写入机制保证不失真、工程上又划了哪些边界。主线始终是那个 Badcase怎么在几分钟内从一个评测结果一路回溯到当初那帧原始数据。一、血缘服务数据闭环的问题分析底座▲ 血缘服务的价值从一次评测 Badcase反向走回源头那帧原始数据数据闭环最痛的六个问题里有一个是「问题无法全链路追溯」——模型 Badcase 追不回原始数据、标注质量、训练配置、评测场景。血缘服务就是专门堵这个洞的它是问题分析平台的底座让「发现问题 → 定位根因 → 输出场景缺口清单 → 反哺数据挖掘」这条链路真正跑得通。没有血缘问题分析就停在「这个 case 错了」有了血缘才能回答「错在哪个环节、哪份数据、哪个版本」。它的存储底座沿用第 12 篇的结论——湖仓Paimon是唯一事实源图库Neo4j是关系视图三级 IDdata_id / artifact_id / run_id是两边统一的语言。这里不重复架构原理只强调一句分工原则图库找关系、湖仓取明细。Neo4j 负责多跳遍历找路径、定范围只返回节点 ID 与关系类型属性、参数快照、质量指标一律回湖仓按 ID 补齐。这个分工贯穿后面所有查询。二、血缘服务能回答的四类问题一个成熟的血缘服务对外提供的不是一个「查血缘」的模糊接口而是四个方向明确的能力正好覆盖数据闭环的正反向追溯、版本对比与影响评估查询方向回答的典型问题服务对象正向追踪这批采集数据最终用在了哪些数据集与模型上数据生产与资产管理反向追溯这个 Badcase 是哪个版本模型、什么参数跑出来的问题分析与根因定位版本分支对比同一批数据SLAM v3 与 v4 哪个质量更好算法迭代决策影响分析算法升级后哪些数据集与训练任务需要重刷重刷排期与成本评估四个方向里反向追溯最能体现血缘服务的价值也正是开头那个 Badcase 的解法。它的走法是这样以Badcase 节点为起点badcase_id先按 data_id 关联到评测任务回溯到评测所用的数据集版本再沿 REFERENCES 边回到具体的产物与算法版本最后回湖仓取出当时的参数快照。图库还留了一条捷径——Badcase 可经 TRACED_TO 边直连 Artifact跳过中间表。整条链路走下来「这个 Badcase 出自哪份数据、哪个算法版本、什么参数」一次性摊开。▲ 四个查询方向正向追踪、反向追溯、版本对比、影响分析覆盖闭环全场景另外两个方向同样落到日常运营版本分支对比定位同一个 clip沿 CONTAINS 找到 SLAM v3、v4 两个并列产物回湖仓取各自质量分做 A/B——这是算法升级要不要全量重刷的决策依据影响分析从 SUPERSEDED_BY 替代关系出发反向遍历 REFERENCES统计还有多少数据集在引用旧版本产物直接输出重刷范围与成本评估。三、服务可靠性写入三链路与状态机查询能力再强前提也是血缘数据本身不失真、不丢边。这是血缘服务最难的部分湖仓和图库是两套系统怎么保证「湖里有的关系图里一定也有」答案是三条链路 一条铁律。链路一是湖仓事实源写入。所有血缘事件先落湖仓产线执行写 dwd_production_run_detail含 input/output_artifact_ids、产物生成写 dwd_production_artifact_detail含 parent_artifact_id、算法升级重刷时旧产物 UPDATEstatussuperseded superseded_by 指向新产物、数据集构建写 dwd_dataset_version_detail含 artifact_refs。关键在于——这些关系字段是冗余落表的它们既是湖仓自己的属性也是后面图库对账的兜底源。▲ 写入三链路湖仓事实源 → 实时 MERGE 保速度 → T1 对账保兜底链路二是图库实时更新。血缘服务监听湖仓 binlog / 变更消息立即按关系字段 MERGE 图库的节点与关系边CONTAINS / DERIVED_FROM / SUPERSEDED_BY / INPUT / PRODUCED / REFERENCES。MERGE 是幂等的——节点按唯一 ID、关系去重content_hash 相同则 artifact_id 相同重试天然无副作用。这条链路保的是速度且实时失败不阻塞湖仓写入。链路三是定期对账兜底。T1 或定时任务扫描湖仓增量按 _ingest_time拿冗余关系字段重建节点与关系对比图库现状缺什么 UPSERT 补齐什么。这条链路保的是最终一致——就算实时链路挂了、延迟了对账也能把图补齐。三条链路合起来就是那条铁律湖仓是唯一事实源图库两条链路都从湖仓取数湖-图最终一致。配套的还有一台状态机让血缘能表达「版本演进」而不只是「静态快照」artifact 从 active 到 superseded新版本写入成功或 invalid质检判定不可用但节点保留供追溯run 从 running 到 success / failed / cancelled其中failed 的 run 不产生 Artifact 节点、不建 INPUT/PRODUCED 边数据集版本从 draft 到 released 再到 deprecated。下游只读 statusactive 的产物数据集一旦绑定 artifact_refs即使产物后来被替代也不影响该版本可复现。四、工程边界四条护栏防止血缘服务失控血缘服务最容易踩的坑是把图库当成第二个数据库、把遍历跑到失控。设计上划了四条边界这也是「服务」区别于「一张关系表」的地方① 属性单一事实源。图库只存节点与关系ID 关系类型属性、参数快照、指标一律取自湖仓绝不双源冗余——否则两边迟早对不上。② 双链路可靠性。湖仓冗余血缘字段是对账源图库实时同步失败时由 T1 对账 UPSERT 补齐可靠性不押在单条链路上。③ 遍历边界。多跳遍历建议限定深度 3–5 跳防止扇出爆炸大批量下游影响分析改走湖仓离线统计审计链路不硬用图库遍历。④ 结果可审计。查询结果同时返回血缘路径与湖仓数据来源表名 ID可复现、可审计。回到开头那个逆光清扫车的 Badcase血缘服务几分钟内给出答案——它出自某个隧道出口逆光的 clip标注用的是 SLAM v3参数快照显示当时曝光补偿配置偏保守更关键的是影响分析发现同一批数据还喂给了另外两个数据集。于是根因不只是「模型不行」而是「这个场景的采集与标注覆盖不足」——这条结论直接变成场景缺口清单下发给数据挖掘去回补或定向采集。 本文要点① 血缘服务是闭环的问题分析底座专治「问题无法全链路追溯」分工原则是图库找关系、湖仓取明细② 对外提供四个方向的能力——正向追踪、反向追溯Badcase 主线、版本分支对比、影响分析③ 可靠性靠写入三链路湖仓事实源冗余落表 图库实时 MERGE 保速度 T1 对账 UPSERT 保兜底配 active/superseded/invalid 状态机表达版本演进④ 四条工程护栏——属性单一事实源、双链路可靠、遍历限深 3–5 跳、结果可审计防止血缘系统失控。