Lakebase能否替代Redis做在线特征存储？

引言：特征存储的技术选型难题

在现代机器学习系统中，特征存储（Feature Store）是连接数据工程与模型服务的关键基础设施。它负责在训练和推理两个阶段之间保持特征一致性，尤其是「在线特征存储」（Online Feature Store），需要在毫秒级延迟下为实时推理提供最新的特征数据。

特征存储的概念最早由 Uber 在 2017 年通过其内部平台 Michelangelo 公开提出，随后 Feast（开源）、Tecton、Hopsworks 等项目相继涌现。特征存储解决的核心问题是「训练-推理偏差」（Training-Serving Skew）：如果训练时使用的特征计算逻辑与推理时不一致，模型性能会严重退化。其三层架构——特征注册表（Feature Registry）、离线存储（支持 Point-in-Time Join 回填历史特征）和在线存储（按实体键点查最新值）——共同保障了端到端的一致性。

长期以来，业界的默认选择是 Redis、Cassandra 这类专门的低延迟 KV 存储或宽列数据库。然而随着 Databricks 推出 Lakebase 这类新型湖仓一体（Lakehouse）事务型数据库，一个值得探讨的问题浮出水面：能否用 Lakebase 直接承载在线特征存储，从而简化整个架构栈？

近期 Reddit 社区中就有开发者抛出了这个疑问，希望了解在真实生产环境中使用 Lakebase 作为在线特征后端的延迟表现、更新频率以及运维取舍。这篇文章将围绕这一话题展开分析。

在线特征存储的核心诉求

要判断 Lakebase 是否适合，首先要明确在线特征存储的硬性要求。

极低的读取延迟

在线推理路径对延迟极为敏感。一个典型的推荐或风控系统，单次请求可能需要拉取数十甚至上百个特征，而整个特征查询的预算往往只有几毫秒。这也是 Redis 长期占据主导地位的核心原因——纯内存架构可以稳定提供亚毫秒级的点查询延迟（P99 通常在 1-2ms 以内）。

Redis 之所以成为在线特征存储的事实标准，不仅因为其亚毫秒级延迟，还因为其数据结构的灵活性——Hash 类型天然适合存储实体的多个特征字段。Redis Cluster 提供了水平扩展能力，而 Redis on Flash 则允许将热数据保留在内存、冷数据下沉到 SSD，降低成本。但 Redis 的劣势同样明显：内存成本高昂（尤其是特征维度较多时），缺乏原生的 Schema 管理和版本控制，与数据湖/仓之间的同步管道需要额外构建和维护，且在大规模场景下的持久化策略（RDB/AOF）可能带来 fork 延迟和写放大问题。

高并发与稳定的尾延迟

生产环境中特征存储往往要承受每秒数万到数十万次的 QPS。相比平均延迟，更关键的是 P99、P999 尾延迟的稳定性。任何 GC 停顿、磁盘 IO 抖动都可能拖累整体的推理 SLA。

在分布式系统中，尾延迟的影响远超直觉。假设一次推理请求需要并行查询 100 个特征，即使单次查询的 P99 延迟为 5ms，整个请求的延迟将由最慢的那次查询决定——这就是所谓的「尾延迟放大」效应（Tail at Scale，由 Google Jeff Dean 在 2013 年系统阐述）。当并行度为 100 时，至少有一次查询超过 P99 阈值的概率约为 63%。这意味着在线特征存储实际需要优化的目标是 P999 甚至 P9999，而 GC 停顿、后台压缩、对象存储的长尾响应等都是导致尾延迟飙升的常见原因。

灵活的更新频率

特征的新鲜度需求差异很大：

• 批量特征：可能每天或每小时从数据仓库刷新一次；
• 近实时特征：通过流处理每几分钟或几秒更新；
• 实时特征：请求时动态计算或秒级更新。

一个理想的在线存储需要同时支持这几种写入模式。

Lakebase 作为特征后端的潜在优势

Lakebase 是 Databricks 生态中面向事务型工作负载的数据库层，它的设计目标之一就是弥合分析型湖仓与低延迟操作型场景之间的鸿沟。

湖仓一体架构的演进背景

湖仓一体架构是 Databricks 在 2020 年正式提出的概念，旨在融合数据湖的灵活性与低成本存储，以及数据仓库的事务性、Schema 管理和高性能查询能力。其技术基石是 Delta Lake——一个构建在对象存储（如 S3、ADLS）之上的开源事务层，通过事务日志实现 ACID 语义、时间旅行和 Schema Evolution。传统的湖仓架构主要面向分析型工作负载，读取延迟在秒到分钟级别，并不适合在线服务。Lakebase 的出现正是为了补齐这一短板，将 OLTP 级别的低延迟读写能力引入湖仓生态。

从已知信息推断，Lakebase 可能采用了存算分离架构，底层仍基于对象存储但通过多层缓存（本地 SSD + 内存）加速热点数据访问。它支持标准 SQL 接口和行级事务，与 Unity Catalog 原生集成实现统一治理，并具备与 Delta Lake 表的双向同步能力。这使得它在概念上非常适合作为湖仓生态中的「服务层」。

架构统一，减少数据同步

传统方案中，特征需要先在湖仓中批量计算，再通过 ETL 管道推送到独立的 Redis/Cassandra 集群，这带来了额外的同步延迟、一致性风险和运维成本。如果 Lakebase 能同时承担离线计算结果的存储与在线服务，理论上可以消除跨系统的数据搬运，让离线特征和在线特征天然共享同一份数据源。

跨系统的数据搬运不仅带来延迟，更隐含深层的一致性风险。常见问题包括：特征计算逻辑在离线（Spark/SQL）和在线（应用代码）之间的实现不一致；批量同步过程中因 Schema 变更导致字段缺失或类型不匹配；以及时间窗口差异——离线训练使用 T-1 的数据，而在线推理可能因同步延迟实际使用的是 T-2 的数据。Lakebase 如果能实现「单一数据源」模式，即离线计算结果直接写入同一张表、在线查询也从同一张表读取，就能从根本上消除这类偏差风险。

降低运维复杂度

维护一套独立的 Redis 集群意味着需要处理内存管理、持久化、分片、故障转移等一系列问题。将特征收敛到湖仓平台内部，可以复用平台已有的权限管理、监控和治理能力，对小型团队尤其有吸引力。

作为对比，Apache Cassandra 虽然是另一个常见的在线特征存储后端（被 Netflix、Instagram 等公司大规模使用），其线性扩展能力和更低的单位存储成本具有优势，但调优复杂性——压缩策略（Compaction Strategy）、一致性级别、Bloom Filter 配置等——同样让小型团队望而却步。Lakebase 作为托管服务，有望将这些运维负担转嫁给平台提供方。

关键挑战与取舍

尽管统一架构诱人，但直接用 Lakebase 替代专用在线存储仍面临几个需要验证的核心问题，这也正是原帖发起者最关心的部分。

延迟能否达标

这是最大的未知数。以内存为核心的 Redis 与基于存储层构建的数据库在点查询延迟上存在数量级差异。Lakebase 虽然定位为事务型数据库，但要稳定支撑推理路径所需的个位数毫秒延迟，仍需在真实高并发负载下验证其 P99 表现。对于延迟不那么敏感的场景（如离线批推理、部分风控规则），门槛会低很多。

具体而言，Redis 的点查询延迟通常在 0.1-1ms（P99），而基于磁盘/对象存储的数据库即使配备缓存层，冷查询延迟也往往在 5-50ms 范围内。Lakebase 能否通过积极的内存缓存策略将热点特征的读取延迟压缩到 5ms 以内，并在缓存未命中时保持可预测的降级延迟，是决定其适用范围的关键分水岭。

更新频率与写入吞吐

特征存储的写入模式和典型 OLTP 事务不同——往往是大批量、高频次的 upsert。需要评估 Lakebase 在持续高频写入下是否会引起延迟抖动，以及流式更新（如 Structured Streaming 写入）的端到端新鲜度能否满足业务需求。

Upsert（INSERT ON CONFLICT UPDATE）是特征存储最核心的写入模式：每个实体的特征值需要被持续覆盖更新。在列存或 LSM-Tree 架构中，频繁的 upsert 会带来写放大问题——同一行数据可能以多个版本存在于不同的文件中，需要通过后台压缩合并。Delta Lake 的 MERGE INTO 操作虽然支持 upsert 语义，但在高频小批量场景下的延迟和吞吐表现与专门为此优化的 KV 存储仍有差距。Lakebase 能否在底层针对这种高频覆盖写入进行专门优化，是其能否胜任特征存储场景的关键技术问题。

关于流式更新，Databricks 的 Structured Streaming 支持微批和连续处理两种模式。微批模式的典型触发间隔在数秒到数分钟之间，端到端延迟通常在 10 秒到数分钟级别。如果使用 Structured Streaming 将实时事件转化为特征并写入 Lakebase，那么端到端新鲜度 = 事件到达延迟 + 流处理延迟 + 写入到可见延迟。对于「近实时特征」场景（如用户最近 5 分钟的点击次数），这个链路能否在 30 秒内闭环是一个关键验证点。

运维取舍的再平衡

统一架构减少了系统数量，却也可能带来新的耦合风险：分析型查询与在线推理查询争抢资源、成本模型变化、以及平台锁定等问题。是否值得，取决于团队的规模、现有技术栈和延迟容忍度。

实践建议：如何评估 Lakebase 的适用性

对于正在考虑这一方案的团队，可以从以下角度评估：

1. 先做延迟基准测试：在目标 QPS 下测量 Lakebase 的 P50/P99/P999 点查询延迟，与现有 Redis 方案对比。特别注意在缓存冷启动和持续写入期间的延迟表现。
2. 分层设计：将延迟极度敏感的高频特征保留在 Redis，将更新频率低、延迟容忍度高的特征迁移到 Lakebase，形成混合架构。这也是 Feast 等开源特征存储推荐的多后端策略。
3. 验证新鲜度链路：测量从上游数据变更到在线特征可见的端到端延迟，确认是否满足业务 SLA。重点关注流式写入的触发间隔配置与写入可见性之间的关系。
4. 评估总拥有成本：不要只看单一组件，而要综合运维、同步管道、人力成本进行整体核算。包括因平台锁定带来的长期风险。

结语

用 Lakebase 承载在线特征存储，本质上是架构统一性与极致低延迟之间的权衡。对于延迟要求苛刻的核心链路，专用的 Redis/Cassandra 短期内仍难以被完全替代；但对于中低频、追求架构简洁的场景，湖仓一体数据库确实提供了一个有吸引力的新选项。

目前社区中相关的生产实践分享还相对稀缺，这也正是原帖希望收集真实经验的原因。随着湖仓事务型能力的持续演进，特征存储的技术选型格局或许会在未来发生实质性变化——但在此之前，充分的基准测试和分层设计仍是最稳妥的路径。