2. 信用评分模型数据流全景：从原始数据到评分输出的全链路概览、关键节点识别

信用评分模型的数据流并非简单的“输入-输出”直线，而是一条涉及多系统、多层级、多校验的复杂管道。理解这条全链路，是实施数据血缘追踪的前提。本章将拆解从原始数据采集到最终评分输出的每一个关键节点，并识别其中的数据质量风险与血缘断裂点。

2.1 数据流全链路五阶段模型

我们将信用评分模型的数据流划分为五个核心阶段，每个阶段都对应特定的数据形态、处理逻辑和血缘记录需求。

2.2 关键节点识别与风险矩阵

在全链路中，并非所有节点都需要同等粒度的血缘追踪。我们根据“数据变更影响范围”和“数据质量风险等级”两个维度，识别出以下必须重点监控的关键节点：

• 节点A：源系统字段映射表 — 风险等级：高。任何映射错误都会向下游传导，且难以回溯。
• 节点B：缺失值填充策略 — 风险等级：高。填充逻辑（均值/中位数/固定值）直接影响特征分布，是模型监控的敏感点。
• 节点C：特征衍生逻辑 — 风险等级：极高。例如“近6个月逾期次数”的SQL中，时间窗口定义错误会导致评分系统性偏差。
• 节点D：模型输入特征顺序 — 风险等级：高。模型文件（如PMML或ONNX）对特征顺序敏感，顺序错乱将输出错误评分。
• 节点E：评分校准公式 — 风险等级：中。校准参数（如PD到分数的转换公式）变更需同步更新所有下游消费方。

2.3 数据流全景SVG图：五阶段与关键节点

下图展示了从原始数据到评分输出的完整数据流，并标注了五个关键监控节点（A-E）。箭头代表数据流向，虚线框代表数据存储层。

2.4 数据流中的血缘断裂场景

在实际生产环境中，数据流并非永远顺畅。以下三种典型场景会导致血缘追踪中断：

• 场景一：临时表介入 — 数据工程师在特征工程阶段创建了临时表 tmp_feature_v2 用于调试，但未在调度系统中注册。该临时表被下游模型消费后，血缘关系无法自动解析。
• 场景二：脚本内联逻辑 — 特征衍生逻辑直接写在Python脚本的 lambda 函数中，而非存储在数据库或配置中心。血缘工具无法解析代码内部的衍生关系。
• 场景三：手工修正数据 — 运营人员直接在数据库中对某条记录的“收入”字段进行手工修改，未通过ETL流程。该修改不会被血缘系统记录。

2.5 关键节点数据质量监控指标

针对上述五个关键节点，我们建议设置以下数据质量监控指标，并与血缘追踪系统联动：

2.6 数据流全景SVG图：血缘断裂场景示意

下图以“临时表介入”场景为例，展示血缘断裂如何发生。正常路径为实线，断裂路径为虚线。

2.7 全链路血缘追踪实施清单

在完成数据流全景梳理后，建议按照以下清单启动血缘追踪实施：

1. 盘点所有源系统 — 列出所有接入的源系统、接口类型（API/DB/文件）、抽取频率。
2. 绘制数据流地图 — 使用上述五阶段模型，标注每个阶段的数据存储位置和处理逻辑。
3. 标记关键节点 — 根据风险矩阵，在数据流地图上标记A-E五个关键节点。
4. 配置血缘采集点 — 在每个关键节点部署血缘采集探针（如SQL解析器、ETL日志采集器）。
5. 建立监控告警 — 为每个关键节点设置数据质量监控指标，并与血缘系统联动。
6. 定期演练 — 每月模拟一次“数据异常回溯”演练，验证血缘追踪能否在30分钟内定位到根因。