Scene-driven feature calculation method OpenMLDB, efficient implementation of "calculate first use"

导读：
本文由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

• 思路：

1. 基于关系型的数据库做中间的存储.

2. 数据的变更是根据中间状态的变更触发最终数据的更新.

• 优点：

1. 因为 Flink CDC 依赖于外部存储,所以可以做状态初始化.比如需要计算近15天的特征时,就不需要将15天前到现在的特征进行重新计算,而是把前14天的数据先初始化到状态存储里再计算到现在.

2. Flink CDC 外部存储的运维是比较稳定方便的.

• 缺点：

1. Flink CDC 缺点是比较依赖外部数据库的性能,而且实现起来比较笨重.

2. 线上线下的逻辑差异比较大.

Flink SQL

• 思路：

1. 方案在思考时,我们使用 Flink SQL 动态表的抽象.

2. 使用优先队列和 MapState 管理数据的过期和数据的出窗.

• 优点：

1. 可以利用 Flink 的特性,包括状态管理.

2. SQL 相对来说会好理解一些,语义回溯比较接近,便于做流批一体.

• 缺点：

1. 踩着 Flink 的一些特性的边界来做,比如我们刚刚说过的 watermark,它既不是事件时间,也不是处理时间,是我们自己维护的一个状态.也就是说我们在事件的设计上还是跳脱了 Flink 的设计,但是其他很多特性都在复用,比如说状态管理和聚合时的批次提交.

考虑数据驱动的计算方式,可以基于Flink CDC进行数据计算,主要思路是：

1. 使用中间存储保存窗口表,对于新进入的数据,只维护近X天的数据;

2. 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）.