Feature Store 横向对比¶
建议先读
一句话回答
自研一个 Feast 级别的东西是大多数团队低估的陷阱；上 Tecton / Hopsworks / Databricks FS 得评估云绑定与成本。Feast 是中型团队的甜点，小团队可以从 Redis + dbt 开始，大厂才有必要自研。
TL;DR
- Feature Store ≠ Redis——核心是离线在线一致性 + Point-in-Time Join + Feature Registry
- Feast：开源、轻量、自部署；需要自配存储后端
- Tecton：商业 SaaS、端到端托管、贵但省事
- Hopsworks：开源 + 商业、含完整 MLOps、北欧出品
- Databricks FS：深度集成 Delta / Unity；绑定 Databricks
- 自建 on Iceberg + Redis：中小规模可做；复杂度在 PIT Join + Schema 治理
- 选型关键：是否已在某云 / Databricks / Snowflake 生态内
为什么需要 Feature Store¶
三个痛点，三选一命中就该考虑 FS：
- Train-Serve Skew：离线训练用 Spark SQL 算特征，在线推理用 Java 重写一遍 → 两套代码必然漂移
- Point-in-Time 泄露：训练集用了未来的特征值（比如 2024-06 的用户活跃度去预测 2024-03 的订单）→ 线下 AUC 0.95，线上崩
- 特征复用困难：推荐系统算了一套 user embedding，风控又重新算一遍；浪费计算
Feature Store 的三项核心能力：
- 统一特征定义（一处定义、离线在线同算）
- Point-in-Time 正确性（训练样本拿到的是事件发生时刻的特征值）
- Feature Registry（目录 + 血缘 + 监控）
主流方案一览¶
| 方案 | 类型 | 开源 | 托管 | 适合规模 | 年费参考 |
|---|---|---|---|---|---|
| Feast | 独立 FS | ✅ Apache 2.0 | 自部署 | 小-中 | 0 + 云资源 |
| Tecton | SaaS | ❌ 商业 | 全托管 | 中-大 | $50K-500K+ |
| Hopsworks | 独立 FS + MLOps | ✅ AGPL + 商业 | 自部署 / 托管 | 中-大 | 商业授权 |
| Databricks Feature Store | 平台内 | ❌ 绑定 Databricks | 托管 | 已用 Databricks | Databricks 账单内 |
| Vertex AI Feature Store | GCP | ❌ 绑定 GCP | 托管 | 已用 GCP | 按量 |
| SageMaker Feature Store | AWS | ❌ 绑定 AWS | 托管 | 已用 AWS | 按量 |
| Feathr (LinkedIn) | 独立 FS | ✅ Apache 2.0 | 自部署 | 中-大 | 0 + 云资源 |
| 自建 Iceberg + Redis + dbt | 自研 | — | 自运营 | 小-中 | 0 + 人力 |
Feast · 开源首选¶
适合
已有湖仓，需要离线在线一致、不想上商业方案、愿意自运营。
架构： - Feature Definition：Python / YAML 声明 - Offline Store：BigQuery / Snowflake / Iceberg 文件 / Spark / Trino - Online Store：Redis / DynamoDB / Bigtable / Cassandra / ScyllaDB / PostgreSQL - Registry：S3 / GCS / PostgreSQL / MySQL（存 metadata） - Provider：GCP / AWS / Local / Kubernetes
# feature_view 定义
from feast import FeatureView, Field
from feast.types import Float32, Int64
user_stats_fv = FeatureView(
name="user_stats",
entities=["user_id"],
ttl=timedelta(days=7),
schema=[
Field(name="avg_order_amount", dtype=Float32),
Field(name="purchase_count_7d", dtype=Int64),
],
source=spark_source,
online=True,
)
# 离线获取训练数据（PIT 自动处理）
training_df = store.get_historical_features(
entity_df=entity_df,
features=["user_stats:avg_order_amount", "user_stats:purchase_count_7d"]
).to_df()
# 在线获取推理特征
features = store.get_online_features(
features=["user_stats:avg_order_amount"],
entity_rows=[{"user_id": 12345}]
).to_dict()
优劣¶
| 优 | 劣 |
|---|---|
| 开源、Apache 2.0 | 不含流式特征（自己接 Flink） |
| 支持多种 offline/online store | 大规模在线 serving 要自己扩展 |
| 湖仓友好（Parquet / Iceberg） | Registry 功能相对弱 |
| Python 原生，ML 团队上手快 | 监控 / 血缘需自己搭 |
| 社区活跃（Tecton 在维护） | 没有 UI（v0.40+ 有 Feast UI 但弱） |
Tecton · 商业旗舰 SaaS¶
适合
模型上线节奏快、团队不想维护 FS 基础设施、预算充足、要求 SLA。
特色： - 端到端托管：写特征定义 → 自动部署到在线 / 离线路径 - 实时特征原生：流式 + 批 + request-time 统一 - 对接湖仓 / 数仓：Snowflake / Databricks / Redshift / BigQuery - UI 很好：监控、血缘、审计完整
优劣¶
| 优 | 劣 |
|---|---|
| 生产就绪、SLA 担保 | 贵（年费几十万美元起） |
| 流式特征一等公民 | 厂商锁定 |
| 专业支持团队 | 数据出境 / 合规要评估 |
| 监控 / 可观测性完整 | 离开 Tecton 迁移成本高 |
Hopsworks · 北欧开源¶
适合
希望一套平台完成 FS + 训练 + 部署；金融 / 医疗强合规场景。
特色： - 更接近 MLOps 平台而不只是 FS（含 Kubeflow、Jupyter、模型 serving） - 支持 On-Premise 部署（合规场景友好） - HopsFS 是他们自家的 HDFS 替代品 - 自带 Feature Registry UI
优劣¶
| 优 | 劣 |
|---|---|
| 开源（虽然 AGPL 有传染性） | AGPL 对某些公司是问题 |
| 完整 MLOps | 学习曲线比 Feast 陡 |
| On-Prem 友好 | 国内社区资料少 |
| 欧洲合规 | 集成湖表（Iceberg / Paimon）较新 |
Databricks Feature Store¶
适合
已经在 Databricks 上、用 Delta + Unity Catalog。
特色： - 深度 Delta + Unity 集成 - Feature Engineering UI in Notebook - Online Tables（2024+ 新功能）把 Delta 物化成在线低延迟表 - 自动血缘：训练 / 推理使用的特征在 Unity Catalog 里可追溯
优劣¶
| 优 | 劣 |
|---|---|
| 零额外运维（Databricks 内置） | 绑定 Databricks |
| Unity Catalog 血缘完整 | 不用 Databricks = 没法用 |
| 企业安全 / 权限到位 | 成本随 Databricks 账单 |
云厂商托管方案¶
Vertex AI Feature Store（GCP）¶
- 2024 重构后全面升级（从 v1 到 v2）
- 底层是 BigQuery + Bigtable
- 绑定 GCP 且迁移难
- BigQuery 客户友好
SageMaker Feature Store（AWS）¶
- 底层 Glue + DynamoDB
- 绑定 AWS
- 与 S3 + Glue Catalog + SageMaker 深度集成
Feathr · LinkedIn 开源¶
适合
大规模、流 + 批、Scala / JVM 栈团队。
特色： - LinkedIn 生产验证、支持流 + 批 + 图特征 - Feathr on Azure 官方支持；其他云需自配 - 声明式 DSL（比 Feast 更表达力） - 社区比 Feast 小
自建方案：Iceberg + Redis + dbt¶
适合
团队规模小、湖已经在、特征数 < 500、主要是批特征。
最小拼装：
Iceberg (离线宽表)
│
├── dbt 统一特征定义 (SQL + Jinja)
│
├── Spark PIT Join → 训练集
│
└── 同步到 Redis (每日批 / Flink 流) → 在线 serving
自建核心组件¶
| 组件 | 技术 | 说明 |
|---|---|---|
| Feature Definition | dbt models | SQL + YAML |
| Offline Store | Iceberg | 带 event_ts 列 |
| Online Store | Redis / Aerospike | 主键 = entity_id |
| Sync Job | Spark batch + Flink | 定时物化到 Redis |
| Registry | 自建 Git 仓库 / dbt docs | 功能弱但够用 |
| PIT Join | Spark SQL asof |
手写谨慎 |
陷阱¶
- PIT Join 写错极常见——是生产事故温床
- 一致性要靠纪律（dbt code review）而非工具
- Schema 演化：加列 / 删列影响在线，要有流程
- 监控 / 血缘全部自己搭
决策矩阵¶
| 需求 | 首选 |
|---|---|
| 湖仓在 Iceberg、自运营、开源 | Feast（offline store = Iceberg；online store = Redis） |
| 已经全栈 Databricks | Databricks FS |
| 已经全栈 GCP / AWS | Vertex AI FS / SageMaker FS |
| 预算足、要 SLA、流式特征多 | Tecton |
| 合规严、要 On-Prem、含 MLOps | Hopsworks |
| 大规模、流批图、Scala 栈 | Feathr |
| 小团队、< 100 特征、全批 | 自建 Iceberg + Redis + dbt |
关键能力对比表¶
| 能力 | Feast | Tecton | Hopsworks | Databricks FS | 自建 |
|---|---|---|---|---|---|
| 开源 | ✅ | ❌ | ✅ AGPL | ❌ | — |
| PIT Join | ✅ | ✅ | ✅ | ✅ | 自己写 |
| 流式特征 | ⚠️ 需接 Flink | ✅ 原生 | ✅ | ✅ | 自己搭 |
| Request-time 特征 | ⚠️ 有限 | ✅ | ✅ | ✅ | 自己搭 |
| Feature Registry UI | 弱 | ✅ | ✅ | ✅（Unity） | ❌ |
| 血缘 | 弱 | ✅ | ✅ | ✅ | ❌ |
| 监控（Feature drift） | 弱 | ✅ | ✅ | 部分 | ❌ |
| 多云 / 多厂 | ✅ | ✅ | ✅ | ❌ | ✅ |
| 湖表原生（Iceberg/Paimon） | ✅ | ⚠️ 通过 Spark | ✅ | 只 Delta | ✅ |
| 社区成熟度 | 中 | 商业 | 中 | 商业 | — |
陷阱（选型通用）¶
- "我们先自建，以后再说"：90% 最后陷在 PIT Join 和监控上，几年下来成本超过 Tecton
- Feast 装上就不管：Online Store 规模 → 自己扩；监控 → 自己建；Feast 不是银弹
- 低估 Schema 治理：特征 300+ 后，谁拥有、何时淘汰、口径冲突都是大事
- 忽视流式特征：欺诈 / 推荐场景近实时是刚需，只做批会落后
- 商业方案没做 POC：Tecton 的 Streaming 适配你的数据规模？自己跑过才知道
- Training Data Snapshot 没锁：训练可复现性不是自动的，需要 Iceberg snapshot id 配合
相关¶
延伸阅读¶
- Feast 官方文档
- Tecton 白皮书
- Hopsworks Feature Store 论文
- Uber Michelangelo — FS 的早期工业实践
- Designing Machine Learning Systems (Chip Huyen) — Chapter 6 详细讲 FS