导读:
本文由Akulaku资深算法开发工程师黄泓4月23日在DataFunSummit上的演讲「Akulaku智能计算系统及应用」整理而成。

在特征计算系统的实现上,Akulaku采用场景驱动方式,通过使用OpenMLDB,更加高效地实现特征“现用现算”。

一、Akulaku的场景和需求

Akulaku是一家主打海外市场的互联网金融服务提供者,服务内容包括网上购物和分期付款,现金贷,保险等等。也就是Akulaku包含金融属性和电商属性,以金融属性为主。

主要的应用场景包括金融风控,电商智能客服以及电商推荐等等。

Akulaku的智能计算架构(如下图所示)整体上分为3层,从下往上依次为特征计算层、模型计算层和智能应用层:

  • 特征计算层:包含底层特征和指标的计算产出

  • 模型计算层:包含模型的训练、部署和针对知识图谱的推理引擎

  • 智能应用层:基于部署的模型、训练的模型和知识推理引擎,我们搭建了一系列的智能应用,包含例如反洗钱模型、风险设备标签等等

file

二、智能计算系统构建的难点

虽然业务场景比较丰富,但难点主要聚焦在特征计算环节,大致包含以下三点:

  • 线上部署:低延时,高时效性

  • 线下分析:高吞吐量

  • 逻辑一致:线下分析和线上部署的逻辑需要完全一致

而在实际场景中,同时满足这三点并不容易。

file

在我们的计算场景中,主要包含三类特征:

  • 时间窗口类:比如近X天的XX个数

  • 群组关联类:比如近X天同一团伙所有成员的订单个数

  • 关联关系类:K度图查询,特定子图模式

部署的模型主要包含三类:

  • 机器学习模型:如XGBoost

  • 序列模型:如TCN

  • 深度NLP模型:BERT

file

三、架构与案例 | 智能计算系统(特征计算方式)的实现

特征计算方式主要分为场景驱动和数据驱动两种。可以通过下图更直观地感受到二者的区别。

  • 场景驱动,即业务调用环节驱动,调用时计算结果

  • 数据驱动,则由底层数据驱动,数据变更时计算、调用和计算解耦

具体案例分析:以“时间窗口”为例

file

以典型案例“时间窗口”为例展开。时间窗口特征,即时间窗口内的统计和加总,比如近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捕捉窗口表的变更,计算出最终结果。

file

2、场景驱动的特征计算方式(基于OpenMLDB的方案)

file

场景驱动的计算方式也并非不可实现。通过使用OpenMLDB,可以更加高效地实现特征“现用现算”。

基于OpenMLDB完成场景驱动的调用,主要思路是:

  • 用空间换时间,使用OpenMLDB把所有数据存储在内存或持久化内存中。在成本不够的情况下,可以考虑存储在持久化内存中。同时,避免类似RocksDB的写放大和读放大,也就是说,存储里没有level这一概念。

  • 使用SQL作为离线和在线的桥梁。离线部分是Spark,基于SQL语义来做数据回溯,从而做离线分析。

而在线部分针对的是时间滑窗维度的问题,是基于时序数据库做数据滑窗。

3、场景驱动(OpenMLDB)和数据驱动(Flink CDC)性能对比

OpenMLDB及Flink CDC的测试环境及结果

  • 数据量:10亿/天

  • 取业务中一个典型场景,行为评分计算,每天的数据量能达到10亿条

  • 除行为评分之外,大概还有三四个数据源

  • OpenMLDB 硬件资源占用:3 x 256G 三节点集群

  • 测试样本:一天内的窗口特征,OpenMLDB和直接读polarDB的延时基本相同(4毫秒左右)

  • 测试结果:两者性能基本相当

file

file

4、两种计算方式在架构中的位置

file

Akulaku的特征计算层未来会向Ray进行一个转变,目前还是以Java为主。数据驱动(FLink+RocksDB+PolarDB)在高性能存储、流式计算引擎、高性能存储的部分实现。场景驱动的部分以OpenMLDB为主,在架构中跨模型计算层和特征计算层。在线部分基于OpenMLDB的在线特征数据库。离线部分则基于OpenMLDB的离线特征数据库和离线计算引擎(OpenMLDB Spark Distribution)。