OpenMLDB研发负责人、第四届范式系统架构师：开源机器学习数据库OpenMLDB：线上线下一致的生产级特征平台AISummit全球人工智能技术大会如期举行。会上，负责OpenMLDB研发的第四范式系统架构师卢冕带来了主题演讲《开源机器学习数据库OpenMLDB：线上线下一致的生产级特征平台》，从人工智能工程实现的数据和特征挑战，OpenMLDB线上线下一致的生产级特征计算平台，OpenMLDBv0.5：性能、成本、易用性增强，共享三个方面。演讲内容整理如下，希望对大家有所启发。人工智能工程实施中的数据和特征挑战今天，据统计，人工智能实施过程中95%的时间花在了数据上。虽然市面上有MySQL等各种数据工具，但远没有解决人工智能落地的问题。所以，首先，让我们了解数据问题。如果你参与过一些机器学习的应用开发，应该对MLOps印象比较深刻，如下图所示：事实上，目前对于MLOps并没有严格的学术定义，可以分为两个过程：离线开发和在线服务为一体。.每个过程中的信息载体，从数据、特征到模型，从线下开发流程到线上服务流程，都会经历三个不同的载体。接下来，我们重点关注中间特征过程的部分，了解如何解决我们面临的挑战。应用背景：基于时序数据的特征工程人工智能在决策场景的发展现在主要分为两类应用，一类是感知类的，比如熟悉的人脸识别，都是感知类的AI应用，基本上基于DNN算法进行。另一个是决策AI场景，比如淘宝购物的个性化推荐。此外，还有一些AI广泛应用于决策的应用场景，如风控场景、反欺诈场景等。所以我们现在说的应用背景，主要是针对这种决策场景。最大的特点是它的数据是二维表中的结构化数据，同时也是时间序列数据。如下图，用户的交易表上有一个“trans_time”，代表每条记录发生的时间点，连接的是一个时序数据。基于时间序列数据的特征工程最常见的处理方法是基于时间窗口的聚合函数。比如一个用户一天的总交易额等，这是特征工程在决策场景中的常见操作。业务场景：满足生产级上线需求的实时推荐系统那么为什么要用OpenMLDB呢？一个很大的背景就是要用真正的硬实时计算来满足AI的需求。什么是硬实时计算？它有两层意思，一是用最新鲜的实时数据来达到最大的决策商业效果。比如利用用户在过去10秒或1分钟内的点击行为来做决策业务，而不是过去一年或前一年的数据。另外很重要的一点是，对于实时计算来说，一旦用户发出行为请求，需要在短时间内甚至毫秒级进行特征计算。目前市场上有很多批计算/流计算产品，但还没有达到毫秒级的硬实时计算要求。例如，如下图所示，搭建一个满足生产级上线需求的实时推荐系统。用户小李搜索关键字“洗衣机”。结合进行实时的特征计算，然后生成一些更有意义的特征，即所谓的特征工程，生成特征的过程。例如，系统会生成“过去三个月某个年龄段顾客购买的前三名最畅销洗衣机”。这类特征不需要很强的时效性，是根据很长的历史数据计算出来的。但是系统也可能需要一些时间敏感的数据，比如“过去一小时/半小时内的浏览记录”等，系统得到新计算的特征后，会给模型推理。这样的系统特征平台主要有两个要求，一个是正确性，即在线和离线特征计算的一致性；二是高效率，即实时特征计算，时延<20ms。从特征计算开发到上线的全生命周期。在没有OpenMLDB方法论之前，大家主要是通过下图所示的流程进行特征计算开发。首先要做一个场景。数据科学家将使用Python/SparkSQL工具进行离线特征提取。数据科学家的KPI是做出一个模型，满足业务要求的准确性。当模型质量达标时，任务完成。特征脚本上线后面临的低延迟、高并发、高可用等工程挑战，不在科学家的管辖范围之内。为了让数据科学家编写的Python脚本上线，工程团队需要介入。他们要做的就是重构和优化数据科学家制作的离线脚本，使用C++/Database进行实时特征提取服务。这满足了低延迟、高并发、高可用等一系列工程需求，让特性脚本真正上线，实现在线服务。这个过程非常昂贵，需要两个技能组使用不同的工具进行干预。两套流程下来后，需要做计算逻辑的一致性检查，即数据科学家开发的特征脚本的计算逻辑必须和最终实时特征的逻辑完全一致提取和发射。这个需求看似简单明了，但是在一致性验证过程中会引入大量的沟通成本、测试成本、迭代开发成本。根据以往的经验，项目越大，一致性验证的时间就越长，成本会非常高。一般来说，一致性验证过程中线上线下不一致的主要原因是开发工具的不一致。例如，科学家使用Python，工程团队使用数据库。工具功能的差异可能会导致功能妥协和不一致。;在数据的定义、算法的定义和认知上也存在差距。总而言之，基于传统两套流程的开发成本非常高，需要两套不同技能站位的开发人员，两套系统的开发和运行，以及在流程中加入堆栈验证和验证。中间。并且OpenMLDB提供了一个低成本的开源解决方案。OpenMLDB：线上线下一致的生产级特征计算平台。去年6月，OpenMLDB正式开源。它是开源社区的一个年轻项目，但已经应用在100多个场景，覆盖300多个节点。OpenMLDB是一个开源的机器学习数据库，主要功能是提供一个线上线下一致的特征平台。那么OpenMLDB是如何满足高性能和正确性的需求呢？如上图所示，首先OpenMLDB唯一使用的编程语言是SQL。不再有两套工具链。数据科学家和开发人员都使用SQL来表达特征。其次，OpenMLDB中有两套引擎，一套是“批处理SQL引擎”，基于Spark++在源代码层面进行了优化，提供了更高性能的计算方式，并做了语法扩展；另一个是“Real-timeSQLengine”，这套是我们团队开发的资源时序数据库，默认是基于内存存储引擎的时序数据库。基于“实时SQL引擎”，实现在线高效的毫秒级实时计算，同时保证高可用、低延迟、高并发。这两个引擎之间还有一个重要的“一致性执行计划生成器”来保证线上线下执行计划逻辑的一致性。有了它，无需人工校对，自然就能保证线上线下的一致性。总而言之，基于该架构，我们的最终目标是实现“开发在线”的优化目标，主要包括三个步骤：离线SQL特征脚本开发；一键部署上线；访问实时请求数据流。可以看出，与前面两套流程、两套工具链、两套开发者投入相比，这套引擎最大的优势在于节省了大量的工程成本，即只要由于数据科学家使用SQL开发特征脚本，不需要工程团队做二轮优化，然后就可以直接上线，不再需要中间的线上线下一致性验证的人工操作，这节省了大量的时间和成本。下图展示了OpenMLDB从离线开发到在线服务的完整流程：总体来说，OpenMLDB解决了一个核心问题——机器学习在线离线一致性；提供了一个核心特性——毫秒级的实时特征计算。这两点是OpenMLDB提供的核心价值。因为OpenMLDB有在线和离线两套引擎，所以应用方式也不同。下图展示了我们的推荐方法，供参考：接下来介绍一下OpenMLDB中的一些核心组件或特性：特性1，线上线下一致的执行引擎，基于统一的底层计算功能，从逻辑计划到物理计划的线上线下执行方式自适应调整，线上线下一致性自然得到保障。Feature2，高性能在线特征计算引擎，包含高性能双层跳表内存索引数据结构；实时计算+预聚合技术的混合优化策略；提供内存和磁盘两种存储引擎，以满足不同的性能和成本需求。Feature3，针对特征计算优化的离线计算引擎，包括多窗口并行计算优化；数据倾斜计算优化；SQL语法扩展；针对特征计算优化的Spark分布等，这些都比社区版有很大的性能提升。Feature4，特征工程的SQL扩展。之前提到我们使用SQL来进行特征定义，但实际上SQL并不是为特征计算而设计的，所以在研究了大量的案例，积累了经验之后，发现有必要对SQL语法做一些扩展来实现让它更好地处理特征计算。场景。这里有两个重要的扩展，一个是LASTJOIN，一个是比较常用的WINDOWUNION，如下图：Feature5，企业级特性支持。OpenMLDB作为分布式数据库，具有高可用、无缝扩缩容、平滑升级等特点，在众多企业案例中得到应用。特性六，以SQL为中心的开发和管理，OpenMLDB也是一种数据库管理，类似于传统数据库，比如如果提供一个CLI，那么OpenMLDB可以在整个CLI中实现一套完整的流程，从离线特性计算到SQL方案从线上到线上请求等，可以提供基于SQL和CLI的全流程开发体验。此外，OpenMLDB目前是开源的。其上下游生态的扩展如下图所示：OpenMLDBv0.5.0：性能、成本和易用性的提升接下来介绍新版本的OpenMLDBv0.5。进行了一些改进。首先看一下OpenMLDB的发展历史。2021年6月，OpenMLDB将开源。其实在这之前它已经有很多客户了，从2017年开始开发第一行代码，已经有四五年的技术积累了。开源一周年，我们大概迭代了五个版本。与之前的版本相比，v0.5.0有以下显着特点：性能升级，聚合技术可以显着提升长窗口性能。无论长窗口查询下的延迟或吞吐量如何，预聚合优化都会将性能提高两个数量级。降低成本。从v0.5.0版本开始，在线引擎提供了基于内存和外存两种引擎选择。基于内存，低延迟，高并发；高使用成本提供毫秒级延迟响应。基于外存，对性能不太敏感；低成本使用在典型的基于SSD的配置下可以降低75%的成本。两个引擎的上层业务代码无感知，零成本切换。增强的可用性。我们在v0.5.0版本引入了用户自定义函数（UDF），也就是说如果SQL不能满足你的特征提取逻辑表达式，支持用户自定义函数，比如C/C++UDF，UDF动态注册等。方便用户扩展计算逻辑，提高应用覆盖率。最后，我要感谢所有OpenMLDB开发人员。自开源以来，已有近100名贡献者在我们的社区做出了代码贡献。同时，我们也欢迎更多的开发者加入社区，贡献自己的力量。一起工作更有意义。大会演讲回放和PPT已上线，精彩内容请前往官网查看。
