导读:
本文由 Akulaku 资深算法开发工程师黄泓 4 月 23 日在 DataFunSummit 上的演讲「Akulaku 智能计算零碎及利用」整顿而成。
在特色计算零碎的实现上,Akulaku 采纳场景驱动形式,通过应用 OpenMLDB,更加高效地实现特色“现用现算”。
一、Akulaku 的场景和需要
Akulaku 是一家主打海内市场的互联网金融服务提供者,服务内容包含网上购物和分期付款,现金贷,保险等等。也就是 Akulaku 蕴含金融属性和电商属性,以金融属性为主。
次要的利用场景包含金融风控,电商智能客服以及电商举荐等等。
Akulaku 的智能计算架构(如下图所示)整体上分为 3 层,从下往上顺次为特色计算层、模型计算层和智能应用层:
- 特色计算层:蕴含底层特色和指标的计算产出
- 模型计算层:蕴含模型的训练、部署和针对常识图谱的推理引擎
- 智能应用层:基于部署的模型、训练的模型和常识推理引擎,咱们搭建了一系列的智能利用,蕴含例如反洗钱模型、危险设施标签等等
二、智能计算零碎构建的难点
尽管业务场景比拟丰盛,但难点次要聚焦在特色计算环节,大抵蕴含以下三点:
- 线上部署:低延时,高时效性
- 线下剖析:高吞吐量
- 逻辑统一:线下剖析和线上部署的逻辑须要完全一致
而在理论场景中,同时满足这三点并不容易。
在咱们的计算场景中,次要蕴含三类特色:
- 工夫窗口类:比方近 X 天的 XX 个数
- 群组关联类:比方近 X 天同一团伙所有成员的订单个数
- 关联关系类:K 度图查问,特定子图模式
部署的模型次要蕴含三类:
- 机器学习模型:如 XGBoost
- 序列模型:如 TCN
- 深度 NLP 模型:BERT
三、架构与案例 | 智能计算零碎(特色计算形式)的实现
特色计算形式次要分为场景驱动和数据驱动两种。能够通过下图更直观地感触到二者的区别。
- 场景驱动,即业务调用环节驱动,调用时计算结果
- 数据驱动,则由底层数据驱动,数据变更时计算、调用和计算解耦
具体案例剖析:以“工夫窗口”为例
以典型案例“工夫窗口”为例开展。工夫窗口特色,即工夫窗口内的统计和加总,比方近 N 天的订单个数,要求实时更新,工夫窗口实时滑动,下单环节延时不能超过 200ms。且在具体业务中,还会有简单的关联需要,比方“团伙近 3 天订单个数”。
思考场景驱动,比较简单间接的想法是间接在关系数据库中写 SQL,但这一计划无法控制延时,在极其状况下延时有可能超过 200ms。所以团队思考了数据驱动的形式,尝试应用 Flink 计算引擎实现滑动窗口的逻辑。
1、数据驱动的特色计算形式(基于 Flink CDC 及 Flink SQL 的计划)
目前,Akulaku 数据驱动的特色计算形式是基于 Flink 的。Flink 又有两种做法,一种是 Flink CDC,一种是 Flink SQL。
Flink CDC
- 思路:
- 基于关系型的数据库做两头的存储。
- 数据的变更是依据中间状态的变更触发最终数据的更新。
- 长处:
- 因为 Flink CDC 依赖于内部存储,所以能够做状态初始化。比方须要计算近 15 天的特色时,就不须要将 15 天前到当初的特色进行从新计算,而是把前 14 天的数据先初始化到状态存储里再计算到当初。
- Flink CDC 内部存储的运维是比较稳定不便的。
- 毛病:
- Flink CDC 毛病是比拟依赖内部数据库的性能,而且实现起来比拟轻便。
- 线上线下的逻辑差别比拟大。
Flink SQL
- 思路:
- 计划在思考时,咱们应用 Flink SQL 动静表的形象。
- 应用优先队列和 MapState 治理数据的过期和数据的出窗。
- 长处:
- 能够利用 Flink 的个性,包含状态治理。
- SQL 相对来说会好了解一些,语义回溯比拟靠近,便于做流批一体。
- 毛病:
- 踩着 Flink 的一些个性的边界来做,比方咱们刚刚说过的 watermark,它既不是事件工夫,也不是解决工夫,是咱们本人保护的一个状态。也就是说咱们在事件的设计上还是跳脱了 Flink 的设计,然而其余很多个性都在复用,比如说状态治理和聚合时的批次提交。
思考数据驱动的计算形式,能够基于 Flink CDC 进行数据计算,次要思路是:
- 应用两头存储保留窗口表,对于新进入的数据,只保护近 X 天的数据;
- Flink cdc 捕获窗口表的变更,计算出最终后果。
2、场景驱动的特色计算形式(基于 OpenMLDB 的计划)
场景驱动的计算形式也并非不可实现。通过应用 OpenMLDB,能够更加高效地实现特色“现用现算”。
基于 OpenMLDB 实现场景驱动的调用,次要思路是:
- 用空间换工夫,应用 OpenMLDB 把所有数据存储在内存或长久化内存中。在老本不够的状况下,能够思考存储在长久化内存中。同时,防止相似 RocksDB 的写放大和读放大,也就是说,存储里没有 level 这一概念。
- 应用 SQL 作为离线和在线的桥梁。离线局部是 Spark,基于 SQL 语义来做数据回溯,从而做离线剖析。
而在线局部针对的是工夫滑窗维度的问题,是基于时序数据库做数据滑窗。
3、场景驱动(OpenMLDB)和数据驱动(Flink CDC)性能比照
OpenMLDB 及 Flink CDC 的测试环境及后果
- 数据量:10 亿 / 天
- 取业务中一个典型场景,行为评分计算,每天的数据量能达到 10 亿条
- 除行为评分之外,大略还有三四个数据源
- OpenMLDB 硬件资源占用:3 x 256G 三节点集群
- 测试样本:一天内的窗口特色,OpenMLDB 和间接读 polarDB 的延时基本相同(4 毫秒左右)
- 测试后果:两者性能根本相当
| | 场景驱动(OpenMLDB)| 数据驱动(Flink CDC)|
| 思路 | 现用现算,在调用时计算 | 数据变更时计算,调用和计算仅甥 |
| 长处 | 1. 实现简略 2. 线上线下容易保持一致,回溯容易 | 1. 业务调用工夫与计算工夫无关,业务可用性高 2. 计算结果与场景无关,一次计算,多场景调用 |
| 局限性 | 1. 硬件依赖性比拟高 2. 保护业务稳定性比拟有挑战 | 1. 复杂性较高 2. 线上线下逻辑不容易保持一致 3. 会有大量无头的数据 |
4、两种计算形式在架构中的地位
Akulaku 的特色计算层将来会向 Ray 进行一个转变,目前还是以 Java 为主。数据驱动(FLink+RocksDB+PolarDB)在高性能存储、流式计算引擎、高性能存储的局部实现。场景驱动的局部以 OpenMLDB 为主,在架构中跨模型计算层和特色计算层。在线局部基于 OpenMLDB 的在线特色数据库。离线局部则基于 OpenMLDB 的离线特色数据库和离线计算引擎(OpenMLDB Spark Distribution)。