Part 01 LSM树模型
常见的的关系型数据库,如MySQL、SQL Server、Oracle等,使用B+ Tree作为数据存储与索引的基本结构,非叶子节点只存放索引数据,叶子节点存放所有数据和指向相邻节点的指针,具有高效的范围查询和稳定的查找效率,以及具有较小的读放大和空间放大。采用磁盘随机读写方式,且以磁盘数据页作为最小的读写单元,随着数据大量插入,导致叶子节点不断分裂,最终导致逻辑连续的数据存放到不同物理磁盘块位置,产生大量的读随机 I/O,从而导致范围查询效率下降和读写放大,磁盘随机读写成为 B+Tree 的瓶颈,适用于读多写少的场景。
Log Structured Merge Tree (日志结构合并树) ,一种先于BigTable出现的文件组织方式,最早可以追溯到1996年 Patrick O'Neil等人的论文,因其独特的数据组织方式(Log Structured)和需要在后台通过不断合并(Merge)的维护方式而得名,在BigTable出现之后,开始被重视被广泛应用于 HBase、Cassandra、ClickHouse、LevelDB、RocksDB 和 TiDB 等写密集型 KV 数据库和存储引擎上。
LSM 树实际上并非是一种具体的数据结构,而是一种具备顺序追加、多层数据结构和定期合并等特性的数据处理逻辑。将离散的随机写转化为批量的顺序写,减少了磁盘寻道时间提高了写入性能,适用于写密集型应用,在Patrick O'Neil的论文中给出了多级的日志结构合并树的结构。
图片
C0 tree在内存中,C1到Ck tree在磁盘上,Ck tree是一个有序的树状结构,数据的写入流转从C0 tree 内存开始,不断被合并到磁盘上更大容量的Ck tree上。由于内存的读写速率都比外存要快非常多,因此数据写入的效率很高。并且数据从内存刷入磁盘时是预排序的,也就是说,LSM树将原本的随机写操作转化成了顺序写操作,写性能大幅提升。但是读取时需要将内存中的数据和磁盘中的数据合并,牺牲了一部分读性能。
Part 02 HBase系统架构
HBase基LSM树模型构建一个分布式的列数据库,HBase采用Master/Slave架构搭建集群,隶属于Hadoop生态系统,数据存储于HDFS中,其整体的系统架构如下图所示:
图片
一个RegionServer由一个(或多个)HLog、一个 BlockCache以及多个Region组成
· HLog用来保证数据写入的可靠性;
· BlockCache可以将数据块缓存在内存中以提升数据读取性能;
· Region是HBase中数据表的一个数据分片,一个RegionServer上通常会负责多个Region 的数据读写。
图片
一张表会被水平切分成多个Region,每个 Region负责自己区域的数据读写请求。一个Region由多个Store组成,每个Store存放对应列簇的数据,比如一个表中有两个列簇,这个表的所有Region就都会包含两个Store。每个Store包含一个MemStore和多个HFile,用户数据写入时会将对应列簇数据写入相应的 MemStore,一旦写入数据的内存大小超过设定阈值,系统就会将MemStore中的数据落盘形成HFile文件。HFile存放在HDFS上,是一种定制化格式的数据存储文件,方便用户进行数据读取。
Part 03 MemStore实现
MemStore是LSM中C0 Tree的实现,由一个可写的Segment,以及一个或多个不可写的Segments构成,所有的数据写入操作,会按顺序先写入日志HLog,再写入MemStore,当MemStore中数据大小超过阈值之后,再将这些数据批量写入磁盘,生成一个新的StoreFile(HFile),最后多个StoreFile(HFile)又会进行Compact。
· 通过MemStoreLAB(Local Allocation Buffer),使用堆外一段固定的内存段Chunk来存储KeyValue数据,当Region执行flush之后释放的就是一段Chunk所占有的连续内存,而不是KeyValue占有的零散内存,很好地解决了内存碎片的问题。
· 使用CellSet存放所有的KeyValue的数据,CellSet核心是一个ConcurrentSkipListMap,数据按照Key值有序存放,而且在高并发写入时,性能远高于ConcurrentHashMap,通过跳表实现高效插入、更高的并发性。
图片
在HBaseV2.x后,使用带合并写内存的CompactingMemStore,MemStore中的Active的Segment数据先Flush成一个Immutable的Segment,多个Immutable Segments可在内存中进行Compaction,当达到一定阈值以后才将内存中的数据持久化成HDFS中的HFile文件。
Part 04 HFile文件结构
HBase使用列族式存储,列族数据是存储在一起的,列族式存储介于行数存储和列式存储之间。
· 一张表,只设置一个列族,等同于行式存储;
· 一张表,设置大量列族,每个列族下仅有一列,等同于行数存储。
在将文件结构前,先看下数据存储格式,当put到hbase一个key和value的时候,会增加一条记录:
(Table, RowKey, Family, Qualifier, Timestamp) -> Value
该记录以字节流的方式存储,对应到磁盘中的存储格式为:
图片
从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消耗,获取相对稳定的读取性能。在实际业务中,需要配置合适的合并策略,在读放大、写放大和空间放大中,做好权衡和取舍。