一、为什么需要 HBase

先说清楚 HBase 解决的是哪类问题。传统 MySQL 在以下场景会明显吃力：

HBase 的定位可以一句话概括：一个稀疏、多维、持久化的有序 Map——(RowKey, ColumnFamily:Qualifier, Timestamp) → Value。它底层强依赖 HDFS 做文件存储、依赖 ZooKeeper 做元数据与选主，自己只负责”怎么组织数据、怎么路由读写”。

二、数据模型：从关系型到多维 Map

理解 HBase 的第一步是丢掉”表 = 二维网格”的直觉。它的逻辑模型是：

• 表（Table）：按 RowKey 字典序排序的行集合。
• 行键（RowKey）：唯一标识一行，全局字典序排列，查询性能完全由它决定。
• 列族（Column Family）：列的物理分组单位，建表时固定（如 info、metrics），同一列族数据存同一文件。
• 列限定符（Qualifier）：列族下的动态列名，可随时新增，无需 DDL。
• 单元格（Cell）：由 (RowKey, CF:Qualifier, Version) 唯一确定，值带多版本时间戳。
• 时间戳（Timestamp）：写入时默认取当前时间，可指定，用于保留多版本。

1
2
3
4
5

RowKey        CF:Qualifier        Timestamp   Value
user_1001     info:name           1728000000  "张三"
user_1001     info:age            1728000000  28
user_1001     metrics:login_cnt   1728000000  12
user_1001     metrics:login_cnt   1727000000  9     ← 同一 cell 的旧版本

注意 user_1001 这一行，不同列族的列稀疏地存在，没有值的列不占任何存储空间——这是它能扛超宽表（上千列）的根本原因。

三、底层存储原理：LSM 树的写入哲学

HBase 的高写入吞吐来自 LSM（Log-Structured Merge）树，核心思想是把随机写变成顺序写。

1
2
3
4

写请求 ──► WAL(HLog)  ──► MemStore(内存有序跳表)
                              │ flush 到磁盘
                              ▼
                          HFile(有序、不可变) ──► Compaction 合并

1. WAL 预写日志：写请求先追加到 HLog（落 HDFS），保证宕机可重放，不丢数据。
2. MemStore：数据写入内存里的跳表，按 RowKey 有序。内存写满（默认 128MB）或满足时间/条数阈值后刷盘。
3. HFile：MemStore 刷盘生成的有序、不可变文件，底层是 HDFS 上的 Block。
4. Compaction：随着 HFile 越来越多，读放大严重，后台线程把多个小 HFile 合并成大文件：
   • Minor Compaction：合并部分相邻小文件，不清理过期/被删除数据。
   • Major Compaction：合并一个 Region 下所有 HFile，真正清理 TTL 过期、被标记删除（墓碑标记）的数据，但开销大、易引发短暂停顿，生产常关掉自动 Major、手动低峰执行。

四、架构与读写链路

4.1 运行时组件

1
2
3
4
5
6
7

ZooKeeper ── 存 hbase:meta 位置、Master/RegionServer 选主与心跳
   │
HMaster ── 管理 schema、Region 分配与负载均衡、分裂决策（轻量，故障可短暂缺失）
   │
RegionServer × N ── 真正服务读写，每个 RS 管多个 Region
   │
Region ── 表按 RowKey 区间切分的最小服务单元（如 [a,m)、[m,z)）

4.2 写流程

1
2
3
4
5

Client → 查 hbase:meta 找到 RowKey 所属 Region 的 RegionServer（结果缓存）
       → 发写请求到该 RS
       → RS 先写 WAL（HLog，HDFS 三副本）
       → 再写 MemStore（内存）
       → 返回 ACK；MemStore 达到阈值后异步 flush 成 HFile

4.3 读流程

读要合并”内存 + 磁盘多版本”，HBase 用两样东西加速：

• BlockCache：RegionServer 读缓存（默认 LRU），缓存热点 HFile Block。
• Bloom Filter：每个 HFile 附带布隆过滤器，读前先判断”这个 RowKey/列 是否可能在这个文件”，跳过大量无关文件，把随机读从 O(文件数) 降到接近 O(1)。

1
2
3
4

读请求 → 先查 BlockCache
       → 未命中则并行查 MemStore + 各 HFile
       → 每个 HFile 先用 BloomFilter 过滤，再按需读 Block
       → 合并多版本，返回最新可见值

五、RowKey 设计实战（最易踩坑）

RowKey 决定数据分布与查询效率，设计失败几乎无法事后补救（要重建表）。核心矛盾是：HBase 按 RowKey 字典序切分 Region，若 RowKey 前缀高度集中（如统一时间戳、统一用户前缀），所有写都会砸到同一个 Region，形成热点。

5.1 加盐（Salting）

给 RowKey 前面加一个散列前缀，把写入均摊到多个 Region：

1
2
3

// 假设有 10 个分桶
int bucket = Math.abs(userId.hashCode() % 10);
String rowKey = bucket + "_" + userId;   // "3_user_1001"

代价：范围扫描时要扫全部 bucket，点查需先知道 bucket，适合”高并发写 + 按完整 key 取”的场景。

5.2 哈希 + 反转

1
2
3
4

// MD5 前缀打散 + 反转用户 ID，兼顾分散与点查
MessageDigest md = MessageDigest.getInstance("MD5");
byte[] prefix = Arrays.copyOfRange(md.digest(userId.getBytes()), 0, 4);
String rowKey = Bytes.toString(prefix) + "_" + new StringBuilder(userId).reverse();

5.3 组合键与时间戳反转

时序数据（监控、日志）常用 (设备ID, 时间) 组合，但时间放前面会热点，放后面又能按设备快速取最近 N 条：

1
2
3

// 时间做反转后缀，保证同一设备的数据连续，且最新数据落在一起
long reversedTs = Long.MAX_VALUE - timestamp;
String rowKey = deviceId + "_" + reversedTs;   // 同设备范围扫描连续，最新在前

六、Region 分裂与合并

随着数据写入，单个 Region 过大（默认 10GB）会被自动分裂成两个，各自服务一半 RowKey 区间，由 HMaster 调度到其他 RegionServer 实现负载均衡。

1
2
3
4

Region [a, z) 写入增长超过阈值
   │ split
   ▼
Region [a, m)  +  Region [m, z)   → 可能被调度到不同 RegionServer

• 触发分裂：Region 内最大 Store 的 HFile 达到 hbase.hregion.max.filesize（默认 10GB）。
• 预分区：建表时用 SPLITS 预切分，避免初期所有数据堆在一个 Region 再集中分裂引发”分裂风暴”。
• 合并（Merge）：运维可手动把过小的相邻 Region 合并，减少元数据与调度开销。

1
2

# 建表时预分区（按十六进制前缀切 16 个 Region）
hbase> create 'metrics', 'info', {SPLITS => ['1','2','3','4','5','6','7','8','9','a','b','c','d','e','f']}

七、性能调优要点

八、与 Kafka / Spark / Flink 的协同

HBase 在大数据平台里通常扮演存储层，与已有三篇自然衔接：

1
2
3
4
5
6
7

业务/日志 ──► Kafka(消息总线,削峰解耦)
                │ 消费
                ▼
         Spark / Flink(计算: 清洗、聚合、特征)
                │ 落库
                ▼
            HBase(海量明细/状态存储)  ←── 在线查询、实时画像、宽表

• Kafka 解决”数据怎么稳稳流起来”，HBase 是流的落地点之一；
• Spark 跑离线 ETL 把结果写进 HBase 做画像宽表；
• Flink 做实时聚合，把状态/明细实时写入 HBase 供在线查询。

三篇已分别讲透消息、批、流，本篇补上”存储”，链路闭环。

九、生产避坑清单

1. RowKey 不设计就上线：上线后几乎无法无损改造，务必先按查询模式设计、压测热点。
2. 单 Region 热点：建表务必预分区，避免全量数据先堆一个 Region 再集中分裂。
3. Major Compaction 撞业务高峰：关自动、低峰手动，否则大合并引发读停顿。
4. BlockCache 与 MemStore 抢内存：读多写少调大 BlockCache，写多反向。
5. 滥用宽行：单 RowKey 下塞几百万列会撑爆 Region，必要时拆行。
6. TTL 不设导致存储膨胀：冷热数据设 TTL，靠 Major Compaction 真正回收。
7. 把 HBase 当 MySQL 用：需要 JOIN、二级索引、跨行事务时，应上 Phoenix 或换 OLTP 库。
8. 忽略 ZooKeeper 与 HDFS 健康：HBase 强依赖二者，ZK 会话超时、HDFS 副本不足会直接拖垮读写。
9. 删除=墓碑标记：delete 只是打标记，真正释放空间要等 Major Compaction。
10. Region 数过多：单 RS 管上千 Region 会拖慢调度与故障恢复，控制单表 Region 规模。

十、小结

HBase 用”LSM 树顺序写 + 列式稀疏存储 + Region 自动分片”三板斧，解决了关系型数据库在海量写入与横向扩展上的天花板。它的性能几乎完全由 RowKey 设计决定——把查询维度放前面、把易热点维度打散，是写好 HBase 的第一性原理。把它和 Kafka（流）、Spark/Flink（算）组合起来，就撑起了一条完整的大数据”采、存、算、用”链路。