基于Flink和规则引擎的实时风控解决方案

案例与解决方案汇总页：
阿里云实时计算产品案例&解决方案汇总

对一个互联网产品来讲，典型的风控场景包括：注册风控、登录风控、交易风控、活动风控等，而风控的最佳效果是防患于未然，因此事前事中和过后三种实现方案中，又以事前预警和事中控制最好。

这要求风控系统必定要有实时性。

本文就介绍一种实时风控解决方案。

1.整体架构

风控是业务场景的产物，风控系统直接服务于业务系统，与之相关的还有惩罚系统和分析系统，各系统关系与角色以下：

• 业务系统，一般是APP+后台 或者 web，是互联网业务的载体，风险从业务系统触发；
• 风控系统，为业务系统提供支持，根据业务系统传来的数据或埋点信息来判断当前用户或事件有无风险；
• 惩罚系统，业务系统根据风控系统的结果来调用，对有风险的用户或事件进行控制或惩罚，好比增长验证码、限制登录、禁止下单等等；
• 分析系统，该系统用以支持风控系统，根据数据来衡量风控系统的表现，好比某策略拦截率忽然下降，那可能意味着该策略已经失效，又好比活动商品被强光的时间忽然变短，这表面整体活动策略可能有问题等等，该系统也应支持运营/分析人员发现新策略；

其中风控系统和分析系统是本文讨论的重点，而为了方便讨论，咱们假设业务场景以下：

• 电商业务；

• 风控范围包括：

  • 注册，虚假注册；
  • 登录，盗号登录；
  • 交易，盗刷客户余额；
  • 活动，优惠活动薅羊毛；
• 风控实现方案：事中风控，目标为拦截异常事件；

2.风控系统

风控系统有规则和模型两种技术路线，规则的优势是简单直观、可解释性强、灵活，因此长期活跃在风控系统之中，但缺点是容易被攻破，一但被黑产猜到里面就会失效，因而在实际的风控系统中，每每再结合上基于模型的风控环节来增长健壮性。但限于篇幅，本文中咱们只重点讨论一种基于规则的风控系统架构，固然若是有模型风控的诉求，该架构也彻底支持。

规则就是针对事物的条件判断，咱们针对注册、登录、交易、活动分别假设几条规则，好比：

• 用户名与身份证姓名不一致；
• 某IP最近1小时注册帐号数超过10个；
• 某帐号最近3分钟登录次数大于5次；
• 某帐号群体最近1消失购买优惠商品超过100件；
• 某帐号最近3分钟领券超过3张；

规则能够组合成规则组，为了简单起见，咱们这里只讨论规则。

规则其实包括三个部分：

• 事实，即被判断的主体和属性，如上面规则的帐号及登录次数、IP和注册次数等；
• 条件，判断的逻辑，如某事实的某属性大于某个指标；
• 指标阈值，判断的依据，好比登录次数的临界阈值，注册帐号数的临界阈值等；

规则可由运营专家凭经验填写，也可由数据分析师根据历史数据发掘，但由于规则在与黑产的攻防之中会被猜中致使失效，因此无一例外都须要动态调整。

基于上边的讨论，咱们设计一个风控系统方案以下：

该系统有三条数据流向：

• 实时风控数据流，由红线标识，同步调用，为风控调用的核心链路；
• 准实时指标数据流，由蓝线标识，异步写入，为实时风控部分准备指标数据；
• 准实时/离线分析数据流，由绿线标识，异步写入，为风控系统的表现分析提供数据；

本节先介绍前两部分，分析系统在下一节介绍。

2.1 实时风控

实时风控是整个系统的核心，被业务系统同步调用，完成对应的风控判断。

前面提到规则每每由人编写而且须要动态调整，因此咱们会把风控判断部分与规则管理部分拆开。规则管理后台为运营服务，由运营人员去进行相关操做：

• 场景管理，决定某个场景是否实施风控，好比活动场景，在活动结束后能够关闭该场景；
• 黑白名单，人工/程序找到系统的黑白名单，直接过滤；
• 规则管理，管理规则，包括增删或修改，好比登录新增IP地址判断，好比下单新增频率校验等；
• 阈值管理，管理指标的阈值，好比规则为某IP最近1小时注册帐号数不能超过10个，那1和10都属于阈值；

讲完管理后台，那规则判断部分的逻辑也就十分清晰了，分别包括前置过滤、事实数据准备、规则判断三个环节。

2.1.1 前置过滤

业务系统在特定事件（如注册、登录、下单、参加活动等）被触发后同步调用风控系统，附带相关上下文，好比IP地址，事件标识等，规则判断部分会根据管理后台的配置决定是否进行判断，若是是，接着进行黑白名单过滤，都经过后进入下一个环节。

这部分逻辑很是简单。

2.1.2 实时数据准备

在进行判断以前，系统必需要准备一些事实数据，好比：

• 注册场景，假如规则为单一IP最近1小时注册帐号数不超过10个，那系统须要根据IP地址去redis/hbase找到该IP最近1小时注册帐号的数目，好比15；
• 登录场景，假如规则为单一帐号最近3分钟登录次数不超过5次，那系统须要根据帐号去redis/hbase找到该帐号最近3分钟登录的次数，好比8；

redis/hbase的数据产出咱们会在第2.2节准实时数据流中进行介绍。

2.2.3 规则判断

在获得事实数据以后，系统会根据规则和阈值进行判断，而后返回结果，整个过程便结束了。

整个过程逻辑上是清晰的，咱们常说的规则引擎主要在这部分起做用，通常来讲这个过程有两种实现方式：

• 借助成熟的规则引擎，好比Drools，Drools和Java环境结合的很是好，自己也很是完善，支持不少特性，不过使用比较繁琐，有较高门槛，可参考文章【1】；
• 基于Groovy等动态语言本身完成，这里不作赘述。可参考文章【2】；

这两种方案都支持规则的动态更新。

2.2 准实时数据流

这部分属于后台逻辑，为风控系统服务，准备事实数据。

把数据准备与逻辑判断拆分，是出于系统的性能/可扩展性的角度考虑的。

前边提到，作规则判断须要事实的相关指标，好比最近一小时登录次数，最近一小时注册帐号数等等，这些指标一般有一段时间跨度，是某种状态或聚合，很难在实时风控过程当中根据原始数据进行计算，由于风控的规则引擎每每是无状态的，不会记录前面的结果。

同时，这部分原始数据量很大，由于用户活动的原始数据都要传过来进行计算，因此这部分每每由一个流式大数据系统来完成。在这里咱们选择Flink，Flink是当今流计算领域无可争议的No.1，不论是性能仍是功能，都能很好的完成这部分工做。

这部分数据流很是简单：

• 业务系统把埋点数据发送到Kafka；

• Flink订阅Kafka，完成原子粒度的聚合；

  • 注：Flink仅完成原子粒度的聚合是和规则的动态变动逻辑相关的。举例来讲，在注册场景中，运营同窗会根据效果一会要判断某IP最近1小时的注册帐号数，一会要判断最近3小时的注册帐号数，一会又要判断最近5小时的注册帐号数……也就是说这个最近N小时的N是动态调整的。那Flink在计算时只应该计算1小时的帐号数，在判断过程当中根据规则来读取最近3个1小时仍是5个1小时，而后聚合后进行判断。由于在Flink的运行机制中，做业提交后会持续运行，若是调整逻辑须要中止做业，修改代码，而后重启，至关麻烦；同时由于Flink中间状态的问题，重启还面临着中间状态可否复用的问题。因此假如直接由Flink完成N小时的聚合的话，每次N的变更都须要重复上面的操做，有时还须要追数据，很是繁琐。

• Flink把汇总的指标结果写入Redis或Hbase，供实时风控系统查询。二者问题都不大，根据场景选择便可。

经过把数据计算和逻辑判断拆分开来并引入Flink，咱们的风控系统能够应对极大的用户规模。

3.分析系统

前面的东西静态来看是一个完整的风控系统，但动态来看就有缺失了，这种缺失不体如今功能性上，而是体如今演进上。即若是从动态的角度来看一个风控系统的话，咱们至少还须要两部分，一是衡量系统的总体效果，一是为系统提供规则/逻辑升级的依据。

在衡量总体效果方面，咱们须要：

• 判断规则是否失效，好比拦截率的忽然下降；
• 判断规则是否多余，好比某规则历来没拦截过任何事件；
• 判断规则是否有漏洞，好比在举办某个促销活动或发放代金券后，福利被领完了，但没有达到预期效果；

在为系统提供规则/逻辑升级依据方面，咱们须要：

• 发现全局规则，好比某人在电子产品的花费忽然增加了100倍，单独来看是有问题的，但总体来看，可能不少人都出现了这个现象，原来是苹果发新品了……
• 识别某种行为的组合，单次行为是正常的，但组合是异常的，好比用户买菜刀是正常的，买车票是正常的，买绳子也是正常的，去加油站加油也是正常的，但短期内同时作这些事情就不是正常的。
• 群体识别，好比经过图分析技术，发现某个群体，而后给给这个群体的全部帐号都打上群体标签，防止出现那种每一个帐号表现都正常，但整个群体却在集中薅羊毛的状况。

这即是分析系统的角色定位，在他的工做中有部分是肯定性的，也有部分是探索性的，为了完成这种工做，该系统须要尽量多的数据支持，如：

• 业务系统的数据，业务的埋点数据，记录详细的用户、交易或活动数据；
• 风控拦截数据，风控系统的埋点数据，好比某个用户在具备某些特征的状态下由于某条规则而被拦截，这条拦截自己就是一个事件数据；

这是一个典型的大数据分析场景，架构也比较灵活，我仅仅给出一种建议的方式。

相对来讲这个系统是最开放的，既有固定的指标分析，也可使用机器学习/数据分析技术发现更多新的规则或模式，限于篇幅，这里就不详细展开了。

原文连接

本文为云栖社区原创内容，未经容许不得转载。