3. 血缘追踪核心概念
在金融场景中，血缘追踪不是单一维度的“记录来源”，而是围绕数据、代码、模型三条链路分别建立可追溯关系，再在关键节点上把它们拼接成一张完整的证据网。理解三者的定义、边界与耦合方式，是后续落地采集、存储、查询和审计能力的前提。
一、核心原理：三种血缘各自回答什么问题
数据血缘（Data Lineage）描述数据实体在系统间的流转路径：一张表、一个字段、一个指标从哪些源系统产生，经过哪些加工、聚合、关联、分流，最终被哪些报表、接口、模型或下游应用消费。它回答的是“这个数从哪来、到哪去、中间被谁改过”。在金融行业，数据血缘通常需要细化到字段级，因为监管报送、风险指标、客户标签往往只依赖少数关键字段。
代码血缘（Code Lineage）描述代码资产之间的依赖与演化关系：某个作业、函数、脚本、配置、调度任务由哪些代码版本构成，引用了哪些库、参数、环境变量，又被哪些上游任务触发、被哪些下游任务依赖。它回答的是“这段逻辑由什么代码产生、改一次会影响谁”。代码血缘是数据血缘的“生产端解释器”，没有代码血缘，数据血缘只能看到结果，无法解释变更原因。
模型血缘（Model Lineage）描述模型从训练到上线的全链路依赖：训练数据版本、特征工程代码、超参数、算法框架、训练环境、评估指标、模型产物、部署服务、推理输入输出，以及后续监控与再训练触发条件。它回答的是“这个模型为什么长这样、它依赖哪些数据和代码、上线后影响了哪些业务决策”。在信贷评分、反欺诈、量化投研等场景，模型血缘直接关系到可解释性与合规审计。
一句话区分：数据血缘看“数据怎么流”，代码血缘看“逻辑怎么来”，模型血缘看“智能怎么生”。三者不是并列孤岛，而是同一生产链条上不同切面的视图。
二、方法流程：从采集到关联的落地路径
落地时建议按“先分后合”推进：先分别建立三类血缘的最小可用采集能力，再通过统一实体标识进行关联。
- 数据血缘采集：优先解析 SQL 执行计划、ETL 日志、调度平台任务元数据，提取 input/output 表与字段映射；对无法解析的存储过程或动态 SQL，补充人工标注或运行时探针。
- 代码血缘采集：接入 Git、CI/CD、调度系统与配置中心，建立 commit、branch、job、task、artifact 之间的引用关系；对 Python/Java/Scala 作业可结合静态分析提取 import、函数调用与参数传递。
- 模型血缘采集：在训练流水线中埋点记录 dataset version、feature set、code commit、hyperparameters、metrics、model artifact hash；在推理服务中记录 model version 与请求批次，形成“训练—部署—推理”闭环。
- 统一关联：为数据表、字段、代码文件、函数、模型、特征、服务分配全局唯一 ID，并在采集时写入关联边。例如某特征字段由某段代码生成，该代码又属于某次模型训练，这条边就把数据血缘与模型血缘连了起来。
# 示例：模型训练埋点中同时记录三类血缘标识
run_id: train_20240612_credit_score_v3
dataset_uri: hdfs://fin/feature/credit_customer_daily/dt=2024-06-11
code_commit: a1b2c3d4e5f6
feature_code: features/credit_score.py::build_income_ratio
model_artifact: s3://models/credit_score/v3/model.pkl
metrics: {auc: 0.812, ks: 0.436}
三、案例/场景：信贷评分模型的一次变更审计
假设某银行信贷评分模型在 6 月上线新版本，监管要求说明“评分结果变化的原因”。此时需要同时调取三类血缘：
- 数据血缘：发现新版本使用了新增的“近 3 个月查询次数”字段，该字段来自征信查询日志表，经过聚合任务加工后进入特征表。
- 代码血缘：该聚合任务在 5 月 28 日有一次代码提交，修改了时间窗口逻辑，由原来的 6 个月改为 3 个月。
- 模型血缘：该特征被纳入 v3 模型训练，训练数据版本为 dt=2024-05-30，模型 AUC 提升 0.015，上线后评分分布整体上移。
三条链路拼在一起，才能形成完整证据：数据字段变更 → 代码逻辑变更 → 模型版本变更 → 业务评分变化。缺少任何一条，审计结论都会显得单薄。
四、误区/复盘：常见混淆与纠正
| 常见误区 | 问题本质 | 纠正方式 |
|---|---|---|
| 把数据血缘等同于代码血缘 | 只看到表字段映射，忽略生成逻辑的版本变化 | 在数据血缘边上附加 code_commit 与 job_id，形成可解释链路 |
| 模型血缘只记录模型文件 | 无法回答“为什么这个模型用了这批数据” | 强制记录 dataset version、feature code、训练配置与评估指标 |
| 三类血缘各自为政，不做关联 | 审计时无法跨域追溯，排查变更耗时 | 建立统一实体 ID 与关联边，至少打通“字段—代码—模型”主路径 |
| 只采集不校验 | 血缘图存在断边、错边，误导影响分析 | 增加血缘完整性校验任务，对缺失边和冲突边告警 |
复盘建议：每季度做一次“血缘走查”，随机抽取一个上线模型或监管指标，沿数据、代码、模型三条链路反向追溯，验证是否能在 10 分钟内定位到源头字段与代码提交。这是检验血缘建设成效最直接的方式。
注意：金融场景中血缘数据本身也可能包含敏感信息（如表名、字段名、客户标签）。血缘存储与查询需要纳入权限体系，避免因“追踪链路”反而造成元数据泄露。
总结来看，数据血缘、代码血缘、模型血缘分别对应“数据流”“逻辑流”“智能流”，三者定义不同、采集方式不同、关注问题不同，但在金融生产链条上高度耦合。只有把它们放在同一套标识与关联框架下，才能真正支撑变更影响分析、监管审计、故障定位与模型治理。