3、特征存储选型：Redis、HBase、Cassandra、TiKV 对比分析

特征存储的选型，说白了就是给你的特征向量找个家。这个家选得好不好，直接决定了线上推理的延迟和系统的运维成本。我这些年踩过不少坑，从 Redis 一路用到 TiKV，每种存储都有它的脾气。

今天咱们就把 Redis、HBase、Cassandra、TiKV 这四位拉出来，从特征存储的视角做个深度对比。嗯，先看一张总览图，心里有个谱。

3.1 Redis：快，但容量是硬伤

Redis 在特征存储里用得最多，说白了就是图它快。我最早做推荐系统特征服务时，第一版就是全量 Redis。单个 key 存一个特征向量，用 Hash 结构存多个特征字段，延迟基本在 100 微秒以内。

但 Redis 有个大坑——内存太贵。我记得有一次业务量翻了三倍，Redis 集群内存直接飙到 1.2TB，采购单递上去运维脸都绿了。而且 Redis 的持久化机制（RDB/AOF）在大规模特征场景下恢复时间很长，一旦宕机，重建缓存是个噩梦。

Redis 的另一个问题是主从异步复制。主节点挂了，没同步的写请求就丢了。对于特征存储来说，丢几个特征可能不会让系统崩溃，但会导致模型推理结果不一致。你想想看，同一个用户两次请求拿到不同特征，模型输出能稳定吗？

3.2 HBase：海量存储，延迟波动大

HBase 是 Hadoop 生态的老将，底层 LSM-Tree 结构天生适合写密集场景。特征存储里，HBase 常用来做全量特征存储，也就是所谓的「特征宽表」。每一行存一个实体（用户/物品），列族按特征类型划分。

我参与过一个广告 CTR 预估项目，特征总量超过 500TB。Redis 肯定扛不住，最后选了 HBase。RowKey 设计成 user_id_reverse + feature_type，避免热点。效果还行，单次查询延迟在 5-20 毫秒之间。

但 HBase 的运维复杂度是真的高。ZooKeeper、HDFS、Region Server 三个组件任何一个出问题，特征服务就跟着抖。而且 HBase 不支持二级索引，想按特征值范围查询？没门。只能按 RowKey 精确查找。

另外，HBase 的强一致性是通过 Region Server 单点写入保证的。一旦 Region Server 宕机，这个 Region 上的特征读写就会中断，直到 Master 重新分配。嗯，这里要注意，HBase 的可用性其实不如 Cassandra。

3.3 Cassandra：高可用，最终一致性

Cassandra 的设计哲学是「可用性优先」。它没有单点故障，每个节点对等，数据通过 Gossip 协议同步。特征存储用 Cassandra，最大的好处是写入几乎不会失败——你随便挂几个节点，集群照样服务。

我有个朋友在海外做社交推荐，特征存储用的 Cassandra。他们的集群横跨三个数据中心，每天写入几百亿条特征。Cassandra 的 LSM-Tree 加上 Tombstone 机制，让删除操作也很轻量。

但 Cassandra 的一致性模型是最终一致性。默认的 ONE 级别下，读到的可能是旧数据。特征存储对一致性要求没那么苛刻，但如果你需要「写入后立即读到」，就得用 QUORUM 级别，延迟会翻倍。

Cassandra 还有一个坑——宽行性能差。特征存储经常需要一次读取几十个甚至上百个特征列。Cassandra 的存储引擎对宽行（几千列以上）的读取效率不高，因为它的数据是按列族物理分布的。我建议把特征按业务域拆成多个窄行，而不是塞进一个超级宽行里。

3.4 TiKV：强一致，Raft 加持

TiKV 是这几年的新秀，底层用 Raft 协议做分布式共识。它本质上是一个支持事务的 KV 存储，但用在特征存储场景也很合适。TiKV 的强一致性比 HBase 更纯粹——每个 Region 的 Raft Group 保证写入不丢。

我最近一个项目就在用 TiKV 做特征存储。原因很简单：业务要求特征写入后必须立即读到，而且不能丢数据。Redis 做不到，Cassandra 做不到，HBase 运维太累。TiKV 的 Raft 机制天然解决了这个问题。

TiKV 的延迟比 Redis 高一些，一般在 1-3 毫秒。但它的容量可以扩展到 TB 甚至 PB 级，而且支持自动负载均衡。PD（Placement Driver）组件会动态调度 Region，避免热点。

不过 TiKV 的生态相对年轻。客户端 SDK 的成熟度不如 Redis 和 HBase，有些语言（比如 Go）的客户端还在迭代中。另外，TiKV 的部署需要 PD、TiKV 节点、Prometheus 监控三件套，学习成本比 Cassandra 高一些。

3.5 四者核心对比

下面这张表是我在实际项目中总结的对比数据，你可以直接拿来当选型参考。

维度	Redis	HBase	Cassandra	TiKV
延迟（P99）	< 1ms	5-50ms	2-10ms	1-5ms
一致性	最终（主从异步）	强一致（单点写入）	最终（可调）	强一致（Raft）
容量上限	百 GB（内存受限）	PB 级	PB 级	TB ~ PB 级
运维复杂度	低	高（依赖 HDFS/ZK）	中	中高
特征读取模式	单 key 或 mget	单 RowKey 扫描	分区键 + 聚类键	单 key 或 batch_get
典型特征量	千万级	十亿级	十亿级	亿级

3.6 选型决策框架

说了这么多，到底怎么选？我个人的决策流程是这样的：

1. 先看延迟要求。如果必须亚毫秒级，别想了，Redis 是唯一选择。但你要做好容量规划和冷热分离。
2. 再看一致性要求。特征写入后必须立即读到？选 TiKV 或 HBase。能接受最终一致性？Cassandra 更省心。
3. 然后看数据量。百 GB 以内 Redis 搞定。TB 级以上，HBase 或 Cassandra。TiKV 在 TB 级表现不错，但 PB 级生态不如 HBase 成熟。
4. 最后看运维能力。团队小、运维弱，优先 Redis + Cassandra。有专职 DBA，HBase 和 TiKV 都可以上。