本文整顿自第四范式资深架构师、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 很多关注和反对，他们的意见对咱们来说十分贵重。对于 OpenMLDBOpenMLDB 在端到端的机器学习流程当中提供了一个线上线下一致性的实时特色计算平台。
上图显示一个典型的机器学习的全流程，包含从离线开发始终到线上服务以及其余信息载体从数据到特色到模型的一个流动变动过程，而 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/… 官网 https://airflow.apache.org/Ai… github 主页 https://github.com/apache/air… 微信交换群