Flink实战之实时风控规则引擎

问题导读： 1、怎样构建一个风控业务架构？ 2、风控规则模型有哪些？ 3、怎样实现Flink CEP 动态更新？

 

一、项目背景

目前钱大妈基于云原生大数据组件（DataWorks、MaxCompute、Flink、Hologres）构建了离线和实时数据一体化的全渠道数据中台，为各业务线提供 BI 报表及数据接口支持。除了数仓的分析场景以外，钱大妈面临着业务系统中的风控需求，例如每季度的营销费用中被不少的羊毛党薅走正常用户的利益，其中羊毛党一方面可能导致用户的口碑下降，另一方面也会影响原有的活动运营预算迅速攀升从而导致资损。钱大妈与阿里云 Flink 实时计算团队共建实时风控规则引擎，精确识别羊毛党以防营销预算流失。

二、业务架构

钱大妈风控业务架构如图二所示总共分为四个部分：事件接入、风险感知、风险应对、风险回溯。通过 Flink 在线 ETL 加工处理的实时用户画像标签和销售事实指标，除了作为线上 BI 指标和实时大屏数据展示，也为实时规则引擎的事件接入提供重要的数据支持。

1. 事件接入。其中包括黑白灰名单库、画像特征数据、行为埋点数据和中台交易数据。

2. 风险感知。策略调研后发布到规则引擎，并对告警结果进行离线回归和多渠道触达。

3. 风险应对。对涉及到财务结算的规则提供再审核、豁免机制或人工补偿。

4. 风险回溯。策略命中后进行统计和风险分类分级，预警离线回溯并对风控事件闭件。

三、规则模型

风控业务专员通过产品界面简单配置即可实时动态发布风控规则，同时对在线 Flink 作业的规则进行新增、更新以及删除，其中风控规则模型主要分为统计型规则和序列型规则，相同模型支持子规则的嵌套，不同模型之间可以通过与、或关系进行组合。

以下为规则组合中需要动态配置能力的配置项：

1. 分组字段。不同字段分组、多字段分组的情况在风控规则的应用中非常常见。有如下规则样例：

   1. 以用户 ID 分组："用户的下单次数"；

   2. 以用户 ID、区域 ID 作为分组："用户同一段时间内不同区域的订单数"。

2. 聚合函数。聚合函数包括业务常用的聚合逻辑，规则引擎依赖 Flink 内置丰富的累加器，并在 Accumulator 接口的基础上进行了根据需求场景的自定义实现。样例规则如下：

   1. A 门店近 30 分钟独立消费用户数小于 100；

   2. B 门店新客消费金额大于 300。

3. 窗口周期。窗口周期也即每个窗口的大小，如业务方可能希望在持续 30 分钟的秒杀活动周期内运行规则，或者希望重点关注异常时段。

   1. 每 30 分钟时间窗口内，单个用户发起超过 20 笔未支付订单；

   2. 凌晨 1 点至 3 点，单个用户支付订单数超 50 笔。

4. 窗口类型。为了面对不同的业务需求，我们将业务规则中常见的窗口类型集成到规则引擎内部。其中包括滑动窗口、累计窗口、甚至是无窗口（即时触发）。

5. 聚合前的过滤条件：

   1. 只对"下单事件"进行统计；

   2. 过滤门店"虚拟用户"。

6. 聚合后的过滤条件：

   1. 用户 A 在 5 分钟内下单次数 "超过 150 次"；

   2. 用户 B 在 5 分钟内购买金额 "超过 300 元"。

7. 计算表达式。风控规则的字段口径通常是需要组合计算的，我们在表达式计算和编译中集成了更轻便和更高性能的 Aviator 表达式引擎。规则样例如下：

   1. 应收金额大于 150 元（应收金额 = 商品金额合计 +运费 + 优惠合计）；

   2. 通过 POS 端支付的应收金额大于 150 元。

8. 行为序列。行为序列其实也是事件与事件之间的组合，他打破了以往风控规则只能基于单事件维度描述事实的壁垒，在事件与事件之间的事实信息也将被规则引擎捕捉。规则样例如下：

   1. 用户 A 在 5 分钟内依次做了点击、收藏、加购；

   2. 用户 B 在 30 分钟前领了优惠券，但是没有下单。

四、难点攻坚

针对规则模型的流式序列型数据，我们选择 Flink CEP 处理事件序列匹配，由于我们整个风控作业使用 Flink 实现，并且 Flink CEP 作为 Flink 官方原生支持的 Library，集成度高无需引用额外组件即可满足事件序列匹配的需求。作业预期是允许用户在产品界面上热发布规则的，但是基于开源的 Flink CEP，实现规则动态更新能力存在以下困难点：

1. Flink 社区的 CEP API 无法支持动态修改 Pattern 即无法满足上层规则中台、风控中台的可集成性；

2. Flink 社区的 CEP API 无法支持Pattern 定义事件之间的超时。

阿里云 Flink 实时计算团队和钱大妈工程师共同攻坚，在 Flink 社区发起如下两个 FLIP 提案并且在阿里云实时计算产品上面输出相应功能解决此问题：

1. FLIP-200 [1]：CEP 支持多规则和动态 Pattern 变更；

2. FLIP-228 [2]：CEP 支持 Pattern 定义事件之间的超时。

阿里云实时计算产品输出的支持多规则和动态规则变更、支持 Pattern 定义事件之间的超时以及支持基于 IterativeCondition 的累加器功能拓宽 Flink 在实时风控的能力，并且上述功能已经在钱大妈生产环境落地实践。其中 Flink CEP 动态更新 Pattern 机制中内部各组件的交互总览如下：

风控规则由产品界面作为入口，规则写入到 Hologres 中，同时 JDBCPatternProcessorDiscover 周期性轮询发现规则的变更。其中规则表的数据结构如下：

1. Id：规则ID；

2. Version：规则对应的版本号；

3. Keyby：规则分组字段（如需分组）；

4. Pattern：CEP Pattern 序列化后的 Json 字符串；

5. Function：CEP 匹配后处理的 PatternProcessFunction；

6. Relation：统计型和规则型之间的与、或关系（前提：统计型和规则型的 ID 相同）。

五、回顾展望

基于 Flink 的实时风控解决方案已接应用于钱大妈集团内部生产环境，在此解决方案里未引入新的技术组件和编程语言，最大化复用 Flink 资源实现实时风控场景需求，极大降低新组件引入存在的潜在运维风险。另一方面也极大降低研发团队的学习成本，高效释放实时计算的人力资源，并且对于研发和业务应用上面带来如下好处：

• 解耦 Flink 作业逻辑开发和业务规则定义；

• 业务规则存储在 Database 中，便于查看规则当前状态和历史版本；

• 规则变更只需修改 Database 存储的规则，Flink 自动加载更新作业中的规则列表；

• 结合 Flink 生态能够非常容易集成事件异构数据源的读取与写入；

• 结合 Flink 分布式能力，大规模扩展至数千并发度匹配运行规则。

后续钱大妈将和阿里云实时计算产品团队，继续共建完善基于 Flink 的实时风控风控解决方案，其中在 Flink CEP 的未来规划将围绕以下三个主要方向展开：

1. Flink CEP 能力的进一步增强；

2. Flink CEP SQL 的动态能力；

3. Flink + DSL 的 Native 支持。