3. 数据血缘基础

在保险精算与风控建模的日常工作中，我们经常遇到一个尴尬场景：模型跑出的赔付率与上月差异明显，但没人能快速说清是哪个数据源变了、哪段清洗逻辑被调整、还是某个特征口径被重新定义。数据血缘（Data Lineage）正是解决这类问题的核心基础设施。它记录数据从产生、加工、流转到最终消费的完整路径，让每一个模型指标都能被追溯、被解释、被复现。

一、核心原理：数据血缘到底记录什么

数据血缘本质上是一张有向图，节点代表数据实体（源表、中间表、特征、模型、报表），边代表加工关系（ETL 任务、SQL 转换、特征计算、模型调用）。它回答三个基本问题：数据从哪来、经过了什么处理、最终去了哪里。

从粒度上看，血缘可分为三个层次：

• 表级血缘：记录表与表之间的依赖关系，适合快速影响分析。
• 字段级血缘：精确到列，说明某个特征字段由哪些源字段经何种表达式计算而来，是保险模型可解释性的关键。
• 任务级血缘：记录调度任务、脚本、参数与运行实例，支撑可重复计算与故障定位。

在保险场景中，字段级血缘尤为重要。例如车险赔付率模型中的“案均赔款”特征，可能由理赔表的“已决金额”与“未决金额”按案件号聚合后再除以案件数得到。若没有字段级血缘，当该特征异常时，排查范围会从一张表扩大到整个数仓。

二、方法流程：如何落地数据血缘

数据血缘的落地通常遵循“采集—解析—存储—应用”四步流程。不同团队可根据技术栈选择不同实现方式。

1. 采集：从调度系统（Airflow、DolphinScheduler）、SQL 日志、ETL 脚本中提取任务与依赖信息。
2. 解析：通过 SQL 解析器（如 sqlparse、Calcite）提取字段级映射关系，识别 select、join、where 中的字段来源。
3. 存储：将血缘关系写入图数据库（Neo4j）或关系表，形成可查询的血缘图谱。
4. 应用：提供影响分析、根因定位、变更审计、可重复计算等能力。

以下是一个简化的字段级血缘解析配置示例，用于说明血缘元数据的组织方式：

{
  "task_id": "feature_claim_avg",
  "source_tables": ["dwd_claim_detail", "dwd_policy"],
  "target_table": "feature_store_v3",
  "field_mappings": [
    {"target": "avg_claim_amount", "expr": "sum(paid_amount)/count(case_no)", "sources": ["dwd_claim_detail.paid_amount", "dwd_claim_detail.case_no"]},
    {"target": "loss_ratio", "expr": "sum(paid_amount)/sum(premium)", "sources": ["dwd_claim_detail.paid_amount", "dwd_policy.premium"]}
  ],
  "schedule": "0 2 * * *",
  "owner": "actuary_team"
}

三、案例场景：血缘如何支撑保险模型可重复计算

某财险公司发现车险赔付率模型在 2024 年 5 月突然上升 3 个百分点。借助数据血缘，团队按以下路径快速定位：

• 从模型 model_2024Q2 反向追溯至训练集 feature_store_v3；
• 发现特征 avg_claim_amount 的分布发生偏移；
• 继续追溯至 dwd_claim_detail，发现上游理赔表在 5 月 1 日新增了一批“未决转已决”数据；
• 确认是数据口径变更而非模型退化，随即在特征计算中增加状态过滤条件，模型恢复稳定。

如果没有字段级血缘，这一排查可能需要数天；有了血缘图谱，整个过程缩短到 2 小时以内。更重要的是，血缘记录让这次口径变更被完整留痕，后续可重复计算时能精确复现当时的处理逻辑。

四、误区与复盘

在实际建设中，团队常陷入以下误区：