特征工程新工具生态图谱(2026):特征存储并购重组、实时计算新锐与向量特征收敛的选型实战
导语:特征工程工具在 2026 年正经历一轮自 2019 年 Feast 诞生以来最剧烈的结构性重排。如果说过去六年行业的主题是”要不要上特征存储”,那么 2025—2026 年的主题已经变成”特征存储作为一个独立品类是否还存在”。Tecton 被 Databricks 收购、Fennel 被 Stripe/Databricks 收入囊中、Hopsworks 重定位为”AI Lakehouse”、Feast 0.18 把重心转向向量检索与 LLM/RAG——这些信号共同指向一个结论:独立特征存储时代正在终结,而”实时特征 + 向量特征 + 湖仓治理”融合成的 AI 上下文层正在成为新基础设施。本文对多源材料做体系化整合,给出三代工具谱系、并购重组时间线、湖仓融合论点、向量收敛趋势、决策权衡矩阵与 30/60/90 落地路线,帮助团队在新工具格局下做出清醒选型。
一、范式背景:为何特征工程工具在 2026 重新洗牌
特征存储解决的核心痛点从未改变:训练—服务偏差(training-serving skew)。同一份 user_average_spend,训练管线按 90 天窗口算、服务管线按 30 天窗口算,模型上线即掉点。特征存储通过”特征定义单一真相源 + point-in-time 正确连接 + 离线/在线双存储”根除这一问题。但到 2025 年,三类外部压力叠加,把工具格局推向重组:
- 实时性成为默认要求。反欺诈、动态定价、实时个性化乃至 2026 年爆发的 RAG 检索与智能体工具调用上下文,都要求特征新鲜度进入秒级甚至亚秒级。批量主导的特征存储被迫把流式作为一等公民。
- Embedding 成为一等特征类型。2024 年以前向量是独立赛道;2026 年 Tecton、Hopsworks、Feast 全部原生支持 vector dtype,并可把 Pinecone/Weaviate/Milvus/pgvector 注册为在线存储——向量库开始自我定位为”只做 embedding 的特征存储”,特征存储则把向量索引吸进同一个 SDK。
- 湖仓治理成熟。Databricks 把 Workspace Feature Store 合并进 Unity Catalog Feature Engineering、Snowflake 用 Snowpark + Feature Store 走同一条路、Iceberg + Polaris 阵营跟进——特征存储正从”产品”退化为”湖仓里的一层”。
这三点叠加,使 2025—2026 成为特征工程工具”死亡与重生”的转折年。
二、三代工具谱系:从”特征库”到”AI 上下文层”
2.1 第一代:开源特征存储基线(Feast)
Feast 起源于 Gojek、后捐赠给 Linux Foundation,是采用最广的开源特征存储。它的定位克制而清晰:不接管你的特征计算逻辑,只解决存储与服务。你用 Spark/Flink/SQL 把特征算出来写入 Feast,Feast 同时提供离线 SDK(给训练,按时间点批量取历史特征、保证时间穿越正确)和在线服务(给推理,毫秒级点查)。其价值在于灵活——自带在线/离线/计算引擎抽象,无厂商锁定,社区活跃(2026 年约 7,200+ GitHub Stars、40 万+ 月下载)。代价是流式计算被完全外推给你自己,监控与治理需要拼装外部可观测性工具。
2.2 第二代:托管实时特征平台(Tecton / Hopsworks)
Tecton 由 Uber Michelangelo 原班人马打造,把流式特征做成原生能力——你写一个 transformation,它负责 Spark Streaming 作业、状态管理与 exactly-once 物化,并内置新鲜度告警、数据质量与漂移检测,厂商宣称 sub-10ms p99。代价是高昂(生产级月费 $2,000–5,000,企业版 $50k+/年)与 SDK 强耦合导致的厂商锁定。Hopsworks 则走”中间路线”:开源 + 商业双轨,用 RonDB(MySQL NDB Cluster 分支)做在线存储实现亚毫秒一致性延迟,离线用 Hudi on 对象存储,自带漂移监测,比 Feast 开箱即用、比 Tecton 便宜。
2.3 第三代:事务型与实时新锐(Fennel / Chalk)+ 流批一体(FeatHub)
2022 年前后出现的两家新锐,在金融与支付领域迅速走红。Fennel 的差异化是”事务一致性”——同一用户的特征更新按支付/事件序列的顺序原子应用,并用 Rust 引擎 + Python 接口实现增量计算(仅重算变动部分,相较 Spark 提升 3–5 倍效率),无需 Spark/Flink。Chalk 让你用 Python 类定义特征、自动推导批与流两条路径,并把外部 API 调用(如征信响应)作为一等可缓存特征,推理时自动对特征图做拓扑排序;其 Rust 运行时可在 10 万 QPS 下做到 <5ms。两者 2025 年都被收购(Fennel→Stripe/Databricks,Chalk 仍独立 SaaS)。FeatHub(字节开源,Apache-2.0)则补上”流批一体”缺口:同一套声明式 Python SDK,开发期用 Local Processor(Pandas)单机实验,上线切到 Flink(毫秒级实时)或 Spark(高吞吐离线),无需改特征计算代码,内置 point-in-time 正确性与特征监控。
| 代际 | 代表工具 | 核心差异化 | 流式能力 | 治理/监控 | 典型成本/锁定 |
|---|---|---|---|---|---|
| 第一代 | Feast(开源) | 存储与服务解耦、云中立 | 弱(Push API,外推) | 基础,需拼装 | 免费软件、自运维、无锁定 |
| 第二代 | Tecton / Hopsworks | 托管实时 / 亚毫秒 RonDB | 强(Flink/Spark 原生) | 内置漂移与血缘 | 高订阅费 / 中高锁定 |
| 第三代 | Fennel / Chalk / FeatHub | 事务一致 / 图拓扑排序 / 流批一体 | 极强(Rust 引擎) | Fennel/Chalk 内置,FeatHub 有指标 | SaaS 或开源、局部锁定 |
三、2025—2026 并购重组:独立特征存储时代的终结
2026 年最戏剧性的变化是”独立特征存储”作为一个可投资品类正在消失。三条主线:
- Tecton → Databricks(2025 年 8 月)。Databricks 以”为部署 AI 智能体提供快速可靠的实时数据”为战略框架收购 Tecton,原 Tecton 的 sub-10ms 延迟、sub-100ms 新鲜度、99.99% 可用性数字,成为 Mosaic AI 智能体平台的延迟叙事。到 2026 年,”Tecton”基本指 Databricks 内部的”特征与上下文层”,独立产品品牌消失。
- Fennel → Stripe / Databricks(2025 年 4 月并购)。 transactional feature store 思想成为支付行业默认范式,Fennel 大概率作为 Stripe 内部反欺诈特征骨干存续。
- Hopsworks → “AI Lakehouse”(5.0,2026 年初)。把特征存储 + 湖表层(Iceberg/Delta/Hudi)+ 向量索引 + 亚毫秒 RonDB 服务层打包,定位”为 AI 而非分析设计”的湖仓,并加入 agent 驱动管线构建。
- Feast 0.18(2026 年 7 月)的 LLM 转向。原生 Apache Iceberg 支持(可读取任意 Iceberg catalog,含 Unity Catalog)、Ray 集成用于 RAG 训练、以及 OpenAI 兼容向量检索 API——智能体发纯文本查询,Feast 服务端 embedding 后按 OpenAI 标准 JSON 返回,消除了”先调 embedding 服务再调 Feast”的双 API 摩擦。
| 时间 | 事件 | 战略含义 |
|---|---|---|
| 2025-04 | Fennel 被 Stripe/Databricks 并购 | 事务型特征存储内化为支付/反欺诈骨干 |
| 2025-08 | Databricks 收购 Tecton | 实时特征服务 = AI 智能体上下文服务 |
| 2026 初 | Hopsworks 5.0 重定位 AI Lakehouse | 特征存储融入 AI 原生湖仓 |
| 2026-07 | Feast 0.18:Iceberg + 向量检索 API | 开源基线转向 LLM/RAG 与开放治理 |
四、湖仓融合论点:”特征存储是一层,而非一个产品”
自 2025 年起最强的趋势是特征存储被吸收进湖仓成为”一层”。决定性信号是 Databricks 把 Workspace Feature Store 合并进 Unity Catalog Feature Engineering;Snowflake 用 Snowpark + Snowflake Feature Store(2024 GA)走同一条路;Iceberg + Polaris/Tabular 阵营也在跟进。如果这一论点成立,到 2027—2028 年,独立”特征存储”品类只在超低频延迟/事务型利基(金融、广告)存活,主流 ML 活在湖仓内。前提是在线存储集成足够快——截至 2026 年 5 月,Online Tables/Bigtable 集成仍差一口气达不到金融级延迟。
一个被多数文章跳过的问题是:“能不能直接用 dbt + Redis?” 诚实的答案是——如果你的生产模型 ≤5 个、特征多为批量(小时/天级)、不要求亚分钟新鲜度、特征跨模型复用少、且有明确 owner 手写 point-in-time join 并保证一致、治理/审计压力轻,那么确实可以不用专门的特征存储。但只要命中以下任一条,专门的特征存储就是正确选择:模型数增长到数十/数百;流式特征需要 1 秒—1 分钟新鲜度;同一特征被 5 个以上模型共享;GDPR / EU AI Act / 国内数据合规要求血缘;反欺诈/推荐/广告走毫秒在线点查路径。
五、向量收敛:Embedding 成为一等特征类型
2024 年及以前,向量是独立于特征存储的赛道;2026 年 embedding 只是”另一种特征类型”。Tecton、Hopsworks、Feast 都原生支持 vector dtype,并允许把 Pinecone、Weaviate、Milvus 或 PostgreSQL pgvector 注册为在线存储。两个后果正在发生:其一,向量库日益自我定位为”只做 embedding 的特征存储”(Pinecone Serverless、Weaviate Cloud);其二,特征存储把向量索引吸进同一个 SDK(Hopsworks Vector Index 是最清晰的例子)。到 2027 年,两者边界将基本消失。本地 RAG 实践也印证这一点:BGE-M3、Cohere embed-v4 等”稠密—稀疏”混合嵌入成为标准,pgvector / Qdrant / Chroma 既存向量又存元数据,与特征存储的在线 KV 形态高度同构。这意味着做 RAG/知识库(如 kshare 这类私有知识库)的团队,其特征与向量资产将统一管理。
六、决策权衡矩阵:如何在新工具格局下选型
选型不再依赖功能清单,而取决于两个诚实问题:你的特征到底需要多实时?你的团队到底有多少运维产能去跑基础设施?在此基础上叠加治理、成本、云锁定、数据主权四个维度。
| 维度 | Feast(开源) | 云原生 FS(AWS/GCP) | Hopsworks | Databricks UC FE | Chalk/Fennel 类新锐 |
|---|---|---|---|---|---|
| 实时性 | 依赖所选在线库+调优 | 中(Bigtable/DynamoDB) | 亚毫秒(RonDB) | 强(Online Tables) | 极强(Rust 引擎) |
| 治理/血缘 | 基础+目录插件 | IAM 集成 | 强 | 极强(UC 行列级) | 强(含血缘) |
| 运维所有权 | 高(自管注册/在线/物化) | 低(托管) | 中(自管或 SaaS) | 极低(PaaS) | 低(SaaS) |
| 成本模型 | 仅自有算力 | 中 | 中低 | $100k+/年中型 | SaaS 计量 |
| 云锁定 | 无(云中立) | 强(绑定云) | 弱 | 强(绑定 DBR) | 中(SDK 耦合) |
选型口诀:
- 成本敏感、要完全控制、特征多为批量 → Feast + Iceberg/数仓。
- 整个 ML 栈已在一朵云、最小化集成摩擦 > 跨云可移植 → 选云原生 Feature Store。
- 已标准化 Databricks/Spark 湖仓 → 选Databricks UC FE(零集成、统一治理)。
- 要强于 Feast 但不想付 Tecton 价、且接受较新生态 → Hopsworks。
- 金融/支付、要求事务一致或超低频延迟、愿付 SaaS → Chalk / 内部化 Fennel。
- 实时流批一体、想用 Flink 又不想写分布式代码 → FeatHub。
七、落地路线(30 / 60 / 90 天)
- 前 30 天 — 基线收敛:选定一个开源基线(推荐 Feast + Iceberg,或若已在 Databricks 则 UC FE),把 5–10 个高价值、被多模型复用的核心特征管起来。建立命名规范 {entity}{signal}{agg}__{window},每个特征指定 owner(团队而非个人)。
- 30–60 天 — 实时与治理:引入流式特征(Flink/Spark Streaming 或 FeatHub),建立新鲜度 SLO 与漂移监控(分布漂移、空值率、基数爆炸、时间新鲜度)。落地数据契约:上游 schema 变更自动检测 + 受影响 feature view/模型血缘图 + 不兼容变更拦截。
- 60–90 天 — 收敛与融合:把向量/embedding 资产并入特征治理体系(统一在线 KV + 向量索引),打通模型—特征双向图(特征消失即刻列出受影响模型),评估是否向湖仓一体(UC / Snowflake)收敛以消除双写。
八、七红旗:避免踩坑
- 红旗一:用特征存储却仍手写两套转换逻辑——等于没解决 skew,定义必须单一真相源。
- 红旗二:把特征存储当数据仓库用——它优化点查与时间点连接,不适合交互式分析,探索性分析回数仓。
- 红旗三:忽略 point-in-time 正确性——历史特征取数若不加时间约束,未来泄露进训练,离线指标虚高。
- 红旗四:无 owner、无命名规范——特征库迅速累积孤儿特征、语义重复,技术债失控。
- 红旗五:监控只盯模型不盯特征——不观测特征漂移会浪费整轮重训练,应先区分”模型退化”与”数据/特征退化”。
- 红旗六:为实时而实时——亚秒新鲜度只在反欺诈/广告/智能体上下文路径上值得其成本,批量场景强行上流式是过度工程。
- 红旗七:忽视本地主权与合规——受监管行业(金融/医疗)优先考虑自托管(Feast/Hopsworks)或数据驻留方案,而非纯 SaaS。
参考来源
- LabHub — Feature Stores 2026 Deep Dive(Feast/Tecton/Hopsworks/Databricks/Chalk/Fennel 全景与对比表)
- Scaler — What Is Feature Store? Feast vs Tecton
- Zaira Labs — Feast 工具指南(2026)
- Deploybase — Best Feature Store Platforms: Feast vs Tecton vs Hopsworks(2026-03)
- Codebridge HQ — Feature Store Design & Management 2026
- Chalk 官网 — Real-Time AI Data Platform
- Antler — Real-time data infra: the sub-second revolution(Chalk/Fennel)
- 亿欧数据 — Fennel AI 公司档案(2025 并购 Databricks)
- Beefed AI(中文)— 企业级可扩展特征存储设计与治理
- 云图网 — 数据中台与 AI 中台的融合(Feast/Tecton 选型)
- Inferensys — Databricks Feature Store vs Feast
- Databricks 文档 — Databricks Feature Store(Unity Catalog)
- Microsoft Learn — Databricks Feature Store overview and glossary
- GitHub — FeatHub: stream-batch unified feature store
- 今日头条 — 流批一体的实时特征工程平台建设实践
- 极客时间 — FeatHub:流批一体的实时特征工程平台
- CSDN — 主流特征工程平台对比(Feast/Feathr/OpenMLDB/FeatHub/Tecton/Hopsworks)
- Refonte Learning — Tecton Doesn’t Exist Anymore: 2026 Feature Store Consolidation
- Datarekha — Feature stores in 2026: Tecton, Feast, Hopsworks — death and rebirth
- Reintech — Feature Store Comparison 2026: Feast vs Tecton vs SageMaker
- PiStack — Feast vs Featureform vs Hopsworks: Self-Hosted ML Feature Store 2026
- Plus8Soft — Building a Local RAG System in 2026(embedding/向量)
- The Neural Base — Feast Native Unity Catalog Integration