风控核心子域——名单服务构建及挑战

时间:2023-02-01 16:00:45

引言

名单服务是风控架构中重要子域,对风险决策的性能、用户体验、成本管控、风险治理沉淀都有重要影响,本文将详细介绍名单服务设计思路和实现。

背景

什么是名单?

名单服务通常有几个部分组成:

风险类型

  • 黑名单:绝对会被拒绝的用户。大部分是历史数据清洗出来作弊或者破坏业务的用户,这部分用户对企业无价值且放之进入会破坏生态平衡
  • 灰名单:灰名单上的客户需要进一步审核。这部分用户可能存在某些风险,但是没有明确的证据表明他们是“黑”的
  • 白名单:这部分客户是正常用户,是企业数分人员基于历史表现清洗出来的合规高价值用户,可以直接放行

名单维度

  • 主键:手机号、用户 ID、身份证号、IP、设备标识、wifi MAC 地址等等
  • 业务域:全域、业务子域、细分领域等等,这边需要字典服务来枚举出需要管控的粒度和场景

时间维度 名单是有一定的生效期的,不同的行为会导致锁定期不一样,生效时间可以灵活设置

为什么需要名单服务?

  • 最易构建的决策能力:风控前期的构建是比较依赖名单决策的,策略数分人员通过历史数据判定哪些是“坏用户”,直接将其存储到名单库中,后续请求直接在第一道名单决策中踢出,而不需要执行后续策略在判定一次。策略相对名单来说是非常“重”的,且名单服务构建简单便捷,省时省力。
  • 性能考虑:名单判定一般是在决策流的第一道,试想,对企业服务来说,大部分用户其实都是正常的,如果每个用户的请求都过一遍策略,对成本是极大的浪费,同时对性能来说也是极大的挑战。此时名单服务通过白黑名单,将大部分用户直接决策出去,只对不明确的客户和有风险的客户来做决策,极大地减少了开销。

设计实现

名单服务的特点如下:

  • 名单数据来源:可以是实时产生、离线跑批生产、运营人员手动批量导入等等,形式多样
  • 性能足够好:属于决策流入口必过服务之一,即最大流量冲击,需要经得起峰值压力,RT 要足够小
  • 稳定性:高性能同时还需要高质量保证,如果名单服务出问题,后果不堪设想,流量全部流放到下游,可能会出现服务雪崩
  • 质量保证:任何名单添加到名单库中都需要重视,随意的添加可能会给企业带来难以想象的损失,所以得有完备的审核记录及添加原因,最重要的是生效时间的设定

整体名单服务的数据流图如下所示,重要节点会作明确说明: 风控核心子域——名单服务构建及挑战

实时链路名单查询设计

考虑到名单有时效性及性能要求,且名单数据结构整体简单(多维度,单个维度存储内容小),选择 Redis 存储名单数据非常适合快速查询,数据结构如下: 风控核心子域——名单服务构建及挑战 说明:

  • 采用 Redis Hash 结构存储数据
  • 为何不用 TTL 来存储过期时间?:一是 expire 最大过期时间不能超过 Integer.MAXVALUE 不能满足长时间的过期诉求;二来 Redis 本身定位是缓存,不是永久存储,即数据是可丢失的,需要自己保证服务的高可用

依赖于 Redis 集群良好的性能,基本能满足线上峰值高 QPS 查询需求,且 RT 能很好的控制在 10 ms 以内。如上所说就是要保障高稳定性需求,如何保障名单数据的高可用是首要问题。

高可用设计

Redis 本身定位是缓存,不能永久保存数据,且集群瘫痪或者数据部分缺失应对业务影响较小(能及时恢复的情况下,运维保障集群的可用性),如下是高可用数据设计架构: 风控核心子域——名单服务构建及挑战 说明:

  • T+1 Job 保证数据稳定:每天离线任务全量覆盖,从关系数据库 PG/MySQL 中抽数 push 到 Redis 中即可
  • Redis 集群出问题:不管是老集群重启还是更换到新集群,先用 RDB 恢复数据,保证线上可用,再立即执行离线任务做精确覆盖(T 日的数据丢失需要立即覆盖),考虑到读写同时进行可能会有问题,需要分集群切流

同时需要关注多线程问题,同一个维度,在同一时间可能存在批量更新情况,尤其是离线任务恢复时,历史数据会存在对一个维度多次更新问题,不考虑多线程问题可能会导致数据被篡改。

数据安全审计

名单库的风险点在于:随意地添加名单可能导致“坏用户”畅通无阻,“好用户”无法在进入业务流程

名单的生产来源及定性原因不明确,线上在排查问题时也只能干瞪眼,为了能回溯名单操作,需要做到如下几点:

  • 写日志:任何写动作需要追加日志,且需要做持久换存储,方便做名单时序数据分析
  • 黑名单 & 白名单需要审计:尤其是线上单独添加这种,必须指明原因且要对操作负责
  • 跑批任务审计:离线任务或者算法推数等需要控量,否则在迭代更新过程中出现 BUG 问题,导致名单数据猛增,后果不堪设想

异动监控

监控重中之重

能第一时间感知问题,监控的维度如下:

  • 决策层面监控:灰、白、黑名单决策数量监控
  • 元数据产出层面监控:任何名单猛增或猛跌都是需要去定性是否正常
  • 拉黑踢白:没有永久犯错的人,也没有永久的好人,名单之间的流动也需要关注

总结

名单服务在风控域中是最重要的子域之一,是风控流量的“网关”。名单库对整个风控决策的稳定性,性能提升起到决定性影响。

同时名单服务也是“高危”的,如果使用不当,可能会给企业良好用户带来困扰,给那些“黑产”敞开门户,需要做好数据审核及异动监控。

往期精彩

欢迎关注公众号:咕咕鸡技术专栏 个人技术博客:https://jifuwei.github.io/

风控核心子域——名单服务构建及挑战

若有收获,就点个赞吧