共计 5204 个字符，预计需要花费 14 分钟才能阅读完成。
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 的大力支持，如果你想进一步跟理解或者交换，能够通过以下渠道取得相干信息或者和咱们互动。
Github: https://github.com/4paradigm/OpenMLDB
中文文档网站：https://docs.openmldb.ai/
中国镜像（国内拜访更为稳固）：http://docs-cn.openmldb.ai/
Email: contact@openmldb.ai
Slack
OpenMLDB 微信交换群