HBase2.0新特性之In-Memory Compaction

Posted 2021-04-19 HBase技术社区

In-Memory Compaction是HBase2.0中的重要特性之一，通过在内存中引入LSM结构，减少多余数据，实现降低flush频率和减小写放大的效果。本文根据HBase2.0中相关代码以及社区的讨论、博客，介绍In-Memory Compaction的使用和实现原理。

原理

概念和数据结构

In-Memory Compaction中引入了MemStore的一个新的实现类 CompactingMemStore。顾名思义，这个类和默认memstore的区别在于实现了在内存中compaction。

CompactingMemStore中，数据以 segment作为单位进行组织，一个memStore中包含多个segment。数据写入时首先进入一个被称为 active 的segment，这个segment是可修改的。当active满之后，会被移动到 pipeline中，这个过程称为 in-memory flush 。pipeline中包含多个segment，其中的数据不可修改。CompactingMemStore会在后台将pipeline中的多个segment合并为一个更大、更紧凑的segment，这就是compaction的过程。

如果RegionServer需要把memstore的数据flush到磁盘，会首先选择其他类型的memstore，然后再选择CompactingMemStore。这是因为CompactingMemStore对内存的管理更有效率，所以延长CompactingMemStore的生命周期可以减少总的I/O。当CompactingMemStore被flush到磁盘时，pipeline中的所有segment会被移到一个snapshot中进行合并然后写入HFile。

在默认的MemStore中，对cell的索引使用ConcurrentSkipListMap，这种结构支持动态修改，但是其中存在大量小对象，内存浪费比较严重。而在CompactingMemStore中，由于pipeline里面的数据是只读的，就可以使用更紧凑的数据结构来存储索引，减少内存使用。代码中使用CellArrayMap结构来存储cell索引，其内部实现是一个数组。

Compaction策略

当一个active segment被flush到pipeline中之后，后台会触发一个任务对pipeline中的数据进行合并。合并任务会对pipeline中所有segment进行scan，将他们的索引合并为一个。有三种合并策略可供选择：Basic,Eager,Adaptive。

Basic compaction策略和Eager compaction策略的区别在于如何处理cell数据。Basic compaction不会清理多余的数据版本，这样就不需要对cell的内存进行拷贝。而Eager compaction会过滤重复的数据，并清理多余的版本，这意味着会有额外的开销：例如如果使用了MSLAB存储cell数据，就需要把经过清理之后的cell从旧的MSLAB拷贝到新的MSLAB。basic适用于所有写入模式，eager则主要针对数据大量淘汰的场景：例如消息队列、购物车等。

Adaptive策略则是根据数据的重复情况来决定是否使用Eager策略。在Adaptive策略中，首先会对待合并的segment进行评估，方法是在已经统计过不重复key个数的segment中，找出cell个数最多的一个，然后用这个segment的numUniqueKeys / getCellsCount得到一个比例，如果比例小于设定的阈值，则使用Eager策略，否则使用Basic策略。

使用

配置

2.0中，默认的In-Memory Compaction策略为basic。可以通过修改hbase-site.xml修改：

<property>

    <name>hbase.hregion.compacting.memstore.type</name> 

    <value><none|basic|eager|adaptive></value>

</property>

也可以单独设置某个列族的级别：

create ‘<tablename>’, {NAME => ‘<cfname>’, IN_MEMORY_COMPACTION => ‘<NONE|BASIC|EAGER|ADAPTIVE>’}

性能提升

社区的博客中给出了两个不同场景的测试结果。使用YCSB测试工具，100-200 GB数据集。分别在key热度符合Zipf分布和平均分布两种情况下，测试了只有写操作情况下写放大、吞吐、GC相比默认memstore的变化，以及读写各占50%情况下尾部读延时的变化。
测试结果如下表：

Key热度分布	写放大	吞吐	GC	尾部读延时
Zipf	30%↓	20% ↑	22% ↓	12% ↓
平均分布	25%↓	50% ↑	36% ↓	无变化

长按下面的二维码关注HBase技术社区

长按下面的二维码邀请加入HBase社区微信群