一、为什么单讲「实时」：特征演进路线上最陡的一段斜坡
此前我们已梳理过特征工程的代际总览。本文聚焦其中斜坡最陡的一段：实时特征计算的技术演进路线。它回答一个具体问题——当业务决策（支付风控、动态定价、个性化推荐、AI Agent 自主行动）依赖「刚刚发生的事实」时，特征体系应当如何从 T+1 批处理一步步演进到毫秒级在线特征服务。
2026 年这一领域发生了结构性变化：Databricks 宣布其特征平台实现 Kafka 事件到在线特征可用的 p99 200ms 端到端新鲜度；Snowflake 推出 Online Feature Store 公测；独立特征平台厂商 Tecton、Featureform 相继被并购；开源侧 Feast 则全面转向 LLM 与检索增强场景。把这些信号拼在一起，可以清晰看到实时特征计算的下一段路线。
二、四阶段演进：从批处理到 Agent 上下文服务
| 阶段 | 时间背景 | 计算方式 | 典型新鲜度 | 核心矛盾 |
|---|---|---|---|---|
| ① 批处理时代 | 2015 年前后及更早 | 定时任务按天/小时计算，结果回填在线缓存 | 小时级到天级 | 特征陈旧，短窗口信号完全缺失 |
| ② Lambda 双链路 | 2017-2021 | 批处理层算历史基线，速度层算实时增量，合并层对齐结果 | 秒级（实时侧） | 两套代码、两套语义，一致性维护成本极高 |
| ③ 流批一体 / Streaming-first | 2022-2025 | Flink/Spark 流式引擎同时回填历史与供给在线，一份定义双写离线与在线两层 | 亚秒级 | 状态管理复杂、回补困难、维护门槛高 |
| ④ 平台原生实时与 Agent 上下文 | 2025-2026 | 数据平台内建实时特征能力（滚动窗口 + 流式 JDBC 写入 + 模型服务直读），特征定义即基础设施 | 200ms p99 甚至亚秒内 | 厂商锁定 vs 开源自治；新鲜度 目标 的端到端度量 |
第四阶段的一个重要推力来自 AI Agent：Agent 自主审批交易、生成个性化报价、路由工单，其决策依据是「最近 15 分钟的账户行为」「当前库存水位」这类极易过期的信号。用 45 分钟前的特征做信贷决策，可能放行一个期间内已超额支出的用户。特征服务因此从「模型的前置步骤」升格为「Agent 与数据之间的低延迟上下文层」。
三、三个关键技术转折点
转折点一：窗口语义从「边界对齐」走向「事件回溯」
实时特征的新鲜度上限，首先由窗口语义决定。以 Databricks 公开的技术细节为例，其特征平台同时支持三种窗口，但 200ms 目标 只有滚动窗口能够兑现：
| 窗口类型 | 更新触发 | 陈旧特征为 | 能否支撑 200ms 目标 |
|---|---|---|---|
| 翻滚窗口（tumbling） | 仅在对齐的时间边界输出 | 边界内持续陈旧 | 不能，浪费流式投入 |
| 滑动窗口（sliding） | 固定步长重叠输出 | 陈旧度减半但边界问题仍在 | 不能，存在边界延迟下限 |
| 滚动窗口（rolling） | 每个事件到达即更新，从事件时间戳向后回溯 | 毫秒级分辨率，事件驱动 | 能，唯一满足项 |
配套的状态管理同样关键：每个滚动聚合（如「近 10 分钟交易总额」）在每个实例上维护本地 RocksDB 状态，读-增-写全程在内存完成，只有特征值跨越网络写入在线层；检查点开销被摊薄到事件流中而非逐行阻塞。这组设计把「窗口边界等待」从延迟预算里彻底移除。
转折点二：特征加工模式从 ETL 预计算走向 ELT 即时加工
国内头部团队（如众安金融）的实践给出了另一条重要经验：实时特征加工存在两条路线——
- ETL 预计算模式：实时任务把特征提前算好写入在线层，查询极快，但特征衍生困难、计算资源消耗大，每新增一个特征都要改动流式任务；
- ELT 即时加工模式：实时只同步业务明细到高速在线存储，查询时按配置的表达式即时计算特征。特征衍生灵活、上线周期短，代价是查询路径更重，需要高性能点查引擎支撑。
两条路线没有绝对优劣：高 QPS、特征集合稳定的风控场景偏向 ETL 预计算；特征需求频繁衍生的信贷与营销场景偏向 ELT 即时加工。成熟平台往往是两者的混合，由特征网关按特征登记信息路由到不同计算路径。
转折点三：一份特征定义贯穿离线与在线，系统性消除训练-服务偏差
训练-服务偏差（training-serving skew）是实时特征演进十余年来始终的宿敌：训练用 SQL、服务用另一套代码，窗口边界、空值处理、连接语义的细微差异都会造成线上线下特征不一致。2026 年的主流答案已经收敛为：特征只定义一次，训练侧通过时间点正确（point-in-time correct）连接取历史值，服务侧读取同一份定义的物化视图或在线值；平台再做离线/在线同值比对，偏差超阈值即提醒。RisingWave 等流式 SQL 引擎甚至把「特征即物化视图」推到极致：定义即服务，天然消除双路径。
四、2025-2026 格局剧变：独立特征平台的终结与平台原生实时化
| 玩家 | 2025-2026 动向 | 路线含义 |
|---|---|---|
| Tecton | 2025 年 8 月被 Databricks 收购，品牌并入 Mosaic AI，独立产品不复存在 | 特征服务被重新定义为「AI Agent 的实时数据层」，独立厂商赛道终结 |
| Featureform | 2025 年 10 月被 Redis 收购，开源仓库停止更新 | 特征能力向存储厂商下沉 |
| Databricks | Spark Real-Time Mode + Lakebase + Model Serving，Kafka 到在线特征 200ms p99 | 湖仓一体平台原生实时特征，一份定义跑批与流 |
| Snowflake | 2026 年 7 月 Online Feature Store 公测，托管 Postgres 服务层 + REST API | 把在线特征纳入受治理的数据平台，减少数据搬运 |
| Feast | 开源持续演进：原生 Iceberg 支持、Ray 集成、OpenAI 兼容向量检索接口 | 开源基线转向 LLM/检索增强与 Agent 场景 |
| Hopsworks | 重定位为 AI Lakehouse，RonDB 亚毫秒在线服务，SIGMOD 基准宣称优于云厂商特征库 | 最后一个独立特征平台厂商，主打「为 AI 而生」 |
| RisingWave 等 | 流式 SQL 引擎直接充当实时特征计算与在线服务层 | 「特征即物化视图」的轻量路线，适合中小团队 |
格局结论：「卖一个独立特征平台」的生意已经结束，特征能力正在向三个方向收敛——云数据平台内建、开源基线自治、流式引擎轻量替代。选型重心从「用不用特征平台」转向「特征能力长在谁的底盘上」。
五、决策权衡与分阶段落地路线
综合多源资讯，实时特征能力不必一步到位。推荐的演进式落地路线：
- 第一步：特征登记 + 离线时间点正确连接。先建立最小特征登记表与离线训练集生成能力，这是所有后续投入的地基；此时不必引入在线层。
- 第二步：按需补在线层。只有当真实存在毫秒级读取诉求时才引入在线存储（Redis/DynamoDB/托管服务层），并为每个特征定义新鲜度目标（SLO），避免「所有特征都实时」的过度建设。
- 第三步：引入流式计算与双写。用 Flink/Spark 流式链路同时填充离线与在线两层，配套精确一次语义、水位线与回补策略；此阶段务必建立离线/在线同值比对。
- 第四步：向平台原生或流式 SQL 收敛。当团队规模与特征复用度足够高，评估数据平台内建实时特征能力或流式 SQL 物化视图，削减自建链路的维护成本。
三条关键权衡：
- 新鲜度 vs 成本：读延迟（p95 常要求 10ms 内）、更新延迟、吞吐三个维度都要分别定预算；为不需要实时的决策付实时成本是最常见的浪费。
- 一致性 vs 灵活性：ELT 即时加工灵活但查询重，ETL 预计算快但衍生难；按特征族分治，而非全局一刀切。
- 回补能力 vs 短期简单：不能回补历史特征的流式链路，会在下一次重训时变成技术债；Databricks 方案故障后最多回放 5 分钟 Kafka 数据即是明示的取舍。
六、实践经验：头部团队的量化收益
- 携程（Flink 实时特征平台）：酒店推荐接入「最近 30 分钟搜索行为」实时特征后，点击率提升 12%、订单转化率提升 8%；支付风控实时计算终端指纹、IP 异常度等特征，欺诈拦截率提升 8%-20%，误报率下降 3%-15%。工程要点：滚动/滑动/会话窗口按业务选择、RocksDB 状态后端 + 状态 TTL 清理、特征版本可回滚。
- 众安金融（实时特征平台）：一次风控策略会放大出数百倍特征查询，因此采用特征网关（鉴权、限流、编排）+ ID-Mapping 多主体路由 + TableStore 高速点查的分层架构；反欺诈特征在流式链路直接算好写入 Redis 与图存储，满足高性能查询；主副表并发更新不一致问题用窗口补偿任务兜底。
- 全球支付机构（公开案例）：Flink 有状态计算 + Redis 亚毫秒读取 + 离线在线共享特征 SDK，风控判定延迟从 500ms 降至 45ms，检出率提升 23%，误报下降 35%，特征服务可用性 99.99%。核心教训是熔断与降级策略必须覆盖每一条特征计算路径。
- 电商推荐（公开案例）：Kafka 会话事件 + Cassandra 短期会话特征 + 预计算历史特征混合，首次访问用户推荐相关度提升 52%，活跃会话转化率提升 18%，支撑 20 万级并发会话。
共性方法论可以归纳为四条：① 特征新鲜度按用例分级而非全局实时；② 离线/在线一份定义 + 同值比对；③ 特征质量（覆盖度、稳定性、业务相关性）持续观测并设阈值；④ 每条查询路径都要有熔断、降级与兜底值。
七、演进趋势判断
- 实时特征即 Agent 基础设施：特征服务的新叙事是「Agent 的低延迟上下文层」，200ms 级新鲜度将成为平台标配而非卖点。
- 滚动窗口 + 内存状态 + 分离式在线存储构成实时特征的标准技术栈；窗口语义的选择直接决定 目标 可达性。
- 特征定义收敛为单一代码路径（SQL/声明式为主），训练与服务共享同一物化定义，训练-服务偏差从「靠纪律」变为「靠架构」。
- 开源与平台原生长期能够共存：受监管、重自治的团队走 Feast/Hopsworks 自建路线；已深耕单一云数据平台的团队走 Databricks/Snowflake 原生路线；轻量团队用流式 SQL 引擎一步到位。
- 向量检索并入特征服务边界：Feast 的 OpenAI 兼容检索接口预示结构化特征与非结构化嵌入将在同一服务层供给，特征工程与检索增强的边界正在模糊。
参考来源
- RisingWave: Real-Time Feature Store in 2026 — Beyond Batch ML Pipelines
- ai|expert: Databricks Feature Store hits 200ms p99 latency via Spark RTM
- Superpower Daily: Databricks Pushes Feature Stores From Batch Lag to 200ms Freshness
- ai|expert: Databricks Feature Store Cuts ML Feature Latency to 200ms（窗口语义与 RocksDB 状态细节）
- Snowflake Help: Online Feature Store Public Preview（2026-07）
- datarekha: Feature stores in 2026 — Tecton, Feast, Hopsworks, death and rebirth
- Hivebook: Feast — Open-Source Feature Store（含 Tecton/Featureform 并购时间线核实）
- Refonte Learning: Inside 2026’s Feature Store Consolidation（Feast 转向 LLM 场景）
- Beehive Strategy: 实时数据流驱动的 AI 决策（Kappa 架构与流式特征存储）
- Habsi Tech: Feature Stores Explained（三条计算路径与架构模式）
- ZDNet Inside: How Do Real-Time Feature Stores Work, and When Are They Worth the Cost?
- Ken W. Alger: Infrastructure Thinking for Real-Time Inference at Scale
- 百度智能云：携程基于 Flink 的实时特征平台
- 百度智能云：携程 Flink 实时特征平台——技术演进与业务赋能实践
- 腾讯云开发者社区：众安金融实时特征平台实践（ELT 即时加工路线）
- Simor Consulting: Comprehensive Guide to Real-Time Feature Engineering（风控/电商/工业案例）