关于机器学习:实时特征计算平台架构方法论和基于-OpenMLDB-的实践

实时特色计算平台架构方法论和基于 OpenMLDB 的实际

导读：在机器学习从开发到上线的闭环中，实时特色计算是其中的重要一环，用于实现数据的实时特色加工。因为其高时效性需要，数据科学家实现特色脚本离线开发当前，往往还须要工程化团队通过大量的优化能力实现上线。另一方面，因为存在离线开发和工程化上线两个流程，线上线下计算一致性验证成为一个必要步骤，并且会消耗大量的工夫和人力。本文将从以上两个痛点登程，形容实时特色计算零碎架构的优化指标 – 开发即上线，以及针对此优化指标的架构设计准则。最初，将会基于开源实时特色计算解决方案 OpenMLDB，具体形容其在实践中的架构设计和优化。

1. 背景介绍

1.1 机器学习闭环

明天，机器学习利用曾经在各行各业积攒了宽泛的利用落地案例。演绎来说，机器学习从开发到上线的全生命周期闭环能够用如下图（Figure-1）概括性形容。

Figure-1: 机器学习闭环

从 Figure-1 能够看到，从横向维度，机器学习全流程被划分成离线开发和线上服务两个相辅相成的流程。从纵向维度，信息价值承载的模式会经验从数据、特色、再到模型的转换过程。

• 数据：原始的数据信息，比方交易的流水信息，蕴含金额、工夫、商户名称等。
• 特色：基于原始数据所生产计算的进一步表达能力更为丰盛的信息，有利于产出后续品质更高的模型，比方某客户在过来三个月内的生产均匀金额等特色。本文即针对特色计算的工程化问题进行具体展开讨论。
• 模型：通过隐含的上万甚至上亿条基于特色生成的数据规定，从超高维度上来形容数据实质的法则，蕴含了基于数据预测行为的能力。

明天，对于数据和模型曾经有充沛的探讨和事实上的工业界规范解决形式。然而对于特色，明天工业界还并没有造成对立的方法论和解决工具。次要因为在人工智能开始利用落地的初期，大量关注都在基于深度学习的感知类利用上，此类利用的特色工程流程绝对规范。然而明天，决策类场景（如风控、个性化举荐等）在大量企业级利用落地。对于决策类场景，特色工程的解决逻辑绝对灵便和简单，因而在这一块目前尚未造成标准化的方法论和工具。这也正是本文所要聚焦的畛域，通过从方法论和架构优化指标的论述，让大家深刻理解实时特色计算零碎及其典型应用流程。

1.2 实时特色计算

本文次要关注具备十分强时效性的实时特色计算，其查问计算的端到端提早个别设定在几十毫秒的量级。实时特色的常见计算模式，是当事件产生时，基于从以后工夫点往前推移的一个工夫点，造成一个工夫窗口，进行窗口内的相干聚合计算。如下图 Figure-2 列举了一个典型的风控畛域的实时特色计算场景，其产生了十天、一个小时、五分钟三个工夫窗口，基于窗口进行了不同的聚合计算。

Figure-2: 风控畛域的典型实时特色计算举例

实时特色计算明天曾经在越来越多的场景中体现出其重要性，其本质在于抓住最新时间段内的数据特色，为疾速决策提供无力撑持。本文次要针对实时特色计算，来进行相干设计理念和架构的论述。

2. 架构设计方法论

2.1. 事实痛点：两套开发流程和线上线下计算一致性校验

明天，在没有一套适合的方法论和工具链的状况下，如果须要开发上线一套实时特色计算逻辑，咱们看到其蕴含三个步骤，即离线特色脚本开发、在线特色代码重构、以及线上线下计算逻辑一致性校验。其三者的关系如下图 Figure-3 所示。

Figure-3: 在短少适合的工具状况下的实时特色计算从开发到上线全流程

这三个步骤次要实现的工作以及参与者见如下表格 Table-1。从 Table-1 中能够看到几个要害信息：

• 因为数据科学家个别习惯应用 Python 等数据分析工具进行特色脚本开发，其开发的模型个别无奈合乎实时特色计算的上线需要，如低提早、高吞吐、高可用等性能和运维指标均无奈满足。
• 因为数据科学家和工程化团队两个团队、两条工具链、两套零碎的开发，因而两套零碎之间的计算一致性校验就变得必不可少而且十分重要。
• 依据大量工程化落地案例，一致性校验因为须要牵涉到团队沟通、需要对齐、重复测试确认等，其破费的人力老本往往是三个步骤两头最高的。

Table 1: 在短少适合工具状况下的实时特色计算从开发到上线的次要步骤

造成线上线下计算逻辑不统一的起因有很多种，比方：

• 工具能力不对等。明天 Python 是大部分数据科学家的首选工具；相同，工程化团队个别会首先尝试应用一些高性能数据库去翻译 Python 脚本。因而两个工具在表达能力上并不对等。当 SQL 的表达能力无奈满足需要时，就可能会呈现计算逻辑上的斗争或者应用 C/C++ 等高性能编程语言去补充相干能力。
• 需要沟通的认知差。数据科学家以及工程化团队对于数据的定义和解决形式的认知可能会不统一。美国的一家线上银行 Varo Bank 形容了一个他们在没有适合工具状况下，实时特色上线时碰到的一个不统一场景（具体能够参照他们工程化团队的博客 Feature Store: Challenges and Considerations）。在上线环境中，工程化团队很天然的认为“账户余额”的定义应该就是实时的账户里的余额；然而对于数据科学家来说，通过离线的数据去构建“实时账户余额”其实是一件相当简单的事件，因而数据科学家应用了一个更加简略的定义，即昨天完结的时候的账户的余额。很显著，两者对于账户余额的认知差，间接造成了线上线下计算逻辑的不一致性。

线上线下计算逻辑一致性校验的必要性，以及所须要破费的微小人力老本，使咱们有必要从新扫视特色计算从开发到上线的全流程。须要一套更为正当的生命周期方法论，以及相应的架构设计，来高效撑持明天急速增长的机器学习落地场景数量和规模。

2.2. 优化指标：开发即上线

咱们曾经意识到，线上线下计算一致性校验是整个零碎实现和施行的瓶颈。那么现实中，如果须要改良整体流程，咱们冀望有一套开发即上线的高效流程。其如下图 Figure-4 所示。在此套优化过的流程中，数据科学家的脚本能够即刻部署上线，而不须要再通过二次代码重构，也不须要额定的线上线下一致性校验。如果基于此流程的方法论能够实现，将会极大地提高实时特色从开发到上线的整体流程，其人力老本也将会从过来的一共 8 人月大幅缩短到 1 人月。

Figure-4: 实时特色计算开发周期的优化指标：开发即上线流程

3. 架构设计实际

3.1. 开发即上线的需要挑战

如果为了达到开发即上线的优化指标，同时须要保障实时计算的高性能，能够总结出如下技术挑战：

• 挑战一：在线实时特色计算的性能要求。如果咱们冀望优化后的流程中（Figure-4），数据科学家的脚本能够间接上线，那么咱们必须要十分小心的解决好在线计算的一些列工程化问题。其最次要的需要是满足低提早、高并发的实时计算需要；此外，如可靠性、可扩展性、灾备、运维等问题亦是在企业生产环境中理论落地须要特地关注的个性。很显然，如果仅仅依附数据科学家应用 Python 写的特色计算脚本来间接上线，是不能满足这些条件的。
• 挑战二：线上线下对立的编程接口。为了升高整体开发到上线老本，咱们冀望在对外用户的视角来看，整个零碎须要一个对立的对外编程接口，而不是如 Table-1 中所示，对外裸露了两套不同的编程接口。
• 挑战三：线上线下计算一致性保障。咱们的优化指标是不再须要额定的高老本的线上线下一致性校验。那么，如何在零碎外部保障好线上线下的计算一致性，是必须要解决的问题。

3.2. 形象架构

Figure-5: 开发即上线的实时特色平台的形象架构

为了解决在章节 3.1 里提到的三个技术挑战，咱们构建出了如上 Figure-5 的形象架构。能够看到，在这个形象架构图里有三大模块，别离对应去解决咱们所面临的的技术挑战。以下表格列出了模块的性能要点以及所解决的章节 3.1 里形容的挑战。

Table-2: 实时特色计算平台架构的外围模块和性能

3.3. OpenMLDB 的架构设计实际

基于如上剖析的 Figure-5 的形象架构，以及 Table-2 所列举的外围模块性能，咱们在此介绍一下 OpenMLDB 的架构实际。OpenMLDB (https://github.com/4paradigm/…) 是一款开源机器学习数据库，次要面向特色计算场景构建高效解决方案。OpenMLDB 的架构设计上秉承了 Figure-5 所列的形象架构，通过基于现有开源软件优化或者自研，来具体实现具体的性能。其具象化当前的架构如下图 Figure-6 所示。

Figure-6: OpenMLDB 整体架构

从架构图 Figure-6 上能够看到，OpenMLDB 有几个要害模块，阐明如下：

• SQL(+)：OpenMLDB 对外裸露 SQL 作为对立的应用接口。因为规范 SQL 并没有对特色计算相干的操作做优化（如时序窗口相干操作），因而其在规范 SQL 的根底上做了性能扩大，反对了更多对于特色计算敌对的语法性能。
• 一致性执行打算生成器：这是保障线上线下计算逻辑一致性的外围模块。外面次要蕴含了 SQL 语法树解析以及基于 LLVM 的执行打算生成模块。其中，对立的执行打算生成模块，对于给定的 SQL，能够翻译成针对线上和线下别离优化的不同的执行打算，然而同时保障两者的计算一致性。
• 分布式批处理 SQL 引擎 Spark(+)：对于面向离线开发的批处理 SQL 引擎，OpenMLDB 基于 Spark 进行了源代码级别的二次优化开发，高效反对 SQL 中对于特色计算的扩大语法。留神，因为批处理引擎本质上并没有任何数据的存储需要，所以这里在逻辑上并不蕴含一个专用的存储引擎，只需从离线数据源下来读取数据进行计算即可。
• 分布式时序数据库：外围的实时计算性能次要由存储引擎和实时 SQL 引擎这两个外围模块承载，独特组成了一个分布式的高性能时序数据库。其中，SQL 引擎为开发团队自研的基于 C++ 编写的高性能内核；数据存储引擎次要为了存储特色计算所须要的最新的窗口数据（即 Figure-2 中的物料数据）。留神，此处的时序数据库会有一个数据生存周期的概念（TTL, Time-To-Live），假如咱们的特色计算逻辑只须要最近三个月的数据，那么超过三个月的旧数据会主动被分明。存储引擎有两种抉择：开发团队自研的内存存储引擎（built-in）：OpenMLDB 为了优化在线解决的提早和吞吐，默认采纳了基于内存的存储计划，构建了双层跳表（double-layered skip list）的索引构造。此种数据结构特地适宜疾速找到某个 key 上面的一个依照工夫戳排序的数据。此种纯内存的索引构造在查找提早上能够达到亚毫秒级别。
• 基于 RocksDB 的外存存储引擎：如果用户对于性能不太敏感，然而心愿升高内存应用老本，用户亦能够抉择基于 RocksDB 的外存存储引擎。

通过以上外围组件的串联，OpenMLDB 能够实现开发即上线的最终优化指标。以下图 Figure-7 总结了 OpenMLDB 从离线开发到部署上线的整体应用流程。对照 Figure-4 所对应的优化流程指标，咱们能够发现，通过 OpenMLDB，从特色开发到上线，很好的践行了开发即上线的核心思想。

Figure-7: OpenMLDB 应用流程

对于 OpenMLDB 的详细信息能够参考以下内容

• 官网：OpenMLDB – 生产级特色开发全栈解决方案
• GitHub:GitHub – 4paradigm/OpenMLDB: OpenMLDB is an open-source machine learning database that provides a feature platform enabling consistent features for training and inference.
• Docs: https://openmldb.ai/docs/zh/

4. 总结

本文总结了构建实时特色计算平台所面临的工程化挑战，以及工业界所冀望的从离线开发到上线的优化指标。基于指标，咱们开展形容了架构设计的方法论和准则。最初咱们介绍了从优化指标登程，基于设计方法论实际的开源解决方案 OpenMLDB 的整体架构。

5. 对于作者

卢冕，博士毕业于香港科技大学计算机系；现为 OpenMLDB 社区 PMC core member；就任于第四范式，是数据库团队以及高性能计算团队的 Tech Lead。