浅谈HBase数据结构和系统架构( 二 ) _HBase

Part 04 HFile文件结构HBase使用列族式存储，列族数据是存储在一起的，列族式存储介于行数存储和列式存储之间。
· 一张表，只设置一个列族，等同于行式存储;
· 一张表，设置大量列族，每个列族下仅有一列，等同于行数存储。
在将文件结构前，先看下数据存储格式，当put到hbase一个key和value的时候，会增加一条记录：
(Table, RowKey, Family, Qualifier, Timestamp) -> Value
【浅谈HBase数据结构和系统架构】该记录以字节流的方式存储，对应到磁盘中的存储格式为：

文章插图
图片
从HBase开始到现在，HFile经历了三个版本，主要变更如下：
· HFile V1 ，HBase 0.92之前，结构简单，参考了Bigtable的SSTable以及Hadoop的TFile，Region Open的时候，需要加载所有的Data Block Index数据，另外，第一次读取时需要加载所有的Bloom Filter数据到内存中。一个HFile中的Bloom Filter的数据大小可达百MB级别，一个RegionServer启动时可能需要加载数GB的Data Block Index数据
· HFile V2，使用分层索引，按需读取Data Block的索引数据和Bloom Filter数据，避免在Region Open阶段或读取阶段一次读入大量的数据，有效降低时延。等load-on-open加载到完，regions server可以认为完成启动，加速启动时间
· HFile V3 ，从0.98版本开始引，主要是为了支持Tag特性，在HFile V2基础上只做了微量改动
在下文内容中，主要围绕HFile V2的设计展开。

文章插图
图片
无论是Data Block Index ，还是Bloom Filter，都采用了分层索引的设计，最多可支持三层索引：
· 最上层为Root Data Index，放在一个称之为Load-on-open Section区域，Region Open时会被加载到内存中，从Root Data Index 索引到 Intermediate Block Index
· 中间层为Intermediate Index Block，从Intermediate Block Index 索引到 Leaf Index Block
· 最底层为Leaf Index Block ，可直接索引到Data Block
在实际场景中，Intermediate Block Index基本上不会存在，因此，索引逻辑被简化为：由Root Data Index直接索引到Leaf Index Block，再由Leaf Index Block查找到的对应的Data Block 。
Part 05 HFile Compaction合并HBase Compaction分为两种：Minor Compaction和Major Compaction，通常我们简称为小合并、大合并，以短时间内的IO消耗，以换取相对稳定的读取性能，下面是一个简单示意图：

文章插图
图片
Minor Compaction，指选取一些小的、相邻的HFile将他们合并成一个更大的HFile 。通过少量的 IO 减少文件个数，提高读取操作的性能，适合较高频率的跑。缺点是只合并了局部的数据，对于那些全局删除操作，无法在合并过程中完全删除。默认情况下，minor compaction会删除选取HFile中的TTL过期数据。
Major Compaction，指将一个Store中所有的HFile合并成一个HFile，这个过程会清理三类没有意义的数据：被删除的数据(打了Delete标记的数据)、TTL过期数据、版本号超过设定版本号的数据。另外，一般情况下，Major Compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此，生产环境下通常关闭自动触发Major Compaction功能，改为手动在业务低峰期触发。
Part 06 总结HBase基于LSM Tree模型，通过MemStore和StoreFile实现内存和磁盘中的日志合并，使用顺序追加、定期合并方式，提高数据的写入性能，支持海量数据的存储。通过Compaction合并，以短时间内的IO消耗，获取相对稳定的读取性能。在实际业务中，需要配置合适的合并策略，在读放大、写放大和空间放大中，做好权衡和取舍。