国内首次 Feature Store Meetup 回顾

2021 年 12 月 16 日
本文字数：4720 字
阅读完需：约 15 分钟

2021 年 12 月 11 日，由第四范式开发者社区主办的国内首次“Feature Store Meetup”，邀请到了来自美团、小米、伴鱼、第四范式的国内机器学习工程领域前沿专家，共同带来关于 MLOps、及 Feature Store 的相关分享。

活动背景

随着机器学习在越来越多的企业部署到更多的场景中，对于数据/Feature（即特征）的管理也越来越有挑战性。如何保证线上/线下的一致性，如何共享多个 feature 以减少重复性工作，如何满足低延迟线上预测实现等问题一直是机器学习落地过程中的难点。Feature Store 的出现实现了有效的功能工程与管理，同时使得整个公司范围内的功能标准化以及离线和在线模型之间的功能一致性。自 2017 年 Ubar 首次提出 Feature Store 的概念发展至今，国内、外已有不少公司在 Feature Store 领域拥有各自的实现、云上产品和一些开源项目。

2021 年 12 月 11 日，由第四范式开发者社区主办的“Feature Store Meetup”，特邀国内机器学习工程领域的五位前沿专家，就对于“如何利用 Feature Store 保证线上/线下的一致性，如何共享多个 feature 以减少重复性工作，如何满足低延迟线上预测实现，及 Feature Store 如何在各家实际场景中的实现与应用”进行交流探讨。

议程回顾

Part 1：Feature Store 背景介绍及概念

第四范式架构师，开放原子基金会 TOC 副主席谭中意，在此次 meetup 中重点介绍了 Feature Store 的背景，概念及 Feature Store 的发展历史。

在机器学习落地过程中，数据部分面临众多挑战，其中包括模型训练需要海量的数据支持，如何保证训练和预测的一致性，如何保证足够低的延迟进行预测等等。针对这些挑战，出现了 Feature Store。按照 Uber 的解释，Feature Store 允许多个团队共享、发现和使用一个经过高度优化后的 Feature。同时 Feature Store 还是跨组织中的不同团队构建、管理和共享功能的中心位置。

2017 年 Uber 在对米开朗基罗机器学习平台介绍中首次提出 Feature Store，自此该项目被业界广泛关注，发展至今已有多个大厂发布出了商业产品。国内对于 Feature Store 的关注也在慢慢兴起，2021 年 6 月第四范式开源的 OpenMLDB 项目，则是国内首家为企业提供全栈 FeatureOps 解决方案的开源机器学习数据库。

Part 2：开源机器学习数据库 OpenMLDB：为企业提供全栈 FeatureOps 解决方案

第四范式架构师，数据库团队和高性能计算团队负责人，开源项目 OpenMLDB 负责人卢冕在此次 meetup 中重点介绍了 AI 工程化落地的数据和特征挑战，OpenMLDB 如何为企业提供全栈 FeatureOps 解决方案等。

MLOps 是覆盖整个机器学习落地的工具与运维，从机器学习角度看，MLOps 分为离线开发和线上服务两个流程。其中离线开发可以分成 DataOps、FeatureOps 和 ModelOps。DataOps 包含数据采集与数据存储，FeatureOps 包含离线特征计算与特征存储和共享，ModelOps 模型训练与超参数调优。之后即可通过部署进行上线，此过程更多关注于实时数据的处理，通过数据流的接入、请求，实时特征的计算以及通过在线推理进行结果数据回流形成结果反馈，进而进行下一轮的迭代。在实际的企业级落地环境中，ProductionOps 也是关注重点，其中包含高可用、可扩缩容、平滑升级实时监控等功能。

AI 工程化落地的最大挑战，是线上线下机器学习系统的一致性校验。数据供给主要包含两方面，即线上线下的特征抽取和数据存取。数据供给主要是为了给后面机器学习的模型训练和在线预估高效提供正确的数据。传统中 AI 应用开发的线上线下是两个割裂的流程。因为线上线下所使用的不同工具、不同流程、甚至不同的开发人员所导致的，这两套流程的对齐往往会耗费巨大的人力去解决这个线上线下一致性问题。

而 OpenMLDB 作为开源机器学习数据库，提供企业级 FeatureOps 全栈解决方案，为了解决线上线下一致性校验的问题，通过三步骤完成开发即上线的要求，1.线下 SQL 特征脚本开发 2.一键部署上线 3.接入实时请求数据流。总体来说，对外暴露的接口对于离线处理，我们的数据源可以从 HDFS 等大数据存储上读取，对于在线实时请求，我们既可以从 Kafka 等业界标准方案接口，也可以从 RESTful 接口实现实时在线服务。OpenMLDB 内部通过一系列的组件和技术来帮助用户高效实现离线和在线的特征抽取，将正确数据供给给训练和预估服务。

如今，OpenMLDB 已成为国内首个为企业提供全栈 FeatureOps 解决方案的开源机器学习数据库的开源项目，包含四大产品特性：线上线下一致性执行引擎，低门槛且功能强大的数据库开发体验，面向特征计算的定制化性能优化，以及企业级应用特性。在未来，OpenMLDB 将聚焦 Cloud native OpenMLDB、基于外存优化的低 TCO 版本、长时间窗口支持、整合自动特征工程等重要特性。同时我们也希望 OpenMLDB 可以帮助更多企业搭建自己的 AI 场景，完成高效正确的供给数据。

Part 3：特征平台在小米广告算法中的实践

小米商业平台技术部负责人黄飞，在本次 meetup 中重点介绍小米是如何通过特征平台来提升算法同学的实验效率，帮助小米实现特征数据的共享，解决离线、在线实验效果不一致等一系列问题。

小米广告从 14 年底开始实现，商业化媒体覆盖 20+小米商业化媒体，及 2000+生态开发者。而特征平台是广告系统中非常是重要的组成部分。通过特征平台可以将算法工程师平时的工作过程中固定的模式和流程，进行工具化平台化从而提升整个算法团队的工程效率。

在小米广告最开始的广告项目中，只有 1、2 个算法工程师全程跟进完成模型上线的过程。随着模型复杂度的上升、整个系统的提升和部署难度的提升，由单个同学 end to end 的部署难度大大提升。所以在此过程中出现了以下几大难点。

算法迭代效率低：处理流程多、特征复用低、存储资源不足
离线有效果，在线没效果：代码不一致、验证困难
性能问题特征规模增长、任务分散优化靠个人

针对以上问题小米提出了特征平台方案，以此提升整体性能及上线效率

任务自动生成、共享特征库实验一键复制、统一存取编码压缩
线上线下用一份代码、线上线下一以来同一份数据
统一优化计算逻辑、统一配置个性化参数策略

小米的特征平台包括：特征管理、数据源管理、样本管理、质量监控四大模块，它可以支持数据源、特征、样本的注册、搜索、复用，并通过 udf 的形式来支持特征的 etl、id 化，编码，并通过配置化的方式对离、在线生成的任务进行统一管理。同时该特征平台在能力层可以支持批处理的能力，在框架层可以支持实时特征、实时数据源、实时样本、实时模型。以保证在整个流程中，提供对数据、特征、样本、模型质量的度量监控和报警。

通过模型训练平台，目前小米的线上模型校验已经通过 752 个模型、上线后保证事故 0 发生。并有 32 个共享算法，超过 100 个在线模型以此提升平台效率，同时 7 日 SLA 达到 100%，保证平台稳定性。Feature Store 的出现很好的解决了小米离线、在线实验效果不一致等一系列问题。

Part 4：美团外卖特征平台的建设与实践

美团外卖广告预估方向工程负责人邹亚劼，在本次活动中介绍了美团外卖特征平台的建设背景、零代码的特征平台架构，及特征在业务赋能上的一些行动。

美团外卖业务种类繁多、数据量大，同时因为特征的迭代周期很长，在美团外卖的特征上线方面出现了效率、准确、性能、成本等方面的诸多问题。外卖算法平台通过统一算法工程框架，解决了模型 &特征迭代的系统性问题，极大地提升了外卖算法的迭代效率。如下图所示，根据功能不同，外卖算法平台可划分为三部分：模型服务、模型训练和特征平台。其中，模型服务用于提供在线模型预估，模型训练用于提供模型的训练产出，特征平台则提供特征和样本的数据支撑。外卖特征平台则聚焦于提供从样本生成->特征生产->特征计算的一站式链路，用于解决特征的快速迭代问题。

随着外卖业务的发展，特征体量也在快速增长，外卖平台面对的挑战和压力也不断增大。目前，平台已接入特征配置近万个，特征维度近 50 种，日处理特征数据量几十 TB，日处理特征千亿量级，日调度任务数量达数百个。面对海量的数据资源，平台如何做到特征的快速迭代、特征的高效计算以及样本的配置化生成？经过不断的摸索、实践和优化，平台功能逐渐完备，使特征迭代能力更上一层台阶。美团外卖特征平台框架由三部分组成：训练样本生成（离线）、特征生产（近线）以及特征获取计算（在线），如下图所示：

训练样本生成：离线侧，平台提供统一配置化的训练样本生成能力，为模型的效果验证提供数据支撑。
特征生产：近线侧，平台提供面对海量特征数据的加工、调度、存储、同步能力，保证特征数据在线快速生效。
特征获取计算：在线侧，平台提供高可用的特征获取能力和高性能的特征计算能力，灵活支撑多种复杂模型的特征需求。

目前，外卖特征平台已接入外卖多条业务线，涵盖数十个场景，为业务的策略迭代提供平台化支持。其中，平台的优势在于两点：

业务提效：通过特征配置化管理能力、特征 &算子 &解决方案复用能力以及离线在线打通能力，提升了特征迭代效率，降低了业务的接入成本，助力业务快速拿到结果。
业务赋能：平台以统一的标准建立特征效果评估体系，有助于特征在业务间的借鉴和流通，最大程度发挥出特征的价值。

未来，外卖特征平台将继续推进从离线->近线->在线的全链路优化工作，在计算性能、资源开销、能力扩展、合作共建等方面持续投入人力探索和建设，并在更多更具挑战的业务场景中发挥平台的价值。同时，平台将继续和模型服务和模型训练紧密结合，共建端到端算法闭环，助力外卖业务蓬勃发展。

Part 5：伴鱼 Feature Store 的演进

伴鱼 AI 平台负责人陈易生介绍了伴鱼如何通过搭建统一的 Feature Store，解决特征的存储和访问问题，将模型的上线周期从周缩减至天。伴鱼的实践对于有 ML 落地需求的公司从 0 开始搭建 Feature Store 有很好的借鉴意义。

随着业务的增长，伴鱼的算法团队面临模型上线难的问题，而与特征有关的问题最为棘手。V1 版本的 Feature Store 让特征上线成为可能。业务方的算法工程师在完成模型训练后，由中台的数据工程师实现特征工程，将特征写入生产环境 Redis；业务方的产品工程师按照算法工程师的规定，在业务服务中从 Redis 读取特征，输入模型。

这一流程存在两个主要问题：

数据和产品工程师「兼职」参与，缺少 ownership。
与人对接效率低。算法工程师的想法要通过数据工程师和产品工程师（而不是自己）来实现，导致数据工程师很难正确地实现特征，产品工程师很难正确地使用特征。

为了解决这两个问题，伴鱼的 Feature Store V2 重构如下：

在 V2 中，算法工程师使用 PyFlink 和 HiveQL 自主实现特征工程，无需依赖数据工程师的协助；AI 平台工程师编写通用的特征注入任务，将处理好的特征写入 Redis，使得产品工程师只需通过接口直接获取特征。

让算法工程师能够自主地实现特征工程，是 V2 设计的核心。以流特征的实现为例，V2 让算法工程师使用熟悉的工具：配置、SQL 和 Python，填写左边三个文件中的 TODO，提交到代码仓库中。在通过代码审核后，CI 会根据上传的文件拼装成可执行的 PyFlink 脚本，提交到 Flink 集群，即可完成特征上线。

V2 相比 V1，实现了更快的特征迭代（从几周到几天）和更好的特征治理。前者是因为算法工程师得以完全掌握进度，无需等待数据工程师和产品工程师的排期。后者则是因为特征代码被统一管理起来。

总结

以上是本次 Meetup 的全部内容，再次感谢小米、美团、伴鱼对本次 Feature Store Meetup 的支持，同时也非常欢迎对 Feature Store、MLOps 有技术激情的同学一起加入我们的技术。最后欢迎大家持续关注 MLOps 的讨论，不妨可以加入 MLOps 讨论群、OpenMLDB 官方交流群