OpenMLDB Meetup #1 会议纪要 - OpenMLDB - 生产级特征开发全栈解决方案

1. 会议内容

OpenMLDB 社区于 2022 年 1 月 15 日举行了第一次面向整个社区的 meetup，不仅由 OpenMLDB 的核心开发团队分享了整体架构以及 v0.4.0 的新特性演示，而且邀请到了 OpenMLDB 的企业客户 - Akulaku 来分享基于 OpenMLDB 的实时特征计算实战场景。

会议主要日程及相关材料如下：

Opening 郑曌 | 第四范式研发副总裁、OpenMLDB项目发起人视频，PPT
开源机器学习数据库 OpenMLDB：提供企业级 FeatureOps 全栈解决方案 卢冕 | 第四范式资深架构师、OpenMLDB 研发负责人视频，PPT
OpenMLDB 在 Akulaku 实时特征计算场景的应用案例 马宇翔 | Akulaku 算法总监视频，PPT
基于 OpenMLDB 0.4.0版本快速搭建全流程线上AI应用 陈迪豪 | 第四范式架构师、OpenMLDB核心研发视频，PPT

2. 讨论交流

会议中，几位嘉宾和社区进行了充分交流，对会议期间交流的问题做如下汇总。

2.1 关于“开源机器学习数据库 OpenMLDB：提供企业级 FeatureOps 全栈解决方案” 的相关问题

Q1：OpenMLDB 和 Feast 相比，有什么优缺点？

A：Feast 关注于 Feature Store 的概念，为线下训练和线上推理提供统一的特征存取服务。但是它的特征是要求已经提前计算好的，无法支持实时的特征计算。OpenMLDB 除了支持特征存取，也同时支持一致性的离线和在线实时特征计算，功能覆盖上会比 Feast 更多一些。

Q2: OpenMLDB 中特征工程数据的一致性是如何保证的？

A：我们底层有一套统一的执行引擎，对于输入的 SQL，会分别去生成对应 SparkSQL 和自研线上时序数据库的执行计划，内部去保证生成的逻辑是一致的，同时又会对线上线下不一样的使用场景和性能要求进行分别优化，具体内部细节可以关注我们最近正在准备的一个blog。

Q3：OpenMLDB 中的数据质量是怎么保证的？

A：在 MLOps 中，数据质量的保证大部分需要依赖 DataOps 的功能，因此这一部分的完整功能并没有包含在 OpenMLDB 的产品边界内。当然，OpenMLDB 本身对于质量较差的数据（比如丢失 label，或者数据不全等），提供了一些统一的处理方式，比如作为 0 或者不参与计算等。

Q4：OpenMLDB 和 SQLFlow 的区别在哪里？

A：SQLFlow 是通过扩展 SQL 去做模型训练和推理，但是 OpenMLDB 的定位是用 SQL 去做高效一致性的特征工程，两者的定位不太一样。

Q5：关于一致性执行引擎，是怎么做到的逻辑计划和物理计划执行的是一致的？举例：一个SQL怎么保证 Spark 的执行和自研的引擎执行是一致的？

A：参照 Q2。

Q6：线上推理对时延敏感，业界普遍使用 Redis 等，这点和线下区别很大，线上线下使用统一 SQL 查询的话，内部是如何保证执行效率的，具体效果怎么样？

A：我们线上和线下两块的计算和存储引擎其实是完全分开的，当然在一致性上是保证的。就像您说的，线上推理对于延迟相当敏感，因此我们的线上引擎是使用完全自研的高性能内存时序数据库引擎，基于双层跳表的数据结构，可以非常好的支持基于时序的特征计算。具体在实际业务中可以在高并发情况下达到大概 20 毫秒左右量级的延迟效果，当然这个延迟和实际场景也有很大关系，会有一定的变化。

Q7：One-hot 编码、特征归一化等操作是如何处理的？

A：目前，one-hot encoding 这一块的功能暂时没有包含在 OpenMLDB 内部。在第四范式的商业平台上，这一块是由另外一个独立的模块完成的，并且根据运行中配置，来保障线上线下一致性。我们接下去的版本会计划把这一部分功能也包含进来，更加完整的囊括特征工程相关功能。

Q8：请问 OpenMLDB 有没有做特征值的版本管理，比如线上发现一个版本的特征有问题，是否可以快速回退版本？还是快速向前演进修正？

A：目前 OpenMLDB 还没有支持特征版本的管理，我们会规划相关 features，敬请期待。

Q9：请问 OpenMLDB 有没有安全性方面的考虑

A：目前 OpenMLDB 在安全性上主要以不产生生产性事故，保证业务正常运行为主。关于安全性的一些额外考量，将会在未来版本内重点考虑。

Q10：我们目前在线特征计算是借助于 Hazelcast 内存计算引擎，一般计算1天内的特征；离线特征计算使用 PySpark，结果存储到 Redis 中。使用的时候在线服务需要到两个地方取特征做融合，然后调用模型服务。想问一下 OpenMLDB 自己做计算引擎和存储，数据应该是分布式的，那怎么做到有节点宕机，引发的数据再平衡问题，以及计算纠错问题

A：OpenMLDB 的数据是按照分片进行分布式存储的。关于宕机问题，我们有高可用方案，宕机以后会自动尝试拉起节点。目前扩容缩容和 rebalance 是需要用户使用我们提供的工具进行迁移。我们会规划做自动迁移的特性。

2.2 关于“OpenMLDB 在 Akulaku 实时特征计算场景的应用案例” 相关问题

Q11：对 top-k 性能比较感兴趣，请问 OpenMLDB 时延 20ms 是什么意思，查询出当前模型所需特征的时延吗？包含了计算逻辑？请求整体时延是多少？

A：这里的延迟是包含了 top-k 的整体计算逻辑，包括了特征抽取和 ranking。具体时延可以查看我们 slides 上的数值（slide 页标题：OpenMLDB 时间 - RTP 系统案例）。具体时延会和实际的 workload 有一定的关系，会有一定的变化。

Q12：目前我们团队在尝试解决数据指标的问题，在找解决方案。请问风控场景的指标是否都可以用 OpenMLDB 来覆盖？如果不可以，使用上有什么样的指导原则？

A：我们所理解的一些数据指标问题，最常见的计算模式就是画一个固定的窗口，如 24 小时，然后在这个窗口里做一些计算，就是我们关心的指标，如ROI、逾期坏账等都是可以通过 SQL 实现的。

Q13：能进一步解读下降本的主要收益来源？

A：我们的收益主要还是人力成本的下降，机器相对来说不那么敏感，也不是占大头。人力成本会比较贵，另外如果使用 OpenMLDB 有对于业务效果的提效，所能达到的收益更加无法估量。

Q14：你的特征加工都是你自己用算法写的吗，这样不是很耗费人力，这套框架与工具只能用sql开发特征的场景才能实现

A：目前的 OpenMLDB 的定位是让数据库学家写 SQL 脚本来进行使用，在我们公司这边（Akulaku），我们绝大多数的决策类场景的实现都是基于 SQL 开发的，其表达能力是足够覆盖特征抽取的场景的。

Q15：请问，TopK计算是基于什么规模的候选集来进行的，模型在线预测填充的特征量有多少

A：不同场景的数据规模会有所不一样，比如我们的用户风险排序是千万级的，人脸是接近亿级别；关于填充特征量，人脸是一个 512 维的特征量，风险排序的话大概是 100 多维的用户画像，

Q16：请问 OpenMLDB 的时延具体是多少？有不同场景指标数据吗？

A：在 slides 上列出了一些典型场景可以参考（18，19页），在不同场景下，根据任务的复杂程度还是有不一样的性能表现的。

Q17：在服务器上有节省么？硬件效率上有更高节省？

A：我们这边的方案是使用了持久内存的机器，具体节省上目前没有比较过，公司对机器成本目前不如人力成本敏感。

Q18：老师，OpenMLDB 大概覆盖了多少比例的特征服务？怎么处理跟已有的历史负担（过去的特征方法）的过渡问题？

A：我们目前是把新的服务，或者痛点服务迁移到 OpenMLDB，比如团伙挖掘；关于之前的特征系统服务，我们目前会两套系统同时跑，然后逐步的进行切量，直到最后把所有的业务迁移到新的系统上。

2.3 关于“基于 OpenMLDB 0.4.0版本快速搭建全流程线上AI应用” 相关问题

Q20：AI 工作流中没有在线的 serving 部分，请问 OpenMLDB 是如何跟 serving 协同工作的？

A：OpenMLDB 的 AI 工作工作流包含了在线特征计算部分，但不包含模型推理部分，因为用户可以使用自己熟悉的机器学习框架来做模型训练，也可以使用模型支持的预估服务进行模型推理，然后在 serving 服务中可以通过OpenMLDB 提供的 APIServer 或者 SDK 来整合在线的特征抽取计算。

Q21：ARM 其他系列，如 A 系列支持吗？

A：ARM 目前只在带 M1 芯片的 MacBook Pro 机器上进行完整的功能测试，其他 ARM 系列如 A 系列暂未支持。未来我们计划会逐步进行测试和支持。

Q22：这样的顶层架构设计不具备行业通用性，可不可以考虑增加适配层统一离在线业务数据，解决一致性问题，然后再配合自动特征工程，解决自动特征工程本省的性能及资源来设计一个通用行业务框架。

A： OpenMLDB 目前定位是解决机器学习全流程中的数据和特征供给问题，后面我们会通过逐步完善以及和其他上下游生态整合，提供开源的端到端完整的 MLOps 解决方案。我们目前优先开源面向社区的是面向 FeatureOps 的特征工程的能力。后续在技术层面也会和开源数据系统行成更友好的生态连接，相关的自动特征工程也是我们非常重要的一个功能模块，会在近期做开源的规划。

Q23：在面对SQL不能覆盖的特征工程场景，OpenMLDB 如果解决？后续是否考虑支持 PythonSQL？

A：目前可以通过 UDF 或者 built-in functions 开发能力去扩展，长期我们会去尝试兼容 Python SQL 等生态工具

Q24：离线的数据存储还是使用的HDFS吗？

A：离线的数据存储可以支持本地文件存储、NFS、HDFS 以及 S3 等分布式存储，可以使用 HDFS 也不局限于 HDFS。另外我们也在计划离线数据也可以通过其他数据库或者存储系统直接引入，建立相应的 connector。

Q25：请问线上特征工程怎么做呢？比如分桶、onehot、特征交叉都是通过 SQL 吗？

A：目前 OpenMLDB 主要关注于特征抽取部分的计算逻辑。如果有一部分特征工程的功能 SQL 确实不能覆盖，一方面比如你提到的标准功能（签名、分桶等），我们会逐步在 OpenMLDB 中包含起来；其他尚未支持的也可以通过我们的 UDF 功能去自定义开发支持。

Q26：看示例，模型特征计算是直接一个 SQL 得到，如果是多阶段/多阶的场景。在线特征这块也是按离线的重复执行？

A：目前 OpenMLDB 支持的特征脚本是单个 SQL 脚本，如果是多个 SQL 脚本就需要在外部多次调用以及上线。事实上，在第四范式落地的场景中，单个 SQL 脚本满足几乎目前所有的特征抽取场景（但是在某些场景下这个脚本可能会变得较为复杂）。在第四范式内部的闭源版本可以直接支持多个 SQL 脚本离线和在线计算，OpenMLDB 也计划将在未来把这一部分功能进行开源。

Q27：特征抽取除了 SQL 方式支持，还支持其他方式么，比如自定义 py 脚本么。

A：目前特征抽取只支持 SQL 语言描述，暂时没有支持自定义的 Python 脚本，这个主要是从上线性能的角度去考虑的。Python 脚本灵活度较高，实现的功能可能难以使用数据库索引技术等方式进行高效优化。OpenMLDB 目前正在考虑通过 Python UDF 的方式去做功能性的扩展和自定义。

Q28：是不是可以这样理解，SQL 是处理数据集的第一步，主要处理时间相关和基本统计，更复杂的模型预处理还是放在模型训练和预测里？换句话，就是在正常的模型训练过程前面增加了一个读取数据源的步骤？

A：可以理解 SQL 计算是进行数据的特征计算，即进行特征工程，这个步骤本身也是相当复杂和重要的。特征工程输出的特征，就可以直接给到后面的模型训练和预测。模型训练需要样本数据，通过特征工程得到更多维度的有意义的特征，可以让模型学习到更精确的知识，这也是特征抽取在整个机器学习中很重要的原因。

Q29：多窗囗聚合计算，是基于内存计算提高性能吗？

A：多窗口聚合计算，是基于内存计算的，所有数据会按照窗口定义，根据分区键进行分区，然后进行排序，排序后数据进行滑动窗口，窗口数据是在内存中进行聚合计算。多个分区可以使用分布式并行计算，单个分区使用内存计算提高性能。

Q30：列转行聚合函数支持吗？

A：目前没有支持列转行聚合函数。如果有这方面需求，可以和我们交流或者去 GitHub 上提交 issue。

3. OpenMLDB 社区

在此感谢 OpenMLDB 社区小伙伴对于本次 meetup 的大力支持，如果你想进一步跟了解或者交流，可以通过以下渠道获得相关信息或者和我们互动。