开源机器学习数据库 OpenMLDB：线上线下一致的生产级特征平台
导读： 在很多机器学习的应用场景中，为获取高业务价值的模型，对于实时特征有很强的需求，常见于实时的个性化推荐、风控、反欺诈等应用场景。针对这个场景需求，今天分享的是开源机器学习数据库 OpenMLDB------提供线上线下一致的生产级特征平台。
下面的介绍分为四个部分：
-
人工智能工程化落地的数据和特征挑战
-
OpenMLDB：线上线下一致的生产级特征平台
-
研发和社区动态
-
提问环节
分享嘉宾｜卢冕博士 第四范式 资深系统架构师
编辑整理｜陈西 前程无忧
出品社区｜DataFun
01/人工智能工程化落地的数据和特征挑战
1. 正确、高效的 AI 数据和特征供给成为数据侧的新挑战
在人工智能工程化落地当中，有大量的时间耗费在数据上。虽然今天在市面上已经有很多开源和商业的数据和特征方案，但是在真正的工程化落地当中，还是没有达到要求。
2. 实时机器学习决策，需要毫秒级的数据和特征计算能力
时常有用户关心：现有开源工具能否做到真正的实时线上的特征处理？
OpenMLDB 就是为了解决这个问题，要做实时机器决策，具备毫秒级的数据和特征的处理能力。流式处理一般可能会在几百毫秒或几秒的量级，不能满足毫秒级硬实时的需求。
（1）实时的定义
① 实时的数据。比如，银行判断刷卡的动作是不是欺诈业务，需要根据非常实时的用户行为数据去判断。
② 实时的计算。计算反应的延迟需要非常低，精确到毫秒级。
（2）用户案例
银行信用卡刷卡的反欺诈场景，要求获取刷卡动作后 20 毫秒内完成所有特征计算，否则可能因潜在风险带来巨大损失。
3. 机器学习应用从离线开发到上线全流程
机器学习应用，从离线到开发，会经历线上和线下两套流程。线下流程包括特征开发、模型训练等，线上流程包括实时的特征计算、模型的推理等。
4. 实时事中反欺诈交易的特征计算
这里举一个银行事中反欺诈场景的例子。刷卡的交易动作产生后， 需要在非常短的时间内判断出是否为欺诈交易，按照设置的时间窗口（比如过去的 10 秒、过去的 3 小时两个窗口），把相关的信息抽取出来做聚合操作。比如取出的原始信息是刷卡金额，那还要取已设置时间窗口的刷卡次数、刷卡最大金额、最小金额、平均金额，这些就是通过特征处理新生成的特征。
为了达到以上目的，在工程上的需求为：
① 线上线下一致性；
② 低延迟、高并发、高可用。
5. 特征计算开发到上线全生命周期
上图列出了在没有 OpenMLDB 的情况下，机器学习 AI 应用落地的流程。
首先数据科学家进场，使用 Python 或者 Spark SQL 编写脚本进行离线特征计算和线下模型训练。工程化团队将科学家写的特征计算脚本，翻译成实时特征计算的线上应用，适应实际业务场景，然后才能上线。期间还需要进行线上线下计算逻辑一致性的校验。数据科学家离线开发脚本的计算逻辑需与工程化团队翻译出来的程序计算逻辑保持一致。这部分工作往往会耗费大量的人力和时间成本。
6. 线上线下不一致性可能的原因
（1）工具能力本身不一致。
（2）需求沟通的认知差。
工程化团队和科学家团队可能对数据和计算逻辑的定义理解不一致。美国一家线上银行的数据科学家团队和工程化团队对账户余额（account balance）使用了两种不同的定义，导致了最后上线的模型效果衰退。
7. 线上线下一致性校验带来的高昂工程化落地成本
在机器学习应用工程化上线的过程当中，线上线下的一致性校验是必不可少且非常重要的步骤。但是线上线下的一致性校验的成本是非常高的。
为了解决以上问题有不同的解决方案，接下来我将介绍 OpenMLDB 开源方案。
--
02/OpenMLDB：线上线下一致的生产级特征平台
1. OpenMLDB 发展历程
OpenMLDB 起源于业界领先的人工智能平台和服务提供商第四范式的内部商业产品。第四范式所提供的商业化人工智能平台，覆盖机器学习端到端应用开发和落地的全流程，包括数据治理、特征工程、模型训练和推理、模型管理等各个方面。其产品在上百个企业级场景中得到部署和大规模应用。
2021 年，OpenMLDB 的核心开发团队将第四范式闭源商业产品中的数据治理和特征工程的核心模块进行了抽象、增强、以及添加了诸多社区友好化特性，进行了二次开发，发布形成了今天的开源项目 OpenMLDB。OpenMLDB 脱胎于经过长达五年实践检验的商业化产品，并且在该领域具有大量的经验沉淀和独特理解。
今天，OpenMLDB 立足于开源开放的社区进行发展，期望帮助更多的企业低成本高质量完成人工智能转型。
2. OpenMLDB 架构
上图展示了 OpenMLDB 的整体架构。在其内部有两个引擎去处理不同的流程。
**批处理 SQL 引擎，**负责处理线下开发流程，应对跑批的场景，是在 Spark 框架基础上，做了很多源代码级别改进后实现的。
另一个引擎是**实时 SQL 引擎，**是完全自研的、分布式的、高可用、可扩缩容的时序数据库，针对特征抽取场景做了很多优化，通过这个引擎去实现特征计算毫秒级的实时处理。
为了保证以上两个引擎之间的一致性，OpenMLDB 还设计一个非常重要的组件，就是中间的执行计划生成器。
整个 OpenMLDB 对外暴露的编程语言只有 SQL，数据科学家用 SQL 语言去定义 feature，通过一致性执行计划生成器在程序内部保证线上和线下的一致性，做到基于 SQL 语言的开发即上线。首先数据科学家用 SQL 做离线特征开发，当验证满足业务需求后，可以通过命令一键部署到线上服务，这时只要接入实时数据就可以提供生产级别的实时特征在线服务了。
3. 从离线开发到线上服务完整流程
整体流程分为线上线下两套模式。
首先数据科学家去做离线的数据导入，这个导入可以是虚拟化的导入（因为读取的是 HDFS 上的数据，只要给 HDFS 的路径就可以）。接下来用 Spark++ 去做离线特征的抽取，这里可能会有 model training 的互动。然后，数据科学家可以通过命令部署 SQL。
接下来切换到在线模式做数据的导入。前文提到我们做特征抽取需要做时间窗口，比如要计算过去一个月内的一些特征，所以在做线上特征抽取时就需要用到最近一个月的实时数据。一方面要进行冷启动的数据导入，另一方面也要将实时的数据接入。
4. 解决一个核心问题，提供一个核心特性
OpenMLDB 解决的一个最核心问题就是线上线下特征计算的一致性。
其核心特性就是提供毫秒级的实时特征计算。
5. OpenMLDB 应用场景和使用方式
我们的初衷是希望用户从离线开发到实时上线都使用 OpenMLDB，通过一键部署完成，保证线上线下一致性。但我们也发现不同用户对 OpenMLDB 有着不同的用法。因为 OpenMLDB 离线引擎和在线引擎是解耦开的，可以只用在线引擎。针对已有特征脚本，需求线上实时特征计算的场景，也可以只用离线引擎，去做离线的数据探索。
6. 产品特性
（1）线上线下一致性执行引擎，使线上线下的数据一致性得以保证。
（2）高性能实时 SQL 引擎，高性能、高可用、可扩展分布式时序数据库。
为了追求高性能，OpenMLDB 默认存储引擎为内存存储引擎，数据和索引都是存在内存当中。同时会通过 binlog、snapshot 等形式来保证它的高可用。但内存的成本较高，所以我们也提供了磁盘存储引擎，成本会显著降低但性能也会有所衰退。用户可以按实际需求选择。
为了达到高性能的实时计算，我们的数据结构都是针对时序数据设计优化过的。
双层链表数据结构，可以快速获取时间窗口内的数据。
另外一个核心优化是预聚合技术，针对窗口非常大或者窗口内的数据非常多的场景，按照一定维度进行预聚合，再加上实时更新的特征，去做真正的实时的特征计算。
基于以上两个技术，可以看到，针对特征抽取的 workload，OpenMLDB 有着非常大优势。预聚合技术也使得性能得到了显著提升。
（3）面向特征计算的优化的离线计算引擎
① 多窗口并行计算优化。
② 数据倾斜计算优化。
③ SQL 语法扩展。
④ 针对时序数据的 Spark 优化。
（4）针对特征工程的 SQL 扩展
① last join，匹配到有多个记录的时候，只会取最新的这一条，主要是为了某个物料的最新的状态。
② window union，可以做两个表的拼表操作，也可以去做跨表的聚合操作。它本质上是针对主表，根据主表的时间窗口在右表上去划一个时间窗口，然后对右表的时间窗口去做拼接或聚合。
（5）企业级特性支持
① 高可用。
② 可无缝扩缩容。
③ 可平滑升级。
④ 企业级监控。
⑤ 双机房，保障安全可靠。
（6）以 SQL 为核心的开发和管理体验
命令都是基于 SQL，提供 CLI 的交互式的开发方式，也提供了各种常用 SDK 和接口。
7. OpenMLDB 开源生态
**① 面向线上数据生态，**如：Pulsar、Kafka、RocketMQ、Flink、RabbitMQ 等。
**② 面向离线数据生态，**如：HDFS、Hive、MaxCompute、HBase、Cassandra、S3 等。
**③ 面向模型构建的算法、框架，**如：XGBoost、LightGBM、TensorFlow、PyTorch、OneFlow、ScikitLearn 等。
**④ 面向机器学习建模全流程的调度框架、部署工具，**如：DolphinScheduler、Airflow、Byzer、Kubeflow、Prometheus、Grafana 等。
8. 案例 -- Akulaku 智能计算架构中的特征平台
**背景：**Akulaku 是一家东南亚的金融科技公司，需要在反洗钱、团伙欺诈检测场景应用特征计算。他们的应用场景需要低延迟、高时效、尽可能反映新数据的实时特征计算，也有线下分析需求，需要使用离线计算引擎。同时，要保证线上线下的一致性。根据这个需求，Akulaku 构建了一套智能计算架构，并将 OpenMLDB 的在线引擎嵌入在模型计算层，离线引擎嵌入在特征计算层。
**应用效果：**Akulaku 10 亿条订单进行窗口特征计算，达到 4 毫秒延迟性能，满足业务需求。
--
03/研发和社区动态
1. OpenMLDB 发展历程
① 开源前有 5 年的商业应用经验和代码的积累。
② 开源后，收到很多用户反馈，比如 akulaku、37 手游、华为、京东科技等。
③ 在国际顶级数据库学术会议 VLDB 发表文章，讲述了 OpenMLDB 的创新技术。
2. V0.6.x 版本新功能
（1）新场景
引入新语法 exclude current_row ，更好地支持事后决策场景，在做请求的时候，可以不去带入当前的行为的数据。
（2）功能增强
① 线引擎支持批处理。
② Spark 和在线引擎部分完全解耦，如果只需要使用在线引擎，那可以完全不需要去部署 Spark，也不需要去占用 Spark 的资源。
③ 预聚合也做了增强。
（3）生态做更多的整合
包括 Airflow、DolphinScheduler 等的 connector，云计算生态的整合。
3. V0.6.x 版本--易用性
引入智能诊断工具和自动化运维工具，降低运维的复杂性。可以做到一键恢复、一键安装部署、自动分片的平衡和迁移。
4. 研发动态 -- 来自社区开发者的实验特性
**① 自动特征工程，**之前是数据科学家使用 SQL 手动写特征脚本。通过 AutoFE 技术用户也可以用自动的方式，通过输入的数据集自动生成特征脚本。这个功能现在还处于实验特性，我们会逐步把它完善，尽量的去降低 OpenMLDB 的使用门槛。
② 数据导出工具。
③ GO SDK。
5. OpenMLDB v0.7 Roadmap
（1）扩充 SQL 能力。
（2）稳定性增强，做内存资源的隔离、应用性的增强。
（3）易用性优化。
--
04/问答环节
Q1：业务上离线数据和实时数据流怎么保证一致？如果离线数据是经过一些 ETL 之后的数据，要保证一致的话，是否会用到原始的 ODS 层的数据？
A1：首先，离线数据源和在线数据源本质上并不是一份，因为做离线开发、离线的特征训练的时候，用的是历史数据。真正上线时，使用的是实时的、不断更新的数据。所以两个数据源并不相同。
在保持一致的问题上，还可以从逻辑角度做处理。如果离线数据是原始数据表通过 ETL做离线特征抽取得到的，在线上使用时，也会经过 ETL 处理。
Q2：在数据源这一块，有没有计划去支持 Hudi 或者 Iceberg？
A2：有的，下一个版本先把 Hive 支持。接下来，我们一定会优先考虑 Hudi 和 Iceberg这种数据源的接入。在不远的将来就能实现支持。
Q3：特征任务有离线和在线，这在 OpenMLDB 里是归为一个还是两个？
A3：在 OpenMLDB 里面是两个任务，因为我们的引擎是分离的。离线引擎默认用Spark ，在线引擎去做线上的服务。为了保证在线服务的稳定性，一般也会把它们分开部署。在绝大部分的生产环境当中，它们也是运行在不同的机器上的。如果比较轻量的在线的自学习任务，可以用在线引擎去做批处理。
Q4：如果数据处理的逻辑需要去做一些定制开发的，这时迭代效率要怎样保障？
A4：OpenMLDB 的 SQL 不能完全支持的时候，提供两种方式可做扩展：第一种方式是 UDF ，现在只支持 C++ 写 UDF，后期优化会加入 Python；第二种是 build-in 函数的开发，对源代码进行改造。也欢迎大家积极参加社区活动，将高需求的新函数开发出来，我们会把它整合在 OpenMLDB 的发版里面。
今天的分享就到这里，谢谢大家。
▌2023数据智能创新与实践大会
- 4大体系，专业解构数据智能
- 16个主题论坛，覆盖当下热点与趋势
- 40+演讲，兼具创新与最佳实践
- 1000+专业观众，内行人的技术盛会
第四届DataFunCon数据智能创新与实践大会将于⏰ 7月21-22日在北京召开，会议主题为新基建·新征程，聚焦数据智能四大体系：数据架构 、数据效能 、算法创新 、智能应用 。在这里，你将领略到数据智能技术实践最前沿的景观。
欢迎大家点击下方链接获取大会门票～
DataFunCon2023（北京站）：数据智能创新与实践大会
