关于flink:钱大妈基于-Flink-的实时风控实践

摘要：本文作者彭明德，介绍了钱大妈与阿里云 Flink 实时计算团队共建实时风控规定引擎，准确辨认羊毛党以防营销估算散失。次要内容包含：

1. 我的项目背景
2. 业务架构
3. 未规定模型
4. 难点攻坚
5. 回顾瞻望

一、我的项目背景

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

图一：钱大妈实时风控流程示意图

二、业务架构

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

1. 事件接入 。其中包含黑白灰名单库、画像特色数据、行为埋点数据和中台交易数据。
2. 危险感知 。策略调研后公布到规定引擎，并对告警后果进行离线回归和多渠道触达。
3. 危险应答 。对波及到财务结算的规定提供再审核、豁免机制或人工弥补。
4. 危险回溯 。策略命中后进行统计和危险分类分级，预警离线回溯并对风控事件闭件。

图二：钱大妈实时风控业务架构图

三、规定模型

风控业务专员通过产品界面简略配置即可实时动静公布风控规定，同时对在线 Flink 作业的规定进行新增、更新以及删除，其中风控规定模型次要分为统计型规定和序列型规定，雷同模型反对子规定的嵌套，不同模型之间能够通过与、或关系进行组合。

图三：钱大妈 Flink 作业 DAG 形象图

以下为规定组合中须要动静配置能力的配置项：

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：CEP 反对多规定和动静 Pattern 变更；
2. FLIP-228：CEP 反对 Pattern 定义事件之间的超时。

阿里云实时计算产品输入的反对多规定和动静规定变更、反对 Pattern 定义事件之间的超时以及反对基于 IterativeCondition 的累加器商业化性能拓宽 Flink 在实时风控的能力，并且上述商业化性能曾经在钱大妈生产环境落地实际。其中 Flink CEP 动静更新 Pattern 机制中外部各组件的交互总览如下：

<p style=”text-align:center”> 图五：社区 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 动静 CEP 规定表

五、回顾瞻望

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

• 解耦 Flink 作业逻辑开发和业务规定定义；
• 业务规定存储在 Database 中，便于查看规定以后状态和历史版本；
• 规定变更只需批改 Database 存储的规定，Flink 主动加载更新作业中的规定列表；
• 联合 Flink 生态可能非常容易集成事件异构数据源的读取与写入；
• 联合 Flink 分布式能力，大规模扩大至数千并发度匹配运行规定。

后续钱大妈将和阿里云实时计算产品团队，持续共建欠缺基于 Flink 的实时风控风控解决方案，其中在 Flink CEP 的将来布局将围绕以下三个次要方向开展：

1. Flink CEP 能力的进一步加强；
2. Flink CEP SQL 的动静能力；
3. Flink + DSL 的 Native 反对

公司简介 ：钱大妈是在社区生鲜连锁中，以 ” 不卖隔夜肉 ” 作为品牌理念的的行业开拓者。在成立之初即从陈腐角度从新梳理传统生鲜行业的规范，对肉菜市场进行新的定义。钱大妈已全国布局近 30 座城市，门店总数冲破 3000 多家，服务家庭超 1000 万。

本文作者 ：彭明德，目前就任于钱大妈，任全渠道数据中台大数据开发工程师。

同时也心愿更多有实时风控需要，或酷爱风控场景建设的小伙伴可能在 Flink 社区风控钉钉专群进行沟通：

图七：Flink 社区实时风控专群二维码