4. 数据补数核心概念
在风控数据体系中，数据回补与补数并不是“把缺的数据重新灌一遍”这么简单。它本质上是一次对历史事实的重新计算与重新表达：上游数据迟到、口径变更、任务失败、规则升级，都会导致某段时间窗口内的数据不完整或不一致。补数就是把这些窗口重新加工，使下游指标、名单、模型特征和审计记录恢复到可信状态。理解补数，必须先厘清四个核心概念：定义、类型、粒度、时效，以及它们对业务的实际影响。
一、补数的定义与核心原理
补数（Data Backfill / Data Repair）是指：在发现数据缺失、错误、延迟或口径变化后，针对指定的历史时间范围，重新执行数据采集、清洗、计算、写入与校验，使目标数据达到与正常调度一致或符合新口径的状态。它的核心原理可以概括为三点：
- 幂等性：同一时间窗口重复补数，结果应一致，不能因为重跑产生重复累计或重复扣减。
- 可追溯性：每次补数必须记录“谁、何时、补了哪个窗口、用什么版本、结果如何”，否则审计无法闭环。
- 影响可控：补数会改写下游数据，必须评估对指标、名单、模型和报表的连锁影响，避免“补一处、乱一片”。
二、补数类型：按成因与目标划分
补数类型决定了处理策略。常见分类如下：
| 类型 | 典型成因 | 处理策略 | 风险点 |
|---|---|---|---|
| 缺失补数 | 上游未送达、任务失败、分区丢失 | 按原口径重跑缺失窗口 | 重复写入、分区覆盖 |
| 修正补数 | 上游数据错误、脏数据、逻辑缺陷 | 先回滚或标记旧数据，再重算 | 旧数据未清理导致双份 |
| 口径补数 | 指标定义变更、规则升级 | 按新口径重算历史窗口 | 新旧口径混用、报表跳变 |
| 延迟补数 | 上游迟到、跨天数据晚到 | 滚动窗口重算，覆盖原结果 | 时效窗口与业务截止冲突 |
| 审计补数 | 监管核查、内部审计要求 | 只读重算，生成对照快照 | 影响生产数据、证据链断裂 |
实际工作中，一次补数往往同时具备多种类型。例如规则升级后，既要修正旧规则产生的错误名单，又要按新口径重算特征，这属于“口径补数+修正补数”的复合场景。
三、补数粒度：时间、分区与实体
补数粒度是补数方案中最容易被低估的部分。粒度太粗，会重算大量无关数据，浪费资源并放大风险；粒度太细，则可能遗漏关联窗口，导致结果不一致。通常从三个维度定义：
- 时间粒度：按小时、天、周还是月补。风控场景中，T+1 指标常按天补，实时特征可能按小时补。
- 分区粒度：按 dt、hour、region、业务线等分区重写。分区是补数的最小物理单位。
- 实体粒度：按用户、设备、商户、订单等实体重算。实体粒度决定了下游名单和模型特征的影响范围。
例如，某风控指标按 dt 分区存储，补数脚本应明确指定分区范围，而不是全表重跑：
# 补数任务参数示例
task: risk_feature_backfill
date_range: 2024-06-01 ~ 2024-06-03
partition: dt
entity: user_id
mode: overwrite
idempotent_key: user_id + dt + feature_version
dry_run: true
四、补数时效与业务影响
补数时效指从发现问题到补数完成、下游恢复可用的时间要求。它直接决定业务能否在决策窗口内使用正确数据。风控场景中，时效通常分为三档：
- 实时级（分钟~小时）：影响实时拦截、名单生效，必须快速补，但需严格限流，避免冲击线上。
- 准实时级（小时~天）：影响 T+1 报表、模型特征，通常安排在业务低峰期补。
- 离线级（天~周）：影响审计、监管报送、历史复盘，可批量补，但要求完整可追溯。
补数对业务的影响体现在四个层面：指标层（报表数字变化）、名单层（命中与放行变化）、模型层（特征分布漂移）、审计层（证据链是否完整）。一次未评估的补数，可能导致昨天已放行的用户今天被重新命中，引发客诉；也可能让模型特征均值突变，导致评分整体偏移。
五、案例与常见误区复盘
某支付风控团队发现 6 月 1 日至 3 日的交易特征缺失，原因是上游日志延迟。工程师直接按天重跑，未清理旧分区，导致特征表出现重复记录，模型评分偏高，部分正常商户被误拦。复盘发现三个问题：
- 补数前未确认写入模式，
append与overwrite混用。 - 未设置幂等键，重复执行产生双份数据。
- 未评估下游模型影响，补数后直接生效。
正确做法是：先标记旧分区为失效，再按 overwrite 重写，补数后跑一致性校验，并生成影响报告。校验 SQL 可参考：
-- 补数后一致性校验：检查重复与空值
SELECT dt, user_id, COUNT(*) AS cnt
FROM risk_feature
WHERE dt BETWEEN '2024-06-01' AND '2024-06-03'
GROUP BY dt, user_id
HAVING COUNT(*) > 1;
SELECT dt, COUNT(*) AS null_cnt
FROM risk_feature
WHERE dt BETWEEN '2024-06-01' AND '2024-06-03'
AND feature_value IS NULL
GROUP BY dt;
常见误区还包括：把补数当“重跑任务”、忽略口径版本、补数后不通知下游、审计日志只记录成功不记录失败。这些都会让补数从“修复”变成“二次事故”。