关于数据库:场景驱动的特征计算方式OpenMLDB高效实现现算先用

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