1. 课程导入

在风控系统里，最让团队头疼的往往不是模型跑不动，而是数据对不上。一次策略误杀、一笔可疑交易漏判、一份监管报送口径不一致，追根溯源时才发现：上游埋点延迟、特征快照缺失、离线任务重跑覆盖了历史分区、补数脚本没有留痕。此时业务要的是"把当时那一刻的数据还原出来"，技术要的是"可重复、可验证、可审计"。这正是本课程要解决的核心问题。

一、三个核心概念：回补、补数与审计追溯

很多团队把"回补"和"补数"混用，导致需求沟通时口径不一。本课程先做严格区分，后续所有实战都基于这套定义。

概念	定义	典型触发场景	关键产出
数据回补（Backfill）	针对已过去的时间窗口，按既定逻辑重新计算并写入历史分区，使历史数据与最新逻辑一致	特征口径变更、模型上线回溯、上游修复后重算	重算后的历史分区、版本标记、差异报告
补数（Data Patching）	针对缺失、错误或延迟到达的少量数据，做定点修复或增量补齐，不改变整体计算逻辑	埋点丢失、上游延迟、单分区损坏	修复记录、补数工单、影响范围说明
审计追溯（Audit Tracing）	从任一风控结论出发，反向定位其依赖的数据、特征、规则、模型版本与操作人	监管检查、客诉举证、内部复盘	血缘链路、快照证据、操作日志

三者的关系可以概括为：回补是"重算历史"，补数是"修补缺口"，审计追溯是"证明过程"。回补和补数都会改变数据，而审计追溯要求这些改变必须可解释、可还原、可追责。缺少追溯能力的回补，本质上是在制造新的数据风险。

二、为什么这件事在风控领域格外重要

风控数据与普通业务数据最大的差异在于：它直接关联资金安全、用户权益与监管合规。一次错误的回补可能让历史逾期率失真，一次无记录的补数可能让策略回溯结论不可信，一次缺失的追溯可能在监管问询时无法自证。

• 合规刚性：监管要求风控决策可解释、可复现，数据变更需留痕，部分场景要求保留原始快照。
• 策略迭代快：模型和规则频繁上线，需要频繁回溯验证，回补成为常态而非例外。
• 链路长且异构：实时特征、离线特征、三方数据、人工审核记录交织，任一环节缺失都会断链。
• 后果不可逆：错误数据一旦进入决策，可能已造成误杀或漏放，只能靠追溯定位并补救。

三、核心原理：可重现性是风控数据的底线

回补、补数与审计追溯共享同一个底层原理：任何时刻的风控结论，都应由"输入数据 + 计算逻辑 + 版本信息"唯一确定。只要这三要素可获取，历史就能被重现；只要重现结果与当时一致，审计就能成立。

由此推导出三条工程原则：

1. 不可变优先：原始数据尽量只追加不覆盖，修正通过新版本表达，而非原地改写。
2. 版本显式化：特征口径、规则、模型、代码都要有版本号，并写入产出数据。
3. 变更可追溯：每次回补或补数都要记录谁、何时、为何、影响哪些分区、如何验证。

下面是一段典型的回补任务元数据记录，它体现了上述原则：

{
  "job_id": "backfill_feature_risk_v3_20240601",
  "type": "backfill",
  "operator": "data-platform",
  "reason": "特征口径由T+1改为T+0，需重算近90天",
  "logic_version": "feature_risk_v3.2.1",
  "target_partitions": ["2024-03-01", "2024-03-02", "..."],
  "source_snapshot": "ods_txn_snapshot@2024-06-01",
  "status": "success",
  "diff_report": "s3://risk-audit/backfill/20240601/diff.html"
}

这段记录的价值在于：半年后有人质疑某天特征值时，可以凭 job_id 找到当时的逻辑版本、源快照和差异报告，而不是靠记忆解释。

四、方法流程：从需求到闭环的五个阶段

本课程后续章节会逐一展开，这里先给出全局流程，帮助建立整体框架。

• 阶段一 需求与影响分析：明确回补/补数范围、时间窗口、影响的下游报表与策略，评估是否触发重跑。
• 阶段二 方案与审批：确定逻辑版本、源数据快照、写入方式（覆盖/新增分区）、回滚方案，走变更审批。
• 阶段三 执行与隔离：在隔离环境先跑小批量验证，再全量执行；执行过程记录日志与指标。
• 阶段四 验证与差异分析：对比新旧数据分布、关键指标、策略命中率，输出差异报告并确认是否符合预期。
• 阶段五 归档与审计：固化元数据、快照、日志、报告，纳入审计追溯体系，支持后续反查。

五、典型场景与常见误区

先看一个真实感较强的场景：某消费金融公司调整了"近7天申请次数"特征口径，需要回补近90天数据用于模型回溯。团队直接覆盖了历史分区，未保留旧版本，也未记录逻辑版本。两周后监管问询某用户的拒绝原因，发现无法还原当时的特征值，因为历史已被新口径覆盖。最终只能以"数据已更新"答复，合规风险显著上升。

这个场景暴露的误区具有普遍性：

• 误区一：把回补当普通重跑。忽略版本记录与快照保留，导致历史不可还原。
• 误区二：补数不留痕。手工修数、直接改库，事后无人知道改了什么。
• 误区三：只关注结果不关注过程。没有日志、没有差异报告，审计时无法自证。
• 误区四：追溯靠人问。血缘关系存在个人经验里，人员流动即断链。

六、学习目标与课程框架

完成本课程后，你应当能够：

1. 准确区分回补、补数与审计追溯，并能根据场景选择正确方案。
2. 设计具备版本记录、快照保留与回滚能力的回补流程。
3. 搭建从风控结论到原始数据的血缘追溯链路。
4. 编写可审计的变更元数据、差异报告与操作日志。
5. 识别并规避回补与补数中的典型风险与误区。

课程整体分为四个模块：基础与规范（定义、原则、元数据标准）、回补实战（方案设计、执行、验证）、补数与修复实战（定点修复、增量补齐、幂等保障）、审计追溯体系（血缘、快照、日志、监管应对）。每个模块都配有可落地的流程、清单与代码示例。

七、实战价值：这门课解决什么问题

对数据工程师，它提供一套可复用的回补与补数工程规范，减少重复踩坑；对风控策略与模型人员，它保证回溯验证的数据可信，让策略迭代有据可依；对合规与审计人员，它提供可举证的数据链路与变更记录；对团队管理者，它降低因数据不可追溯带来的合规与资金风险。

归根结底，风控数据回补、补数与审计追溯不是三个孤立的技术动作，而是一套以可重现性为核心的数据治理能力。掌握它，意味着你不仅能修数据，还能证明你修得对、修得可查、修得可回退。这正是本课程希望带给你的核心能力。