实时决策系统中 OpenMLDB 的常见架构整合方式
输入“/”快速插入内容
实时决策系统中 OpenMLDB 的常见架构整合方式
实时决策系统中 OpenMLDB 的常见架构整合方式
OpenMLDB 提供了一个线上线下一致性的实时特征计算平台。对于如何在实际业务系统中整合 OpenMLDB，构建完整的机器学习平台，OpenMLDB 提供了灵活的支持。本文关注基于 OpenMLDB，在企业级业务系统中使用的常见架构。我们主要关注存储和计算两个方面：
•
离在线数据存储架构：如何合理的进行离线和在线数据的存储，并维持离在线数据的一致性。
•
实时决策应用架构：如何基于 OpenMLDB 的实时请求计算模式构建线上应用，包含常见的事中决策和实时查询应用架构。
离在线数据的存储架构
由于不同的性能和数据量的需求，在一般情况下，OpenMLDB 的离线和在线数据在物理上是分开存储：
•
在线数据存储：OpenMLDB 提供了一个高效的实时数据库（基于内存或者磁盘），主要目的为存储在线数据用于实时特征计算，而非全量数据。其主要特点为：
◦
针对时序数据的毫秒级访问，默认基于内存
◦
具备数据过期自动淘汰的能力（TTL），TTL 可以根据表格粒度进行设置，用于线数据库仅存放必需的时间窗口内的数据
◦
默认基于内存的存储引擎虽然性能较高，但是可能存在内存消耗量较大的问题，可以在满足性能要求的前提下使用基于磁盘的存储引擎
•
离线数仓：OpenMLDB 本身并不提供独立的离线存储引擎，可以灵活支持不同的离线数仓和架构形式。
以下讨论常见的离线和在线数据的存储架构。
全量数据存储于实时数据库（不推荐）
画板
用户可以选择把全量数据存储于 OpenMLDB 的实时数据库，此种使用方式带来的优势是使用简单，并且物理上仅有一份数据，也节省了管理维护成本。但此种方式在实际使用中较少使用，主要有以下潜在问题：
•
全量数据一般较大，而 OpenMLDB 为了保证线上性能，默认使用了基于内存的存储引擎，基于内存存储全量数据会带来较大的硬件成本负担。
•
OpenMLDB 虽然也提供了基于磁盘的存储引擎，但是磁盘存储会带来 3-7x 左右的性能下降，可能无法满足某些在线业务场景需求。
•
离线和在线数据存储于同一个物理介质，可能会对线上实时计算的性能和稳定性带来较大的负面影响。
因此在实际中，为了充分发挥 OpenMLDB 的实时计算能力，我们并不推荐存储全量数据在 OpenMLDB，而是和离线数仓配合使用。
离在线数据存储分离管理架构
画板
目前在实际使用场景中，大部分用户基于此种离在线存储分离管理的架构。基于此种架构，数据会同时写入到离线数仓和实时数据库。OpenMLDB 的实时数据库会设置表格级别的数据过期（TTL）。此种设置会对应于所需要的特征脚本内的时间窗口的大小，即实时数据库只存储用于实时特征计算的必要的数据，而非全量数据。相关注意点：
•
实际企业架构中，数据源一般基于 Kafka 等消息队列的订阅机制。不同的应用会去分别消费数据。在此种架构下，写入到 OpenMLDB 的实时数据库的通路，以及存储到离线数仓的通路，可以认为是两个独立的消费者。
•
如果并非基于消息队列的订阅机制，也可以认为在 OpenMLDB 上游有一个或者多个数据接收程序，用于实现和管理 OpenMLDB 的在线存储以及离线存储。
•
OpenMLDB 实时数据库的过期时间需要正确的被设置，使得实时数据库内存储的数据可以被用于正确的实时特征计算。
•
此种架构的主要缺点是管理稍复杂，从用户视角看到了离线和在线两份数据需要本单独管理。
离在线数据存储统一视图架构（v0.8.0 以后版本可用）
画板
在此种离在线数据统一视图的架构下，简化了用户视角对于离在线数据的同步和管理。我们预期会在 0.7.4 版本推出一个自动化的从实时数据库到离线数仓的同步机制。在此种架构下，虽然在物理上我们依然有实时数据库和离线数仓两个存储引擎，但是在用户视角上，可以仅关注一个写入通路。用户只需要将新的数据写入 OpenMLDB 实时数据库，设置好实时到离线的同步机制，OpenMLDB 即可以自动化地将数据实时或者定时地同步到一个或者多个离线数仓。OpenMLDB 的实时数据库依然依靠数据过期机制仅保存用于线上特征计算的数据，而离线数仓会保留所有全量数据。该功能从 v0.8.0 版本开始引入。
实时决策应用架构
实时请求计算模式
在了解实时决策应用架构前，需要先了解 OpenMLDB 线上实时计算引擎提供的基于请求的实时计算模式，其主要包含三个步骤：
1.
客户端通过 REST APIs 或者 OpenMLDB SDKs 发送计算请求（request），该请求可选带有当前事件的状态信息数据，比如当前刷卡事件的刷卡金额、商铺 ID 等。
2.
OpenMLDB 实时引擎接受该请求，根据已经部署上线的特征计算逻辑，进行按需（on-demand）的实时特征计算
3.
OpenMLDB 将实时计算结果返回给发起请求的客户端，完成本次实时计算请求
本文将从实际应用场景出发，阐述基于 OpenMLDB 的实时请求计算模式的常见应用搭建架构。我们会介绍两种常见的应用架构。
事中决策应用架构
OpenMLDB 的默认计算模式为支持事中决策的应用，其字面意义即为在事件发生过程中的决策行为。因此其主要特点为，当前事件产生的行为数据也会被纳入决策考量中。其最典型的例子即为信用卡反欺诈：当一笔信用卡交易发生时，反欺诈系统会在交易真正落实之前进行决策，同时把当前的刷卡行为数据（比如当前刷卡的金额、时间、地点等），连同近期一段时间窗口内的数据进行一起考量决策。该架构在反欺诈、风控等领域被广泛采用。
我们来看一个具体的例子。下图显示了当一个刷卡交易发生时，整个系统发生的功能逻辑。可以看到，系统中维护了历史交易记录，当一个新的交易行为发生时，当前的行为数据会被虚拟插入表格中，连同近期的交易记录一起，做特征计算，再给到模型推理，最后判断是否为欺诈交易。
注意，上图中显示了新来的刷卡记录数据被虚拟插入到历史交易表，这是因为在 OpenMLDB 的请求模式中，系统默认就会把请求所带的事中数据虚拟地插入到表格中，参与到整体特征计算中（如果特殊情况下不需要当前请求行信息参与决策，可以使用 EXCLUDE CURRENT_ROW 关键字，详见 “附录：EXCLUDE CURRENT_ROW 语义解释”）。同时，在普遍情况下，当前请求行对于后续的决策也是有用的，因此其在完成当前的特征计算以后，应该被真正的物理插入到数据库。为了构建一个如上业务流程的事中决策系统，我们下面列举一个典型的架构流程图。
该架构基于 OpenMLDB SDK，做到了严格的事中决策，该流程包含两个阶段：
1.
上图中的步骤1、2、3，实际构成了一次 OpenMLDB 的实时请求，并且本次请求附带了本次事件发生时候的必需的数据（卡号、刷卡金额、时间戳）。
2.
完成实时请求以后，客户端通过 OpenMLDB SDK 额外发起了一次数据插入请求，把当前的交易行为数据插入到 OpenMLDB，以供后续的实时请求计算使用。
以上基于 OpenMLDB SDK 的严格事中决策架构，是 OpenMLDB 默认并且所推荐的架构。在实际的企业应用架构中，由于外围耦合架构或者内部权限的复杂性，也会存在一些变种。比如，数据写入的通路被完全分离开来，使用 Kafka 或者其他方式进行单独的数据写入。但是，该架构如果没有做额外的强制性保障，可能会存在读写顺序上的问题，从而导致窗口内数据重复或者缺少计算。因此，一般情况下，我们还是推荐使用上图的严格的事中决策架构。