1. 课程导入

欢迎进入《风控数据血缘与指标口径治理实战》。在风控体系里，模型、策略、报表、监管报送几乎都建立在数据之上，但真正让团队“踩坑”的往往不是算法本身，而是数据从哪来、经过哪些加工、最终被谁使用，以及同一个指标在不同团队口中是否指同一件事。本课程要解决的，正是这两个看似基础、实则决定风控数据可信度的核心问题：数据血缘与指标口径治理。

一、学习目标：从“能查数”到“能解释、能追溯、能治理”

本课程不是单纯讲工具操作，而是希望学员完成三个层次的能力跃迁。第一层是看得见：能够识别风控核心数据链路中的源系统、加工任务、中间表、指标与报表之间的依赖关系。第二层是说得清：当指标异常、口径冲突或监管问询发生时，能快速定位问题发生在哪一环，并给出可验证的解释。第三层是治得住：能够设计血缘采集、口径登记、变更评审与影响分析的机制，让治理从“救火”走向“防火”。

• 理解数据血缘在风控场景中的对象、粒度与边界，区分表级、字段级、任务级血缘。
• 掌握指标口径的构成要素：业务定义、计算逻辑、统计周期、过滤条件、数据来源与责任主体。
• 能够绘制一条典型风控指标链路，并识别其中的关键节点与风险点。
• 能够设计口径冲突的发现、评审、发布与回溯流程。
• 能够用血缘做影响分析，支撑变更管理、故障排查与监管报送。

二、核心价值：为什么风控必须做血缘与口径治理

风控数据有三个显著特征：链路长、口径多、变更频繁。一笔贷款从申请、审批、放款到贷后，数据会经过业务系统、数仓、特征平台、模型平台和报表系统。如果没有血缘，一次上游字段变更可能导致下游几十个指标同时失真；如果没有口径治理，同一个“逾期率”在风险、财务、监管报表中可能算出三个不同结果。治理的价值体现在四个层面：

三、整体知识框架：三条主线与一个闭环

本课程的知识框架可以概括为“三条主线、一个闭环”。三条主线分别是：血缘采集与建模、指标口径治理、平台化与运营机制。一个闭环是指从“发现异常”到“影响分析”再到“变更评审”和“口径发布”的治理闭环。

风控数据治理闭环：
异常发现 → 血缘追溯 → 影响分析 → 口径评审 → 变更发布 → 监控回归
    ↑                                                         |
    └──────────────────── 持续运营与度量 ←───────────────────┘

在血缘侧，需要关注采集方式（SQL解析、任务日志、埋点、元数据API）、存储模型（图数据库或关系表）以及查询能力（上下游、影响面、路径）。在口径侧，需要建立指标字典、口径模板、版本管理和审批流。在平台侧，则要把血缘与口径打通，让用户在看指标时能直接看到它的来源和计算逻辑。

四、实战路线图：从0到1的落地路径

很多团队一上来就想做全链路血缘，结果投入大、见效慢。更务实的路线是以风控核心指标为切入点，先打通一条链路，再逐步扩展。建议按以下四个阶段推进：

1. 阶段一：盘点与选点。梳理风控核心指标清单，选出3～5个高频、高争议、高监管要求的指标作为试点。
2. 阶段二：血缘打通。针对试点指标，采集从源系统到报表的完整链路，形成表级和字段级血缘。
3. 阶段三：口径登记。为每个指标建立口径卡片，明确业务定义、计算逻辑、过滤条件、责任人和版本。
4. 阶段四：机制运营。建立变更评审、影响分析、口径冲突仲裁和定期审计机制，让治理持续运转。

五、常见误区与复盘：别让治理变成“文档工程”

在过往项目中，最常见的误区有三个。第一，只建血缘不更新，导致血缘图很快过期，反而误导决策。第二，口径只写文档不落系统，业务方查不到、用不上，最终又回到口头确认。第三，治理与研发流程脱节，变更不触发影响分析，血缘和口径成为事后补录的负担。

正确的做法是把治理嵌入日常研发流程：需求评审时确认口径，开发时自动采集血缘，发布前做影响分析，上线后监控指标波动。只有这样，血缘和口径才能真正成为风控数据体系的“基础设施”，而不是额外的文档负担。

本章作为课程导入，已经勾勒出学习目标、核心价值、知识框架和实战路线。接下来，我们将从数据血缘的基本概念与风控场景中的具体形态开始，逐步深入到采集、建模、口径治理和平台化落地的完整实战。