HBase读写流程与MemStore刷写机制

一、引言：为什么HBase"读比写慢"

在前面的文章中，我们多次提到一个看似矛盾的说法——HBase是读比写慢的框架。这听起来很奇怪：通常数据库的写入操作（涉及磁盘IO、日志记录、索引更新）应该比读取更慢才对。为什么HBase会反过来？

要理解这个现象，我们必须深入HBase的读写流程。HBase通过精巧的设计，将写入操作优化到了极致（顺序写+内存缓存），而读取操作由于需要合并多个数据源（内存+磁盘+多版本），反而更加复杂。本文将揭开这个秘密。

二、HBase写流程详解

2.1 写流程全景图

HBase的写流程是一个精心设计的多阶段过程，兼顾了可靠性和高性能。让我们先看整体流程：

上图展示了HBase写流程的时序图：

1. Client发送Put/Delete请求到RegionServer
2. RegionServer先写入WAL（保证数据不丢失）
3. 再写入MemStore（保证写入性能）
4. 返回ACK给Client（写入完成）
5. 后台异步Flush MemStore到HFile（持久化）

2.2 写流程详细步骤

步骤1：Client定位目标RegionServer

客户端写入数据前，首先需要知道数据应该写入哪个RegionServer。这个过程涉及元数据查询和缓存：

关键设计：

• Meta Cache：客户端缓存Region位置信息，避免每次请求都访问Zookeeper
• 缓存失效：Region迁移（Split、负载均衡）时，客户端会自动重新获取
• 首次访问：需要3次网络往返（Zookeeper→hbase:meta→RegionServer），后续只需1次

步骤2：RegionServer接收并处理写入请求

当RegionServer接收到Put请求后，会执行以下操作：

步骤3：WAL（Write-Ahead Log）写入详解

WAL是HBase数据可靠性的核心保障。让我们深入理解WAL的工作原理：

WAL的作用：

• 数据恢复：RegionServer宕机时，通过WAL恢复未Flush的MemStore数据
• 顺序写入：WAL采用追加写入方式，性能极高
• 持久化保证：数据先写WAL再写MemStore，确保即使崩溃也不丢失

WAL的存储结构：

WAL写入的关键设计：

WAL的刷盘策略：

// HBase提供多种WAL刷盘策略// 1. SYNC（默认）：每次写入都同步刷盘，最安全但最慢// 2. ASYNC：异步刷盘，性能最好但可能丢失数据// 3. FSYNC：强制刷盘，最安全// 配置项（hbase-site.xml）<property><name>hbase.wal.hsync</name><value>true</value><!--使用hsync而非hflush，更安全--></property>

步骤4：MemStore写入详解

MemStore是HBase高性能写入的核心设计。数据写入MemStore后，写入操作对客户端来说就已经"完成"了：

上图展示了MemStore的结构和Flush过程：

• MemStore：内存中的有序数据结构（ConcurrentSkipListMap）
• Flush：当MemStore达到一定阈值，将数据批量写入HDFS，生成新的HFile
• 不同列族独立Flush：每个Store（列族）有自己的MemStore，独立Flush

MemStore的核心特性：

MemStore的数据结构：

MemStore（ConcurrentSkipListMap） ├── Key: row1|cf1:c1|ts=1000 → Value: "value1" ├── Key: row1|cf1:c2|ts=1001 → Value: "value2" ├── Key: row2|cf1:c1|ts=1002 → Value: "value3" ├── Key: row2|cf2:c1|ts=1003 → Value: "value4" └── Key: row3|cf1:c1|ts=1004 → Value: "value5" 排序规则：RowKey → ColumnFamily → ColumnQualifier → TimeStamp（降序）

为什么使用SkipList而不是B+树？

• SkipList是无锁并发数据结构，适合高并发写入
• B+树需要复杂的锁机制，并发性能较差
• SkipList的实现更简单，内存开销更小

步骤5：返回ACK与后台Flush

关键设计：

• 客户端收到ACK时，数据只保证在WAL和MemStore中
• 数据可能尚未持久化到HDFS（还在内存中）
• Flush是后台异步执行的，不影响写入性能
• 即使此时RegionServer宕机，数据也可以通过WAL恢复

2.3 写流程的性能优化点

HBase的写流程经过多层优化，实现了极高的写入性能：

2.4 写流程的可靠性保障

虽然HBase写入性能极高，但可靠性并未牺牲：

三重保障：

1. WAL（预写日志）：数据先写入WAL，即使MemStore丢失也可恢复
2. HDFS副本：WAL和HFile都存储在HDFS上，默认3副本
3. MemStore恢复：RegionServer重启时，通过回放WAL恢复MemStore

三、HBase读流程详解

3.1 读流程全景图

HBase的读流程比写流程复杂得多，因为数据可能分布在多个位置：

上图展示了RegionServer的内部结构：

• BlockCache：读缓存，缓存了之前从HFile读取的数据块
• MemStore：写缓存，同时包含未Flush的最新数据
• HFile：磁盘中的持久化数据文件
• WAL：预写日志（读取时不需要访问）

3.2 读流程详细步骤

步骤1：Client定位目标RegionServer

与写流程相同，客户端首先定位目标RegionServer：

步骤2：RegionServer处理读取请求

RegionServer接收到Get或Scan请求后，需要从多个数据源查找数据：

步骤3：BlockCache查找

BlockCache是HBase的读缓存，用于缓存从HFile中读取的数据块：

BlockCache的核心特性：

BlockCache的查找过程：

Get请求：RowKey = "row1001", Column = "info:name" BlockCache查找： ┌─────────────────────────────────────┐ │ BlockCache (LRU Cache) │ │ │ │ Key: Block-1 (RowKey范围: row1~row1000) │ Key: Block-2 (RowKey范围: row1001~row2000) ← 命中！ │ Key: Block-3 (RowKey范围: row2001~row3000) │ ... │ └─────────────────────────────────────┘ 如果命中Block-2： - 在Block-2中查找RowKey="row1001", Column="info:name" - 找到则直接返回 - 未找到则继续查找MemStore和HFile

步骤4：MemStore查找

MemStore不仅是写缓存，也是最新的读缓存：

MemStore查找： ┌─────────────────────────────────────┐ │ MemStore (SkipList) │ │ │ │ row1001|info:name|ts=5000 → "Nick" ← 最新版本！ │ row1001|info:name|ts=4000 → "Tom" │ row1001|info:age|ts=5000 → "25" │ row1002|info:name|ts=5000 → "Jerry" │ ... │ └─────────────────────────────────────┘ 查找RowKey="row1001", Column="info:name"： - 在SkipList中二分查找 - 找到多个版本（ts=5000和ts=4000） - 返回最新版本（ts=5000）的值"Nick"

为什么MemStore也是读缓存？

• MemStore中的数据是最新写入的，尚未Flush到HFile
• 如果读取时不查MemStore，会读到旧数据（HFile中的数据）
• 因此读取必须同时查MemStore，合并结果

步骤5：HFile查找

如果BlockCache和MemStore都未命中（或需要更多版本），需要在HFile中查找：

上图展示了HBase的完整架构：Client通过Zookeeper找到HMaster和RegionServer，RegionServer中的Store包含MemStore和StoreFile（HFile），所有数据最终存储在HDFS的DataNode上。

HFile查找的优化机制：

布隆过滤器的工作原理：

布隆过滤器：一种空间效率极高的概率型数据结构 特点： - 判断"可能存在"（有一定的误报率） - 判断"肯定不存在"（100%准确） - 空间占用极小（相比存储所有Key） HFile查找时使用布隆过滤器： 1. 查询布隆过滤器：RowKey="row1001"是否在这个HFile中？ 2. 如果布隆过滤器说"不存在" → 直接跳过该HFile（100%准确） 3. 如果布隆过滤器说"可能存在" → 读取HFile确认（可能有误报） 效果： - 假设有10个HFile，只有1个包含目标数据 - 布隆过滤器可以跳过8~9个HFile - 只需读取1~2个HFile，减少90%的IO

步骤6：多数据源合并

读取操作最终需要从多个数据源获取数据，然后合并去重：

读取RowKey="row1001", Column="info:name", VERSIONS=2 数据源1：BlockCache - row1001|info:name|ts=5000 → "Nick" - row1001|info:name|ts=4000 → "Tom" 数据源2：MemStore - row1001|info:name|ts=5500 → "Jack" ← 最新！ - row1001|info:name|ts=5000 → "Nick" 数据源3：HFile-1 - row1001|info:name|ts=3000 → "Alice" - row1001|info:name|ts=2000 → "Bob" 数据源4：HFile-2 - row1001|info:name|ts=4500 → "Charlie" 合并过程： 1. 收集所有数据源的匹配数据 2. 按TimeStamp降序排序 3. 取最新的2个版本（VERSIONS=2） 4. 过滤Delete标记的数据 结果： - ts=5500 → "Jack"（来自MemStore，最新） - ts=5000 → "Nick"（BlockCache和MemStore都有，去重）

3.3 为什么读比写慢？

现在我们可以回答开头的问题了：

核心原因：

• 写入是追加操作，只需在WAL末尾追加、在MemStore中插入
• 读取是查询操作，需要在多个数据源中查找、合并、排序
• 写入的ACK在数据到MemStore时返回，不等待磁盘Flush
• 读取必须等待所有数据源查找完成才能返回

注意：这里的"慢"是相对而言。HBase的读取性能在海量数据场景下仍然非常优秀，只是相比其极致的写入性能略逊一筹。

四、MemStore Flush机制详解

4.1 为什么需要Flush

MemStore是内存中的数据结构，存在以下限制：

• 内存容量有限：无法无限存储数据
• 数据可靠性：内存数据宕机时会丢失（虽然有WAL可以恢复，但恢复需要时间）
• 查询性能：MemStore数据量过大时，查询性能下降

因此，MemStore中的数据需要定期**Flush（刷写）**到HDFS，生成HFile文件。

4.2 Flush的触发条件

HBase有四种触发Flush的条件，满足任一条件即触发：

上图展示了Region、Store、MemStore和HFile的关系：一个Region包含多个Store（每个列族一个），每个Store包含一个MemStore和多个HFile。

触发条件1：MemStore大小阈值

条件：单个MemStore大小达到阈值 参数：hbase.hregion.memstore.flush.size 默认值：134217728（128MB） 触发行为： - 该MemStore所在Region的所有MemStore都会Flush - 生成新的HFile文件 注意： - 即使其他MemStore很小，也会一起Flush - 因为同一Region的MemStore共享WAL，需要一起处理

阻塞写入的阈值：

参数：hbase.hregion.memstore.block.multiplier 默认值：4 阻塞阈值 = hbase.hregion.memstore.flush.size × multiplier = 128MB × 4 = 512MB 当MemStore达到512MB时： - 阻塞该MemStore的写入操作 - 直到Flush完成，释放空间 - 防止MemStore无限增长导致OOM

触发条件2：RegionServer全局MemStore阈值

条件：RegionServer上所有MemStore的总大小达到阈值 参数： - hbase.regionserver.global.memstore.size（上限，默认0.4，即JVM堆的40%） - hbase.regionserver.global.memstore.size.lower.limit（下限，默认0.95） 触发行为： 1. 当总MemStore达到JVM堆的40%时，开始Flush 2. 按MemStore大小从大到小排序，依次Flush 3. 直到总MemStore降到40% × 95% = 38%以下 阻塞阈值： - 当总MemStore达到JVM堆的40%时 - 阻塞所有MemStore的写入 - 直到Flush完成，释放空间

为什么需要全局阈值？

场景：一个RegionServer上有100个Region - 每个Region有2个列族 - 每个MemStore 100MB - 总MemStore = 100 × 2 × 100MB = 20GB 如果JVM堆是32GB： - 20GB / 32GB = 62.5% > 40% - 触发全局Flush - 防止OOM

触发条件3：时间阈值

条件：距离上次Flush超过一定时间 参数：hbase.regionserver.optionalcacheflushinterval 默认值：3600000（1小时） 触发行为： - 即使MemStore很小，也会定期Flush - 保证数据及时持久化 - 减少WAL文件积累 注意： - 如果MemStore为空，不会触发Flush - 这个参数在HBase 1.3.1中已废弃，但逻辑仍存在

触发条件4：WAL文件数量阈值

条件：WAL文件数量超过限制 参数：hbase.regionserver.max.logs（已废弃，自动计算） 自动计算值：通常与Region数量相关 触发行为： - 当WAL文件数量过多时 - 按时间顺序，将最早的WAL对应的MemStore Flush - 释放WAL文件，减少恢复时间 目的： - 控制WAL文件数量 - 减少RegionServer宕机时的恢复时间 - 每个WAL文件默认128MB

4.3 Flush的详细过程

当Flush触发时，HBase执行以下步骤：

Flush过程： 1. 创建新的MemStore（Snapshot） ┌─────────────────┐ │ 旧MemStore │ ← 冻结，不再写入新数据 │ (待Flush) │ └─────────────────┘ ┌─────────────────┐ │ 新MemStore │ ← 接收新的写入请求 │ (继续写入) │ └─────────────────┘ 2. 将旧MemStore的数据排序并写入临时HFile - 遍历SkipList中的所有KeyValue - 按顺序写入HFile - 生成Block Index和布隆过滤器 3. 将临时HFile移动到正式目录 - 从临时目录移动到HDFS的正式存储目录 - 原子操作，保证一致性 4. 更新Region的StoreFile列表 - 将新HFile加入StoreFile列表 - 旧MemStore可以被垃圾回收 5. 通知WAL可以删除已Flush的数据 - WAL中对应的数据可以安全删除 - 减少WAL文件数量

4.4 Flush的影响

五、Compaction机制概述

Flush会产生大量小HFile，影响读取性能。Compaction机制用于合并HFile：

上图展示了Compaction的过程：

• Minor Compaction：合并相邻的小HFile，不清理过期数据
• Major Compaction：合并所有HFile，清理过期和删除的数据

5.1 Minor Compaction

触发条件： - Store中的HFile数量达到阈值（默认3个） - 手动触发 行为： - 选择相邻的若干个小HFile - 合并成一个较大的HFile - 不清理过期数据和Delete标记 目的： - 减少HFile数量 - 提高读取性能（减少需要查找的文件） - 不消耗太多IO资源

5.2 Major Compaction

触发条件： - 默认7天自动触发一次（可配置） - 手动触发 行为： - 合并Store中的所有HFile - 清理过期数据（超过版本数或TTL） - 清理Delete标记的数据（物理删除） 目的： - 彻底清理无用数据 - 合并为一个大HFile，读取性能最优 - 但消耗大量IO资源，可能影响业务 注意： - Major Compaction期间，该Store的读写性能可能下降 - 建议在业务低峰期手动触发 - 或调整自动触发时间

六、读写流程优化建议

6.1 写入优化

批量写入示例：

// Java API批量写入List<Put>puts=newArrayList<>();for(inti=0;i<10000;i++){Putput=newPut(Bytes.toBytes("row"+i));put.addColumn(Bytes.toBytes("info"),Bytes.toBytes("name"),Bytes.toBytes("value"+i));puts.add(put);}table.put(puts);// 一次性提交10000条

6.2 读取优化

读取优化示例：

// 只查询需要的列族，减少IOGetget=newGet(Bytes.toBytes("row1001"));get.addFamily(Bytes.toBytes("info"));// 只查info列族// get.addColumn(Bytes.toBytes("info"), Bytes.toBytes("name")); // 或只查指定列// Scan设置缓存Scanscan=newScan();scan.setCaching(500);// 每次RPC返回500行scan.setBatch(100);// 每行最多返回100个Cellscan.setCacheBlocks(true);// 缓存读取的数据块

6.3 MemStore和Flush优化

七、常见问题与排查

7.1 写入延迟高

排查步骤：

# 1. 检查WAL刷盘策略# hbase-site.xml中检查hbase.wal.hsync配置# 2. 检查MemStore是否频繁Flush# RegionServer Web UI查看Flush频率# 3. 检查是否触发全局MemStore阻塞# 日志中搜索"Blocking updates"# 4. 检查Region热点# HMaster Web UI查看各Region的写入量

解决方案：

• 如果WAL同步刷盘导致延迟高，考虑使用SSD或调整刷盘策略（注意可靠性权衡）
• 如果MemStore频繁Flush，增加Flush阈值或预分区分散压力
• 如果Region热点，优化RowKey设计

7.2 读取延迟高

排查步骤：

# 1. 检查BlockCache命中率# RegionServer Web UI查看BlockCache命中率# 2. 检查HFile数量# 如果HFile数量过多，需要触发Compaction# 3. 检查布隆过滤器配置# 确认布隆过滤器已启用# 4. 检查Region热点# 某些Region读取量过大，需要负载均衡

解决方案：

• 如果BlockCache命中率低，增加BlockCache大小或优化查询模式
• 如果HFile数量多，触发Compaction
• 如果Region热点，优化RowKey设计或预分区

7.3 MemStore频繁Flush

现象：日志中频繁出现"Flushing MemStore"，写入性能波动。

原因：

• MemStore阈值设置过小
• 写入量过大，单个Region压力过大
• 列族过多，每个列族都有MemStore

解决方案：

<!-- 增加MemStore阈值 --><property><name>hbase.hregion.memstore.flush.size</name><value>268435456</value><!-- 256MB --></property><!-- 增加全局阈值 --><property><name>hbase.regionserver.global.memstore.size</name><value>0.5</value><!-- JVM堆的50% --></property>

7.4 WAL文件积累过多

现象：WAL目录文件数量持续增长，磁盘空间不足。

原因：

• Flush不及时，WAL无法清理
• RegionServer负载过高，Flush队列积压

解决方案：

• 检查Flush是否正常触发
• 手动触发Flush：flush 'table_name'
• 检查是否有RegionServer宕机导致WAL未清理

八、总结

8.1 写流程核心要点

8.2 读流程核心要点

8.3 Flush核心要点

8.4 性能优化口诀

写入快：批量写入、预分区、散列RowKey、控制列族数

读取快：BlockCache调优、布隆过滤器、只查需要列、合理版本数

Flush稳：阈值合理、线程充足、Compaction及时、监控到位

如果本文对你有帮助，欢迎点赞、收藏、关注专栏，有问题请在评论区留言讨论。