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

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

零、为什么还在聊 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 读写略快（得益于 HDFS 深度优化和强一致路径短），但 Cassandra 在弹性扩展和故障自愈上明显胜出。选谁，看你是更在意"单集群极致性能+生态"还是"运维省心+多活"。

四、典型场景适配

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

五、选型决策树

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

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

六、踩坑提示

HBase 坑：

Cassandra 坑：

七、总结

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 个让生产作业提速的实战技巧