共计 5152 个字符，预计需要花费 13 分钟才能阅读完成。
摘要：本文整顿自 Airwallex Risk ML Platform Team 董大凡，在 Flink Forward Asia 2022 实时风控专场的分享。本篇内容次要分为五个局部：
- 背景介绍
- 应答计划
- 技术挑战与亮点
- 可用性保障
- 线上体现
点击查看直播回放和演讲 PPT
一、背景介绍
Airwallex 是一个以“创立一个让企业跨境经营的环境，以此助推寰球的数字经济倒退。”为指标的金融科技公司。服务有 GTPN、PA、Scale。目前 Airwallex 总用户数超过 6 万，遍布 20+ 个国家 / 地区，且用户数放弃稳步增长，过来一年新增用户超过 100%；日均匀交易数超过 12 万笔；峰值交易流量超过 100 笔 / 秒；单个交易申请的总时延不能超过 800 毫秒（P99）。
以上就是 Airwallex 大体的服务。那么对于咱们来说，危险在哪里呢？
平台必须升高的一些危险：
- 对于 GTPN 这种转账服务，会有一些人想利用咱们这种国内转账的能力去做洗钱。
- 对于 PA 有一些收款服务，就会波及到欺诈和纠纷事件。比方咱们的客户是一个电商客户，如果他卖假货，而后利用咱们对收货时延的宽容，把钱从客户那里通过咱们的渠道转移到本人的账户上。当客户发现收到的货有问题提出申述的时候，责任就会由咱们来承当。
- 对于 Scale 会波及到很多个子用户，他们之间会有很多外部的转账操作，也会有一些欺诈行为。
针对以上危险，咱们公司成立了 RISK 团队。公司对这个团队的要求是，心愿可能高效辨认并拦挡歹意转账；并且决策过程可查问，决策后果可解释；同时确保用户体验不受影响。
作为 ML Platform 团队，咱们提供了一个稳固高效的 Feature 计算平台，并对机器学习工程师提供了敌对的编程接口，还提供了一站式模型训练和部署解决方案。
咱们的团队成员：Xin Hao、Yusup Ashrap、Michael Liu、Tim Zhu。
二、应答计划
2.1 Airwallex 业务与产品介绍
对于应答危险，业内曾经有了很多探讨，能够总结为以下几点。
- 传统规定引擎，可扩展性无限，无奈解决如此复杂多变的场景。如果想解决这种场景，会让规定或者执行逻辑变得十分难以保护。
- 引入机器学习技术对危险进行探测曾经成为行业倒退的支流方向。
- 在风控畛域，模型须要大量频繁回看不同工夫周期内特定账户行为特色，应用传统离线数据处理形式，无奈及时产生所需数据（Feature）。
- 所以综上所述，咱们决定拥抱 Flink 原生流计算能力，构建流式风控平台。
从上图左侧局部能够看到，Scale/GTPN/PA 是咱们正在执行转账的服务。每一笔服务都会给咱们的 Risk Decision Service 发一个告诉，并通知它是 Approve 还是 Reject。所以当初咱们把 Risk Decision Service 当成一个黑盒看，就是这样一个架构。
因为 Risk Decision Service 须要一些机器学习的技术或者其余技术去做计算，所以它须要绝对丰盛的数据。咱们当初有两个数据源，一个是流的 Kafka 数据源，它有个 Account Transaction Log。即每产生一笔交易，都会有一条数据实时汇总到服务里去。另一个是批的数据源，它是一个绝对比较稳定不会变动的数据。因为咱们是借助 Google 的云存储，所以它会放在 Google Cloud 上。
而后将这两个数据 Feed 给 Risk Decision Service 供它进行计算。
接下来须要把数据计算出来。Flink Feature Calculation Engine 会同时接入流数据和批数据进行 Join，提供一个更丰盛的流数据，供咱们计算 Feature。同时，咱们还有一个基于 Redis 的 Feature Cache System，它能够在 Inference 的时候，实时从外面读取数据，而后把生成的数据实时的写入到 Redis 里。
而后就引入了 Risk Model Inference Engine，它会调用一些机器学习模型或规定模型，读取一些 Feature。而后对每一笔进入的 Transaction 进行危险评估，并返回一个后果，来通知咱们的客户容许还是回绝这笔 Transaction。
下面提到须要对后果做到可查，可解释，那么就须要把所有的后果和后果在计算中用到的 Feature 都存储下来。所以如上图右侧所示，咱们引入了 Data Persist 并在外边接上了 Google Cloud Storage，实时把 Model Inference Result 和生成的 Feature 汇总，而后在 Google Cloud 上落盘存储。
上图是咱们的整体架构，上层借助了 Google Cloud 存储和 Kafka 的能力，给下层提供一些数据。下层是 Feature Generating Job，蕴含 Feature Serving、Feature Persist、Flink Feature Generation Job。再往下层是 Model Inference，它跟外层进行通信，调用 Model 做一些判断，同时它也会调用右侧的 Persistlayer 存储这些数据。
最上层次要负责 Management 和 Control，它有 Flink Operator 用来调度上层 Flink Job 运行；Model Management 治理每一个上线 Model 以后版本和版本所须要的 Feature 列表；DSL Management Management 用来实现 Flink Feature Generation Job 的对立接口。
三、技术挑战与亮点
3.1 挑战与应答
咱们面对的挑战次要有左侧的 3 点。
第一个是 Feature 计算须要频繁重算历史数据。每一个 Incoming 的 Event 都可能会触发滑动窗口的滑动，而后就会触发一个 Feature 从新计算，这个计算量还是比拟大的。
另外，认真想想其实还有一个场景，比方当初必须的 Feature 里有过来一个月的总交易量，如果想从新上线一版 Feature 计算逻辑，就须要把这一个月的数据都回溯一遍能力计算出来。所以频繁重算并不只是蕴含 Feature 失常运行时，一个追随滑动窗口的更新，也蕴含 Feature 计算逻辑更新时，对历史数据的重算。
为了解决上述问题，咱们间接把流自身做成一个 Process 的介质，而后把流的窗口扩充，把它当成一个批的计算，就能够做历史数据的回溯了。
第二个是 Flink 编程逻辑过于简单。因为 Feature 生成逻辑是由写 Decision Model 的科学家决定的，他们比拟善于做一些 ML 相干的模型开发，如果让他们学习 Flink Native 开发会比较复杂。另外咱们也不必 Flink SQL，因为咱们认为 Flink SQL 语言的表现力无限，一些绝对简单的跨行操作，用 SQL 开发起来会比拟艰难，不是十分直观。
为了解决这个问题，咱们形象了一个 DSL for ML Engineer。让工程师不须要接触 Flink 那些简单的概念，就能够写出本人须要的 Job。
第三个是模型对 Feature 依赖关系复杂多变。在风控畛域，会遇到不同的危险。每个人都会有本人 Feature 要求，而这些不同的 Feature 会有绝对比较复杂的生成逻辑，这些生成逻辑都还会对应一个独自的 Flink Job。咱们该如何治理这些 Flink Job 呢？
咱们有一个一体化的模型和 Feature 治理。因为咱们线上做 Inference 的时候，是基于某个模型的特定版本，而每个模型会有本人的 Feature 依赖关系，每个 Feature 会有本人对应的 Feature Generating Job。如果反过来，咱们只有抓住模型的外围点，反推它的 Dependency，就能够保障在线上跑的只有咱们必须的 Feature Generating Job。所以只有买通模型和 Feature 的 Metadata，就能够比拟高效的去做 Job 的 Schedule。
3.2 挑战的应答细节
接下来为大家介绍方才三个挑战的应答细节。
第一个是 Kappa Architecture。上图左侧是一个时间轴，大略形容了咱们程序的执行逻辑，时间轴下面是一个大的滑动窗口。
在新的 Feature Generating Job 上线时，须要回看两周的数据，就会应用长时间窗口，加上 event time, 用于 Job 初始化。如果以后解决的工夫和 Current Time 曾经小于咱们的判断规范，就会主动切换为短时间窗口，加上 processing time 升高 latency。
基于以上两种机制，能够让咱们的程序主动在这两个模型之间切换。咱们会通过一些标记文件或者共享存储的形式把以后程序的状态裸露进去，而后由 Flink Operator 调度实现在这两种模式之间的自在切换。
第二个是 DSL for ML Engineer。上图左侧是 DSL 提供的所有 API，有 FlatMap、Map、Keyby、Sum、Value。
而后看公开的两行，两个模式都能够用下面齐全同样的接口去做开发，所以 DSL 屏蔽 Feature 生成过程中流批数据的差别，也简化接口，暗藏上层细节逻辑。因为 Feature Generation 基本不须要绝对比较复杂的概念，比方像 Watermark、Point-in-time Joins 都不须要裸露给科学家，他们的行为能够齐全由 DSL 来表白。这样科学家就能通过一些简略的培训，独立开发 Feature Generation Job 了。
第三个是一体化的模型和 Feature 治理。如果想高效调度 Feature Generating Job，就必须要买通 Model 和 Filter 的 Metadata。那么 Model Management Service 作为整个零碎的治理数据中心保护如下信息，它保护着如下几点。
- Model 对 Feature 的依赖关系。
- Model 的生命周期。
- Feature 的生成逻辑。
在零碎运行时，通过 Model Management Service 遍历以后应用的全副 Model，并汇总全副依赖 Feature，而后调度每一个 Feature 的生成 Job。
四、可用性保障
上图左侧是咱们简化的零碎架构。像 Inference Engine 或者 Model Management 这些服务，尽管提供的内容比拟新鲜，但实质上就是线上服务。对线上服务做高考用，无非就是冗余、备份、分层切换流量的操作，那么咱们如何做到 Feature Generation Job 的高考用性呢？
咱们想做的就是冗余。为了反对冗余，咱们必须实现幂等的 Feature 生成，从而实现 Feature Generation Job 的冗余能力。在这样一个需要下，咱们引入了以下 Convention。
- 应用 Feature Name 作为 Feature 的惟一标识。
- Feature Version 单增，并在写入的时候主动 Merge。
- Model Inference 依据注册的 Feature 名字始终生产最新版本 Data。
这里咱们提供了一种额定要求，就是写 Feature 的人必须保障 Feature 向后兼容，如果不能向后兼容，就换一个名字。在这种状况下，就能够实现冗余的存在。
举个例子，当初线上呈现了一个 Feature Generation 的 bug，一些 Feature 无奈失常生成。咱们首先会修复 bug，而后 push 一个新的 DSL，而后把 Version 值加 1，重新部署新的 Feature Generation。
新的 Job 会处于 Catchup Mode，读取历史数据，并从新计算 Feature。它计算出来的每一个 Feature 都会实时写入到，曾经筹备好的 Feature Catch 里。
因为旧的零碎并不是齐全不可用，所以咱们还会保障旧的版本的生成 Job 同时在这儿，提供最大的能力。直到新的 Feature Generation Mode 曾经追上最新的数据，咱们就能够把旧的版本下线，由新的版本去 serve。通过这种形式，咱们能够确保实现咱们的高可用性。
同时，Flink Operator 同步监控零碎负载，动静调整系统资源。
举了一个例子，在某一个集群里对应一些 Job 的数量，能够看到一些 Job 都能够在这被正确的 Schedule。咱们做了这样一个 UI，让运维工程师能够更不便的去察看零碎的运行状况。
五、线上体现
线上体现：PA Fraud Detection Metric
上图是咱们的 PA Fraud Detection Metric，能够看到咱们 P99 的 latency 大部分都在 800 毫秒以下，右侧有一个 spike，是由一个 deployment 造成的。
点击查看直播回放和演讲 PPT
更多内容
流动举荐
阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/product/bigdata/sc
