共计 9392 个字符，预计需要花费 24 分钟才能阅读完成。
本文依据卢冕在『OpenMLDB Meetup No.1』中的演讲整顿而成。
开源机器学习数据库 OpenMLDB：为企业提供全栈 FeatureOps 解决方案
明天的演讲围绕 OpenMLDB 给企业提供全栈 FeatureOps 解决方案 开展，同时对 OpenMLDB 的次要个性和新公布 0.4.0 版本的新性能 进行介绍。
首先介绍一下我本人，我叫卢冕，博士毕业于香港科技大学计算机系，目前在第四范式负责零碎架构师，次要负责数据库团队和高性能计算团队，同时也是开源我的项目 OpenMLDB 的次要研发负责人，目前次要专一于数据库系统和异构计算。
明天的分享次要蕴含三个内容：
- 背景介绍：AI 工程化落地的数据和特色的挑战。
- OpenMLDB 为企业提供全栈 FeatureOps 解决方案：为什么要做
FeatureOps，为什么要去有 OpenMLDB，OpenMLDB 的一些次要个性是什么。 - 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 模型的时候，首先是数据科学家写特色脚本，所谓这个特色脚本就是后面提到的，要如何去抽取这些特色，要定义哪些特色，比方抽取什么最近三天内什么交易量最大的特色。
数据科学家会首先进场去写特色脚本，而后做模型训练，当他做完这部分内容，达到称心的成果当前，即特色脚本和模型都调整实现之后，就到了业务上线的局部。此时会有一个工程化团队来负责业务上线的局部，并进一步染指。
为什么不能间接拿数据科学家做的货色上线？
- 数据科学家他关注的点是模型的准确度、精确度、品质，但他不太关怀模型上线后 latency，QPS 等等。
- 大部分迷信数据科学家做这个过程当中，用的是 Python，RSQL 这种偏差批处理比拟易用的框架，这种面向批处理的这种框架，它间接上线会带来很多问题：
- 上线的逻辑和数据处理的逻辑不同；
- 在性能上，这种批处理的框架不能满足实时处理的需要。
所以个别会有一个工程化团队，把科学家做的特色工程的脚本和模型训练的建模办法，翻译成线上的一套货色。线上的工程化团队不会应用 Python 这种框架去上线，因为他们十分关注 latency、QPS，他们会用一些高性能数据库，甚至去用 c ++ 本人搭建一套特色抽取的服务，买通前面预估服务这条线。
图中虚线框起来的局部就是 FeatureOps 所笼罩的性能范畴，下文将重视讲次要的特色抽取、特色计算所笼罩的性能范畴。从离线开发翻译到线上的实时特色计算，因为线上线下是两套零碎，由两个团队开发，所以 一致性校验 是不可避免的。它其实是整个 FeatureOps 工程化外面代价最大的环节，依照第四范式的教训来说，一致性校验占整个工程的比例会十分高，因为这里牵涉到很多成果的对齐联调，以及人和人之间的沟通老本。
线上线下不统一可能的起因
1.工具能力的不一致性。离线开发和线上利用，应用的工具栈和开发栈可能是齐全不一样的。
- 离线开发数据科学家更偏好于像 python、spark 这种这种工具；做线上利用的时候，考究高性能、低 latency，就须要用一些高性能的编程语言或者数据库来做。
- 当咱们有两套工具的时候，它们笼罩的性能范畴是不一样的，比方说做离线开发的时候，应用的是 python，能够实现很简单的性能，而线上 MySQL 的性能就会受限于于 SQL。
工具能力的不一致性，就会造成做一些斗争的场面，产生的成果就不同。
- 需要沟通的认知差。这不是一个技术问题，然而在理论工程落地当中十分重要。这里咱们举一个例子，Varo，一家十分有名做线上银行的公司，在美国有很多的用户，他们的工程师提到了需要沟通认知差的问题。对于如何定义 account balance，他们有一个教训：
很显著两者之间的认知差，就能造成前面的整个训练成果的不一致性，从而导致了他们的利用里呈现了十分重大的线上业务问题。其实不光是这家银行，在第四范式整个我的项目实际的周期教训当中，咱们都或多或少都碰到过这种沟通认知差带来的问题。一旦呈现这种问题，排查的老本其实还是十分高的。
当然还有其余一些起因，这里我就列举了两种最重要的起因。
线上线下一致性校验带来的昂扬工程化落地老本
因为线上线下的一致性问题的产生，校验是必然的。一次性校验带来了很多老本上的问题：
- 须要两组不同技能栈的开发人员投入，能力去实现从线下到线上的部署的过程。
- 线上线下两套零碎的开发和经营。
这两点在工程化落地老本、开发成本、人力老本下面，都有十分大的代价。
【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 外面咱们讲了两个事件：
- 是把咱们整个 OpenMLDB 的实现架构都去认真进行了形容，所以大家想理解这个架构的话能够也去参照一下 paper；
- 讲了怎么去跟明天的前沿的硬件技术做联合，前沿的硬件技术就是 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 的线上引擎给联合起来，达到了三个十分好的成果：
- 复原工夫从原本的 6 个小时级别降到了 1 分钟，线上业务的意义其实是十分微小的，线上业务比方说点餐零碎，是不容许长时间掉线的，或者不容许某节点掉线当前影响业务的服务质量。联合之后，一分钟就能把这个业务从新拉起来，就不会影响到服务质量。
- 因为一些底层架构的批改，也 改良了 20% 的长尾提早。在 TP9999 的状况下，这就十分显著。
- 缩小了总成本。因为内存单台机器内存扩充，应用的机器数量就变少了，原来用 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，能够进行反馈，咱们会去依据社区的反馈去看需要的优先级，也十分欢送来自社区的共同开发。
