ML 特征存储架构：在线与离线一致性保障

特征存储（Feature Store）解决的是 ML 系统里最阴险的一类 bug：训练-服务偏差（training-serving skew）——训练时用一套逻辑算特征、线上服务时用另一套，两边悄悄不一致，模型离线指标漂亮、上线就拉胯。本文讲清这个问题的三种来源、特征存储的标准架构、point-in-time 正确性，以及"要不要上特征存储"的诚实判断。

一、训练-服务偏差的三个来源

计算逻辑不一致：训练管道用 Spark/SQL 算"近 30 天订单数"，线上服务用另一段 Java 代码重新实现——两边对"30 天"的边界、时区、去重处理细节不同,偏差就进来了

时间泄漏（time leakage）：训练样本用了"未来"的数据——例如用全量历史算出的用户均值去训练预测上周行为的模型,离线指标虚高,线上还原不了

新鲜度差异：训练用 T-1 批数据,线上是实时流——同一特征在两个环境天然不同步

特征存储的核心承诺：特征定义一次、两处一致地取用。

二、标准架构

text
特征定义（代码,版本化）
   │ 一套转换逻辑
   ├── 离线存储（Parquet/数仓）──→ 训练：point-in-time join 取历史快照
   └── 在线存储（Redis/DynamoDB）──→ 服务：毫秒级按 key 取最新值
        ↑ 物化（batch 定时回填 + streaming 实时更新）

离线侧存全量历史,供训练与回测;在线侧只存每个实体的最新特征值,供低延迟推理

物化（materialization）是同步机制:同一份定义算出的值写进两个存储——一致性由"单一定义"保证,而不是靠两队人小心

Point-in-time join 是训练侧的关键操作:为每条训练样本取"该样本时间点当时"的特征值,从机制上杜绝时间泄漏。这是特征存储最难自己手搓对的部分

主流选择:开源 Feast（最常用的入门标准）、Tecton（托管商业版）、各云厂商自带（SageMaker/Vertex 特征存储）、以及 Databricks/Snowflake 生态内置方案。

三、什么时候真的需要它

需要：多个模型复用同一批特征、在线推理有实时特征需求（风控/推荐/定价）、团队≥几人且训练与服务由不同人维护——这时"单一定义"的协调价值兑现。

不需要：单模型、批量预测、特征都能在请求时现算——一张离线特征表 + 请求时计算就够,上平台是过度设计。诚实的经验法则:第一次被训练-服务偏差咬过之后再上,你会知道自己在买什么。

LLM 时代的注脚：RAG/Agent 应用的"特征"多是文本与嵌入,走向量库与提示词组装路线;但当 LLM 应用需要结构化用户特征进提示词（"该用户近 30 天活跃度"）,特征存储的在线侧正好是那个取数端点——两套基础设施在 Agent 系统里正在合流。传统表格类 ML（保险定价、风控）仍是特征存储的主场。

四、落地要点

特征定义进版本控制,改动走 review——特征是共享 API,随手改会无声破坏下游模型

监控两侧一致性:定期抽样对比在线值与离线重算值,偏差超阈值告警（画像式监控同样适用于特征分布漂移）

新鲜度 SLA 显式化:每个特征标注"多旧算过期",线上取到过期值时的降级行为（用默认值/拒绝预测）写进代码

从 Feast + 现有基础设施起步（离线用现有数仓、在线用现有 Redis）,验证工作流再谈托管平台

FAQ

Q：特征存储和数据仓库什么关系？ 数仓是离线侧的底座;特征存储在其上加了"在线服务 + point-in-time 语义 + 定义复用"三件数仓不管的事。

Q：实时特征(流式)必须上 Flink 吗？ 看新鲜度要求:分钟级用微批回填就够;秒级（反欺诈）才需要流式管道,复杂度高一个量级,别为用而用。

Q：和 MLOps 的模型注册表怎么配合？ 注册表管模型版本,特征存储管特征版本——训练记录里同时钉住两者的版本号,才能完整复现一次训练（注册表实践同理）。

---

*最后更新：2026 年 6 月。*