📚 课程目录第2章风控数据源与SQL基础回顾

2. 风控数据源与SQL基础回顾

风控数据分析的起点是理解数据从哪里来、长什么样，以及如何用SQL高效、安全地操作这些数据。本章将系统梳理风控领域最常见的三类数据源，回顾SQL核心语法，并建立一套风控场景下的SQL编写规范，为后续的质量监控打下坚实基础。

2.1 常见风控数据源

风控模型与规则引擎依赖的数据主要来自内部业务系统、第三方合作机构以及历史积累的标签库。按用途可归纳为以下三大类：

数据源类型	典型表/接口	核心字段示例	风控用途
用户画像	user_profile, user_tag	user_id, age, gender, occupation, credit_level, registration_days	身份核验、信用评分、群体划分
交易流水	transaction_log, payment_order	trans_id, user_id, amount, trans_time, merchant_id, trans_type, ip_address	异常交易检测、欺诈模式识别、额度管控
黑名单	blacklist, risk_device, fraud_ip	id_type, id_value, list_type, source, create_time, expire_time	拦截已知风险实体、设备指纹匹配

实践要点：风控数据源通常具有高敏感性和时效性。用户画像中的标签可能涉及隐私，交易流水需要精确到秒级时间戳，黑名单则必须支持快速过期与增量更新。在SQL查询中，务必对敏感字段进行脱敏处理，并对时间窗口条件做索引优化。

2.2 SQL基础语法回顾

风控SQL开发中，以下语法是最高频使用的核心子集。掌握它们能覆盖90%以上的日常数据提取与质量校验需求。

2.2.1 数据查询与过滤

-- 基础查询：用户画像表，筛选高信用等级用户
SELECT user_id, credit_level, registration_days
FROM user_profile
WHERE credit_level >= 4
  AND registration_days > 30
ORDER BY credit_level DESC;

2.2.2 多表关联与聚合

-- 关联交易流水与黑名单，统计命中黑名单的交易笔数与金额
SELECT b.list_type,
       COUNT(t.trans_id) AS hit_count,
       ROUND(SUM(t.amount), 2) AS total_amount
FROM transaction_log t
INNER JOIN blacklist b
  ON t.user_id = b.id_value
WHERE t.trans_time >= '2025-01-01'
  AND b.expire_time > NOW()
GROUP BY b.list_type
HAVING COUNT(t.trans_id) > 0;

2.2.3 窗口函数与排名

-- 对每个用户按交易金额降序排名，取前3笔大额交易
SELECT user_id, trans_id, amount,
       ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY amount DESC) AS rn
FROM transaction_log
QUALIFY rn <= 3;  -- 部分引擎支持 QUALIFY 语法

常见陷阱：风控场景中，JOIN 条件遗漏索引字段会导致全表扫描，影响实时监控性能。另外，GROUP BY 与 HAVING 的过滤顺序容易混淆——WHERE 在聚合前过滤行，HAVING 在聚合后过滤组，务必区分使用。

2.3 风控SQL编写规范

为了保障数据质量、查询性能和团队协作效率，风控SQL必须遵循统一的编写规范。以下规范将贯穿本课程所有实战案例。

规范类别	具体要求	示例/反例
命名规范	表名使用小写+下划线；字段名清晰表达业务含义；临时表加 `tmp_` 前缀	✅ `user_profile` ❌ `UserProfile`
注释规范	每个查询块顶部写清目的；复杂逻辑逐行注释；标注作者与最后修改日期	✅ `-- 提取近7天命中黑名单的交易`
性能规范	WHERE 条件中避免函数包裹索引字段；JOIN 键必须建索引；限制 SELECT * 的使用	✅ `WHERE trans_time >= '2025-01-01'` ❌ `WHERE DATE(trans_time) = '2025-01-01'`
安全规范	敏感字段（手机号、身份证）查询后立即脱敏；禁止将生产数据直接导出到本地	✅ `CONCAT(LEFT(phone,3), '****', RIGHT(phone,4))`
可读性规范	关键字大写；子查询缩进对齐；长SQL按逻辑分块空行	✅ `SELECT ... FROM ... WHERE ...` 统一大写

  规范落地建议：建议团队在代码仓库中维护一份 .sqlfluff 或 SQL_Lint 配置文件，将上述规范固化为自动化检查规则。每次提交SQL前，通过CI流水线自动校验命名、注释、性能和安全规则，从源头拦截低质量代码进入生产环境。