关于数据库:实时决策系统中-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.7.4 反对）

在此种离在线数据对立视图的架构下，简化了用户视角对于离在线数据的同步和治理。咱们预期会在 0.7.4 版本推出一个自动化的从实时数据库到离线数仓的同步机制。在此种架构下，尽管在物理上咱们仍然有实时数据库和离线数仓两个存储引擎，然而在用户视角上，能够仅关注一个写入通路。用户只须要将新的数据写入 OpenMLDB 实时数据库，设置好实时到离线的同步机制，OpenMLDB 即能够自动化地将数据实时或者定时地同步到一个或者多个离线数仓。OpenMLDB 的实时数据库仍然依附数据过期机制仅保留用于线上特色计算的数据，而离线数仓会保留所有全量数据。该性能预期在 2023 年 4 月上旬的 0.7.4 版本会退出。

实时决策利用架构

实时申请计算模式

在理解实时决策利用架构前，须要先理解 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 或者其余形式进行独自的数据写入。然而，该架构如果没有做额定的强制性保障，可能会存在读写程序上的问题，从而导致窗口内数据反复或者短少计算。因而，个别状况下，咱们还是举荐应用上图的严格的事中决策架构。

实时查问利用架构

在一些举荐类利用场景中，往往须要在某一个工夫点做一次实时计算的查问，该查问自身不带有具备意义的数据。比方当用户进行商品浏览时，须要在用户关上浏览器时，实时查问过来十分钟内平台上合乎该用户趣味的最热门的商品数据，进行商品排序举荐。在此类场景下，用户的申请和相干物料数据的写入能够齐全解耦开，同时用户的申请并不带有具备意义的数据，仅仅是为了触发一次实时计算申请，能够应用 SQL 关键字 EXCLUDE CURRENT_ROW 达到该目标。

能够看到，在下面的架构中，实时申请（只读）和数据的写入通路被解耦开。

• 对于数据写入通路，用户能够通过流式（比方 Kafka connector）或者 OpenMLDB SDK 的形式，将相干物料数据一直的写入到 OpenMLDB 的数据库内

• 对于实时申请局部，次要有两个特点：

  • 申请实现当前不再须要额定的步骤写入实时数据（相干数据由数据写入通路实现，申请自身不带有具备意义的数据）
  • 因为 OpenMLDB 默认的申请计算行为会进行虚构的数据插入，然而在这种架构下，实时申请所带的数据不再具备意义。因而，咱们须要应用扩大的 SQL 关键字 EXCLUDE CURRENT_ROW，来达到该目标。

其余扩大架构

除了下面介绍的两种架构，OpenMLDB 也能够扩大为反对离线特色线上查问架构，以及反对流式特色等架构。咱们将在后续的文章中逐渐介绍其余理论中利用到的企业级架构。

附录：EXCLUDE CURRENT_ROW 语义解释

OpenMLDB 的申请模式默认会把以后数据行虚构插入到表格，一起参加窗口计算。如果不须要以后行的数据参加计算，能够应用 EXCLUDE CURRENT_ROW。该语法把以后申请行的数据排除在窗口计算以外，然而申请行提供的 PARTITION BY KEY 和 ORDER BY KEY 仍然须要被应用，用于定位申请的具体数据和工夫窗口。

以下应用一个具体例子来阐明其语义。假如其用于存储交易记录的数据表格 txn 的 schema 如下。

咱们应用如下加上了 EXCLUDE CURRENT_ROW 的 SQL：

SELECT card_id, sum(amount) OVER (w1) AS w1_amount_sum FROM txn 
    WINDOW w1 AS (PARTITION BY card_id ORDER BY txn_time 
    ROWS BETWEEN 2 PRECEDING AND CURRENT ROW EXCLUDE CURRENT_ROW);

该语句定义了一个以 card_id 为 key，依据 txn_time 进行排序，并且基于以后申请行往前包含两行的一个窗口；同时，因为定义了 EXCLUDE CURRENT_ROW，以后申请行理论不进入窗口进行计算。

简化期间，咱们假如该表格仅存在以下两条数据：

 --------- ----------- --------------- 
  card_id   amount      txn_time       
 --------- ----------- --------------- 
  aaa       22.000000   1636097890000  
  aaa       20.000000   1636097290000  
 --------- ----------- --------------- 

咱们发送实时计算申请，其中蕴含的申请数据为：

如果不应用 EXCLUDE CURRENT_ROW，则以后申请行，以及数据库里曾经蕴含的两行均会进入窗口中，参加实时计算，其返回后果为 “aaa, 65.0″。然而，因为其部署的 SQL 中带有 EXCLUDE CURRENT_ROW，则以后行不进入窗口计算，所以其返回值理论为 “aaa, 42.0″。留神，尽管以后行的值 amount 并不进入窗口进行计算，然而其 card_id（用于标记分类的 key），以及 txn_time（用于标记工夫戳信息），仍然须要被正确设置，用于寻找正确的窗口数据。