导读：明天咱们将从线上线下统一的生产级特色计算平台这个点切入，从「人工智能工程化落地过程中企业面临的数据和特色挑战」 ，「OpenMLDB：线上线下一致性的生产级特色计算平台」，「拥抱开源、面向社区」三个方面介绍开源机器学习数据库 OpenMLDB。 心愿这场分享可能帮忙大家理解 OpenMLDB 是什么，能做什么，实用于哪些场景。同时本文也将首次介绍   OpenMLDB的应用场景和生态构建。

OpenMLDB应用场景：笼罩离线开发到实时线上计算的残缺流程，满足高计算性能需求和实时计算需要，同时也满足纯离线开发及实时线上计算需要。

OpenMLDB生态构建：减速链接DataOps（Pulsar、Kafka等）、ModelOps（TensorFlow、PyTorch、LightGBM等） ，无阻对接ProductionOps（Airflow、DolphinScheduler等） ，围绕OpenMLDB构建面向机器学习利用及上线全流程的上下游生态。

介绍一下我本人，我叫卢冕，目前在第四范式负责零碎架构师，次要负责数据库团队和高性能计算团队，同时也是开源我的项目 OpenMLDB 的次要研发负责人，目前次要专一于数据库系统和异构计算。

1 | 人工智能工程化落地过程中企业面临的数据和特色挑战

首先来看一下背景之一——以后人工智能工程化落地过程中所面对的数据和特色挑战。通过统计数据，咱们理解到现在企业在推动人工智能落地的时候，可能会将 95% 的工夫都花在数据问题的解决上，数据治理的问题亟待解决。尽管明天咱们能在市面上看到十分多的开源或是商业的数据解决方案，例如 Hadoop、MySQL 等曾经向大家提供了丰盛的解决方案。

然而，在 AI 工程化落地过程当中，这些计划是否曾经齐全解决了咱们所面对的挑战，满足了所有咱们所期待的需要？其实目前还是存在很多问题的。

MLOps 残缺生命周期

在 AI 工程化落地的这个过程当中，MLOps 成为一个十分风行的概念。置信大家或多或少都对此有些理解。MLOps 概括了人工智能机器学习工程化落地的残缺生命周期所须要的一些工具以及服务。

下图展现的是 MLOps 运作的闭环流程，能够看到它会分为离线开发和线上服务两个局部。在机器学习相干的开发中，咱们经常会把工作流程拆分为模型的训练和上线，这两套流程存在较大的差别。当咱们吧这两套流程搁置在企业级的生产场景中，它们能够进一步地拆解为 DataOps、FeatureOps 和 ModelOps。这次分享将集中关注 FeatureOps，议论如何通过 OpenMLDB 这一个线上线下统一的生产级特色计算平台去解决特色计算、特色存储、线上实时特色计算以及特色服务的问题。

能够留神的是，画面下方线上服务局部这一块还退出了一个环节——ProductionOps，它是企业人工智能工程化落地时一个十分重要的环节。在生产环境之下，企业会十分看重高可用、可扩缩容、平滑降级、实时监控这些企业级外围。所以 ProductionOps 也是咱们做 FeatureOps 过程中十分关注的内容。

面向决策类场景的特色工程

本次内容分享的背景之二是 OpenMLDB 所触发的利用背景。目前 OpenMLDB 面向的次要场景是决策类场景，是基于理论数据的这种特色工程。这里的关键词有三：

  • 面向结构化数据和决策类场景
  • 解决时序数据
  • 基于工夫窗口的聚合函数

开展阐明上述三点。

其中的结构化数据，简略来说指的是表数据。而决策类场景指的是区别于基于深度学习的感知类产品所面向的角色类场景，更多利用于实时举荐零碎、风控系统、反欺诈零碎等企业业务零碎的场景。

所谓的时序数据，就是所有的数据记录都会带有一个工夫戳，如图中数据表格里的第四列就蕴含着工夫戳。

在理论生产当中特色工程基本上都是对这种时序数据去做这个工夫窗口上的聚合函数，这也是咱们解决最多的特色工程。

生产级特色工程业务需要

上面咱们会从业务角度举例，阐明生产级特色工程所面向是两大业务需要：

  • 线上模型精度合乎业务需要
  • 特色实时计算，满足低提早

以实时举荐零碎为例，比方小李同学，在某个工夫点想买洗衣机，去搜寻洗衣机，触发了搜寻行为当前，前面整个特色计算会做什么？首先进来的实时行为特色，这三个原始的特色就是 User ID，data 以及他在搜寻的产品。如果咱们只是拿这三个特色去做模型训练和推理，是达不到一个业务需要的模型精度的。

此时咱们须要做的是一个特色工程，所谓的特色工程就是咱们从数据库里去进一步地拉取一些历史数据，比方说咱们从交易数据库、商品数据库、用户数据库去拉取一些历史数据，而后组合、计算，失去一些更残缺的更有意义的特色。

图片最左边就是一个实时的特色。假如以后有个主播正在带货，或者网络购物平台正好有一批优惠券正在发放，此时就会存在一个十分实时的特色，比方以后优惠券最多的或者折扣力度最大的洗衣机型号是什么，也可能是过来5分钟内点击量最多的洗衣机是什么，这些特色的计算对实时性的要求十分高。当然抽取的特色中也有一部分特色可能和小李过来的消费行为相结合。比方说小李过来一年买的最多的电子品牌是什么，他的生产平均水平是什么。咱们将所有的特色组合起来，衍生进去的新特色，就是通过特色工程（或者叫做特色计算）生产的特色，最初组合成一个残缺的特色列表，再将它给到后续的模型预估。

从这个案例咱们能够看出，做特色工程蕴含了十分重要的特色计算步骤。

特色平台开发上线生命周期

在这两个业务需要之下，特色计算平台从开发到上线的全生命周期是如何实现的呢？

一开始入场的是数据科学家，他们会依据历史数据和业务精度的要求建设一个离线的业务模型，在此过程中设计离线特色脚本。这个特色脚本就是后面提到的过来一段时间内的点击量的特色等等。要如何去抽取这些特色，要定义哪些特色，判断不同的场景中须要开发何种特色脚本是数据科学家的工作，而在这个过程中大部分数据科学家喜爱应用的语言是 Python，一部分科学家也有可能用到 SparkSQL。

对于数据科学家而言，次要工作就是开发出高质量模型，并通过数据验证测试使得最初生成的模型品质是合乎预期的。而上线后的工程化需要，例如低提早、高吞吐、可运维性等等既不在他们的工作职责之内，也不是数据科学家善于解决的问题。当工作进展到业务上线的局部时，会有工程化团队来负责，并进一步染指 AI 落地。

工程化团队须要去把数据科学家实现的脚本做重构，他们会用一些高性能数据库，甚至用 C++ 从新搭建一套特色抽取的服务，使得上线的产品可能满足业务的实时计算低提早性能需求。

线上线下计算逻辑一致性校验

那么是否通过数据科学家和工程化团队的接力开发解决，产品就能完满上线了呢？在理论的工程化落地中，答案是是否定的。因为两头还缺了很重要的一步——线上线下计算逻辑一致性校验。

计算逻辑一致性校验，简略来说就是数据科学家和工程化团队生产的模型的精度须要达成统一。最实质问题在特色计算方面，要保障特色抽取的计算逻辑统一。这个中央大家可能听起来很简略，但实际上做起来是不容易的，对齐联调所须要的人力老本、测试老本和修护老本十分宏大。在咱们以往的客户服务实际中，一次性校验往往破费数月甚至靠近一年的工夫去重复校验。而投入大量老本去重复验证，天然是因为线上线下经常出现不一致性。

线上线下不统一可能的起因

  • 工具能力的不一致性。离线开发和线上利用，应用的工具栈和开发栈可能是齐全不一样的。

离线开发数据科学家更偏好于像 Python、Spark这种这种工具；做线上利用的时候，考究高性能、低提早，就须要用一些高性能的编程语言或者数据库来做。

当咱们有两套工具的时候，它们笼罩的性能范畴是不一样的，比方说做离线开发的时候，应用的是Python，能够实现很简单的性能，而线上MySQL的性能就会受限于于SQL。

工具能力的不一致性，就会造成做一些斗争的场面，产生的成果就不同。

  • 需要沟通的认知差。这不是一个技术问题，然而在理论工程落地当中十分重要。

这里咱们举一个例子，Varo，一家十分有名做线上银行的公司，在美国有很多的用户，他们的工程师提到了需要沟通认知差的问题。对于如何定义account balance，他们就有一个教训。工程化团队认为这个 account balance 即是上线当前实时的账户余额；然而数据科学家团队为了简化，而采纳了昨天完结时候的账户余额。很显著两者之间的认知差，就能造成前面的整个训练成果的不一致性，从而导致了他们的利用里呈现了十分重大的线上业务问题。其实不光是这家银行，在第四范式整个我的项目实际的周期教训当中，咱们都或多或少都碰到过这种沟通认知差带来的问题。一旦呈现这种问题，排查的老本其实还是十分高的。

当然起因是多样的，这里咱们只列举了两种最重要的起因。

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

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

  • 须要两组不同技能栈的开发人员投入，能力去实现从线下到线上的部署的过程。
  • 线上线下两套零碎的开发和经营。

这两点在工程化落地老本、开发成本、人力老本下面，都有十分大的代价。

为了解决这个问题，国内外的头部企业会破费上千个小时自研构建平台保障线上线下一致性，这个平台和企业外部产品是深度耦合的。除了这些有着超强研发能力的头部企业以外，剩下的大部分企业因为投入研发的老本可能比洽购的老本更高，更多地会洽购一些Saas工具和服务来解决这个问题。

而明天，OpenMLDB 就提供了另外一种可能，咱们提供开源的解决方案，提供 FeatureOps 的企业级解决方案，帮忙企业去做到低成本高效率地解决痛难点。

2 | OpenMLDB 为企业提供线上线计算统一的生产级特色计算平台开源解决方案

2.1 OpenMLDB 架构以及阐明

这张图展现的是 OpenMLDB 的架构。

从外围来看，咱们提供了对立的 SQL 接口。

对开发人员来讲，开发不再须要两套接口。数据科学家在离线开发过程当中写的 SQL，就是最初上线的 SQL，这两者是人造对立的。对外部的开发者来说，语言转化为同一种，数据科学家写的 SQL 不须要工程化团队翻译，就能间接上线。

为了保障这个性能，OpenMLDB 外部设有对立的计算执行引擎，做对立的底层计算逻辑，以及逻辑打算到物理打算的翻译。拿来同一个 SQL，就能翻译成适合的、保障两者一致性的执行打算给到线上计算引擎。

关注高低构造，能够看到线下和线上的两套计算引擎。

因为后面提到过，线上和线下两者的性能要求其实是齐全不一样的，所以计算引擎还是离开的状态。

线下做离线开发的时候，咱们看重的是数据规模以及批处理的效率，所以线下模块实质上还是咱们在 Spark 的根底上做了一些改良。

线上看重的是线上服务的低提早、高吞吐、高并发，线上服务可能只能承受十几到几十毫秒这种量级的提早。为了达到这个目标，线上的整个计算引擎是咱们团队从头开发的一套 in memory 的基于纯内存的内存索引构造，是一个十分高效的基于内存运算的时序数据库。

这两头还有一个十分重要的形成——一致性执行引擎。

一致性执行引擎最重要的工作就是保障线上线下执行逻辑的一致性。外表上来看，就是拿一个对立的 SQL，既能转换到 Spark 去做，对离线批处理也能转换到自研的时序数据库，进行线上的高性能SQL查问。

线上线下会共享一些对立的计算函数，更重要的是，会存在一个逻辑打算到物理打算的线上线下执行模式的自适应。因为线上和线下执行的时候，数据状态是十分不一样的，做离线开发的时候，不论是 label 的样本表还是物料表，都是批处理的模式，在线上时一条一条传输过去，咱们更看重的是一条一条的内存，所以会做一些细节上的转换，更好地达到性能要求。

那么通过的两头的执行引擎，一方面是达到线上线下的一致性，另一方面也能达到线上和线下的不同的执行效率的要求。也就是说在OpenMLDB外部曾经做到了线上线下的一致性，不再须要额定的人力。

总结来说，OpenMLDB 做到了开发及上线的三步骤：

  • 线下SQL特色脚本开发
  • 一键部署上线
  • 接入实时申请数据流

（这里解释一下实时数据流的概念，例如咱们须要三月以来的购物数据作为数据流，随着零碎外事实世界的时间推移，数据流的内容也会过期，须要更新，那么须要实时的数据流靠近，一直把最新的三个月数据保留在外部。这也是咱们和 Pulsar 单干打造新的基于数据流的接口的起因，在这方面 OpenMLDB 下一步还会继续优化。）

2.2 OpenMLDB 利用场景和形式

在利用场景和形式的介绍中，咱们应用这样一张图表，越往右离线计算性能需求越高，越往上实时计算需要越高，通过两条虚线，把它划为四个象限。咱们暂且不讲左下角的需要，重点介绍其余三个象限。

右上象限就是咱们方才提到的场景，须要从离线开发到实时线上计算的残缺流程，能够用咱们 OpenMLDB 残缺的离线到实时上线流程去做这个开发和业务上线。这个过程中会用到咱们的离线引擎和在线引擎，也能享受到线上线下一致性的性能，是咱们认为的最典型的一种应用形式。

左上象限的场景也是咱们在理论中接触过的利用场景，当很多小伙伴开始试用 OpenMLDB 的时候，其实曾经有很多现存的业务逻辑了，这个时候能够只想利用OpenMLDB高性能的线上计算引擎。OpenMLDB 的离线和在线引擎是一个解耦的状态，所以可能满足独自应用在线引擎去做实时特色计算。当然这个中央的线上线下一致性无奈失去 十分严格的保障了。如果你前期须要利用到新的场景，或者一致性须要失去十分强的验证，可能还是要通过 OpenMLDB 走残缺的离线到实时上线流程。

还有一种需要，如右下象限所示。如果不须要做实时特色计算，或者不须要去做上线，可能只须要做一个摸索，或是做模型推理钻研，没有上线需要，那也能够用到 OpenMLDB 的离线引擎，就是通过咱们改良的 Spark 版本做开发，改良版本会对离线特色抽取的性能起到十分大的改善作用。

这三种应用形式不仅在企业用户还是在社区用户中都有存在。

2.3 从离线开发到线上服务残缺流程

接着，我会从咱们最举荐的离线开发到线上服务的残缺流程来解说。

首先，咱们会做离线的模式，把离线的数据导到 OpenMLDB，能够是软链的导入形式。此处的 Offline database 是一个虚构概念化的存在，此时咱们就能够做一个离线模型特色脚本的开发，在这个过程中和 Model training 可能也会有一个交互，要重复去调整。待到性能达到预期后，咱们能够做一个动作，即 SQL deployment。把 SQL 部署上线，那么 OpenMLDB 的部署模式就会从 Offline 转至 Online。

在 Online 的首要工作是冷启动，导入须要的数据。咱们特色脚本个别是面向时序数据的，所以会在窗口上做计算。假如我只须要最近三个月的数据，那我在上线的工夫点须要在冷启动的时候把最近三个月的数据导入。而实际上，最近三个月的数据是不够的，因为事实世界的工夫是一直推移的，所以须要不断更新这个 Online database。因而，OpenMLDB 须要接入在线的实时数据流。当然这里也提供 SDK，也反对通过 SDK 去实时地插入数据。

做完这一步曾经万事具备，此时你能够应用 Preview 性能去看一下线上数据导入是否正确，但这是可选的。

做到这一步呢，整个 OpenMLD B就会转入一个叫做 Request mode，曾经处在一个能够做实时计算的这个模式当中了。在我方才讲述的例子中，小李搜寻洗衣机关键字的信息进来后，零碎就能联合计算逻辑和数据源坐等返回的特定后果了。这样一个 OpenMLDB 应用流程在咱们的产品文档里有更进一步的形容。

2.4 OpenMLDB 产品个性

在介绍完 OpenMLDB 整体的架构和应用流程后，我会开展解说 OpenMLDB 的产品个性。

2.4.1 OpenMLDB 产品个性一：线上线下一致性执行

之前讲过的一致性执行引擎，其实就是在外部去把 SQL 做了一个转换，转换成线上的执行打算和线下的执行打算，保障这两个值是从定义和执行逻辑上都是统一的。等于说线上线下一致性是在 OpenMLDB 的外部失去了一个人造的保障。

2.4.2 OpenMLDB 产品个性二：高性能在线特色计算引擎

第二个十分重要的个性，就是咱们之前讲到的在线特色计算引擎。那咱们怎么去保障在的计算的高性能呢？

第一，在线计算引擎加存储引擎都是咱们自研的一个时序特色数据库，在外部它是一个双层的跳表构造，这有利于咱们去高效地拿到窗口化的数据。

第二，咱们做了一些预聚合的解决，局部特色能够提前去聚合计算，不须要等到查问时才筹备。比方说须要过来一年内的商品点击量之前，咱们能够把每个月的点击量先做好预聚合，当这个线上申请到来的时候，只需把每个月的点击量加起来再补充上最新的特色，就能够达到目标。 在这两种策略的加持下，咱们和其余同样是 in memory 的数据库去做比拟，能够看到在专门对这个特色工程做的窗口化查问需要下，OpenMLDB的性能会有十分大的劣势。

2.4.3 OpenMLDB 产品个性三：面向特色计算的优化的离线计算引擎

第三个个性就是离线计算引擎的优化。

离线计算引擎是基于 Spark 的优化的版本，咱们不是把原始的 Spark 间接拿来的，而是针对特色计优化做了一些措施，比方左边这个图，叫做多窗口的一些并行计算优化：SQL 定义了两个窗口，是在不同的 key 下面，一个是 group by name，一个是 group by age，这是两个工夫窗口，在 Spark3.0 上翻译进去，这两个窗口会串行地去执行，有时候没法齐全的十分好地利用集群的资源，所以咱们在这里就改变了 Spark 的源代码，使其能够并行执行起来的，从而晋升效率。这是其中的一个改变，其余的还有比方数据歪斜的优化，都是基于在 Spark 发行版外面去做的一些优化。左下角这个图显示了咱们目前的版本和 Spark 原始版本的性能比对，能够看到，达到了一个十分显著的性能晋升，特地是针对特色工程相干的操作。

2.4.4 OpenMLDB 产品个性四：针对特色工程的 SQL 扩大

特色四波及到一个很常听到的疑难。因为咱们是基于 SQL 去做这个特色工程，那大家很天然的会有一个问题——SQL 的表达能力是否足够？咱们的答复是，原生的规范的 SQL 对某些比较复杂的特色解决逻辑上其实不是那么敌对。然而，在 OpenMLDB 中，咱们做了SQL语法和性能的扩大。

最典型例子是图片右边展现的 LAST JOIN，它可能在左表匹配到右表多行的时候只取最近的一条或者设定的某一条。这种场景在机器学习的这个训练外面有很多利用。

还有一个例子时 WINDOW UNION 的语法，从直观来了解，其实是做了一个跨表的窗口聚合操作。比方说这个左表（也是主表），左表的这个工夫戳能够在右表的匹配的数据集上画一个工夫窗口，在右表做一个聚合，而后把聚合后果拼到左表上。跨表聚合是 WINDOW UNION 所要达到最次要目标，当然它还有一些更简单的用法，大家能够去参考咱们的语法文档。

基于语法扩大和性能扩大，OpenMLDB 中 SQL 目前的表达能力是足够的。当然咱们也看到社区用户其实可能有一些更高的要求，特地是针对一些这个计算函数，咱们也在一直的扩大可能的新语法，包含新的 build in 函数，这块内容也十分欢送大家来和咱们一起做。

2.4.5 OpenMLDB 产品个性五：企业级个性反对

第五个十分重要的个性波及到 OpenMLDB 的历史，它是从第四范式的商业产品转化而来，在开源之前曾经利用于很多大规模的企业级利用里了，且在上百个场景外面都通过了实际。所以咱们十分看重如何真正落到企业大规模企业级利用里的一些 feature，比方说高可用、扩缩融、平滑降级和企业级监控在现在的 OpenMLDB 中都是反对的。

最次要的一些企业级的 feature 曾经在开源版本里列出来了，还有比方多租户、云原生，曾经在咱们的 roadmap 中，这一部分性能咱们会一直地欠缺它，去更好的去为企业级利用做服务。

2.4.6 OpenMLDB 产品个性六：以SQL为外围的开发和治理体验

最初给大家分享一下这个 OpenMLDB 的一个十分重要的应用形式。咱们认为它是一个数据库，最核心的一点就是 OpenMLDB 是以 SQL 为外围的全流程开发和治理体验，在 CLI 外面去做离线特色计划的开发，开发完离线特色计算，能够一步切换到这个SQL的计划上线，间接用一个 DEPLOY 命令把离线的计划切换到线上，就能够间接进入 serving 的服务。而后按步骤操作，就能够间接做线上申请,进行实时特色计算了。

通过一个 API 做线上申请，或者通过 Python，Java 的 SDK，都能够间接去跟 serving 的服务器做通信和线上申请。能够看到，基于 SQL 和基于 CLI 的开发非常低门槛以及不便。

2.5 OpenMLDB 上下游生态

将 OpenMLDB 投射到 MLOps 生命周期中，能够看到 OpenMLDB 占据着其中 FeatureOps 的地位，次要是做特色计算。

2.5.1 外部框架

先解析 OpenMLDB 外部框架，咱们有这个 Online 引擎和 Offline 引擎。

Online 引擎又能够被细分为存储和执行。在其中的 SQL 执行层面，因为须要贮存最新的实时数据的，所以咱们会有一个 Storage engine，在默认状况下会有 in memory storage（build in）。它其实是十分高效的、专门面向时序数据库去优化的一个内存数据库。当然咱们也能够数据存在磁盘上，把 RocksDB 插进来。所以 OpenMLDB v 0.5.0的版本会同时提供两种不同的 Storage Engine。如果你对性能需求特地高，能够抉择 in memory storage engine。如果你对性能不太敏感然而器重老本，那么能够应用基于磁盘的存储（RocksDB）。

Online SQL Engine 这一块是咱们自研的，用于高性能进行 SQL 计算。Offline 板块是基于Spark去做了正当的批改，称作这个 OpenMLDB 的 Spark 发行版，将来咱们可能也会有其余的一些扩大。

2.5.2 Data sources

右边的是 DataOps，介绍了数据是如何获取的。比方说 Online data sources 板块，咱们公布了 OpenMLDB Pulsar connector, 曾经能够接入 Pulsar 的数据了。这个月公布的版本中，咱们应该还会把 Kafka 的这个 connector 也同时公布进去，更加有利于这个大家数据的接入。在 Offline data sources 这一块呢，OpenMLDB 反对间接接入 HDFS、S3 数据 ，将来咱们也会反对更多的数据源。

2.5.3 ModelOps

往右的 ModelOps 这边，其实是一些上游模型。上游模型通过一些规范输入格局，就能间接接入了。这个月会公布的新版本中，咱们会把这个模型特色的性能整合进来，让它能够输入这个规范的 LIBSVM 或者 CSV 的格局，能够间接给到 Pytorch 等应用。

2.5.4 ProductionOps

咱们也在做部署合和工作编排，OpenMLDB 曾经和 Airflow 和 Kubeflow 做了对接，无望在近期实现与 Airflow 的单干内容。监控一块也是十分易于应用的，OpenMLDB 曾经和 Prometheus 和 Grafana 做了对接。

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

在前沿技术翻新上咱们也有产出成绩，这个是去年被录用的一个 VLDB 的 paper，VLDB 是国内数据库界最顶尖的学术界的会议，在 paper 外面咱们讲了两个事件：

  • 一是把咱们整个 OpenMLDB 的实现架构都去认真进行了形容，所以大家想理解这个架构的话能够也去参照一下 paper；
  • 二是讲了怎么去跟明天的前沿的硬件技术做联合，前沿的硬件技术就是 persistent memory，即长久内存，以前在学术界叫做非易失性内存。

长久内存是英特尔在大略 18、 19 年左右，公布了真正工业界第一款企业级的长久内存利用，奥腾长久内存。那么长久内存有什么劣势呢？首先它成本低，它的单位价格是 Dram的 1/3~1/4 左右。当然它的性能也会比 Dram 略微差 1/2 或 1/3 左右，然而比 SSD 还是会好一个量级的。其次容量大，一条长久内存能够最高到 512 GB，一台服务器上就很容易达到几个 TB。还有一个十分革命性的技术，就是可持久性的内存。当初的 Dram 掉电当前数据都没了，而 Persistent memory 掉电当前这个数据还在，这个是一个十分革命性的技术。

咱们把长久内存跟 OpenMLDB 线上执行引擎曾经联合了起来。后面提到了线上执行引擎的特点，首先它是一个基本上是基于纯内存的执行引擎，所以把它运行起来的老本有时候还是挺高的，如果场景特地大，为了满足内存需要，须要十几台机器，能力运行起来。同时它也有复原工夫慢的问题，因为它一旦掉电，须要从内部存储从新构建内存镜像，须要较长的工夫。

于是咱们就把长久内存跟 OpenMLDB 的线上引擎给联合起来，达到了三个十分好的成果：

  • 复原工夫从原本的 6 个小时级别降到了 1 分钟。线上业务的意义其实是十分微小的，线上业务比方说点餐零碎，是不容许长时间掉线的，或者不容许某节点掉线当前影响业务的服务质量。联合之后，一分钟就能把这个业务从新拉起来，就不会影响到服务质量。
  • 因为一些底层架构的批改，也改良了 20% 的长尾提早。在 TP9999 的状况下，这就十分显著。
  • 缩小了总成本。因为内存单台机器内存扩充，应用的机器数量就变少了，原来用 16 台，当初只须要 6 台，老本一下子就降下来了。

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

接下来举一个简略的例子，在某银行的事中反欺诈交易场景，OpenMLDB 其实就是处于 FeatureOps 的地位，同时连接了离线批处理和实时特色计算。而后在某银行的业务场景里，他们对响应的要求是十分高的，须要提早在 20 ms 以内。能够看到，相比拟于它原来传统规定的零碎、客户自研的零碎，OpenMLDB 提供了一个更好的成果，满足了他们倒退的业务需要。

2.8 OpenMLDB 的历史

其实 OpenMLDB 是从第四范式成立第一天就开始做的产品。通过了 5 年的研发积淀，OpenMLDB 跟随着商业产品经验了上百个我的项目的验证，累积了十分多的案例。

3 | 面向开源凋谢的 OpenMLDB 社区倒退

3.1 OpenMLDB 倒退历程

OpenMLDB 真正开源是去年的 6 月，咱们其中的要害组件从新从商业平台中抽取进去，做了包装和优化造成了 OpenMLDB 明天的状态，并且对外开源，奉献给社区。咱们开源后播种了不错的反馈，去年 9 月播种了第一个开源企业用户 Akulaku，往年咱们也看到很多新团队在不断深入应用 OpenMLDB。

3.2 OpenMLDB 开源根本信息

这张图上是 OpenMLDB 的一些根本信息，大家能够简略理解。

3.3 感激OpenMLDB的社区开发者

趁这个机会，我想再次感激一下 OpenMLDB 的社区开发者。到目前为止，共有 51 位开发者退出社区。是大家一直地投入工夫精力，OpenMLDB 能力被推动着一直往前倒退。从 0.4.0 版本以来，又有 15 位新退出的开发者为社区做出了奉献。在这里，我想示意诚挚的感激。如果大家对 OpenMLDB 感兴趣，也十分欢送你作为新搭档退出。

3.4 OpenMLDB v0.5.0 次要个性

最初想重点给大家介绍 OpenMLDB v0.5.0的新个性，预计在 4 月底公布。

  • 预聚合技术利用到长窗口上。这个长窗口指的是工夫窗口十分大，蕴含上百万条数据，针对这块数据做优化解决，咱们会把预聚合技术利用进去，指数级晋升长窗口聚合性能。
  • 提供一个新的针对磁盘的存储引擎。如果你对价格敏感的话，能够选者这种 RocksDB 的外存贮存。这样使得线上存储引擎可插拔以适配不同业务需要，既能够反对基于内存的高性能存储引擎，也能够反对基于外存的大容量低成本存储引擎，还能够反对基于长久内存的存储引擎以在性能和老本间保持平衡。
  • UDF（用户自定义函数）反对，也会在退出到产品中，大幅晋升易用性和适用性。
  • 反对基于哈希的离散特色编码，以及编码后特色输入到CSV合LIBSVM格局，间接利用到模型训练合模型推理。
  • 欠缺的监控能力，在企业级应用环境中大幅晋升稳定性、可观测性、和可剖析性。
  • 上下游数据源生态整合，提供多种数据源 connectors，包含线上数据源的 Kafka, Pulsar connectors 等等。

3.5 OpenMLDB 后续重要个性

后续布局中 OpenMLDB 个性会朝着三个次要指标去走，三个次要指标就是升高应用门槛，升高应用老本，以及跟上下游生态的买通。

后续迭代都会一直地朝着这三个指标走。比如去布局一个 Cloud native 的 OpenMLDB 版本，包含主动特色工程，可能是明天用户还须要写 SQL，而在将来 SQL 能够依据数据去主动生成。以及还有基于异构硬件的优化，非结构化数据的反对，特色版本合血缘关系治理。大家对某个 feature 特地感兴趣或者特地需要的话，能够通过社区、Github 等渠道进行反馈，咱们会去依据社区的反馈去看需要的优先级，也十分欢送来自社区的共同开发。

3.6 欢送退出 OpenMLDB 开源社区

上次 Meetup 时，我预报了官网的上线。现在 OpenMLDB 官网曾经顺利推出，欢送大家拜访。或者也能够拜访咱们的 Github 页面，退出咱们的微信交换群，又或是我的集体微信探讨交换。

明天的分享就到这里了，感激大家。