1. 课程导入

在金融风控、监管报送与数据治理场景中，风险报告往往不是一张孤立的报表，而是一条从源系统到指标口径、再到最终披露结果的完整数据链路。当监管问询“这个不良率为什么从2.1%变成2.3%”时，如果只能回答“系统算出来的”，就无法满足可解释、可审计、可追责的要求。本课程要解决的核心问题，正是让每一个风险指标都能被“顺藤摸瓜”地还原到最细粒度的字段与加工逻辑。

一、什么是风险报告血缘与字段级追溯

风险报告血缘（Risk Report Lineage）描述的是风险报告中的指标、报表项、数据项之间，以及它们与上游数据源之间的依赖关系网络。它回答的是“这个数字从哪里来、经过哪些加工、影响了谁”。血缘通常分为三层：

• 报表级血缘：报表与报表、报表与数据集市之间的依赖，例如资本充足率报表依赖风险加权资产汇总表。
• 指标级血缘：指标与指标之间的计算关系，例如拨备覆盖率 = 贷款损失准备 / 不良贷款余额。
• 字段级血缘：最细粒度，精确到某张表的某个字段、某个转换规则、某个过滤条件，例如不良贷款余额来自 dw_loan_detail.loan_balance 在 loan_status = 'NPL' 条件下的汇总。

字段级追溯（Field-Level Traceability）是在血缘基础上，支持正向与反向双向追踪的能力：正向从源字段出发，查看它流向了哪些指标和报表；反向从报表数字出发，逐层下钻到具体字段、加工任务和责任人。二者结合，才构成完整的“血缘+追溯”能力。

二、核心原理：从数据流到可追溯链路

字段级追溯的底层原理可以概括为“解析—建模—存储—查询”四步。首先通过SQL解析、ETL日志解析、调度依赖解析，提取字段间的映射关系；然后将这些关系建模为有向无环图（DAG），节点是字段或指标，边是加工规则；接着存入图数据库或血缘元数据表；最后通过图查询实现多跳追溯。

-- 字段级血缘元数据示例
{
  "source_field": "ods.loan_detail.loan_balance",
  "target_field": "dw.npl_summary.npl_balance",
  "transform_type": "SUM",
  "filter_condition": "loan_status = 'NPL'",
  "job_id": "etl_npl_daily",
  "owner": "risk_data_team"
}

在实际系统中，血缘关系往往不是手工维护的，而是通过解析Hive SQL、Spark作业、存储过程自动生成。解析的准确率直接决定追溯的可信度，因此需要建立“解析—校验—人工补录”的闭环机制。

三、学习目标与整体课程框架

本课程共30章，围绕“概念—方法—工具—实战—复盘”的主线展开。学完本课程，你应当能够：

1. 准确区分报表级、指标级、字段级血缘，并说明各自适用场景。
2. 掌握SQL解析、ETL日志解析、调度依赖解析三种血缘采集方法。
3. 能够设计字段级血缘元数据模型，并落地到图数据库或关系表。
4. 独立完成一次从风险报告数字到源系统字段的反向追溯演练。
5. 识别血缘断链、口径漂移、版本混乱等常见问题并给出治理方案。

四、实战价值与典型场景

字段级追溯的价值在监管报送、内部审计、数据变更管理三类场景中尤为突出。以监管问询为例，监管方要求说明某季度不良贷款率上升的原因，团队需要快速定位：是不良贷款余额口径变化，还是贷款总额分母调整，抑或是某分行数据补录。没有字段级追溯，排查可能需要数天；有了追溯链路，可以在分钟级完成下钻。

五、常见误区与复盘要点

初学者常陷入三个误区。第一，认为“有ETL调度依赖就等于有字段级血缘”——调度依赖只说明任务先后，不说明字段映射。第二，认为“血缘越全越好”——过度采集会带来维护成本和噪声，应按风险报告关键指标优先覆盖。第三，忽视版本管理——口径变更后旧血缘未更新，会导致追溯结果失真。