特征工程新工具生态图谱(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 天)

  1. 前 30 天 — 基线收敛:选定一个开源基线(推荐 Feast + Iceberg,或若已在 Databricks 则 UC FE),把 5–10 个高价值、被多模型复用的核心特征管起来。建立命名规范 {entity}{signal}{agg}__{window},每个特征指定 owner(团队而非个人)。
  2. 30–60 天 — 实时与治理:引入流式特征(Flink/Spark Streaming 或 FeatHub),建立新鲜度 SLO 与漂移监控(分布漂移、空值率、基数爆炸、时间新鲜度)。落地数据契约:上游 schema 变更自动检测 + 受影响 feature view/模型血缘图 + 不兼容变更拦截。
  3. 60–90 天 — 收敛与融合:把向量/embedding 资产并入特征治理体系(统一在线 KV + 向量索引),打通模型—特征双向图(特征消失即刻列出受影响模型),评估是否向湖仓一体(UC / Snowflake)收敛以消除双写。

八、七红旗:避免踩坑

  • 红旗一:用特征存储却仍手写两套转换逻辑——等于没解决 skew,定义必须单一真相源。
  • 红旗二:把特征存储当数据仓库用——它优化点查与时间点连接,不适合交互式分析,探索性分析回数仓。
  • 红旗三:忽略 point-in-time 正确性——历史特征取数若不加时间约束,未来泄露进训练,离线指标虚高。
  • 红旗四:无 owner、无命名规范——特征库迅速累积孤儿特征、语义重复,技术债失控。
  • 红旗五:监控只盯模型不盯特征——不观测特征漂移会浪费整轮重训练,应先区分”模型退化”与”数据/特征退化”。
  • 红旗六:为实时而实时——亚秒新鲜度只在反欺诈/广告/智能体上下文路径上值得其成本,批量场景强行上流式是过度工程。
  • 红旗七:忽视本地主权与合规——受监管行业(金融/医疗)优先考虑自托管(Feast/Hopsworks)或数据驻留方案,而非纯 SaaS。

参考来源