开源机器学习数据库 OpenMLDB v0.4.0 产品介绍

本文根据卢冕在『OpenMLDB Meetup No.1』中的演讲整理而成。

开源机器学习数据库OpenMLDB：为企业提供全栈 FeatureOps 解决方案

今天的演讲围绕OpenMLDB给企业提供全栈 FeatureOps 解决方案展开，同时对 OpenMLDB 的主要特性和新发布 0.4.0 版本的新功能进行介绍。

首先介绍一下我自己，我叫卢冕，博士毕业于香港科技大学计算机系，目前在第四范式担任系统架构师，主要负责数据库团队和高性能计算团队，同时也是开源项目 OpenMLDB 的主要研发负责人，目前主要专注于数据库系统和异构计算。

今天的分享主要包含三个内容：

1. 背景介绍：AI 工程化落地的数据和特征的挑战。

2. OpenMLDB 为企业提供全栈 FeatureOps 解决方案：为什么要做 FeatureOps，为什么要去有 OpenMLDB，OpenMLDB 的一些主要特性是什么。 

3. OpenMLDB 现在的开源状况、发展状况以及 0.4.0 版本的特性。

【01 | AI 工程化落地的数据和特征的挑战】

数据侧的技术演进为基于人工智能的决策提供了可能

今天数据的大规模快速演进，为人工智能的决策提供了可能。因为 10 年、20 年前，对于企业来说数据量可能只是百 G 级别的，数据规模在今天来看其实是非常少的，主要依赖于人工录入去做数据分析。到今天这个数据规模就已经变得非常大了，可能达到数百 PB 级别的数据，这种超大的数据量为我们做人工智能决策提供了可能，同时也带来了一个非常大的挑战——怎么去做数据治理。

正确、高效的 AI 数据和特征供给成为数据侧的新挑战

企业在数据治理上花费了高达 95%的时间和精力，数据治理包括数据收集、数据清理、数据处理、数据计算、数据供给。今天在业界有非常多的数据治理方案，例如 Hadoop、MySQL、MEMSAL、Oracle、DeltaLAKE，这些基础架构软件都是构建 AI 系统的一个非常重要的组成部分。但是这些软件到底是否已经解决了 AI 工程化落地的问题呢？其实我们今天看到这些现有的方案，很多时候并没有完全解决 AI 工程化的数据问题。

MLOps 的完整生命周期

为了理解 AI 工程化落地数据问题到底是什么，我们先来介绍一些背景信息。先引出一个最近非常火的名词叫做 MLOps，MLOps 覆盖了机器学习从开发到上线到运维整个生命周期的所有工具集和运维手段。

把 MLOps 拆开来看就得到这张图，它分为离线开发和线上服务两个分离的流程，为什么会有这两个流程？我们注意到，两个流程里面 high level 的组件其实都是一样的，包括 DataOps、FeatureOps、 ModelOps，但是这两个流程还是有非常不一样的点。

人工智能的开发流程按照这个图来，先要有一个离线开发，做离线训练的流程，等到模型训练已经达到要求了，就转为线上服务。这个线上服务又叫做 Inference，在 ModelOps 里面是做推理。

这两个流程虽然有一些共同点，但是在算法的实现上，在落地工程落地的要求上，其实都有非常大的差别。在真正地做到 MLOps 实践企业落地的时候，经常会把这两个流程分开看。在这两个流程里面，可以看到有 DataOps、FeatureOps、 ModelOps，在离线开发这一块，DataOps 负责数据采集和存储。

FeatureOps 是我今天要重点覆盖的部分，它主要包含了特征计算、特征存储、线上实时特征计算以及特征服务这几个环节。ModelOps 覆盖的是线下离线部分的模型训练和线上的推理。

简单来讲，这 6 大组件构成了 MLOps 的整体闭环。还有一个环节 ProductionOps，是企业真正做人工智能工程化落地时一个非常重要的环节。做线上服务的时候，会非常看重这些企业级的核心，包括高可用可扩缩容、升级、监控，都是非常必要的，所以 ProductionOps 作为一个子模块，被包含在 MLOps 里面。

FeatureOps - 实时特征计算

FeatureOps 最主要的功能是什么？它最主要涵盖的功能就是特征工程，举个做实时特征计算的例子，例子中还包含了一个离线的特征计算。离线的特征计算和实时特征计算在总体的逻辑上是类似的，区别主要体现在实现的要求上，这里我们主要关注实时的特征计算。

举一个性化搜索的例子，比如小李同学，在某个时间点想买洗衣机，去搜索洗衣机，触发了搜索行为以后，后面整个特征计算会做什么？首先进来的实时行为特征，只是这三个原始的特征，就是 User ID，data 以及他在搜索东西。如果我们只是拿这三个特征去做模型训练和推理，它是达不到一个非常好的模型精度的。

此时需要做一个特征工程，所谓的特征工程就是我们从数据库里去进一步的去拉取一些历史数据，比方说我们从交易数据库、商品数据库、用户数据库去拉取一些历史数据，然后组合、计算，得到一些更完整的更有意义的特征。

图片最右边就是一个实时的特征，比方说当前有个主播正在带货，或者天猫正好有一批优惠券正在发放，就会存在一个非常实时的特征，比如当前优惠券最多的或者折扣力度最大的洗衣机型号是什么，也可能是过去 5 分钟内点击量最多的洗衣机是什么，也可能是跟小李过去的消费行为有一些结合的特征，就比方说小李过去一年买的最多的电子品牌是什么，他的消费平均水平是什么，这些所有的这些特征全部组合起来，这些新的衍生出来的特征，就是通过特征工程（或者叫做特征计算）衍生出来的特征，最后组合成一个完整的特征列表，然后再去给到后面做模型预估。所以做特征工程包含了非常重要的特征计算步骤。

FeatureOps 工程化的最大挑战-线上线下一致性校验

接下来，带大家了解一下，在实际落地过程当中特征工程是怎么做的。普遍流程是，一开始做 AI 模型的时候，首先是数据科学家写特征脚本，所谓这个特征脚本就是前面提到的，要如何去抽取这些特征，要定义哪些特征，比如抽取什么最近三天内什么交易量最大的特征。

数据科学家会首先进场去写特征脚本，然后做模型训练，当他做完这部分内容，达到满意的效果以后，即特征脚本和模型都调整完成之后，就到了业务上线的部分。此时会有一个工程化团队来负责业务上线的部分，并进一步介入。

为什么不能直接拿数据科学家做的东西上线？

1. 数据科学家他关注的点是模型的准确度、精确度、质量，但他不太关心模型上线后 latency， QPS 等等。

2. 大部分科学数据科学家做这个过程当中，用的是 Python，RSQL 这种偏向批处理比较易用的框架，这种面向批处理的这种框架，它直接上线会带来很多问题：

• 上线的逻辑和数据处理的逻辑不同；

• 在性能上，这种批处理的框架不能满足实时处理的需求。

所以一般会有一个工程化团队，把科学家做的特征工程的脚本和模型训练的建模方法，翻译成线上的一套东西。线上的工程化团队不会使用 Python 这种框架去上线，因为他们非常关注 latency、QPS，他们会用一些高性能数据库，甚至去用 c++自己搭建一套特征抽取的服务，打通后面预估服务这条线。

图中虚线框起来的部分就是 FeatureOps 所覆盖的功能范围，下文将注重讲主要的特征抽取、特征计算所覆盖的功能范围。从离线开发翻译到线上的实时特征计算，因为线上线下是两套系统，由两个团队开发，所以一致性校验是不可避免的。它其实是整个 FeatureOps 工程化里面代价最大的环节，按照第四范式的经验来说，一致性校验占整个工程的比例会非常高，因为这里牵涉到很多效果的对齐联调，以及人和人之间的沟通成本。

线上线下不一致可能的原因

1. 工具能力的不一致性。离线开发和线上应用，使用的工具栈和开发栈可能是完全不一样的。

• 离线开发数据科学家更偏好于像 python、spark 这种这种工具；做线上应用的时候，讲究高性能、低 latency，就需要用一些高性能的编程语言或者数据库来做。

• 当我们有两套工具的时候，它们覆盖的功能范围是不一样的，比方说做离线开发的时候，使用的是 python，可以实现很复杂的功能，而线上 MySQL 的功能就会受限于于 SQL。

工具能力的不一致性，就会造成做一些妥协的局面，产生的效果就不同。

2. 需求沟通的认知差。这不是一个技术问题，但是在实际工程落地当中非常重要。这里我们举一个例子，Varo，一家非常有名做线上银行的公司，在美国有很多的用户，他们的工程师提到了需求沟通认知差的问题。关于如何定义 account balance，他们有一个教训：

很明显两者之间的认知差，就能造成后面的整个训练效果的不一致性，从而导致了他们的应用里出现了非常严重的线上业务问题。其实不光是这家银行，在第四范式整个项目实践的周期经验当中，我们都或多或少都碰到过这种沟通认知差带来的问题。一旦出现这种问题，排查的成本其实还是非常高的。

当然还有其他一些原因，这里我就列举了两种最重要的原因。

线上线下一致性校验带来的高昂工程化落地成本

因为线上线下的一致性问题的产生，校验是必然的。一次性校验带来了很多成本上的问题：

1. 需要两组不同技能栈的开发人员投入，才能去完成从线下到线上的部署的过程。

2. 线上线下两套系统的开发和运营。

这两点在工程化落地成本、开发成本、人力成本上面，都有非常大的代价。

【02 | OpenMLDB 为企业提供全栈 FeatureOps 解决方案】

FeatureOps 工程化解决方案

所以 FeatureOps 它有一些什么样的解决方案？

头部企业会自研构建保证线上线下一致性的平台，但是他们投入的成本也是非常高的。除了这些有非常强的研发能力的企业以外，剩下的企业更多地会采购一些 Saas 工具和服务，解决这个问题，因为投入研发的成本可能比采购的成本更高。

而 OpenMLDB 就提供了另外一种解决方案，我们提供了开源的解决方案，帮助企业去做到低成本高效率地解决问题，提供 FeatureOps 企业级的解决方案。

OpenMLDB 是一个开源机器学习数据库，提供企业级 FeatureOps 全栈解决方案

首先这张图把整个架构把转换到了 OpenMLDB 的架构图上。我们看到这张图跟前面的图片有三个显著的区别：

1、从对外暴露的编程语言 API 来讲，我们提供了统一的 SQL 接口。

对开发人员来讲，就不再需要两套开发接口。数据科学家在离线开发过程当中写的 SQL，就是最后上线的 SQL，这两者是天然统一的。对外部的开发者来说，它就是同一种语言。数据科学家写的 SQL 不需要工程化团队翻译，就直接能上线。

为了保证这个特点，我们内部有统一的计算执行引擎，做统一的底层计算逻辑，以及逻辑计划到物理计划的翻译。拿来同一个 SQL，翻译成合适的、保证两者一致性的执行计划给到线上计算引擎。

2、这里看到线下的计算引擎和线上的计算引擎，他们其实还是分开的，因为前面提到过，线上和线下两者的性能要求其实是完全不一样的。

线下做离线开发的时候，我们看重的是看中的是批处理的效率，所以线下这个模块它其实我们本质上还是基于 spark 的，只是我们在 spark 上做了一些改进。

3、线上这一块看重的是线上服务的 latency，并发性，QPS，线上服务可能只能接受十几到几十毫秒这种量级的延迟。为了达到这个目的，线上的整个计算引擎是我们团队从头开始开发的一套 in memory 的基于纯内存的内存索引结构。

它就是一个非常高效的基于内存运算的时序数据库。这个数据库是 OpenMLDB 团队从头开始构建的，没有参照第三方的数据库，主要也是因为一些深度的优化可以更好地去集成，不会再被一些外部的限制约束。因为做特征工程的时候，有一些非常特殊的优化点。前面提到的例子中，特征工程脚本可能是非常复杂的，而且跟时序是有非常强的相关性，我做一个刷卡动作，做一个搜索动作，我们看到的可能是前 1 分钟这个状态是怎么样的，这是一个非常强的跟持续相关的计算引擎。所以基于这一点，我们开发了一套做时序特征计算优化的计算引擎。

基于这样一套架构，OpenMLDB 的终极目标是实现开发即上线：第一步是离线的特征脚本开发，拿来的是离线的数据，开发完第二步就是一键上线，从线下直接切换到线上，这个过程对用户基本上是无感知的，敲个命令就完了。从线下切换到线上模式，直接起一个 serving 的服务，让实时数据流把它接进来，直接就能做线上服务了。这个过程就省去了一致性校验，没有了两个系统的运营维护，AI 工程化的成本会大大降低。

OpenMLDB 产品特性一：线上下一致性执行引擎

本文不会详细展开讲特性的技术细节，大家如果感兴趣，可以关注我们后续的 MeetUp，我们可以展开讲里面的技术细节，同时大家也可以关注我们在目前在知乎上的 OpenMLDB 专栏，会持续地披露一些技术细节。

一致性执行引擎表面上来看，就是拿一个统一的 SQL，既能转换到 spark 去做，对离线批处理，也能转换到自研的时序数据库，进行线上的高性能 SQL 查询。线上线下会共享一些统一的计算函数，更重要的是，会存在一个逻辑计划到物理计划的线上线下执行模式的自适应。因为线上和线下执行的时候，数据形态是非常不一样的，做离线开发的时候，不管是 label 的样本表，还是物料表，它都是一张表，因为这些数据都是批处理的模式，在线上的时候一条一条过来，我们更看重的是一条一条的内存，所以我们会做一些细节上的转换，更好地达到性能要求。所以通过的中间的执行引擎，一方面是达到线上线下的一致性，另一方面达到线上和线下的不同的执行效率的要求。

OpenMLDB 产品特性二：以 SQL 为核心的开发和管理体验

第二个特性是，特征低门槛的以 SQL 为核心的开发和管理体验。这点对于降低使用成本非常重要。图上是我们的命令行，它非常像 MySQL 的命令行。在 CLI 里面去做离线特征方案的开发，开发完离线特征计算，可以一步切换到这个 SQL 的方案上线，直接用一个 DEPLOY 命令把离线的方案切换到线上，然后就会直接起一个 serving 的服务。然后通过第三步，就可以直接做线上请求了。

这是通过一个 API 做线上请求，或者通过 Python，Java 的 SDK，都提供了不同的 SDK 直接去跟 serving 的服务器做通信和线上请求。可以看到，基于 SQL 和基于 CLI 的开发非常的低门槛和方便。

OpenMLDB 产品特性三：面向特征计算的性能优化 – 离线计算引擎

离线计算引擎是基于 spark 的优化的版本，我们不是把原始的 spark 直接拿来的，而是针对特征计优化做了一些措施，比如右边这个图，叫做多窗口的一些并行计算优化：SQL 定义了两个窗口，是在不同的 key 上面，一个是 group by name，一个是 group by age，这是两个实验窗口，在 spark3.0 上翻译出来，这两个窗口会串行地去执行，有时候没法完全的非常好地利用集群的资源，所以我们在这里就改动了 spark 的源代码，把它变成一个生成的计划，从而使其可以并行执行起来的。

这是其中的一个改动，其他的还有比如数据倾斜的优化，基于现代化的硬件优化技术去做了一些优化，比如底层的 cmd 的适配，都是基于在 spark 发行版里面去做的一些优化。左下角这个图显示了我们目前的版本和 spark 原始版本的性能比对，可以看到，我们还是可以达到一个非常显著的性能提升，特别是对于特征工程跟持续相关的操作。

详细的技术细节可以在 OpenMLDB 专栏上相应的文章中找到

OpenMLDB 产品特性三：面向特征计算的性能优化 – 在线计算引擎

在线计算引擎是完全从零开始自建了一套时序特征数据库。它本质上是一个双层的跳表，跳表结构有两层：第一层是根据 key 做一个跳表的排序索引，第二层是根据 ts 再去做一层排序作用。

这种结构对持续相关的查询非常友好，比方说我要查到小李这个人过去三天内的一些消费记录，直接通过 index 就能非常快地查找到。所以线上的这一部分索引结构，就保证了在高压力复杂查询下，延迟可以小于 20 毫秒。

同样左下角的图也显示了 OpenMLDB 和其他商用纯内存数据库的性能比较，当然是针对特征计算特定的 workload 的情况下的比较。可以看到经过一些优化，特别是针对持续查询的优化，我们的性能是有非常大优势的。尤其是当查询变得复杂的时候，比如 Window 特别多的时候，其他数据库的性能延迟增长会非常陡峭，而 OpenMLDB 的延迟增长还是比较稳定的，能符合线上业务的需求。

大家对这一块技术感兴趣的话，也可以去看我们在 VLDB 上发表的一个 paper，论文里详细描述了里面的数据结构。

OpenMLDB 产品特性四：企业级特性支持

第四个非常重要的特性是跟 ProductionOps 有关的一些特性，OpenMLDB 在开源之前已经应用于很多大规模的企业级应用里了，且在上百个场景里面都经过了实践。所以我们非常看重如何真正落到企业大规模企业级应用里的一些 feature，比方说高可用、扩缩融、平滑升级、多租户和企业级监控。

最主要的一些企业级的 feature 已经在开源版本里列出来了，还有比如多租户、企业级监控、异构内存架构，有一些是在我们的内部版本里有一些实现，有一些我们还在开发当中，这一部分功能我们会不断地完善它，去更好的去为企业级应用做服务。

拥抱前沿新硬件技术：基于持久内存的优化

技术讲到最后一页，再稍微提一下我们在技术创新性上的成果，这个是我们去年被录用的一个 VLDB 的 paper，VLDB 是国际数据库界最顶尖的学术界的会议，在 paper 里面我们讲了两个事情：

1. 是把我们整个 OpenMLDB 的实现架构都去仔细进行了描述，所以大家想了解这个架构的话可以也去参照一下 paper；

2. 讲了怎么去跟今天的前沿的硬件技术做结合，前沿的硬件技术就是 persistent memory，即持久内存，以前在学术界叫做非意识性内存。

持久内存是英特尔在大概 18、 19 年左右，发布了真正工业界第一款企业级的持久内存应用，奥腾持久内存。那么持久内存有什么优势呢？首先它成本低，它的单位价格是 dram 的 1/3~1/4 左右。当然它的性能也会比 dram 稍微差 1/2 或 1/3 左右，但是比 SSD 还是会好一个量级的。其次容量大，一条插槽可以最高到 512GB，我们在 server 上能插 11 条，其实很容易就达到几个 TB 的一个 server 配置。还有一个非常革命性的技术，就是可持久性的内存。现在的 dram 掉电以后数据都没了，而 Persistent memory 掉电以后这个数据还在，这个是一个非常革命性的技术。

我们把持久内存跟 OpenMLDB 线上执行引擎已经结合了起来。前面提到了线上执行引擎的特点，首先它是一个基本上是基于纯内存的执行引擎，所以把它 run 起来的成本有时候还是挺高的，如果场景特别大，为了满足内存需求，需要十几台机器，才能运营起来。同时它也有恢复时间慢的问题，因为它一旦掉电，需要从外部存储重新构建内存镜像，需要较长的时间。

于是我们就把持久内存跟 OpenMLDB 的线上引擎给结合起来，达到了三个非常好的效果：

1. 恢复时间从本来的 6 个小时级别降到了 1 分钟，线上业务的意义其实是非常巨大的，线上业务比方说点餐系统，是不允许长时间掉线的，或者不允许某节点掉线以后影响业务的服务质量。结合之后，一分钟就能把这个业务重新拉起来，就不会影响到服务质量。

2. 由于一些底层架构的修改，也改进了 20%的长尾延迟。在 TP9999 的情况下，这就非常显著。

3. 减少了总成本。因为内存单台机器内存扩大，使用的机器数量就变少了，原来用 16 台，现在只需要 6 台，成本一下子就降下来了。这一部分我们现在暂时还没有放到我们开源版本里面去，后期也会考虑去做一部分的开源工作或一部分的 release 功能出来。

OpenMLDB 典型案例 – 某银行事中反欺诈交易

接下来举一个简单的例子，在某银行的事中反欺诈交易这个点，OpenMLDB 其实就是处于 FeatureOps 的位置。然后在某银行的客户里，可以看到，相比较于它原来传统规则的系统、客户自研的系统，我们都达到了一个更好的效

OpenMLDB 的技术沉淀

最后总结一下技术沉淀。其实 OpenMLDB 是从第四范式成立第一天就开始做 DB 了，他并不是最近才开源才开始开发的，其实已经经过了 5 年的研发沉淀，经历了大概上百个项目的验证，在这个过程当中申请了 8 件专利，包括一个国际顶级的学术会议，VLDB 的一篇 paper，同时，我们和国内外的一流高校都有合作。关注产品商业化落地的同时，我们也非常关注前沿的学术研究，所以大家如果在学校里做数据库研究，对这个感兴趣，我们非常 open，非常欢迎跟我们去做一些合作。

【03 | 拥抱开源，面向社区】

最后我会简单介绍下 OpenMLDB 现在发展状态，我刚才已经讲到我们在过去 5 年已经有了非常多的沉淀。

OpenMLDB 发展历程

这是 OpenMLDB 的时间线。在去年 6 月份之前，OpenMLDB 还是一个内部的闭源商业版本，在去年 6 月开源，在开源以后这个时间线上比较 highlight 的就是 8 月份我们有一个 VIDB 的 paper 的发表，然后 9 月份我们非常荣幸，有了第一个社区企业用户 AKULAKU。

昨天我们发布了 0.4.0 版本，后面对 0.04.0 版本的一些 highlight 的 feature 进行介绍。

OpenMLDB 开源基本信息

这是 OpenMLDB 的一些非常 high level 的总结。不包含第三方 dependency 的代码，纯粹的 openMLDB 的代码行数有 30 万多。这个量其实还是非常大的。测试 case 就有 18k 多，经过了时间的检验的。目前可以看到开源以后，代码在不断地迭代更新，也非常感谢社区的一些贡献。

OpenMLDB 0.4.0 – 增强 SQL 为核心的开发体验

简单介绍一下 0.4.0 的一些 highlight 特性，一个是以 SQL 为核心的开发体验，之前已经讲过，但是在 0.4.0 版本里面做了一些增强，使它能够在单机版和集成版里使用，而且做了相应的一些增强。

OpenMLDB 0.4.0 – 线上监控，为企业级应用保驾护航

然后另外一个非常重要的 feature，我们引入了线上监控模块，让普罗米修斯，Grafana 接入了线上监控模块。这个 feature 还是第一次引入，所以还有很多需要完善的地方，但至少可以进行一些基本的监控，后续这会是一个非常的重要的功能，我们会去把它不断的完善。

OpenMLDB 0.4.0 – 完整的文档治理

还有一个非常重要的里程碑，就是我们终于做了一个非常完善的文档治理。我们的文档网站其实已经上线，大家今天就可以去查看我们的文档，里面有 OpenMLDB 介绍，有快速上手的教程，以及非常详细的 SQL 语言的一些参考，大家感兴趣的话可以去看。

OpenMLDB 官网即将上线

另外一个预告是 OpenMLDB 官网即将上线，应该在这个月底就能上线，敬请期待。

OpenMLDB 后续重要特性

最后我非常简单地讲一下我们后续规划中的一些非常重要的特性，我们特性会朝着三个主要目标去走，三个主要目标就是降低使用门槛，降低使用成本，以及跟上下游生态的打通。

后续迭代都会不断地朝着这三个目标走。比方去规划一个 cloud native 的版本，去基于把内存版本去换成一个基于外存优化的 TCO 版本，长时间窗口能支持更大的数据量，包括自动特征工程流出引擎以及边缘端的版本，我们会按照优先级去给他做一些排序，如果今天线上的小伙伴如果对某个 feature 特别感兴趣，这个正好是你业务当中要用的 feature，可以进行反馈，我们会去根据社区的反馈去看需求的优先级，也非常欢迎来自社区的共同开发。