Feast：ML 特征管理的开源方案

机器学习项目中有个常见问题。数据科学家花大量时间在特征工程上，但训练和推理用的特征经常对不上。模型在线下跑得好好的，一上线效果就变差。核心原因之一是特征缺乏统一管理。

Feast（Feature Store）就是解决这个问题的开源项目，GitHub 上已有 7,000+ Star。

Feature Store 是做什么的

Feature Store 是特征的中心化管理平台。特征的定义、计算和存储都集中在这里，训练和推理流程统一从这取数据。这样做的好处是保证训练和推理用的特征一致，避免模型上线后效果打折。

Feast 是这个领域落地最早的项目之一。它不绑定特定基础设施，可以对接已有的数据库和数据湖，不需要为了用 Feature Store 而迁移数据。

三个核心存储

Feast 提供三个存储层，对应不同场景。

离线存储（Offline Store）处理历史数据，适合大规模批处理。数据科学家用它生成训练数据集，支持 Snowflake、BigQuery、Redshift、DuckDB 等多种引擎。

在线存储（Online Store）负责低延迟查询，模型上线后的实时推理走这条路。支持 Redis、DynamoDB、Cassandra、PostgreSQL 等后端，可以按需选择。

特征服务器（Feature Server）是统一的服务接口，应用通过标准 API 获取特征值，不需要关心底层用的是哪个存储系统。

解决的实际问题

数据泄露是 ML 团队常遇到的问题。训练时如果用了未来的特征值，模型测试指标好看，上线后效果直线下降。Feast 通过 point-in-time 查询机制，保证每个训练样本只取该时间点之前的数据。

特征复用也是一个痛点。不同模型经常需要相同的特征，没有统一管理时各团队各自实现，逻辑分散而且不一致。Feast 提供特征注册和发现机制，团队可以共享已有特征定义，减少重复工作。

基础设施解耦方面，特征定义和存储实现是分离的。训练阶段用离线存储批处理，推理阶段用在线存储实时读取。底层切换存储系统时，上层的特征定义代码不需要改动。

支持的生态

Feast 的数据源覆盖很广。离线方面支持 Snowflake、BigQuery、Redshift、DuckDB、Dask、Spark 等。在线方面支持 Redis、DynamoDB、PostgreSQL、Cassandra、MongoDB、Elasticsearch，以及 Qdrant 和 Milvus 等向量数据库。社区插件还覆盖了 ClickHouse、Trino、HBase、ScyllaDB 等。

数据源方面支持 Parquet 文件、Kafka、Kinesis 等流式数据，接入方式比较灵活。

上手体验

pip 安装后运行 feast init 可以创建特征仓库模板。用 Python SDK 定义特征视图，feast apply 注册到注册中心。之后通过 SDK 获取历史特征训练模型，或者通过在线 API 读取实时特征做推理。整体流程比较清晰。

Feast 适合有一定规模的 ML 团队，特别是多模型同时在迭代、需要统一管理特征的场景。功能比较扎实，社区活跃度不错，集成了大量主流的存储和计算引擎。

代、需要统一管理特征的场景。功能比较扎实，社区活跃度不错，集成了大量主流的存储和计算引擎。