HBase存储结构深度解析：从MemStore到HFile的物理落地

1. 项目概述：从“一行数据存哪了”开始讲清楚HBase的底层真相

你有没有在调试一个HBase表时，明明put了一条数据，用scan却查不到？或者明明删掉了某行，region server日志里还在报“compaction pending”？又或者集群负载突然飙升，监控显示WAL写入延迟暴涨，但业务QPS没变？这些问题背后，几乎都绕不开一个被很多人忽略的事实：HBase不是黑盒，它是一套有明确物理结构、严格模块边界、强依赖时序与状态管理的分布式存储系统。而所谓“HBase存储结构”，绝不是教科书上那张静态的LSM-Tree示意图能概括的——它是MemStore如何被flush成HFile、HFile内部如何组织Block、BlockCache如何按LRU-K策略淘汰、WAL如何分段落盘并保障崩溃恢复、Region如何切分又如何迁移……这些模块不是并列关系，而是环环相扣、一损俱损的精密链条。

我带过好几个团队做实时数仓迁移，最常听到的抱怨是：“HBase写得快，但读得不稳定”“小文件太多，集群越来越慢”。后来一查，八成是运维同学只调了hbase.hregion.memstore.flush.size，却完全没碰hbase.hstore.blockingStoreFiles或hfile.block.cache.size；或者开发同学用BulkLoad导入数据，却没预估好split policy导致Region数量爆炸。这些都不是配置错误，而是对存储模块间耦合关系缺乏基本体感。这篇内容不讲API怎么调、不讲Shell命令怎么敲，就死磕一件事：把HBase的存储结构拆开、摊平、还原成磁盘上的字节流和内存里的对象图。你会看到，一个Put请求进来后，数据在MemStore里怎么排队，在WAL里怎么序列化，在HFile里怎么编码压缩，在BlockCache里怎么索引定位——每一步都有明确的内存布局、磁盘格式和状态转换条件。适合正在排查性能瓶颈的SRE、设计海量写入架构的后端工程师、以及想真正搞懂NoSQL底层逻辑的数据库爱好者。它不承诺让你三天成为专家，但能确保你下次看到“RegionTooBusyException”时，第一反应不是重启服务，而是去查WAL roll的频率和HLog的fsync耗时。

2. 存储结构全景拆解：从逻辑表到物理文件的逐层映射

2.1 逻辑视图与物理落地的根本矛盾

HBase对外呈现的是二维稀疏表（RowKey + ColumnFamily + Qualifier + Timestamp），但底层存储必须解决三个硬约束：随机写入的高吞吐、范围查询的低延迟、故障场景下的强一致性。传统B+树在分布式环境下难以兼顾这三点，所以HBase选择了LSM-Tree（Log-Structured Merge-Tree）作为核心范式。但注意，LSM-Tree不是HBase的专利，它的精妙之处在于如何将理论模型适配到HDFS的追加写特性、ZooKeeper的协调能力、以及Java GC对大对象的敏感性上。

我们以一张典型的用户行为日志表为例：user_behavior，包含cf:page_id、cf:action_type、cf:duration_ms三个列。当执行put 'user_behavior', 'uid_123456|20240520|102345', 'cf:page_id', 'home'时，这条记录不会立刻落盘，而是经历以下路径：

1. 客户端序列化：RowKeyuid_123456|20240520|102345被转为字节数组（UTF-8编码），Qualifierpage_id同理，Timestamp默认取服务端时间戳（毫秒级），整个Cell被封装为KeyValue对象（注意：不是Map，是固定结构的二进制协议）。
2. WAL预写日志：KeyValue先写入WAL（Write-Ahead Log），这是HDFS上的一个滚动文件（如hlog.1716234567890），采用Hadoop SequenceFile格式，Key为HLogKey（含region名、sequenceId、timestamp），Value为WALEdit（包含多个KeyValue）。这一步必须fsync成功，否则Put直接失败——这是CAP中“C”的底线。
3. MemStore内存缓冲：KeyValue同时写入对应Region的MemStore（本质是ConcurrentSkipListMap），按RowKey排序。这里有个关键细节：MemStore不存原始字符串，而是存byte[]引用，且同一RowKey下不同ColumnFamily的数据是分开存储的（即cf:page_id和cf:action_type在不同子Map里），这为后续flush时按CF分离HFile打下基础。
4. Flush触发机制：当MemStore大小超过hbase.hregion.memstore.flush.size（默认128MB）或全局MemStore使用量超hbase.regionserver.global.memstore.size（默认40%堆内存）时，触发flush。此时MemStore会被冻结（freeze），新写入进入新的MemStore实例，而旧实例异步刷盘。

提示：MemStore flush不是简单dump内存，而是要重排序。因为WAL里记录的是乱序写入（不同RowKey并发写），而HFile要求严格RowKey有序。所以flush线程会遍历MemStore的跳表，按RowKey升序提取所有KeyValue，再按ColumnFamily分组，最后为每个CF生成独立的HFile。

2.2 HFile：HBase的物理存储单元与二进制契约

HFile是HBase的基石文件格式，其设计目标是：支持快速随机查找、高效范围扫描、可预测的磁盘IO模式、以及与HDFS块对齐的存储效率。从HBase 2.0开始，HFile默认使用V3版本（V2已废弃），其结构如下图所示（文字描述）：

+---------------------+ | Trailer | ← 固定长度（512字节），存指向其他块的偏移量 +---------------------+ | File Info | ← K-V对集合，存创建时间、MAX_SEQ_ID、COMPARATOR等元信息 +---------------------+ | Meta Index | ← 元数据块索引，存Meta Block的起始偏移和大小 +---------------------+ | Meta Blocks | ← 可选，存Bloom Filter、Index Block等元数据 +---------------------+ | Leaf Index Block | ← 叶子索引块，存Data Block的起始偏移（按key区间划分） +---------------------+ | Intermediate Index| ← 中间索引块，存Leaf Index Block的偏移（多层索引） +---------------------+ | Data Blocks | ← 核心数据块，存实际KeyValue（经编码+压缩） +---------------------+

重点解析Data Block：

• 每个Data Block默认64KB（hfile.block.size），这是HDFS默认块大小的1/64，确保一次HDFS读取能加载完整Block，避免跨块IO。
• Block内KeyValue按RowKey有序排列，但不是明文存储。HBase采用Prefix Encoding（前缀编码）：同一Block内，后一个KeyValue的RowKey只存与前一个不同的后缀部分（如row100,row101→ 存row100,1）；Qualifier同理。这使Block压缩率提升30%-50%。
• 每个KeyValue包含5个字段：key_len（int）、value_len（int）、row_len（short）、family_len（byte）、qualifier_len（short），然后才是实际字节流。这种紧凑二进制格式让解析速度远超JSON/Protobuf。

注意：HFile不存Timestamp字段的明文！它被编码为相对于Block内第一个KeyValue的时间戳的delta值（VarInt），进一步压缩空间。这也是为什么HBase不支持按Timestamp范围查询——索引只建在RowKey上。

2.3 BlockCache：内存中的热数据加速器与淘汰艺术

HFile是只读的，但读请求不能每次都走HDFS。HBase在RegionServer堆外内存（Off-Heap）中维护BlockCache，缓存频繁访问的HFile Block。其核心挑战是：如何在有限内存下，让缓存命中率最大化，同时避免GC风暴？

HBase 2.x默认使用BucketCache（替代了老版LRUBlockCache），其设计哲学是“分而治之”：

• 内存划分为固定大小的Bucket（如2MB），每个Bucket存一种类型Block（DATA、INDEX、BLOOM、META）。
• 淘汰策略不是简单的LRU，而是SLRU（Segmented LRU）：将每个Bucket分为Hot和Cold两段，新加载Block先进Cold段，若被再次访问则晋升到Hot段；淘汰时优先清Cold段，Hot段保留更久。
• 关键参数hfile.block.cache.size（默认0.4）控制BlockCache占堆外内存比例，但必须与hbase.bucketcache.size（单位MB）配合设置。例如：若RegionServer堆外内存设为8GB（-XX:MaxDirectMemorySize=8g），则hbase.bucketcache.size应设为8192，hfile.block.cache.size保持0.4即可。

实测发现：当业务存在明显热点RowKey（如首页商品ID），将hbase.rs.cache.blocks.on.write设为true，能让新flush的HFile Block立即加载进Cache，首查延迟降低60%。但这会增加flush耗时，需权衡。

2.4 WAL：崩溃恢复的生命线与性能平衡点

WAL是HBase保证ACID中Durability的唯一手段。它的设计充满妥协：

• 不存全量数据：WAL只存KeyValue的原始字节，不存Schema、不存索引、不压缩（避免fsync时CPU瓶颈）。
• 滚动而非覆盖：WAL文件按大小（hbase.regionserver.hlog.blocksize，默认128MB）或时间（hbase.regionserver.logroll.period，默认1小时）滚动，旧文件在所有对应Region完成flush后才被归档删除。
• 异步刷盘但强一致：客户端Put成功，意味着WAL fsync完成。但RegionServer可配置hbase.regionserver.hlog.syncer.class为AsyncWriter，用单独线程批量fsync，降低单次延迟。

一个常被忽视的陷阱：hbase.wal.provider默认是filesystem，但在SSD集群上，切换为multiwal（多WAL文件并行写）可将WAL吞吐提升3倍。原理很简单：单WAL是串行瓶颈，multiwal为每个Region分配独立WAL文件，写入完全并行。

3. 核心模块协同机制：从写入到读取的全链路剖析

3.1 写入链路：Put请求的七步生死劫

一个Put请求从客户端发出到最终落盘，要穿越7个关键模块，每一步都可能成为瓶颈：

1. Client Side Buffering：客户端HTable默认开启写缓冲（hbase.client.write.buffer，默认2MB）。当缓冲满或显式调用flush()时，才批量发送RPC。这减少网络往返，但增加单次延迟。对延迟敏感业务，建议设为0，走单条同步写。
2. RPC Dispatcher：RegionServer的RpcServer接收请求，根据RowKey路由到对应Handler线程池。若Handler线程数不足（hbase.rpc.server.numreaders），请求排队，表现为rpcQueueTime飙升。
3. WAL Sync：这是最耗时环节。测试显示，在普通SATA盘上，单次fsync平均耗时8ms；在NVMe SSD上可压到0.3ms。因此hbase.regionserver.hlog.sync必须设为true（默认），禁用即放弃持久性。
4. MemStore Insert：ConcurrentSkipListMap插入复杂度O(logN)，但N是当前MemStore大小（通常<10万），实测单次插入<10μs。瓶颈在于锁竞争——所有写入同一Region的线程争抢MemStore锁。
5. MemStore Size Check：每次插入后检查memstoreSize > flushSize。这个检查是原子的，但频繁调用会影响性能。HBase 2.3优化为“懒检查”，只在插入后定期采样。
6. Flush Trigger & Freeze：当触发flush，原MemStore被freeze，新写入转向新实例。freeze操作本身很快（毫秒级），但后续的排序、编码、压缩、写HDFS是重IO操作。
7. HFile Commit：新HFile写入HDFS临时目录（.tmp），待全部Block写完并校验CRC后，原子rename到正式目录。这一步保证HFile的完整性——要么全有，要么全无。

实操心得：我们曾遇到一个案例，业务写入突增，RegionServer频繁full GC。排查发现hbase.hregion.memstore.flush.size被误设为1GB（远超默认128MB），导致单次flush要处理巨量数据，GC压力暴增。调回128MB后，GC频率下降90%，写入TPS反而提升15%——因为小flush更平滑，避免了长尾延迟。

3.2 读取链路：Get/Scan如何在百万级HFile中秒级定位

读请求的路径比写更复杂，因为它要聚合多个来源的数据：

• Get请求（单行精确查询）：

  1. 先查BlockCache：用RowKey哈希定位可能缓存的Data Block。
  2. 若未命中，读HFile的Index Block，二分查找目标RowKey所在的Data Block偏移。
  3. 加载该Data Block到内存，线性扫描（因Block内有序，可用二分）。
  4. 同时检查WAL：若该RowKey在WAL中有更新但尚未flush，则合并WAL中的最新值（此过程叫“MemStore read”）。
  5. 最后返回结果。整个过程通常<10ms（SSD环境）。

• Scan请求（范围扫描）：

  1. 首先确定扫描的Region范围（可能跨多个Region）。
  2. 对每个Region，打开所有相关HFile的Reader（包括MemStore snapshot）。
  3. 维护一个最小堆（Min-Heap），堆中每个元素是某个HFile Reader的当前KeyValue。每次pop堆顶，即获取全局最小RowKey。
  4. 堆顶被消费后，对应Reader推进到下一个KeyValue，重新入堆。
  5. 当RowKey超出scan范围，停止。此机制保证了O(logN)的合并效率，N为参与扫描的HFile数量。

关键优化点：hbase.client.scanner.caching（默认100）控制每次RPC返回的行数。设过大（如1000）会导致单次响应包过大，网络超时；设过小（如10）则RPC次数暴增。我们在线上按平均Row大小（约2KB）计算：caching = 1MB / avg_row_size ≈ 500，实测网络和CPU均衡最佳。

3.3 Compaction：对抗数据碎片化的自动手术刀

HFile不断flush，必然产生大量小文件。Compaction就是HBase的“垃圾回收”，分两类：

• Minor Compaction（小合并）：

  • 触发条件：hbase.hstore.compaction.min（默认3）个HFile堆积时自动触发。
  • 过程：只合并小HFile（<hbase.hstore.compaction.max.size，默认10GB），不重写大HFile。
  • 特点：速度快（分钟级），I/O压力小，但无法删除已标记删除（Delete）的数据。

• Major Compaction（大合并）：

  • 触发条件：hbase.hregion.majorcompaction（默认7天）周期性触发，或手动major_compact。
  • 过程：合并Region下所有HFile，重写全部数据，清理过期版本和Delete标记。
  • 特点：彻底但昂贵（小时级），I/O和CPU双高，可能阻塞读写。

注意：Major Compaction不是“越勤快越好”。我们曾将周期设为1天，结果每天凌晨集群load average飙到50+，业务延迟翻倍。后改为“业务低峰期手动触发+监控HFile数量自动告警”，稳定运行两年无异常。

Compaction的调度算法很关键。HBase 2.x引入ExploringCompactionPolicy，它不简单按HFile数量合并，而是模拟合并后的读放大（Read Amplification）和写放大（Write Amplification），选择最优合并集。例如：合并3个10MB文件 vs 合并1个100MB+2个5MB文件，前者RA更低，后者WA更低，算法会权衡。

3.4 Region Split：水平扩展的临界点与分裂阵痛

Region是HBase的负载均衡单元。当Region大小超过hbase.hregion.max.filesize（默认10GB）时，触发Split：

1. Pre-split：Master下发split指令，RegionServer在本地创建两个子Region（daughter A和daughter B）。
2. StoreFile Split：对每个HFile，用MidKey（中间RowKey）切分成两半，分别写入A和B的临时目录。
3. Atomic Rename：将A、B的临时目录原子rename为正式目录，并更新.META.表。
4. Assignment：ZooKeeper通知Master，Master将新Region分配给其他RegionServer（或本机）。

Split的痛点在于不可用窗口：从split开始到新Region上线，原Region对客户端不可用（NotServingRegionException）。HBase 2.x优化为Daughter Region预热：在split过程中，新Region已加载BlockCache并预热热点Block，上线后立即可服务。

实测数据：一个10GB Region split平均耗时23秒（SSD），其中StoreFile split占70%时间。因此，预分区（Pre-split）是规避split抖动的黄金法则。例如，预估未来一年RowKey范围是uid_0000000000到uid_9999999999，可按1000个Region预分：create 't1', 'f1', {NUMREGIONS => 1000, SPLITALGO => 'HexStringSplit'}。

4. 实战调优指南：基于真实场景的参数精调与避坑清单

4.1 写入性能调优：从“写不进去”到“写得飞起”

当业务反馈“HBase写入延迟高”，不要急着加机器，先看这5个参数：

参数名	默认值	推荐值	调优逻辑	实测效果
hbase.hregion.memstore.flush.size	128MB	64MB	小flush降低单次IO压力，减少GC	写入TPS↑18%，P99延迟↓35%
hbase.hstore.blockingStoreFiles	10	16	提高HFile堆积阈值，减少minor compaction频率	compaction次数↓40%，CPU占用↓25%
hbase.regionserver.wal.codec	org.apache.hadoop.hbase.regionserver.wal.WALCellCodec	org.apache.hadoop.hbase.regionserver.wal.IndexedWALCellCodec	启用WAL索引，加速WAL replay	故障恢复时间↓60%
hbase.hregion.majorcompaction	604800000(7天)	0	关闭自动major，改用业务低峰期手动触发	避免凌晨集群雪崩
hbase.coprocessor.region.classes	空	org.apache.hadoop.hbase.coprocessor.AggregateImplementation	开启协处理器，支持sum/count等聚合	减少客户端数据传输量

重要提醒：hbase.hregion.memstore.flush.size不能盲目调小！若设为32MB，而业务单次Put平均1KB，则每3.2万次写入就flush一次，产生海量小HFile，最终引发compaction风暴。必须结合hbase.hstore.compaction.min（默认3）和业务写入频次综合计算。

4.2 读取性能调优：让Scan像Get一样快

Scan慢的根源往往是“读放大”——一次Scan要读多个HFile的多个Block。优化核心是减少参与Scan的HFile数量：

• 启用Bloom Filter：在建表时指定BLOOMFILTER => 'ROW'（对RowKey建布隆过滤器）。它能在读HFile前快速判断“该RowKey是否可能存在于本文件”，避免无效IO。实测对稀疏查询（如查100个随机UID），IO减少70%。
• 调整TTL与Versions：TTL => 604800（7天）和VERSIONS => 1能大幅减少HFile中冗余数据。注意：VERSIONS => 1意味着旧数据被新数据覆盖，不支持历史追溯。
• 使用Filter下推：避免scan.setFilter(new RowFilter(CompareOp.EQUAL, new BinaryComparator(Bytes.toBytes("uid_123"))))这种客户端过滤，改用SingleColumnValueFilter并确保Qualifier有索引（需协处理器支持）。

一个经典案例：某日志分析平台Scan超时，排查发现hfile.block.cache.size被设为0.1（太小），导致90%的Scan Block Cache Miss，全部走HDFS。调至0.4后，P95延迟从8s降至120ms。

4.3 稳定性加固：避开OOM、Split风暴、WAL积压三大雷区

• OOM防护：

  • hbase.regionserver.global.memstore.size（默认0.4）和hfile.block.cache.size（默认0.4）之和不能超过0.8，否则堆外内存不足。
  • 必须设置-XX:+UseG1GC -XX:MaxGCPauseMillis=100，G1 GC对大堆更友好。
  • 监控MemStoreSize和BlockCacheSize，告警阈值设为85%。

• Split风暴预防：

  • 禁用自动split：hbase.hregion.majorcompaction设为0，hbase.hregion.split.policy设为DisabledRegionSplitPolicy。
  • 改用ConstantSizeRegionSplitPolicy，按固定大小split，避免热点Region无限膨胀。

• WAL积压处理：

  • 监控WALAppendTime_mean和WALSyncTime_mean，超过10ms需告警。
  • 若WAL写入慢，优先检查HDFS namenode负载（hdfs dfsadmin -report）和datanode磁盘IO（iostat -x 1）。
  • 极端情况下，可临时启用hbase.regionserver.wal.disable（仅测试环境！），但会丢失数据。

4.4 故障排查速查表：5分钟定位90%的HBase问题

现象	可能原因	快速验证命令	解决方案
Put超时，日志报TimeoutIOException	RPC Handler线程耗尽	echo "status 'detailed'" | hbase shell查rpcQueueTime	增加hbase.rpc.server.numreaders
Scan极慢，hbase.metrics.regionserver.storefileCount> 100	小HFile过多，compaction滞后	hbase org.apache.hadoop.hbase.util.HBaseFsck -fixReferenceFiles	手动触发major_compact
RegionServer频繁宕机，GC日志显示Full GC	MemStore或BlockCache内存溢出	jstat -gc <pid>查OU(Old Used)	调整hbase.regionserver.global.memstore.size
新写入数据查不到	客户端缓存了旧Region位置	hbase shell执行flush 'table_name'	清客户端缓存：hbase.client.meta.cache.enabled=false
WAL目录持续增长不清理	Region未完成flush，WAL被hold	hdfs dfs -ls /hbase/WALs/查文件修改时间	重启卡住的RegionServer，或手动hbase hbck -fixMeta

我踩过的最深的坑：某次升级HBase 2.4后，所有Scan变慢3倍。排查数日，最终发现hbase.regionserver.storefile.refresh.period（默认0）被误设为30000（30秒）。这个参数会让RegionServer每30秒重新加载HFile元数据，引发大量不必要的HDFS list操作。设回0后，一切恢复正常。记住：任何非0的“刷新”类参数，在生产环境都要三思。

5. 常见问题与深度排查技巧实录

5.1 “HBase写入吞吐上不去，CPU却很高” —— 编码与压缩的隐性成本

现象：集群CPU使用率长期>80%，但写入TPS卡在5万/s上不去。top显示java进程占CPU最高，jstack看到大量SnappyCompressor.compress线程。

根因分析：HBase默认对HFile启用SNAPPY压缩（hfile.compression），而Snappy压缩是CPU密集型操作。当RegionServer CPU成为瓶颈时，压缩反而成了拖累。

验证步骤：

1. 查看HFile压缩状态：hbase org.apache.hadoop.hbase.util.HBaseFsck -metaonly，确认compression字段。
2. 监控JVM线程：jstack <pid>搜索compress，确认线程栈。
3. 对比测试：停写，用hbase org.apache.hadoop.hbase.io.hfile.HFilePrettyPrinter -f /hbase/data/default/t1/.../f/...查看单个HFile的压缩率（通常SNAPPY达3:1）。

解决方案：

• 换压缩算法：GZ压缩率更高（5:1）但更慢；LZ4速度最快（比SNAPPY快2倍），压缩率略低（2.5:1）。线上推荐LZ4：alter 't1', {NAME => 'f1', COMPRESSION => 'LZ4'}。
• 关闭压缩：对冷数据或SSD集群，COMPRESSION => 'NONE'可释放CPU，用存储空间换性能。
• 升级硬件：换用Intel AVX-512指令集CPU，Snappy压缩性能可提升40%。

经验：我们做过AB测试，同样10GB原始数据，SNAPPY压缩耗时12s，LZ4仅5.3s，CPU占用峰值从95%降至65%。虽然HFile体积大了15%，但SSD随机读性能足够弥补，整体写入TPS提升22%。

5.2 “RegionServer启动失败，报错Failed to become active master” —— ZooKeeper会话超时的连锁反应

现象：RegionServer进程启动后几秒内退出，日志关键错误：

2024-05-20 10:20:33,123 ERROR [main] zookeeper.RecoverableZooKeeper: ZooKeeper create failed after 4 attempts ... Caused by: org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss

这不是ZooKeeper连不上，而是RegionServer与ZK的session timeout设置不合理。

深度解析：RegionServer启动时，需在ZK的/hbase/rs节点下创建临时顺序节点。这个操作必须在ZK session timeout（默认40秒）内完成。若RegionServer初始化慢（如加载大量HFile元数据、BlockCache预热），就会超时。

验证方法：

• 查ZK配置：cat $ZK_HOME/conf/zoo.cfg | grep tickTime，tickTime=2000，则initLimit=10→sessionTimeout=40000ms。
• 查RegionServer日志：搜索Starting up到Registered in ZK的时间差。

标准修复流程：

1. 增大ZK session timeout：在hbase-site.xml中添加：

   <property> <name>zookeeper.session.timeout</name> <value>60000</value> <!-- 60秒 --> </property>

2. 同步修改ZK配置：zoo.cfg中tickTime=2000，则initLimit=30，syncLimit=10，确保ZK服务端也支持60秒session。
3. 优化RegionServer启动：关闭hbase.regionserver.storefile.refresh.period，避免启动时扫描所有HFile。

注意：zookeeper.session.timeout不能设得过大（如300秒），否则ZK故障检测延迟太高，影响集群高可用。60秒是生产环境黄金值。

5.3 “HBase Master UI显示Region数激增，但业务无新增数据” —— Split未完成的幽灵Region

现象：HBase Master Web UI中Regions in Transition长期>0，Region Count持续上涨，但hbase.metrics.regionserver.storefileCount稳定，业务无写入。

根因：Region Split卡在中间状态。Split过程分多步，任何一步失败都会留下“幽灵Region”——它们在ZK中有节点，HDFS中有文件，但Master认为它们未完成，既不分配也不清理。

排查命令：

# 查看ZK中未完成的split echo "ls /hbase/splitWAL" | zkCli.sh echo "ls /hbase/running" | zkCli.sh # 查看HDFS中孤立的split文件 hdfs dfs -ls /hbase/.tmp/ hdfs dfs -ls /hbase/data/default/t1/

典型场景：Split时RegionServer宕机，daughter A已创建，daughter B未完成，ZK中残留/hbase/splitWAL/region_A节点。

安全清理步骤：

1. 确认RegionServer已下线：hbase shell执行list_regions 't1'，确认无该Region的Server。
2. 手动删除ZK节点：

   echo "rmr /hbase/splitWAL/region_A" | zkCli.sh echo "rmr /hbase/running/region_A" | zkCli.sh

3. 清理HDFS临时文件：

   hdfs dfs -rm -r /hbase/.tmp/region_A hdfs dfs -rm -r /hbase/data/default/t1/region_A

4. 触发hbck修复：hbase hbck -fixMeta -fixAssignments

重要原则：绝不手动删除正在服务的Region的HFile！必须通过hbck工具，它会校验元数据一致性。我们曾有人误删，导致整个表NotServingRegionException，恢复花了6小时。

5.4 “BulkLoad导入后，Scan结果缺失部分数据” —— HFile时间戳与MemStore的时序战争

现象：用LoadIncrementalHFiles导入一批HFile后，用scan查不到刚导入的数据，但get单行却能查到。

根因：BulkLoad的HFile中KeyValue的Timestamp，与Region当前MemStore的oldestUnflushedSequenceId冲突。

技术细节：HBase要求所有数据按SequenceId（单调递增）排序。BulkLoad的HFile默认使用导入时间戳，若该时间戳小于Region当前MemStore中最早的未flush KeyValue的timestamp，则BulkLoad数据被视为“过期”，在Scan时被跳过。

验证方法：

1. 查看BulkLoad HFile的timestamp：hbase org.apache.hadoop.hbase.io.hfile.HFilePrettyPrinter -f /path/to/hfile | head -20
2. 查看Region MemStore状态：hbase shell执行status 'detailed'，找对应Region的oldestUnflushedSequenceId。

解决方案：

• 强制HFile使用最大时间戳：BulkLoad前，用hbase org.apache.hadoop.hbase.util.HFileTool重写HFile，指定--timestamp为Long.MAX_VALUE。
• 清空MemStore：导入前，对目标Region执行flush 't1', 'region_name'，确保MemStore为空。
• 使用completebulkload的-Dhbase.loadincremental.timestamp参数：HBase 2.3+支持，直接指定时间戳。

这个问题在实时数仓场景高频出现：Flink作业每5分钟BulkLoad一次，若Region恰好在导入时有少量写入，就可能丢数据。我们的标准流程是：BulkLoad前必flush，并监控MemStoreSize确保为0。

6. 存储演进趋势与架构思考：超越HBase本身的技术洞察

HBase的存储设计，本质是2010年代硬件条件（HDD为主、千兆网络、Java 6 GC）下的最优解。但今天，硬件和需求都在变，这迫使我们重新审视它的模块边界：

• WAL的消亡？NVMe SSD的随机写延迟已逼近内存（<100μs），而WAL的fsync开销（即使异步）仍是瓶颈。TiDB的Raft Log、CockroachDB的Raft Entry，都把日志和数据混合存储，靠共识算法保证一致性。HBase的WAL+HFile分离架构，在极致性能场景下显得笨重。

• MemStore的重构：ConcurrentSkipListMap在百万级Key时，内存占用和GC压力巨大。RocksDB用Subcompaction和Column Families实现更细粒度的内存管理。HBase社区也在探索ChunkCache（基于堆外内存的MemStore替代品），但成熟度尚低。

• HFile的终结？列存格式（如Parquet）在OLAP场景碾压行存。HBase on Object Store（S3/HDFS