📚 课程目录第2章风控数据体系基础

2. 风控数据体系基础

做数据回补、补数与审计追溯，第一步不是写SQL，而是把“数据从哪来、长什么样、怎么流动、落在哪张表”讲清楚。风控数据体系如果没梳理明白，回补时就会出现补错分区、补重数据、口径不一致、审计断链等典型事故。本节从四个维度建立基础认知：数据分类、数据源、流转链路、常见表与字段。

一、核心原理：风控数据为什么要先分类

风控数据的本质是“用历史行为与属性判断当前风险”。不同数据在时效性、准确性、可回溯性上的要求差异极大，因此必须先分类，才能决定存储方式、保留周期和回补策略。

按来源分：内部业务数据（订单、支付、登录）、外部三方数据（征信、设备指纹、黑名单）、衍生数据（规则命中、模型分、标签）。
按时效分：实时流数据（毫秒级决策）、准实时数据（分钟级）、离线批量数据（T+1）。
按可变性分：事实数据（一旦产生不可变，如交易流水）、状态数据（会更新，如用户风险等级）、快照数据（按时间切片，如每日额度）。
按敏感度分：一般数据、敏感个人信息、需脱敏或加密存储的数据。

分类的直接价值：事实数据适合按分区回补，状态数据回补时必须还原“当时状态”，快照数据回补要严格对齐业务日期。分类错了，回补逻辑一定错。

二、数据源与接入方式

风控系统的数据源通常分为四类，接入方式与回补难度各不相同。

数据源类型	典型内容	接入方式	回补难度
业务库	订单、支付、用户、账户	Binlog订阅、离线抽数	中，需处理更新与删除
日志埋点	登录、设备、行为事件	Kafka、日志采集	高，易丢失、格式多变
三方接口	征信、黑名单、评分	API调用、文件交换	高，依赖对方可重放性
衍生计算	规则命中、模型分、标签	离线任务、流计算	低，可重跑但需版本对齐

接入时最关键的是保留“原始层”。原始层不做业务清洗，只做落地和分区，这样回补时才有可信的源头。很多团队跳过原始层直接进明细层，一旦口径变更就无法追溯。

三、数据流转链路

典型风控数据链路可以概括为：采集 → 原始层 → 明细层 → 汇总/特征层 → 服务层 → 决策与审计。

业务库/日志/三方
      │
      ▼
  ODS 原始层（按天分区，保留原始报文）
      │
      ▼
  DWD 明细层（清洗、标准化、去重）
      │
      ▼
  DWS/DWT 汇总与特征层（用户维度、设备维度）
      │
      ▼
  ADS 服务层（规则输入、模型输入、报表）
      │
      ▼
  决策引擎 → 风控结果 → 审计追溯表

回补和补数通常发生在ODS到ADS之间。审计追溯则要求每一层都能回答三个问题：这条数据什么时候进来的、经过了哪些加工、当时用的哪个版本。因此链路设计必须保留分区字段、批次号、任务版本、数据版本。

建议在每层都增加 etl_batch_id（批次号）和 data_version（数据版本）。回补时用批次号隔离，避免覆盖正常数据；审计时用版本号还原当时口径。

四、常见数据表与字段说明

风控域常见表可以按“事件表、状态表、快照表、结果表”四类理解。

事件表：记录发生了什么，如交易事件表、登录事件表。字段通常包括 event_id、user_id、device_id、event_time、amount、ip、status。
状态表：记录当前状态，如用户风险等级表。字段包括 user_id、risk_level、update_time、operator。
快照表：按日期切片，如每日额度快照。字段包括 dt、user_id、credit_limit、used_amount。
结果表：记录决策输出，如规则命中表、模型分表。字段包括 request_id、rule_id、hit_flag、score、decision、create_time。

下面是一张典型的风控决策结果表字段示例：

CREATE TABLE risk_decision_result (
  request_id      STRING  COMMENT '请求唯一ID',
  user_id         STRING  COMMENT '用户ID',
  device_id       STRING  COMMENT '设备ID',
  rule_id         STRING  COMMENT '规则编号',
  hit_flag        INT     COMMENT '是否命中 0/1',
  model_score     DOUBLE  COMMENT '模型分',
  decision        STRING  COMMENT '决策结果 PASS/REJECT/REVIEW',
  data_version    STRING  COMMENT '数据版本',
  etl_batch_id    STRING  COMMENT '批次号',
  dt              STRING  COMMENT '业务日期分区',
  create_time     TIMESTAMP COMMENT '创建时间'
);

五、案例与场景：一次补数为什么补出了双倍命中

某团队发现某天规则命中率异常偏低，决定对DWD层做补数。操作时直接按dt重跑并覆盖原分区，但没有清理下游DWS汇总表。结果DWS中旧数据与新数据叠加，命中次数翻倍，报表显示命中率暴涨。审计时无法判断哪份数据是最终版本。

复盘结论有三点：第一，补数必须走批次隔离，不能直接覆盖；第二，下游汇总表要同步重算或标记失效；第三，审计表要记录补数操作人、时间、影响范围。这正是数据分类和链路设计不到位的代价。

常见误区：把“补数”当成简单重跑。实际上补数涉及分区、批次、下游依赖、版本和审计五件事。缺少任何一件，都会在追溯时断链。

六、方法流程：梳理风控数据体系的五步法

盘点数据源：列出所有内部库、日志、三方接口，标注时效与可重放性。
定义分类：按事实/状态/快照/结果四类归档，明确保留周期。
绘制链路：从ODS到ADS逐层标注表名、分区字段、更新方式。
补齐元数据：为每张表登记字段含义、口径、版本、负责人。
设计审计字段：统一加入批次号、数据版本、来源标识，确保可追溯。