风控项目说明
项目背景
薅羊毛在大多数情况下都只是一句玩笑话，但职业的羊毛党，或由此而衍生出来的黑灰产们，是让许多互联网公司都非常头疼的存在。
哪里有利益，哪里就有黑灰产——一只蚊子腿虽然无肉，但千万只，甚至上亿只蚊子腿的性质可就不一样了。
羊毛党正是利用平台漏洞，然后通过机器的批量 + 自动化操作，达到攫取惊人利益的目的。
下面是典型的（无门槛）优惠券场景下羊毛党的作案链路。
俗话说防患于未然，从图上可以看到，只要能够通过技术手段实禁止批量脚本的执行，就已经将大部分的低级羊毛党们挡在了门外。
至于说如何识别出恶意薅羊毛的行为，这也不难——因为在风控系统常年与羊毛党们的较量中，已经对这一群体的特征有了非常清晰的判断依据。
行为目的明确，他们的行为序列通常是
登录-领券-下单。只对客单价低的羊毛商品感兴趣，尤其是单价为
5~20元的商品。下单商品种类单一：订单商品种类超过一半为折扣商品。
年/月商品订单量少，因为他们只对羊毛商品感兴趣。
下单时间通常在深夜，比如凌晨1点至5点期间。
年/月登录次数少：羊毛党目的性强。
注册时间短，有的是当天注册当天就下单，根本不养号。
IP和设备更换频繁。
IP和设备出现重叠。
基于以上这些明确的判断依据，就可以制定有针对性的业务规则指标。
| 风控指标 | 举例说明 |
|---|---|
| 静态指标 | 1. 下单地址是否常用地址 2. 券使用的用户没有使用常用IP下单 |
| 统计指标 | 1. 账号近1分钟内登录次数 >= 3次 2. 用户领券数量超过50张 3. 领券用户近10天未登录但促销时有登录 |
| 关联指标 | 修改账号绑定手机号后马上下单 |
| 行为指标 | 用户行为序列为登录-领券-查看商品-添加购物车-下单 |
上面这些风控指标或风控规则都是需要存储到MySQL数据库中去的。
技术选型
一个功能相对完备的风控系统需要通常会包括风控运营管理、风控业务控制和风控规则引擎这三大部分。
当然，具体的功能结构和模块都是由不同的业务需求及其场景决定的。
风控运营管理：一套提供给运营人员使用的风控管理系统，包括设定风控策略、黑白名单管理、权限设置，以及展示风控事件的数据大屏等功能，这一块属于常规的业务系统开发，不管是Java、Python还是Go，都可以轻松实现，使用MVC三层架构、微服务或者是DDD都可以。风控业务控制：用来控制整个风控事件的处理流程，例如，对于任何一个风控事件的处理，首先从MySQL中加载风控规则，然后判断它具体的场景行为，然后进行简单的黑白名单判断，之后再进行指标计算，最后决定执行哪种风控策略。风控规则引擎：这是整个风控系统的核心部分。事件总线：通常会使用Kafka、Flume或Sqoop实现各类客户端埋点上报数据、服务端日志信息及业务行为事件的采集，或者将这些数据存储起来供后续使用，或者直接输送到规则引擎中进行实时计算。这里进行了简化，仅以Kafka + Flume的组合实现对业务日志的采集。下面是几种不同数据采集组件之间的简单比较。
对比项 Flume Logstash Sqoop Filebeat 运行方式 基于JVM 基于JRuby 基于JVM 基于Go 性能消耗 高 高 大数据量时受限 低 多数据源 支持 支持 有限 仅支持文件 多目的地 支持 支持 有限 支持 自定义功能 支持 支持 通过插件扩展 弱 维护成本 低 高 高 低 应用场景 业务日志采集 运维数据采集 业务数据采集 通用 规则引擎：计算各类风控事件数据是否符合风控指标的要求。常规组合是Flink，再加上辅助的规则引擎，例如，Drools、Groovy，或者是更轻量级的Aviator。数据持久化：存储风控指标计算过程中需要用到的各种数据，这些数据有些是实时的，有些是离线的。一些中间结算结果会保存到Redis，而一些离线数据，也往往会通过Clickhouse先执行一些预计算后再交由Flink处理，这样可以加快规则引擎的计算速度，提高整体性能。
整体架构
基于以上分析和设计，整个风控系统的架构如下。
而这里要展示的是风控系统核心的指标计算和行为序列识别的过程，因为它是整个风控系统最精华、技术含量最高的部分。
关注公众号后回复 风控 即可获得Flink大数据风控栏目剩余文章的访问密码。
