3. 数据完整性治理概述

在风控体系中，数据完整性不是“有没有数据”这么简单，而是指在业务需要做出判断时，关键字段、关键记录、关键链路是否齐全、连续、可追溯。完整性一旦被破坏，准确性和一致性就失去了讨论基础：缺了字段，规则无法执行；缺了事件，模型无法还原；缺了关联，审计无法闭环。因此，完整性治理应作为风控数据治理的第一道防线。

一、核心原理：完整性的四个维度

风控数据的完整性可以从四个维度来理解，它们分别回答不同的问题：

• 字段完整性：单条记录中，必填字段是否为空、是否缺失关键属性。例如设备指纹、IP、证件号、银行卡号等。
• 记录完整性：应产生的业务记录是否都落库。例如每笔申请都应有申请事件、决策事件、结果事件。
• 链路完整性：跨系统、跨环节的数据是否能串联成完整链路。例如从注册、登录、申请、授信到支用，事件序列是否连续。
• 时间完整性：时间戳是否齐全、时区是否统一、事件顺序是否可还原。时间缺失或错乱会直接破坏风控时序判断。

这四个维度不是并列孤立的，而是层层递进：字段缺失会影响记录可用性，记录缺失会破坏链路，链路断裂又会让时间序列分析失效。治理时不能只补字段，而要沿着“字段—记录—链路—时间”逐层校验。

二、常见缺失场景与业务影响

完整性缺失在风控场景中非常普遍，常见场景可以归纳为以下几类：

缺失场景	典型表现	业务影响
上游采集缺失	设备信息、位置、行为埋点未上报或上报为空	规则命中率下降，模型特征缺失，误判率上升
接口字段遗漏	第三方数据源返回字段缺失或结构变更	决策链路中断，人工复核量增加
事件漏记	申请、审批、放款等关键事件未落库	无法还原用户行为路径，审计追踪困难
关联键缺失	用户ID、设备ID、订单号不一致或为空	跨系统数据无法关联，团伙识别失效
时间戳异常	时间为空、时区混乱、顺序颠倒	时序特征失真，实时风控窗口计算错误
历史数据迁移丢失	旧系统数据未完整迁移或映射错误	回溯分析偏差，模型训练样本不完整

这些缺失场景带来的业务影响，往往不是单点故障，而是连锁反应。例如设备信息缺失会导致设备指纹规则失效，进而使团伙识别能力下降；事件漏记会让事后审计无法还原决策依据，带来合规风险。更严重的是，完整性缺失具有隐蔽性：它不会像系统宕机那样立刻暴露，而是逐渐侵蚀风控效果。

三、治理原则与落地流程

完整性治理应遵循以下原则：

1. 关键字段优先：不是所有字段都同等重要。应围绕风控决策、模型特征、审计要求，定义关键字段清单。
2. 源头治理为主：优先在上游采集、接口契约、埋点规范中解决，而不是在下游反复清洗。
3. 可度量、可监控：完整性必须有量化指标，如必填字段填充率、事件到达率、链路闭合率。
4. 责任到人：每个关键数据项都应有明确的数据Owner和系统Owner。
5. 闭环修复：发现缺失后，要能定位、补数、验证并防止复发。

落地流程可以概括为“定义—检测—定位—修复—验证”五步：

1. 定义关键数据清单与完整性规则
   示例：申请事件必须包含 user_id、device_id、apply_time、decision_result

2. 检测完整性指标
   示例：每日统计必填字段填充率、事件到达率、链路闭合率

3. 定位缺失根因
   示例：按上游系统、接口、埋点版本、时间窗口分组分析

4. 修复与补数
   示例：接口补字段、埋点补上报、历史数据回补

5. 验证与防复发
   示例：回归校验、监控告警、接口契约测试

在技术实现上，完整性检测通常需要配置规则并定期运行。例如，可以用SQL对关键字段做空值率和事件覆盖率检查：

-- 检查申请事件关键字段缺失情况
SELECT
  COUNT(*) AS total_cnt,
  SUM(CASE WHEN user_id IS NULL THEN 1 ELSE 0 END) AS user_id_missing,
  SUM(CASE WHEN device_id IS NULL THEN 1 ELSE 0 END) AS device_id_missing,
  SUM(CASE WHEN apply_time IS NULL THEN 1 ELSE 0 END) AS apply_time_missing
FROM risk_apply_event
WHERE dt = '2025-03-01';

-- 检查申请到决策的事件链路闭合率
SELECT
  COUNT(DISTINCT a.apply_id) AS apply_cnt,
  COUNT(DISTINCT d.apply_id) AS decision_cnt,
  COUNT(DISTINCT d.apply_id) / COUNT(DISTINCT a.apply_id) AS close_rate
FROM risk_apply_event a
LEFT JOIN risk_decision_event d
  ON a.apply_id = d.apply_id
WHERE a.dt = '2025-03-01';

这些指标应纳入日常监控，并设置阈值告警。例如，关键字段填充率低于99.5%、事件到达率低于99%、链路闭合率低于98%时，应触发排查。

四、案例复盘：一次设备信息缺失引发的风控失效

某信贷风控团队曾遇到一次典型问题：某段时间内，设备指纹规则命中率明显下降，团伙识别模型效果变差。排查后发现，安卓端某版本App在特定机型上未采集到设备信息，导致device_id字段为空。由于该字段不是数据库必填项，问题在上线两周后才被发现。

复盘时发现三个关键问题：

• 设备信息未列入关键字段清单，缺少完整性监控；
• 客户端埋点与后端接口没有契约校验，字段缺失未告警；
• 下游模型对缺失值有默认填充，掩盖了问题严重性。

修复措施包括：将device_id纳入关键字段并设置填充率告警；在接口层增加字段校验；对模型缺失值填充逻辑增加监控；建立埋点版本回归测试。经过治理，设备信息填充率恢复到99.9%以上，团伙识别效果也逐步恢复。

综上，数据完整性治理是风控数据治理的基础工程。它要求我们从字段、记录、链路、时间四个维度建立完整性视图，识别常见缺失场景，量化业务影响，并坚持源头治理、关键优先、可度量、责任到人、闭环修复的原则。只有完整性得到保障，准确性和一致性治理才有稳固的起点。