本文整顿自 OpenMLDB PMC 卢冕 在 OpenMLDB Meetup No.6 中的分享——《开源机器学习数据库 OpenMLDB：线上线下统一的生产级特色平台》。非常感谢大家来加入此次 OpenMLDB 第六次 Meetup。我叫卢冕，是 OpenMLDB 的研发负责人，也是第四范式的零碎架构师。
明天由我来给大家整体介绍 OpenMLDB 的定位和个性，回顾最近一个月来 release 的内容和 OpenMLDB 研发停顿。
我的分享次要分为三局部。第一局部介绍以后人工智能工程化落地所面临的数据和特色挑战第二局部解说咱们目前如何通过 OpenMLDB 这个线上线下统一的生产级特色平台来解决这些挑战第三局部率领大家回顾 OpenMLDB 的倒退历程，以及 OpenMLDB 下一版本的 Roadmap。Tips：目前咱们正在布局 OpenMLDB v0.7.0，已有一个初步的 roadmap（还在调整批改中）。如果大家对 OpenMLDB 有期待和需要或是对于参加开发某一个 feature 十分感兴趣，咱们欢送大家和咱们进行具体地交换，也会把来自开源社区的需要放在探讨排期比拟高优的地位。交换通道：https://github.com/4paradigm/… 人工智能工程化落地所面临的数据和特色挑战数据挑战
在现在人工智能落地的过程当中，其实咱们把大部分工夫都破费在数据治理上。明天市面上曾经有十分多的数据治理工具，如 MySQL、HDFS 等。但从 AI 落地的角度思考，这些工具未能齐全解决咱们 AI 落地中的一些工程化问题。接下来就来具体介绍 AI 工程化落地面临的挑战，以及 OpenMLDB 的解决思路。毫秒级实时特色计算需要广大
在此之前，先阐明一个十分重要的背景常识：OpenMLDB 所面向的利用场景是机器学习的决策类场景，而且是时效性要求十分强的决策场景，因而它须要具备毫秒级的数据和特色解决能力。可能大家都晓得咱们的目前接触到的 AI 利用能够分为两类。一类是感知类，例如 CV、人脸识别、NLP，它们都是属于感知类的利用。另一类是 OpenMLDB 所关注的决策类的 AI 利用，次要面向于商业场景，像是防控、风控、反欺诈、个性化举荐等等。决策类的 AI 利用个别针对结构化的数据。那为什么咱们须要实时的机器学习去做决策呢？其实，所谓实时机器学习决策，能够从两个维度下来了解。一个维度是咱们须要实时的数据。当咱们须要对以后行为的产生做出判断，必须通过十秒甚至更短时的实时数据能力取得更精确的判断。另一个维度是咱们须要实时的计算，只有在十分短的工夫内把计算结果反映进去，能力做到业务要求下的疾速响应。针对此类须要实时数据和实时计算的场景，咱们现实生活中曾经有了十分丰盛的需要场景。AI 无人车、量化交易、银行的风控和事中反欺诈等都须要基于实时数据的疾速实时计算。在明天的市面上，咱们也能看到很多机器学习的通用大数据处理框架，如 Spark、Flink，甚至是 Python，然而这些框架都不能达到毫秒级的实时计算响应速度。以 OpenMLDB 企业客户为例，在他们的银行反欺诈场景中，须要零碎的响应工夫管制在 20 毫秒以内。若响应工夫过长，反欺诈机制可能生效，导致大量损失。所以市场还是十分须要有一款具备毫秒级实时数据和特色解决能力的工具，为机器学习场景决策提供更强有力的反对。OpenMLDB 最具劣势的利用场景正是实时的机器学习决策。机器学习利用开发上线全流程接下来让咱们进入到另一个重要的背景常识——机器学习利用从离线开发到上线全流程是怎么的。
整个需要会分为离线和线上两个局部。在离线开发环节，数据科学家会一直摸索开发特色脚本和模型，使它们可能达到最终的精度要求。在线上服务环节，要将服务上线，真正做到线上的实时预测以及实时特色计算。OpenMLDB 关注的是其中的特色局部，而不波及后续的模型。
在这里，咱们能够通过上面的事中反欺诈交易的案例帮忙大家理解实时特色计算场景。假如图中有一位用户做了刷卡的行为动作。咱们能够失去刷卡金额、刷卡工夫、卡号这些生产记录，也是最原始的数据。咱们的反欺诈零碎会通过一张历史交易表，查问到做了消费行为的卡号，进而失去一系列的历史数据。因为咱们是做事中反欺诈的，所以以后的数据也能为判断提供根据，它也会虚构地裸露到表格当中和交易记录等历史数据独特造成所有的原始交易信息，提供给特色抽取。在右侧图表中还能够察看到一个十分重要的特色，就是信息的工夫戳。所有原始信息都是基于时序排列的。这里常常须要做的特色计算模式，就是基于窗口的聚合模式。在例子里，咱们能够划定两个窗口，一个是十秒的窗口，即从以后交易的工夫点向前十秒的工夫点划一个工夫窗口；另一个是三小时的窗口。基于这两个工夫窗口，咱们能够做一些特色抽取，比方说过来十秒或三小时的刷卡次数、最大刷卡金额、最小刷卡金额以及均匀每次刷卡金额。那么通过计算咱们失去了一些无效的特色信息，这些特色信息会提供给前面的模型推理环节应用。这个就是 OpenMLDB 面向的实时特色计算场景中的典型案利。通过这个案例，咱们能够看到两个十分值得关注的工程化需要。第一点，线上线下的一致性。简略来说就是线上服务的成果需与数据科学家离线开发的成果统一。第二点，低提早、高并发、高可用的工程化需要。接下来我会开展解说这两点需要。特色计算开发上线全生命周期
上图能够展现出特色计算开发，从开发到上线的生命周期。首先会由数据科学家进入我的项目体系，他会依据教训应用 Python、SparkSQL 做离线特色计算。当离线特色计算的输入后果能够满足业务需要时，数据科学家生产满足业务精度的特色脚本和模型的工作就实现了。但因为离线的特色脚本和模型不能满足低提早、高并发、高可用的线上工程化需要。此时会有工程化团队染指。他们会应用一些高性能、高可用的工具，像 Database、C++ 把离线特色计算脚本转换成成实时特色计算的程序利用，满足生产需要后真正做上线服务。那这个流程当中呢，其实咱们有看到两组开发人员以及两套工具链。最重要的是两头还有一个环节，叫做计算逻辑一致性校验。这个环节须要保障的数据科学家和工程化团队开发脚本的计算逻辑、数据定义是截然不同的。听下来这是一个间接且简略的需要，但在真正的工程化落地实际中，一致性校验往往要投入大量的工夫精力。咱们不仅须要这个工程化团队实现性能优化，还要一直地沟通对齐、去两边对齐、迭代测试，保障计算逻辑的一致性。依据咱们以往的业务教训，这个环节很可能会成为整个我的项目周期的瓶颈，消耗几个月甚至一年以上的工夫，计算其投入老本，是十分昂扬的。线上线下不统一起因
而线上线下不统一的起因也是多样的，它可能受到工具能力不统一的影响，也可能是需要沟通认知差导致的。美国一家线上银行的工程师就曾写博客述说过这种需要认知的差别，他在文章里提到本人对账户余额的定义与其余共事默认的账户余额定义以及解决形式不统一，导致了线上线下的不统一。特色平台工程化解决方案
为了解决该痛点，头部企业会破费上千小时自研构建数据与特色平台，来解决诸如线上线下一致性、数据穿梭、特色回填、高并发低提早等工程挑战；其余中小企业则须要洽购昂扬的 SaaS 工具和数据治理服务。OpenMLDB 抉择为大家提供开源的、低成本、高效率、企业级的解决方案。OpenMLDB：线上线下统一的生产级特色平台 OpenMLDB 诞生背景
OpenMLDB 是去年 6 月开源的，然而其中的技术累积曾经超过了四五年的工夫。在第四范式的商业产品中，OpenMLDB 的前身是嵌入在 MLOps 产品中的特色平台，过来咱们叫它 RTIDB 或 FEDB，曾经追随第四范式的商业化产品在 100 多个场景失去利用落地。OpenMLDB 如何解决之前提到的两个问题呢？让咱们往下看。
在 OpenMLDB 架构中有两套解决引擎。一套用于 离线开发，解决离线数据。它是咱们基于 Spark 做了源代码级别优化后的产物，专门提供给数据科学家做离线摸索，面向批处理模式。另一套面向工程化，是针对生产级线上服务研发的实时 SQL 引擎，是由咱们研发团队齐全从零到一、自主搭建的。它是针对时序数据，也针对特色工程优化的一个分布式时序数据库。除了两套引擎外，架构中还有一个十分重要的一致性执行打算生成器。它保障了线上线下两套引擎生产的执行打算在计算逻辑上完全一致。配套这样一套架构，OpenMLDB 对外裸露的惟一编程语言是 SQL。用户只须要把 SQL 写好就能通过一致性执行打算生成器去生成线上和线下的执行打算，同时人造保障这两套执行打算对数据定义、计算逻辑定义是完全一致的。这个架构能帮忙咱们达到“开发即上线”的终极目标。数据科学家实现离线特色开发后，只需一行 deploy 命令，就能间接把计算逻辑从离线批处理的引擎切换到线上实时引擎。再去把这个实时数据接入，就能实现离线开发到上线的流程。这样做不再须要工程化团队的染指，也不须要两个团队两套设施的对齐沟通，不再须要重复的一致性校验，所以能大大降低 AI 工程化落地的老本。OpenMLDB 参加的开发上线全流程
具体流程如上图。step 1：在离线开发模式，数据科学家导入离线数据用于特色摸索开发（留神：OpenMLDB 离线引擎反对硬拷贝和软拷贝。在软拷贝模式下只须要给出 HDFS 门路，不做理论的数据拷贝）step 2：应用 OpenMLDB 提供的基于 Spark 改良的离线引擎在 HDFS 文件上做离线特色抽取，在这个阶段内数据科学家还会和模型训练交互，一直对特色抽取脚本进行调优。step 3：调试特色脚本至称心状态就能够把 SQL 上线，同时这也意味着计算逻辑上线。step 4：此时，切换 OpenMLDB 到在线模式。筹备冷启动须要的数据，比方特色抽取逻辑须要过来三个月的工夫窗口数据，那咱们须要把从上线工夫点开始倒退三个月前的所有数据导入。step 5：筹备实时数据接入，随着事实工夫的推移，最近三个月的窗口数据是一直变动的，数据窗口在一直前移，所以须要把实时数据接入。这里能够通过 OpenMLDB 提供的 SDK 去写入，也能够通过咱们这个提供的 connectors，像 Kafka Connector，Pulsar Connector，RocketMQ Connector 等把实时数据间接入。step 6：接下来就能够进入实时特色计算，用户发送实时申请，OpenMLDB 会基于最新的窗口数据，进行特色计算，并返回后果。在线上引擎中，OpenMLDB 有一个真正数据存储引擎，同时咱们反对 TTL（一个数据过期的概念）。如果咱们须要三个月的数据，那么当数据库中的存储大于三个月会主动淘汰过期的数据。基于计算逻辑加数据呢，咱们的实时特色服务就曾经筹备好了。OpenMLDB 此时能够服务线上的实时申请，并把实时特色送出去提供给前面的模型推理。OpenMLDB 外围问题与外围个性
总结上述内容，OpenMLDB 解决了线上线下特色计算不统一的外围问题，提供了毫秒级实时特色计算的外围个性。OpenMLDB 利用场景和应用形式
因为咱们发现在社区当中存在很多不同的应用形式，所以在这里为大家列举展现一下 OpenMLDB 的应用形式。咱们最举荐的应用形式当然是方才演示的从离线开发到实时上线的残缺流程？这样能保障线上线下一致性。不过取决于场景需要，社区里也有许多不同的应用形式，能够给大家提供参考。比方某些用户已有离线特色脚本了，但之前应用的在线引擎达不到性能需求，所以只用了 OpenMLDB 的在线引擎。同理，也存在一些用户不须要去做线上的实时预估只须要跑批，就能够独自应用 OpenMLDB 的离线局部。明天咱们看到在开源社区中这三种形式都有呈现。再为大家简略介绍一下产品个性吧。OpenMLDB 产品个性一：线上线下一致性执行引擎
第一个是线上线下一致性执行引擎能够人造保障线上线下的一致性，这点咱们不反复介绍了。OpenMLDB 产品个性二：高性能在线特色计算引擎
第二个重要个性是咱们这个高性能在线特色计算引擎。图中展现了咱们实时引擎的次要模块，这里想传播的次要信息是 OpenMLDB 是一个分布式、高性能、可扩大、高可用的架构。在设计中咱们用 Zookeeper 治理原数据，用 Nameserver 保障 Tablet 的治理和故障的转移。而 Tablets 是咱们整个数据库存储和执行的最小单位，其中蕴含了贮存引擎和执行引擎。OpenMLDB 的存储引擎是默认应用基于内存的存储模式，以此保障线上服务的高性能。当然咱们也有设置 Binlog 机制和备份机制，爱护数据，帮忙长久化。基于内存的存储模式带来高性能的同时也会带来比拟高的老本，所以咱们也为对性能要求不敏感的用户提供了老本更低的磁盘存储模式。
在实时特色计算引擎中，咱们最外围的优化是双层跳表构造和预聚合技术。其中最显著的优化是 OpenMLDB 外部应用了双层跳表构造。双层跳表构造能够帮忙咱们疾速地找到相应数据给，保障线上计算的高性能。另外一个外围优化技术是预聚合技术。简略来说是针对数据量微小的窗口，咱们会提前计算局部后果，便于在实时计算时升高提早。左侧条形图是 OpenMLDB 与两个内存型商业数据库的性能比照图，能够看到在时序特色继续抽取的 workload 下 OpenMLDB 还是有比拟显著的劣势。左侧折线图是咱们应用预聚合技术后的性能晋升体现，当窗口的数据量级达到几百万时，预聚合技术能够使提早从秒级降至十毫秒以内。性能测试报告：https://openmldb.feishu.cn/wi… 产品个性三：面向特色计算的优化的离线计算引擎
第三个个性和离线引擎无关。首先，咱们在 Spark 的根底上做了语法的扩大。其次，OpenMLDB 把一些执行打算也做了优化批改。而后最终咱们达成的这个目标也是为了让这个 Spark 可能更不便的去做特色计算，而且能达到一个更高的一个效率。OpenMLDB 产品个性四：针对特色工程的 SQL 扩大
第四个个性是 OpenMLDB 针对特色工程做了 SQL 的扩大——Last Join 和 Window Union。Last Join 语法可能在左表匹配到右表多条记录时只取其中一条，个别是会取最新的一条。这种状况通常是右表为某物体不断更新的信息状态，咱们只须要最新的状态过去做拼表，做最初的特色计算，这种场景其实在机器学习中十分常见。如果 Last Join 是一个简略的拼表，那 Window Union 其实就是一个绝对简单的拼表。Window Union 的设计针对另一种机器学习常见场景。在咱们的事实利用中数据个别会呈现在多表外面。Window Union 不是简略的取一条数据过去拼表，而是通过左表信息找到右表的对应记录而后再用。如果咱们应用规范的 SQL 去实现上述要求也可能写进去，但会写的相当简单，执行效率也对应降落。OpenMLDB 产品个性五：企业级个性反对
第五个个性是 OpenMLDB 提供企业级的个性反对，包含高可用、扩缩容、平滑降级、企业级监控以及双机房保障。当初咱们也在开发多租户还有云原生等企业级个性。OpenMLDB 产品个性六：以 SQL 为外围的开发治理体验
最初的个性让咱们用一个 OpenMLDB CLI 界面展现。如果应用过 MySQL，你必定会对 CLI 有印象。OpenMLDB 作为一个数据库产品，也提供了一个相似的 CLI，用户能够在这里十分不便地实现整套流程，实现离线开发。OpenMLDB 上下游生态
作为一个开源软件，开源生态建设也必不可少。OpenMLDB 也在上下游生态方面做了不少致力。上游的数据生态局部，因为在生产环境的应用状况，咱们更专一在线数据的生态单干。对接 Kafka、Pulsar、RocketMQ，咱们都有开发相应的 Connector。在离线局部，OpenMLDB 目前次要读取 HDFS 上的数据，咱们也在打算对接 Hive、Cassandra，争取能做到把这两个工具中的离线数据间接导入。上游的模型局部，OpenMLDB 还是 松耦合 的实现形式。因为咱们输入的格局比拟规范，上游模型能够间接读取应用。在生产这一模块，OpenMLDB 也和 Airflow、DolphinScheduler、Bzyer 做了紧耦合，可能间接在上述工具中调用 OpenMLDB 的算子。在监控这一模块，OpenMLDB 也和 Prometheus 做了对接。OpenMLDB 利用案例
在特色介绍后，让咱们用一个客户案例帮大家更具体地理解 OpenMLDB 的利用。Akulaku 是 OpenMLDB 第一个深度应用企业用户，是一家出海东南亚的线上金融公司。在 Akulaku 的利用中 OpenMLDB 的应用场景也大部分是和金融无关。在图上的架构中，线上局部的设计中 OpenMLDB 被搁置在模型计算层，在离线局部 OpenMLDB 位于特色计算层，通过这样的架构保障了线上线下特色计算的一致性并且实现了线上服务。
Akulaku 的利用场景和需解决的痛点与 OpenMLDB 十分匹配。Akulaku 的线上部署须要达到低提早并发并且高时效性的要求，须要尽可能陈腐数据来反映实时的变更。线下剖析也须要满足高吞吐的需要，同时要保障线上线下的逻辑完全一致。应用 OpenMLDB 后，在一天内须要解决大略 10 亿 条订单数据的 Akulaku，可能将窗口计算提早大大降低，达到 4 毫秒 的级别。History & RoadmapHistoryOpenMLDB 倒退历程
接下来的工夫咱们会简略介绍 OpenMLDB 目前的倒退状态和将来的布局。开源至今，OpenMLDB 曾经经验了一年多工夫的迭代，从 0.1.0 降级到了 0.6.0，第七个版本预计会在往年 11 月或者 12 月和大家见面。在成长的过程中，咱们收到了十分多来自社区小伙伴的反馈，也吸引了一批用户的应用。Akulaku、京东科技、华为、37 手游的同学都有深刻参加到 OpenMLDB 的成长中，非常感谢合作伙伴带给咱们社区的倡议及反馈。OpenMLDB 近期优化
过来一个月中，OpenMLDB 次要公布了一个大版本、两个小版本。其实咱们做了两件十分重要的事件。第一是是咱们引入了一个数据库状态智能诊断工具以及一个自动化的 log 收集工具。在社区的探讨交换中咱们发现 OpenMLDB 的状态诊断以及 log 解析存在有余，常常会消耗大量人力去排查集群状态。所以咱们在 0.6.0 版本里引入了智能诊断工具。心愿在存在问题是能为社区用户提供初始信息、调整倡议，甚至是间接解决。第二是实现了 OpenMLDB 和 Airflow 的整合。大家能够在十分风行的编排工具 Airflow 中间接调用咱们的 OpenMLDB 算子。另外，咱们也做了 SQL 的语法加强。提供了更多预先决策的性能，反对 EXCLUDE CURRENT_ROW。在 0.6.1 版本中，咱们次要是做了一些修复，进一步晋升了离线引擎的性能和稳定性，减少了 Oneflow 的整合案例。在上周公布的 0.6.2 版本中，OpenMLDB 可能反对离线引擎的独立运行，对这个日志输出格局做了优化，缩小一些意义不大的有效信息呈现。OpenMLDB v0.7 Roadmap
现状咱们曾经在布局 0.7.0 版本的过程中了，目前大抵拟定了三个方向。第一，加强 OpenMLDB 的 SQL 能力，特地是加强预聚合能力。因为咱们看到局部用户的特色抽取语法逻辑非常复杂，所以尽管咱们提供了 UDF 反对，然而接下来仍然会在 SQL 的原生能力下来做加强。第二个重要方向是，咱们会 晋升 OpenMLDB 的稳定性。比方咱们可能会通过一些伎俩实现内存资源的隔离。以前造成 OpenMLDB 不稳固的最大的问题是内存耗费适度，而用户没有感知。一旦适度耗费，就可能会被 OS 给杀掉。所以在下一个版本中，咱们会打算引入内存资源隔离的伎俩来防止服务的齐全中断。第三，在 易用性上做更多优化。之前会有社区用户埋怨运维命令过于简单。针对这些声音，咱们会对运维命令做一些简化优化。OpenMLDB 0.7.0 版本也会尝试在阿里云市场提供一个开箱即用的服务。欢送大家继续关注。OpenMLDB 欢送你的退出
明天的介绍到这里就完结了。最初也十分欢送大家退出 OpenMLDB 社区，能够扫描二维码入群理解更多相干内容或和咱们做深刻交换。相干链接✦OpenMLDB 官网 https://openmldb.ai/OpenMLDB github 主页 https://github.com/4paradigm/… 微信交换群