3. 数据基础与采集：需要哪些数据源、数据质量要求、数据采集频率与粒度

做风险预警，说白了就是跟数据打交道。我见过太多团队，模型建得漂漂亮亮，最后栽在数据上。嗯，这里咱们得把地基打牢。

3.1 核心数据源：你至少需要这几类

我个人习惯把数据源分成三大类。缺了哪一类，预警系统都会变成“睁眼瞎”。

数据类别	典型数据源	我踩过的坑
内部交易数据	订单流水、支付记录、退款记录	曾经有个项目，只拉了主订单表，漏了子订单的拆分数据，结果预警阈值全偏了。
外部征信/黑名单	央行征信、百行征信、法院执行信息	外部数据更新慢，我建议至少每天拉一次全量快照。
行为日志数据	登录日志、点击流、设备指纹	日志量最大，但最容易被忽略。你想想看，一个用户突然换了设备登录，这本身就是信号。

3.2 数据质量要求：脏数据比没数据更可怕

我在项目中遇到过一件事：某个风控指标突然报警，查了半天，发现是上游ETL脚本写错了，把“0”和“NULL”混为一谈。白白浪费了团队两天时间。

所以，数据质量必须定死几条红线：

• 完整性：关键字段（如用户ID、交易金额）不允许为空。空值率超过5%的表，直接打回重审。
• 准确性：金额字段必须与支付网关对账一致。我曾经用“SUM(订单金额) = 支付流水总额”这个等式，揪出过数据管道丢数据的Bug。
• 时效性：离线数据延迟不能超过T+1，实时数据延迟不能超过5分钟。为什么？因为阈值是动态的，你用昨天的数据去算今天的风险，黄花菜都凉了。
• 一致性：同一个用户ID，在交易表和日志表里必须能关联上。我建议用数据血缘工具做自动校验。

3.3 采集频率与粒度：快还是准？这是个问题

采集频率和粒度，说白了就是“你要多快看到风险”和“你要看多细”。

我一般这样定：

• 实时采集（秒级）：用于支付、登录等高敏感事件。粒度要细到单笔交易。比如，同一IP在1秒内发起5笔支付，这必须实时拦截。
• 准实时采集（分钟级）：用于用户行为画像更新。粒度可以聚合到“用户-小时”级别。比如，统计过去1小时内的登录失败次数。
• 批量采集（天级）：用于征信更新、黑名单同步。粒度通常是全量快照或增量更新。我建议用增量更新，全量跑太费资源。

为什么会这样区分？你想想看，如果所有数据都实时采集，服务器扛不住，成本也爆炸。如果都按天采集，那实时风控就形同虚设。

3.4 知识体系框架：一张图看懂数据基础

下面这张图，是我自己总结的数据采集核心逻辑。你可以把它当成一个检查清单。

嗯，这张图其实就讲了三件事：数据从哪来、质量怎么控、采集怎么定。把这三点理清楚，你的预警系统就有了一个靠谱的数据底座。

---