OpenMLDB Meetup No.7 回顾 | OpenMLDB＋AutoX：整合自动特征工程，拥抱高效机器学习

OpenMLDB Meetup No.7 回顾

会议内容

OpenMLDB 社区于 2022年10月29日举行了第七期 meetup，会议相关视频及资料如下：

OpenMLDB PMC core member 卢冕，以《开源机器学习数据库 OpenMLDB：线上线下一致的生产级特征平台》为题，为大家重点介绍了 OpenMLDB 社区 10月的工作进展。

• 视频链接: https://www.zhihu.com/zvideo/1570865332234706945

• 链接：https://pan.baidu.com/s/1whJ7SR7YGw0E-2HH52wnjA

• 提取码：open

第四范式高级科学家 蔡恒兴，给大家介绍了表数据场景下自动机器学习的相关核心技术以及相应的开源产品 AutoX，让希望能够低门槛使用人工智能技术的朋友看到可以期待的未来。

• 视频链接：https://www.zhihu.com/zvideo/1570865733248196608

• 链接：https://pan.baidu.com/s/1LHndaYCH-GbKXc87jo93Uw

• 提取码：open

来自伊利诺伊大学的 OpenMLDB 社区贡献者 徐鹏程，围绕"OpenMLDB 整合自动特征工程" 课题，为观众讲解 AutoFE 的流程原理，展示 AutoX 特征工程在 OpenMLDB 中的作用，并带来精彩的现场演示。

• 视频链接：https://www.zhihu.com/zvideo/1570865680102121472

• 链接：https://pan.baidu.com/s/1zIo_swMA3RH4caek2f9oHg

• 提取码：open

讨论交流——OpenMLDB

Q1: 假如应用场景下走 spark 难度较大，是否可以绕过 spark 做批处理？这样的使用场景吞吐量如何？

A1: OpenMLDB 0.6.4 版本正好做了最新的优化升级，可以满足“不使用 spark 跑批”的需求。现在的 OpenMLDB 支持在线 batch 模式，用户可以把 spark 完全丢掉，用在线引擎跑批。不过这样操作需要注意控制数据量，因为我们的在线 batch 模式默认使用内存，资源消耗较多，可扩展性比起 spark 依然存在差距。如果只做自学习、做批量跑批，完全可以承担。

Q2: 模型要上线的话，固化模型支持哪些格式？

A2: OpenMLDB 专注特征部分，本身不处理模型。我们会把处理特征生产的大宽表直接喂给下游的模型。模型一般使用大家比较熟悉的第三方开源软件，如 LightBGM、XGBoost 等。所以模型格式取决于后续对接的框架，而不再 OpenMLDB 的考虑范围。

Q3: 如何部署 OpenMLDB 可以支持资源动态扩容，保证服务的高可用？OpenMLDB 能否和 K8S 结合呢，这些内容有没有相关的操作介绍呀？

A3: OpenMLDB 本身支持动态扩容，可以随意增加物理机，通过扩容操作做水平扩容。

OpenMLDB 是一个分布式系统，在多数条件下都支持高可用。在 OpenMLDB 在线模块架构的文章介绍中有如何保证高可用的相关原理介绍。

关于 OpenMLDB 和 K8S 的结合，目前 OpenMLDB 离线引擎已经适配成功，但在线引擎还未做适配整合，后续会考虑。

如果用户有生产上线的需求，为了服务的稳定性，我们还是建议部署在物理机上。

关于动态扩容可以查看 ：

http://openmldb.ai/docs/zh/main/maintain/scale.html

在线模块架构参考：
http://openmldb.ai/docs/zh/main/reference/arch/online_arch.html

Q4: 部署OpenMLDB需要的硬件资源（如CPU、内存）有没有相关的参考呢？

A4: 可以参考这篇文章：OpenMLDB 线上引擎资源需求预估模型，助你快速预估资源消耗

Q5: autox.fit_transform() 做的特征工程，如何与 OpenMLDB 结合保证线上线下特征的一致性？

A5: OpenMLDB 和 AutoX 的整合更多是借鉴了 AutoX 算法，在 OpenMLDB 外部设置了一个自动生成 SQL 的 AutoFE 模块。可以理解为，只要把 AutoX 生成的 SQL 给到 OpenMLDB，后续的所有操作流程和原本保持一致即可。只是 SQL 的开发者由数据科学家变成了 AutoFE 模块，而后续的线上线下一致性通过 OpenMLDB 来保证。

讨论交流——AutoX

Q1: AutoX 自动特征工程是不是暴力穷举尝试实现的？特征的可解释性如何、以及资源消耗、性能方面是怎样的？

A1: AutoX 不是暴力穷举实现的，而会根据具体情况降低复杂度，确定搜索空间。我们实现的思路是：先提取数据元特征，再基于不同场景选择判断，利用经验配置，在一定范围内搜索。

目前特征的可解释性做的并不多，我们的可解释性工作更侧重建模后的效果影响因素分析。

AutoX 使用时，常用单机或者单台服务器去跑代码。这里可以举例解释消耗和性能：千万级的数据、几百列代码去跑 AutoX，在 GPU 32 核，内存256 G 的设置下需要 12 个小时。和 OpenMLDB 合作后，性能和资源消耗方面会有进一步的优化。

Q2: 现在有很多端到端的深度学习模型也包含了特征工程的工作，AutoX 相比深度学习模型的特征 Encoder 有什么区别和优势呢？

A2: 两者难做直接的比较。AutoX 中也集成了一些用深度学习 Encoder 模型来提取的特征。AutoX 是开放的，更专注于最后呈现的效果，不局限于某种特征构造方式。

Q3: 基于元特征定义产出的自动特征，其实本质上还是一种历史经验特征的迁移，这里的自动其实体现的是 zero-code？

A3: 用户不需要定义元特征，AutoX会根据已有的内部逻辑自动提取，并且匹配模型。用户只需要定义基础的数据路径、标签等。

Q4: AutoX 目前是支持分布式么？

A4: 本身不支持。如果 AutoX 调用了 XGBoost、X-Boost，可以通过第三方工具实现分布式。

Q5: 想问线上效果的好坏能不能找到是由哪个特征导致的？以便后续优化。

A5: 可以实现，AutoX-interpreter 的项目包含这种功能。我们集成了很多算法，你能通过它们找到具体会有哪些关键因素导致模型效果不好，包括基于模型的可解释、影响力样本获取等功能。

Q6: AutoX 依赖的库数量较多，如 TF，torch 等。当 AutoX 不使用这些库的时候，能不能先避免 import 操作？简单说就是，不用 TF 的时候，AutoX 能否不 import？因为有些用户不一定安装了 TF，torch 这种深度学习框架。

A6: 谢谢这位同学的建议，我们之前也有发现这个问题，并且计划在近期做优化。可以用 lazy import 解决。

Q7: 可以只用 AutoX 的调参能力吗？AutoX 对接分布式 hadoop 集群，读取 HDFS 或 hive 数据可以实现吗？

A7: 可以单独调用。结合 OpenMLDB 之后，对接 hadoop 集群，读取 HFDS 或hive 数据都可以实现。

AutoX 社区

想进一步了解 AutoX 社区或者与核心开发者做进一步的交流讨论，可以通过 Github 获取更多联系渠道。

Github: https://github.com/4paradigm/AutoX

OpenMLDB 社区

在此感谢大家对于本次 meetup 的大力支持，如果想进一步了解 OpenMLDB 或者参与社区技术交流，可以通过以下渠道获得相关信息和互动。

Github: https://github.com/4paradigm/OpenMLDB

Email: contact@openmldb.ai

OpenMLDB 微信交流群：