Kubeflow 与 Feast 协作：特性存储在 ML 基础设施中的角色与实践解析
【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast
本文基于 Feast 官方播客中与 Kubeflow 联合创始人 David Aronchick 的对谈（原始博客），系统梳理 Kubeflow 的设计哲学、其在 ML 基础设施中的组件拼图，并结合本仓库（Feast 开源特性存储）的源码与文档，说明特性存储如何支撑从 Notebook 到分布式训练再到在线推理的完整链路。读完本文，你将理解 Kubeflow 与 Feast 的协作边界、Feast 训练/在线特征检索与 Kubernetes 部署的落地方式，以及 ML 基础设施标准化与开源协作的前沿议题。
背景：一次关于 ML 基础设施的对谈
2022 年 4 月，The Feast Podcast邀请到 Kubeflow 联合创始人 David Aronchick，与主持人 Willem Pienaar（Feast 联合创始人）和 Demetrios Brinkmann 一起，围绕"今天搭建机器学习（ML）基础设施有多复杂、未来需要什么来改进这一过程"展开讨论。对谈的核心话题有三：
- Kubeflow 的诞生与设计哲学；
- 如何改善数据科学家与软件工程师之间的协作；
- 整个行业加速发展需要什么条件。
以下内容完整继承了这场对谈的要点，并结合本仓库（Feast）的实际实现逐层展开，让讨论落到可运行的代码与配置上。
Kubeflow 的诞生与设计哲学：连接 Notebook 与分布式训练
Kubeflow 是一个改进 ML 工作流在 Kubernetes（容器管理系统）上部署过程的项目。它是开源平台，最初基于 Google 内部部署 TensorFlow 模型的方法，可部署在一切支持 Kubernetes 的环境上：本地（on-premise）、Google Cloud、AWS 与 Azure。
对机器学习从业者来说，训练通常只有两种方式：
- 数据集较小时：在 Jupyter Notebook 中工作，快速迭代参数，几乎无需手工配置；
- 数据集很大时：需要分布式训练，动用大量物理机或虚拟机。
Kubeflow 的初衷正是连接这两个世界——从一个 Jupyter Notebook 起步，随着数据集增长，平滑迁移到具备更多特性、流水线和特性存储的分布式训练。David 强调，Kubeflow 自身并不提供这些附加能力，而是希望与提供这些能力的服务合作——这正是 Kubeflow 与 Feast 深度协作的起点。
在 Feast 的架构中，这一"连接"体现在两个核心存储的设计上（见 架构总览）：
- Offline Store：处理历史数据，用于批量评分与模型训练；
- Online Store：低延迟存储，为实时预测提供特征值；
- Feature Server：在线提供预计算特征的成熟服务。
这一分工与 Kubeflow"先 Notebook、后分布式"的演进路径天然匹配：训练阶段从离线存储读取历史特征，上线阶段从在线存储读取实时特征，同一个特性视图（Feature View）同时服务两个阶段，避免两套特征定义不一致的问题。
Kubeflow 的组件拼图：特性存储、流水线引擎与推理端点各司其职
David 描述了 Kubeflow 的构建方式——它建立在多种服务的组合之上：
| 组件 | 职责 |
|---|---|
| Kubeflow | 定义流水线语言（pipeline language） |
| Feast | 提供特性存储（feature store） |
| Argo | 在底层执行工作流（workflows） |
| Katib | 提供超参数搜索（hyperparameter sweep） |
| Seldon | 提供推理端点（inference endpoint） |
随着 Kubeflow 日趋成熟，其目标是从"一次安装大量服务的单体式基础设施"重构为"更干净、更专业化"的形态，让用户只安装自己需要的服务——KServe 的毕业（graduation）就是这一趋势的例证。
对应当前 Feast 仓库，各"拼图"的能力可以在以下位置找到对应实现：
- 特性定义与注册：
FeatureView（特性视图）把离线/在线环境中的特征数据建模为一致的对象，支持数据源、实体、schema、TTL 等配置； - 训练数据生成：
store.get_historical_features(...)从离线存储按 point-in-time 语义生成训练数据集； - 在线特征检索：
store.get_online_features(...)从在线存储以毫秒级延迟取特征； - 数据新鲜度：
feast materialize/feast materialize-incremental定期把离线数据灌入在线存储（物化）。
Feast 的特性存储能力如何落地：训练数据与在线特征
特性存储的实战价值最终体现在"训练与推理用同一套特征"。以仓库 README.md 中的 Quickstart 为例，训练数据生成只需一个实体 DataFrame：
from feast import FeatureStore import pandas as pd from datetime import datetime entity_df = pd.DataFrame.from_dict({ "driver_id": [1001, 1002, 1003, 1004], "event_timestamp": [ datetime(2021, 4, 12, 10, 59, 42), datetime(2021, 4, 12, 8, 12, 10), datetime(2021, 4, 12, 16, 40, 26), datetime(2021, 4, 12, 15, 1 , 12) ] }) store = FeatureStore(repo_path=".") training_df = store.get_historical_features( entity_df=entity_df, features=[ 'driver_hourly_stats:conv_rate', 'driver_hourly_stats:acc_rate', 'driver_hourly_stats:avg_daily_trips' ], ).to_df()训练完成后，模型上线需要的在线特征同样一行代码：
feature_vector = store.get_online_features( features=[ 'driver_hourly_stats:conv_rate', 'driver_hourly_stats:acc_rate', 'driver_hourly_stats:avg_daily_trips' ], entity_rows=[{"driver_id": 1001}] ).to_dict()而把训练数据灌入在线存储，则通过物化命令完成（推荐增量物化）：
CURRENT_TIME=$(date -u +"%Y-%m-%dT%H:%M:%S") feast materialize-incremental $CURRENT_TIME关于如何避免训练阶段的数据泄漏，Feast 通过 point-in-time 连接 保证生成的特征集在时间语义上严格正确——这正是对谈中"让数据科学家专注特征工程而非调试 join 逻辑"诉求的工程化回答。Feast 也支持流式数据通过 Push API 直接写入在线/离线存储，对应 Kubeflow 生态中实时特征进入推理链路的场景。
数据科学家与软件工程师的协作：把 ML pipeline 的每一步映射到正确工具
对谈的第二部分聚焦协作问题。数据科学家负责微调模型参数，工程师负责把模型生产化（productionize）——即保证其无中断地稳定运行。David 指出两个核心痛点：
- ML 系统的 API 复杂难用，成为数据科学家的阻碍，生产部署流程尚无法完全自动化；
- ML 工作更接近科学（提出假设并验证），而非软件开发（迭代式发布新版本）。基于大数据集构建分布式模型后，很难再回到 Jupyter 这种交互式环境，除非重建一个更小的模型。
更实际的问题是：ML 从业者的工作整体是一条流水线，但单个步骤常常没有清晰描述，导致难以把每一步映射到正确的工具。数据科学家的一天往往是：下载 CSV → 删除某列 → 上传到特性存储 → 跑 Python 脚本 → 训练。Willem 因而提出更好的解法："小团队应该能够针对解决业务问题的具体用例，独立部署解决方案。"David 则希望借助现有工具让这条流水线更易执行："Kubeflow、Kubernetes 等中当然已有部分组件，我正在思考下一个抽象层应该是什么样子，它应该很快面世。"
这一"抽象层"思想在 Feast 中已有具体体现：特性以 FeatureView 形式统一建模，训练与在线检索共用同一份 schema 定义；FeatureService 进一步把"某个模型版本需要的特征集合"固化下来，成为训练与推理之间的稳定契约。生产实践中，在生产环境运行 Feast 指南建议通过 CI/CD 自动执行feast plan与feast apply，把特性仓库的变更同步到注册表（Registry），并用 staging 环境验证后再提升到生产。
把 Feast 部署到 Kubernetes：Operator 与 FeatureStore 自定义资源
由于 Kubeflow 基于 Kubernetes，理解 Feast 在 Kubernetes 上的部署方式是本次协作落地的关键。仓库提供了 Feast Operator——一个用于部署和管理 Feast 的 Kubernetes Operator。安装后，用户只需提交一个FeatureStore自定义资源（CR）：
apiVersion: feast.dev/v1 kind: FeatureStore metadata: name: sample spec: feastProject: my_projectOperator 会据此拉起在线存储特性服务器（默认是 Python feature server）等组件，并自动执行feast apply等初始化工作。更完整的部署步骤参见 Feast on Kubernetes：
# 1. 安装 Operator（最新版） kubectl apply --server-side --force-conflicts -f <operator 安装清单> # 2. 部署一个 FeatureStore kubectl apply -f <v1_featurestore.yaml 样例> # 3. 查看状态 kubectl get feast生产环境的其他关键操作（数据库型注册表、可扩展物化引擎、Airflow/Kubernetes Job 调度、流式特征摄入、${ENV_VAR}配置注入）均在 生产部署指南 中有完整示例，此处不再展开。可以说，Feast 与 Kubeflow 的协作在仓库层面已经有了一条"特性仓库 → CI/CD → Operator → Kubernetes 集群"的成熟路径。
加速 ML 行业：标准化、收敛与开源协作
对谈最后讨论了行业层面的话题。MLOps 平台格局极其复杂，而 Kubernetes 之所以被选为 Kubeflow 的骨干，是因为它"易于搭建和调整"。Willem 预判了 ML 与 MLOps 工具的整合趋势："整合终将发生，因为工具太多了，不可能全部存活。现在是培育期，接下来是适者生存。"当时已可见的案例包括 DataRobot 收购 Algorithmia、Snowflake 收购 Streamlit，以及 Databricks 收购 Cortex Labs。
对于 Kubeflow 这样的开源项目，David 的立场是：核心组件周围应当有一个负责制定标准的工作组，而不是由单个人做所有决策。他给出的协作经验是：新功能需要时，代码讨论只占 10% 的工作量，大头在于决定实现细节并确保它真正可用；最快把事情做成的方式就是自己先把它构建出来，然后努力让它合并进去。
最有前瞻性的观点是关于标准层：David 认为，要真正改善 ML 生态，"不仅需要一套描述整个平台的标准层，还需要一套描述机器学习中许多通用对象的系统：feature、feature store、data set、training run、experiment、serving inference 等等。它会激发创新，因为它定义了一组用户可以生产和消费的清晰契约。"目前这在程序化层面还很困难，因为系统五花八门，需要编写大量辅助工具来连接数据集。
从 Feast 仓库看，这种"清晰契约"正在逐步落地：类型系统（feast/types.py 所定义的 Field 类型）、注册表（Registry）作为特征定义的单一事实来源、FeatureService 作为模型特征版本化契约，以及 Alpha 特性视图版本化 对 schema/UDF 变更的快照审计——这些都是在为"feature / feature store / data set"等通用对象定义稳定接口。
总结：一次协作如何映照 ML 基础设施的未来
这场对谈浓缩了 ML 基础设施演进的两个关键判断：
- 分工专业化：Kubeflow 聚焦流水线语言与编排，Feast 聚焦特征存储，Argo/Katib/Seldon 各司其职——与其构建单体平台，不如让专业组件通过清晰契约协作；
- 标准化是创新前提：从通用对象（feature、feature store、dataset、training run、experiment、serving inference）的标准化开始，才能让不同团队、不同工具之间真正实现"生产与消费"。
对开发者而言，本仓库是实践这一愿景的最佳起点：快速上手可参考 Quickstart 与 架构总览，Kubernetes 落地可参考 Operator 配置指南 与 生产部署拓扑，深入理解可阅读 ADR 系列 了解组件重构与演进决策。欢迎在仓库 CONTRIBUTING.md 与 社区治理文档 中了解参与方式——正如 David 所言，最快的方式就是自己动手构建并让它合并。
【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
