1. 课程导入
在金融数据体系中，一份风险报表上的数字，可能来自上游数十张表、若干个特征工程脚本、两三个模型版本，以及多轮人工调整。当监管问询“这个指标为什么变了”、当模型出现异常漂移、当数据质量告警突然爆发时，如果无法快速回答“它从哪来、经过谁、变成了什么”，排查成本会呈指数级上升。这正是金融血缘追踪要解决的核心问题。
一、什么是金融血缘追踪
金融血缘追踪（Financial Lineage Tracking）是指对金融数据、代码与模型在生命周期内的来源、流转、变换和依赖关系进行系统性记录、关联与可视化的能力。它关注的不是单一数据表，而是“数据—代码—模型—指标—报表”之间的完整链路。
从对象维度看，血缘通常包含三层：
- 数据血缘：表、字段、分区、指标之间的上下游关系，例如“客户违约标签”来自“还款记录表”和“逾期天数表”。
- 代码血缘：SQL、Python、调度任务、特征脚本与数据对象之间的生成与消费关系。
- 模型血缘：训练数据、特征集、超参数、模型版本、评估结果与线上推理服务之间的依赖链。
三者并非孤立存在。数据由代码加工，模型消费数据并产出评分，评分又回流为新的数据字段。血缘追踪的价值，就在于把这条链“接起来、看得见、查得到”。
二、学习目标
本课程不是泛泛介绍“血缘很重要”，而是围绕金融场景，训练可落地的工程能力。完成学习后，你应当能够：
- 理解数据、代码、模型三类血缘的差异与关联，建立统一血缘图谱的认知模型。
- 掌握从 SQL 解析、任务调度日志、模型注册信息中抽取血缘元数据的基本方法。
- 能够设计血缘存储结构，并实现字段级、表级、模型级的依赖查询。
- 能够基于血缘完成影响分析、根因定位、变更审计与合规追溯。
- 能够识别血缘建设中的常见误区，并制定分阶段落地路线。
三、整体课程框架
课程共 30 章，按“概念—技术—实战—治理”四条主线推进，整体结构如下表所示：
| 阶段 | 章节范围 | 核心内容 | 产出能力 |
|---|---|---|---|
| 导入与认知 | 第1—4章 | 定义、价值、金融场景、血缘模型 | 建立统一认知框架 |
| 数据血缘技术 | 第5—12章 | SQL解析、字段级追踪、调度集成、图存储 | 能抽取并存储数据血缘 |
| 代码与模型血缘 | 第13—20章 | 特征脚本追踪、模型注册、版本关联、推理链路 | 能打通代码与模型链路 |
| 实战与治理 | 第21—30章 | 影响分析、根因定位、审计合规、平台化落地 | 能支撑生产级血缘应用 |
四、实战价值与典型场景
血缘追踪在金融行业的价值，最终体现在“缩短问题定位时间”和“降低合规风险”两个维度。以下是最常见的四类场景：
- 监管报送核查：监管要求说明某指标的计算口径与数据来源，血缘可一键展开完整链路。
- 模型风险排查：模型评分异常时，沿血缘回溯特征来源与训练数据版本，快速锁定问题节点。
- 数据质量根因定位：某张表出现空值率飙升，通过下游影响分析判断波及哪些报表和模型。
- 变更影响评估：上游字段即将下线，提前识别所有依赖方，避免“改一处、崩一片”。
核心判断：血缘追踪不是“画一张关系图”，而是建立一套可查询、可追溯、可审计的元数据基础设施。图只是呈现形式，底层元数据的完整性、准确性和时效性才是关键。
五、常见误区与复盘
在课程开始前，先明确几个高频误区，避免后续走弯路：
- 误区一：只做表级血缘。表级血缘只能回答“哪张表依赖哪张表”，无法定位到字段。金融场景中，指标口径往往精确到字段，字段级血缘才是刚需。
- 误区二：血缘靠人工维护。人工维护的血缘图很快会过期。必须从 SQL 解析、调度日志、模型注册等环节自动抽取。
- 误区三：一次性建设完成。血缘是持续演进的工程，需要随数据管道和模型迭代同步更新。
- 误区四：忽视模型血缘。很多团队只追踪数据表，却忽略了特征工程脚本和模型版本，导致模型问题无法回溯。
提醒：血缘追踪的准确性依赖元数据质量。如果上游任务命名混乱、SQL 动态拼接严重、模型版本管理缺失，血缘建设会非常困难。因此，本课程会在技术章节中同步强调元数据规范与治理。
接下来，课程将从金融场景中的血缘需求出发，逐步深入到数据、代码与模型三层链路的抽取、存储、查询与应用。你将看到真实的 SQL 解析示例、血缘图存储结构、模型版本关联方法，以及影响分析和根因定位的完整实战路径。