本文整理自第四范式资深架构师、OpenMLDB PMC 卢冕在第四范式技术日「高效落地的AI开源生态」分论坛的主题分享——《开源机器学习数据库 OpenMLDB：提供线上线下一致的生产特征平台》。内容包括：
- 感恩 OpenMLDB 贡献者
- OpenMLDB 发展历程
- OpenMLDB 架构设计
- 0.6.0 最新版本讲解
- 落地案例分享
欢迎大家来到第四范式技术日，今天我分享的主题是《开源机器学习数据库 OpenMLDB：提供线上线下一致的生产特征平台》，我是来自第四范式的资深架构师，OpenMLDB PMC 卢冕。
感恩贡献者
正好是 OpenMLDB 开源大概一周年左右，所以我今天先趁这个机会来感谢一下我们 OpenMLDB 社区贡献者。
左下的曲线图是 OpenMLDB 开源一周年以来的社区贡献者的增长曲线图，我们可以看到到今天为止 OpenMLDB 一共有一百多位贡献者，开源贡献者数量呈现一个比较平稳的上涨趋势。左边的头像以及右边的词云图其实是我们 OpenMLDB Github 社区上贡献者的头像以及 Github ID。
今天，趁此机会我在这里感谢百位 OpenMLDB 社区的贡献者。如果没有这些社区贡献者，OpenMLDB 社区不会取得这样茁壮的成长。
发展历程
接着，我也借这个机会来回顾一下 OpenMLDB 的发展历程，OpenMLDB 是在去年 6 月份正式开源。所以到今天为止，OpenMLDB 作为一个开源项目成长了一年多，在开源社区它还是一个非常年轻的项目。
但是在开源前，OpenMLDB 已经跟随第四范式的商业化平台“先知”在很多客户中得到部署，落地超过一百多个场景。其实早在 2017年 OpenMLDB 就开始了代码技术的累积，所以虽然 OpenMLDB 才开源一周年，但是已经拥有四五年的技术积累。
开源以后，OpenMLDB 也取得了很多成绩。首先自开源到今天它一共迭代了六个版本，每个版本都有不同的新功能加入。
在去年 8 月份，基于 OpenMLDB 的优化创新论文在国际顶级的数据库学术会议 VLDB 上发表。
去年 9 月份我们有第一个开源企业用户 Akulaku，这是一家以印尼为主要市场的线上金融公司。
在过去一年里，我们通过社区收获到了非常多的用户反馈。来自 Akulaku、京东科技，以及一些传统行业的企业用户都给了 OpenMLDB 很多关注和支持，他们的意见对我们来说非常宝贵。
关于 OpenMLDB
OpenMLDB 在端到端的机器学习流程当中提供了一个线上线下一致性的实时特征计算平台。
上图显示一个典型的机器学习的全流程，包括从离线开发一直到线上服务以及其他信息载体从数据到特征到模型的一个流动变化过程，而OpenMLDB 专注于中间的这一特征平台部分，给上下游去提供实时的特征计算能力。
OpenMLDB 需求场景
那为什么 OpenMLDB 会强调毫秒级实时特征计算的重要性？因为我们看到今天只有这种毫秒级的硬实时计算才能够真正满足 AI 的需求，能够最大化地实现实时决策业务效果。
刚刚所说的实时计算主要有两方面的维度，一方面是我们需要使用最新鲜的实时的数据，比如过去一分钟或者几分钟访问点击的这个模式；另一个方面的实时计算是需要在非常短的时间去做实时响应。
我们今天看到在市面上确实也是有很多做批量计算和流式计算的计算框架，但它们都没有真正满足 AI 硬实时毫秒级的需求。与之对应的是毫秒级的需求非常常见，在诸如 AI 的无人车、反欺诈场景等应用中都有迫切的需要，比方说右侧表格列举的某银行事中反欺诈场景需要二十毫秒非常高速地的实时特征计算来业务需求。
OpenMLDB 架构设计
当没有 OpenMLDB 时，想开发一个满足实时计算，同时满足线上线下一致性的系统，应该如何做呢？我们看到很多企业的流程是这样的：
首先他们会有一套离线开发的流程，就是数据科学家用他们特定的算法的知识去构建一个离线特征计算的脚本，数据科学家的任务是去构建一个模型精度能够达到业务实践需求的脚本，他们通常会用 Python 或者 SparkSQL 来完成，而这个脚本是不能直接实时上线，做到实时计算的。
所以这个时候一般会有工程化团队介入，把数据科学家的离线特征计算脚本转化成用 Database 或者 C++ 等高性能的方式去满足线上低延迟、高并发以及高可用的工程化需求。在这个流程当中，做完离线开发的线上服务后还有一个非常重要的工作叫做计算逻辑的一致性校验，它往往会耗费大量的人力去做沟通，去做反复地迭代、测试、开发。
根据第四范式以前的经验，如果基于这套流程，中间的一致性校验可能会花费数月的时间导致 AI 场景的落地成本剧增。
这个问题，OpenMLDB是怎么解决的呢？右边这张图显示了 OpenMLDB 比较简要的关键架构。
我们可以看到首先 OpenMLDB 对外暴露了一个唯一的一个编程语言就 SQL。
OpenMLDB 内部还有两套处理引擎，一套专门负责批处理的引擎，是基于 Spark 做了源代码级别优化、针对特征计算场景提升性能的引擎。第二套是实时 SQL 引擎，是 OpenMLDB 团队自研的时序数据库，也是整个 OpenMLDB 保证毫秒级实时特征计算的核心引擎。
基于这两个离线引擎和在线引擎之间，我们会有一个一致性的执行计划生成器，保证它们生成的执行计划是一致的，天然保障了线上线下的一致性。
基于这么一套引擎系统，我们可以达到最终开发即上线的目的。数据科学家使用批处理的 SQL 引擎，去写批处理的特征计算脚本做离线的开发，开发后可以通过一个命令直接把 SQL 脚本一键上线，此时整个 OpenMLDB 的计算模式就会从线下切换到线上，这个时候我们再去接入这个实时数据，就能完成开发上线。
所以大家看到基于这么一套引擎，我们在整个流程当中只需要数据科学家把 SQL 脚本写好，通过一键上线就能做到上线服务，不再需要工程化团队优化，也不再需要人为完成逻辑校验，可以节省大量的 AI 落地成本。所以简单回顾一下 OpenMLDB 的核心特性就是做一个线上线下的特征计算一致去提供一个非常高效的毫秒级的实时特征计算能力。
OpenMLDB 作为一个开源软件，也做了很多上下游生态的整合。OpenMLDB 内部的离线引擎本身就是基于 Spark，而线上引擎方面我们提供了两种模式，一种是基于内存的引擎这种能提供毫秒级计算的模式，另外一种模式面向对于成本比较敏感的用户，他们可以使用基于 RockDB 基于第三方存储引擎的这么一种模式，达到降低成本的效果。
对于上游来说，OpenMLDB 也对接了很多在线的数据源，像 Kafka，像 Pulsar，能够更加方便把实时数据记录。离线的数据源目前主要是 HDFS、S3，后面也会做进一步扩展。对于下游来说，模型这一块目前主要是一个松耦合的对接方式，主要还是输出一些标准文件格式，使它们可以被后面 ModelOps 的软件所读取。
在部署和监控这一块，我们其实也做了很多第三方软件整合，比如在部署这一块我们跟 Airflow、Dolphinscheduler、Byzer 做了一些整合，监控也基于 Prometheus 和 Grafana 去做。
这里可以给大家简单看一下 OpenMLDB 和 Dolphinscheduler 整合界面，可以看到在这里的话我们已经把 OpenMLDB 作为一个算子整合在 Dolphinscheduler 里面，大家可以通过拖拉拽做非常简单的配置，比如任务的优先级，线上线下模式。这里就有一个非常典型的脚本，通过拖拉拽的形式，我们就可以方便地搭建 AI 整个流程。这张图显示了一个非常典型的流程，就是通过创建表导入数据，做离线特征抽取，我们去做模型的训练，这个时候会有一步验证的流程，如果模型训练成功就会直接切换到模型部署，否则就会输出一个报告。基于 Dolphinscheduler 加 OpenMLDB 就可以非常方便地做到这一个非常典型的从训练到部署的一个流程。
最新升级
接下来的时间我来为大家介绍一下 OpenMLDB 最新发布的 0.6.0版本，在这个版本里面我们集合了非常多来自社区的反馈意见，着重提升了 OpenMLDB 的可运维性和稳定性。
因为 OpenMLDB 运维相对复杂的，所以最新版本里提供了一个全新的智能诊断工具，能够方便用户自己去排查。另一方面我们也提供了一些功能性的增强，以及修复了比较多的 bug，解决了一些稳定性问题。在生态合作方面，OpenMLDB 与 Airflow 完成了整合。希望这个版本的 OpenMLDB 可以达到比较稳定的状态并且可运维性得到较大的提升。
左侧的截图可以看出，最新版会提供一些诊断工具来帮忙判断当前 OpenMLDB 的状态，如果存在问题的话，诊断工具会把相关信息抓取出来，同时建议用户做相应操作完成简单的修复尝试。右侧的截图是 OpenMLDB 和 Airflow 整合的 Provider，就是用户可以在 Airflow 里调用 OpenMLDB 去做编排调度。
客户案例
最后要和大家着重介绍的是 OpenMLDB 过去一年来落地的客户案例。
Akulaku
首先要提到我们第一个社区用户——Akulaku，这是一家主攻印尼市场的线上金融科技公司。
Akulaku 在整体架构里构建了一个智能计算平台，可以看到在它的智能计算平台里最上层是智能应用，大部分应用都与风控、反欺诈有关，而下面两层是 Akulaku 的底层技术架构层，OpenMLDB 的线引擎部署在模型计算层，离线引擎部署在特征计算层，提供特征计算。
Akulaku 的需求跟 OpenMLDB 的特性非常吻合，在线上时需要做低延迟、高时效性的计算尽可能反映实时数据的变更，所以需要 OpenMLDB 使用实时数据去做实时的计算；线下它则要去做高吞吐的数据分析，最重要的保证线上线下部署的逻辑完全一致。这个与OpenMLDB 提供的线上线下一致性相契合，所以 Akulaku 最终使用 OpenMLDB 的解决方案，使用 SQL 作为离线和在线的桥梁，实现了一天内处理近 10 亿条定单数据的需要，能做到及时的更新，去做时间窗口实时滑动计算，达到4毫秒的延迟。
某银行——事中反欺诈
第二个案例有关某银行事中交易的风控系统。OpenMLDB 在风控系统架构中衔接了实时特征计算和批处理的特征计算，把两边的线上模块和自学习模块做了连接，保证两边线上线下的一致性。
在这个案例里，银行方对特征计算模块的性能要求非常高，为了应对如今有数目繁多的欺诈手段，他们需要非常快速地做出高效的实时响应，银行的需求是要在 20 毫秒内走完特征计算流程。然而不管是基于行方传统的规则系统，还是客户自研的系统，都无法达到这一个严苛的要求，最后他们使用 OpenMLDB 的方案，依托分布式可扩展的在线预估能力，能够最终达到小于 20 毫秒的实时特征计算。
某国家级科研机构——计算海量数据特征
第三个案例是某国家级的科研单位使用 OpenMLDB 在 IOT 场景里做数据的处理。
在某科研单位的应用场景里，多个设备的实时数据流是通过 Pulsar 导入到 OpenMLDB，OpenMLDB 以在线数据库的模式去做实时在线计算，同时在应用模块里面会不断请求实时计算一场波形的数据。因为数据来自三万个检测设备，每个设备又会每秒产生一百个数据点，所以客户的需求是数据写入需要达到 QPS 三百万的数级。在应用侧，查询计算每十秒就会发送不同设备的数据，请求进行多个窗口的边缘计算，所以计算请求的性能要求大概是 QPS 3000。基于OpenMLDB 的方案，我们只需要使用一台服务器就可以在不考虑高可用的情况下满足数据保存占用内存 50GP，一台服务器就可以满足整体的容量和智能需求，去提供实时 IOT 的数据处理和计算能力。
某金融服务机构——智能运维场景
这张图显示的是某金融服务机构的智能运维场景。
在这个案例中有很多业务系统的监控指标。客户是通过 Kafka 把数据灌到一个实时数据特征平台，在特征计算平台里面做模型推理，再把这个预测结果放到规则决策的系统里，最后决定决策结果是否要报警给运维人员。
行方原来的方案是基于整体做了特征计算，随着业务的扩展，他们希望实现业务的十倍扩容，在原来的方案里面实现十倍扩容，机器也需要实现十倍增长，成本非常高的，所以最后他们使用了基于 OpenMLDB 的升级方案。升级方案是把 OpenMLDB 作为特征计算平台替代原来的 Redis 方案，升级之后 CPU 的资源消耗和内存使用上都有 2 到 3 倍的优化，进而实现扩容成本 50% 的下降，就是说只需要做五倍的机器扩容就可以实现业务的十倍扩容目标，大大降低了资源成本。
某互联网科技公司——实时风控场景
接下来的案例来自于某互联网科技公司。
该公司的需求场景也是实时风控场景。客户原先的实时风控场景同样使用了基于 Redis 方案，辅助一些自研脚本来完成实时特征计算。但是随着业务升级，客户发现原来这套方案在实时计算的反应速度上无法达到需求，计算延迟较高，于是客户选择使用 OpenMLDB 的升级方案，最终使用 OpenMLDB 去替代 Redis，资源利用率获得显著提升，实现了毫秒级实时特征计算，轻松满足了他们的业务需求。
慕尚集团——智能营销平台
最后一个落地案例来自于 OpenMLDB 和慕尚集团的深度合作。慕尚集团是一家中国领先的、由新零售模式驱动的休闲时尚服饰和多品牌运营公司，2019年已经在港交所上市。
随着业务的扩展，慕尚集团对数字化转型产生非常迫切的需求，而以前的营销平台是基于专家规则打造的，需要改造。结合慕尚集团的业务与需求，第四范式使用了 AutoX ＋OpenMLDB 共同构建了新的智能营销平台，并基于新营销平台搭建衍生出了适应多种场景 AI 应用，比如个性化推荐应用、广告精准投放应用、客户流失预警应用等等。
最后
最后我们也欢迎大家加入OpenMLDB的开源社区，和我们在技术方面或者案例方面做更多的互动交流。
谢谢大家，我今天的分享就到这里。
相关链接
✦
OpenMLDB 官网
https://openmldb.ai/
OpenMLDB github 主页
https://github.com/4paradigm/OpenMLDB
Airflow 官网
https://airflow.apache.org/
Airflow github 主页
https://github.com/apache/airflow
OpenMLDB 微信交流群
