HBase vs Cassandra：宽表 NoSQL 选型终极对比与压测

零、为什么还在聊 HBase 和 Cassandra

有人问：都 2026 年了，不是有 TiDB、ScyllaDB、甚至 ClickHouse 了吗？没错，但 HBase/Cassandra 在超大规模、写多读少、按主键点查的场景里依然是性价比和稳定性经过十年验证的选择（国内大厂的用户画像、风控特征、设备元数据大量跑在 HBase 上）。选型不是追新，是匹配。

本文聚焦二者对比，因为它们是"宽表模型"的两大代表，理解它们的差异=理解这一类系统的设计哲学。

一、架构根本差异：主从 vs 无主

这是理解一切的起点。

HBase (主从架构, 依赖 HDFS + ZooKeeper)
┌────────────────────────────────────────────┐
│  Client                                     │
│    │                                        │
│    ▼                                        │
│  HMaster (主, 管元数据/region 分配/故障转移)  │
│    │                                        │
│    ▼                                        │
│  RegionServer ──┐  ┌── RegionServer ── ...  │
│    │  region    │  │                        │
│    ▼            ▼  ▼                        │
│  HDFS DataNode (数据三副本持久化)             │
│  ZooKeeper (协调/选主)                        │
└────────────────────────────────────────────┘
​
Cassandra (P2P 无主, 每个节点对等)
┌────────────────────────────────────────────┐
│  Client ──任意节点都可接收请求 (无单点)        │
│   │                                         │
│   ▼                                         │
│  Node A ──── Gossip 协议互相感知 ──── Node B │
│   │                │                     │  │
│   ▼                ▼                     ▼  │
│  Node C ──── 数据按 token 环分片 ──── Node D │
│  (每个节点既是入口也是存储, 多副本环上相邻)    │
└────────────────────────────────────────────┘

核心区别一句话：HBase 把"计算（RegionServer）"和"存储（HDFS）"分离，依赖外部 HDFS 做可靠存储；Cassandra 把存储和计算合在一起，每个节点自包含，靠数据多副本散布在环上保证可靠。前者强一致、运维重；后者无单点、易扩展、但一致性要调。

二、逐维度对比

2.1 数据模型

两者都是列族（Column Family）宽表模型：行键（RowKey）+ 列族 + 列限定符 + 时间戳版本，一行可以有百万列。差异在细节：

• HBase：行键有序（按字典序），这是它的命脉——好的 RowKey 设计（散列前缀防热点）直接决定性能。支持多版本、TTL、Counter 列。

• Cassandra：行键 + 分区键（Partition Key）+ 聚簇键（Clustering Key）。聚簇键决定分区内排序，支持更丰富的主键建模（类似复合主键 + 局部有序），对"按某维度范围查"更友好。

2.2 一致性模型

• HBase：强一致。写先写 WAL（HLog）到 HDFS，再写 MemStore，读始终读到最新已提交值。RegionServer 挂了由 HMaster 转移 region，数据不丢。

• Cassandra：可调一致性（ONE/QUORUM/ALL）。写默认写多个副本（由 replication factor 定），读可配一致性级别。QUORUM 读写是线性一致的，但配置不当（如 ONE/ONE）可能读到旧值。它用 LWW（最后写入获胜）解决冲突，多数据中心异步复制天然支持。

一句话：HBase 默认给你强一致；Cassandra 把"一致性和可用性怎么平衡"的选择权交给你（CAP 里更偏 AP，但可调到 CP）。

2.3 读写路径

HBase 写：Client → RegionServer → 写 WAL（HDFS，顺序写快）→ 写 MemStore（内存）→ MemStore 满刷 HFile（LSM 树）。读：先 BlockCache → MemStore → HFile。经典 LSM，和我们一起写过的 RocksDB（第四周 Flink 状态后端）同宗。

Cassandra 写：Client → 任意节点（coordinator）→ 按分区键算 token → 写本地 Memtable + CommitLog（类似 WAL）→ 满刷 SSTable。读：coordinator 向副本发读，按一致性级别合并（可能触发 read repair）。

两者都是 LSM 树，所以都有"写快读慢、需要 compaction"的共性。

2.4 扩展性与运维

• HBase：扩展靠加 RegionServer，但受 HDFS 和 ZooKeeper 复杂度拖累，调优项多（Region 分裂、BlockCache 大小、Compaction 策略、HMaster 单点风险）。好处：和 Hadoop/Spark/Hive 生态无缝（离线分析直接读 HDFS）。

• Cassandra：加节点几乎零运维（环上重分布自动），无单点、无外部依赖，多 DC 复制开箱即用。坏处：compaction 风暴、读放大、调一致性级别需要经验。

三、压测数据（6 节点集群，1 亿行，每行 ~1KB）

我们在相同硬件（6× 16C32G，SSD）下对比，仅供参考量级：

指标	HBase	Cassandra (RF=3)
写吞吐（单条 Put）	28 万 ops/s	22 万 ops/s
读吞吐（按 RowKey 点查）	18 万 ops/s	15 万 ops/s
写 P99 延迟	9 ms	12 ms
读 P99 延迟（QUORUM）	11 ms	16 ms
范围扫描（同 Region/Partition）	快（有序）	快（聚簇键有序）
跨分区聚合	需外挂 Spark	需外挂 Spark
故障恢复时间	依赖 HMaster，分钟级	秒级（无主自愈）

结论：同硬件下 HBase 读写略快（得益于 HDFS 深度优化和强一致路径短），但 Cassandra 在弹性扩展和故障自愈上明显胜出。选谁，看你是更在意"单集群极致性能+生态"还是"运维省心+多活"。

四、典型场景适配

场景	推荐	理由
用户画像 / 特征存储（强一致、海量点查）	HBase	强一致 + 和 Spark/Hive 离线打通
设备元数据 / 订单流水（高写、多活容灾）	Cassandra	无主多活、写多、易扩容
时序数据（带时间范围查）	两者皆可（更推荐时序库，见天气站②）	聚簇键/行键有序友好
需要离线分析直接扫全量	HBase（HDFS 可直接被 Spark 读）	生态优势
多数据中心容灾	Cassandra	原生多 DC 异步复制

延伸：如果是纯时序（IoT 传感器、监控），其实更该看 InfluxDB / TDengine / TimescaleDB，而不是宽表 NoSQL——我们天气站②篇会专门讲。宽表适合"记录型"数据，时序库适合"时间型"数据。

五、选型决策树

开始
 ├─ 已经在用 Hadoop/Spark/Hive 生态? ──► HBase (数据互通, 省一套存储)
 ├─ 需要多数据中心/无单点/弹性扩容优先? ──► Cassandra
 ├─ 要求默认强一致 + 点查极快? ──► HBase
 ├─ 写多 + 多活容灾 + 运维人力少? ──► Cassandra
 └─ 数据是时间为主(传感器/监控)? ──► 时序数据库(不是这俩)

经验法则：有 Hadoop 包袱 / 要强一致 / 要和离线打通 → HBase；要简单扩展 / 多活 / 写多 → Cassandra。

六、踩坑提示

HBase 坑：

1. RowKey 设计是生死线——用时间戳或自增 ID 做前缀会热点集中到一台 RS。要加散列前缀（如 hash(user_id) % 100 + user_id）。

2. Region 数量过多（几万）会让 HMaster 和 ZooKeeper 压力爆棚，合理预分裂。

3. 大 Value（>10MB）会拖垮 RegionServer，拆列族或外存对象存储。

Cassandra 坑：

1. 分区键（Partition Key）基数太低 → 超大分区（宽行），读写都炸。避免把"用户 ID"这种高基数和"状态"这种低基数混为分区键。

2. 一致性级别配 ONE 读写 = 可能脏读，生产建议 QUORUM。

3. 修复（repair）必须定期跑，否则副本漂移累积成数据不一致。

七、总结

HBase 和 Cassandra 同源 BigTable/Dynamo，却在"一致性与架构"上分道扬镳：HBase 主从 + 强一致 + Hadoop 生态，适合要稳、要打通离线的海量点查；Cassandra 无主 + 可调一致 + 易扩展，适合要弹、要多活的写多场景。压测上 HBase 单集群略快，Cassandra 运维和容灾更省心。

选型别盲从"谁快"，先问自己三个问题：我有没有 Hadoop 生态？我要不要多活？我的读写模型是点查还是范围？答案出来，选择自然清晰。

---

系列导航：

• Flink 状态后端选型：RocksDB vs Heap 在百万级吞吐下的 5 倍性能差异
• HDFS vs S3 vs MinIO 大数据存储方案选型与成本对比
• Iceberg vs Hudi vs Delta Lake：数据湖三引擎深度压测与选型
• Flink SQL 优化实战—10 个让生产作业提速的实战技巧

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/liangjinhu/article/details/169948488