3. 实时特征存储选型：Redis、HBase、Druid、TiKV 对比与适用场景
实时特征存储是 Feature Store 的核心基础设施，它直接决定了特征写入延迟、查询吞吐量、数据一致性以及运维成本。当前业界主流的实时特征存储方案包括 Redis、HBase、Druid 和 TiKV，它们在数据模型、一致性模型、扩展能力和典型场景上存在显著差异。本节将从实时特征工程的实际需求出发，对这四种存储系统进行系统性对比，并给出选型建议。
3.1 实时特征存储的核心需求
在进入具体选型之前，需要明确实时特征存储必须满足的几项关键能力：
- 低延迟写入与读取：特征写入通常要求在毫秒级完成，在线推理场景下特征查询的 P99 延迟应低于 10ms。
- 高并发访问：在线服务可能面临每秒数万甚至数十万次的特征查询请求。
- 数据一致性：特征更新后，下游模型应能立即读到最新值（强一致性或最终一致性需根据场景权衡）。
- 水平扩展：特征数量随业务增长，存储系统应支持在线扩缩容。
- TTL 与过期管理：实时特征通常具有时效性，系统需支持自动过期清理。
3.2 四种存储系统核心特性对比
| 特性维度 | Redis | HBase | Druid | TiKV |
|---|---|---|---|---|
| 数据模型 | Key-Value / 多种数据结构 | 宽表（RowKey + 列族 + 时间戳） | 时序事件（时间戳 + 维度 + 指标） | 分布式 Key-Value（支持事务） |
| 一致性模型 | 最终一致性（集群模式） | 强一致性（单行） | 最终一致性（近实时） | 强一致性（Raft 共识） |
| 写入延迟 | < 1ms（单机） | 2-10ms | 秒级（批量导入） | 1-5ms |
| 查询延迟 | < 1ms（点查） | 5-20ms（点查） | 100ms-数秒（聚合查询） | 1-5ms（点查） |
| 高并发能力 | 极高（单机 10w+ QPS） | 高（依赖 Region 分布） | 中（适合 OLAP 场景） | 高（分布式架构） |
| 水平扩展 | 集群模式（Proxy / Redis Cluster） | 原生支持（Region 分裂） | 原生支持（Segment 分片） | 原生支持（Raft Group 分裂） |
| TTL 支持 | 原生（EXPIRE / 淘汰策略） | 需自行实现（TTL 列族） | 原生（基于时间窗口） | 需自行实现（GC 机制） |
| 运维复杂度 | 低 | 高（依赖 HDFS / ZK） | 中（依赖 ZK / 深度存储） | 中（依赖 PD 组件） |
3.3 各存储系统的适用场景分析
3.3.1 Redis：在线特征缓存的首选
Redis 凭借其极致的读写性能和丰富的数据结构，成为实时特征缓存层的事实标准。在 Feature Store 架构中，Redis 通常作为 在线特征存储，用于存放模型推理时需要实时访问的特征数据。
- 适用场景：高并发点查、特征维度固定、数据量在内存可承受范围内（通常单机几十 GB 到几百 GB）。
- 典型用法：使用 Hash 结构存储用户画像特征，Key 为用户 ID，Field 为特征名，Value 为特征值。
- 注意事项：内存成本高；集群模式下跨 Slot 的批量操作性能下降；数据持久化需额外配置 AOF/RDB。
# 特征写入示例（用户实时行为特征）
HSET user:10086 click_count 42 purchase_amount 1299.50 last_category "electronics"
EXPIRE user:10086 3600 # 1小时过期
# 特征读取
HGETALL user:10086
3.3.2 HBase：海量特征数据的可靠存储
HBase 基于 HDFS 提供海量数据的随机读写能力，适合存储 历史特征宽表 或 长周期特征。其强一致性和自动 Region 分裂机制使其能够承载 PB 级特征数据。
- 适用场景：特征维度极多（数千列）、数据量超过内存容量、需要存储特征的历史版本。
- 典型用法：RowKey 设计为 user_id + feature_family，列族按特征类型划分（如行为特征、画像特征）。
- 注意事项：查询延迟相对 Redis 较高；RowKey 设计直接影响查询性能；需要维护 HDFS 和 ZooKeeper 集群。
3.3.3 Druid：时序特征聚合与分析
Druid 专为时序数据设计，支持秒级数据摄入和亚秒级聚合查询。在 Feature Store 中，Druid 通常用于 实时特征计算后的聚合结果存储，以及 特征监控与回溯分析。
- 适用场景：基于时间窗口的聚合特征（如过去 1 小时点击率）、特征分布统计、异常检测。
- 典型用法：将实时流计算（Flink）产出的窗口聚合结果写入 Druid，供离线分析和在线查询使用。
- 注意事项：单条记录更新成本高（Druid 以追加为主）；不适合高频点查；数据近实时可见（通常延迟 1-10 秒）。
3.3.4 TiKV：强一致性与分布式事务场景
TiKV 作为分布式 Key-Value 存储，通过 Raft 协议提供强一致性和高可用性。在 Feature Store 中，TiKV 适合对 数据一致性要求极高 的场景，例如金融风控特征、实时反欺诈特征。
- 适用场景：需要跨行事务的特征更新、特征与标签的联合写入、多副本强一致。
- 典型用法：使用 TiKV 存储用户实时风险评分特征，配合 TiDB 进行 SQL 查询。
- 注意事项：运维复杂度高于 Redis；写入延迟受 Raft 多数派确认影响；社区生态相对 Redis 较小。
3.4 选型决策流程
以下 SVG 图展示了从业务需求出发的选型决策路径：
3.5 混合存储架构实践
在大型 Feature Store 系统中，单一存储无法满足所有需求。推荐采用 分层混合存储 架构：
- 热数据层（Redis）：存放最近 1-7 天的活跃特征，提供毫秒级在线查询。
- 温数据层（HBase / TiKV）：存放全量特征数据，支持回溯和批量导出。
- 分析层（Druid）：存放聚合后的时序特征，用于监控、分析和特征回溯。
3.6 选型总结矩阵
| 场景特征 | 推荐存储 | 核心理由 |
|---|---|---|
| 高并发在线点查（延迟 < 5ms） | Redis | 内存级读写性能，丰富的数据结构 |
| 海量特征宽表（PB 级） | HBase | 原生水平扩展，低成本存储 |
| 时序聚合特征 / 监控分析 | Druid | 秒级摄入，亚秒级聚合查询 |
| 强一致性 / 事务需求 | TiKV | Raft 共识，分布式事务支持 |
| 混合负载（点查 + 分析） | Redis + Druid | 分层架构，各取所长 |
选型不是一次性决策。随着业务发展，特征存储的负载特征可能发生变化，建议在架构设计时预留存储层切换或扩展的接口，例如通过统一的 Feature Store SDK 屏蔽底层存储差异。