HBase新特性—StripeCompaction

借鉴于LevelDB、Cassandra的Compaction方法，https://issues.apache.org/jira/browse/HBASE-7667 提出了Stripe Compaction的方法。 Motivation： 1）过多Region会增大RS维护的开销，降低RS的读写性能。随着数据量的增大，在一定程度上增加Region个数，会提高

借鉴于LevelDB、Cassandra的Compaction方法，https://issues.apache.org/jira/browse/HBASE-7667 提出了Stripe Compaction的方法。

Motivation：
1）过多Region会增大RS维护的开销，降低RS的读写性能。随着数据量的增大，在一定程度上增加Region个数，会提高系统的吞吐率。然而，RS上服务的Region个数增多，增加了RS下内存维护的开销，尤其每个Store下都配置有一个MemStore，从而会造成频率更高的Flush操作，影响系统的读写性能。因此，如果能够提出更轻量级的mini-Region，不仅能够降低服务多个Region的开销，而且能够提升读写数据的效率。

2) Region Compaction容易”放大”。例如，Region区间为[1FFF，2FFF）,在该区间内仅有[1FFF，21FF)区间有大量的写操作(put、delete)，但是,在触及MajorCompaction条件时，却需要对所有的文件执行Major Compaction，从而引起大量的IO。

3) Region Split操作代价较大。

需要了解之前HBase的Compaction与Flush过程，可以参考：HBaseCompaction机制 以及 HBase Flush对读写的影响

Stripe-Compaction设计的核心思想：
1）对于Region下的rowkey区间进行二次切分，例如[1FFF,2FFF)，切分成[1FFF,24FF),[24FF,2FFF)两个区间，每个区间成为Stripe。
2）Region下的数据文件分为Level-0和Level-1两层。其中Level-0主要用来存储临时的数据文件(例如使用bulkload或者执行mem flush操作之后的数据)， Level-1层的数据是按照Stripe的分区来区分。
3）支持两种方式的配置：Mini-regions的个数设置、或者以Size-based为大小触发因子的自动切分机制。
4）容错机制。如果在Stripes之间存在空洞。那么可以根据在Store当中的设置，将所有的处于Level-1层的文件回归到Level-0重新进行compaction。
5）Get操作时，一个Row所涉及到文件有：MemStore、Level-0下所有文件、以及Level-1下对应Stripe区下的文件。根据Stack的意见，最终Level-0下的文件只是一个暂时的状态，大部分文件都位于Level-1 Stripe下，因此，这样随机读时，需要涉及到的文件更聚集。
6）Scan操作时，需要定位startrow即可。在扫描过程中，会按照Stripe的row区间的排序，依次进行。
7）Compaction，是Level-0上升到Level-1的过程，同时，在Level-1层次的数据，也会进行相关的合并。
8）在Split操作时，定位Rowkey区间的中心点，可以根据Stripe记录的位置，进一步查找，因此，使用预置的Stripe会有利于Split操作的进行，可以实现多数HFile文件直接拷贝到子Region目录，从而加快了Split操作的效率。

下面对于Cassandra以及LevelDB中使用的多层次Compaction算法做一个介绍。

1)分层式压缩方式将数据分成条个层，最底层的叫L0，其上分别是L1，L2….，每一层的数据大小是其上的那一层数据最大大小的10倍，其中最底层L0的大小为5M (可以配置)
2) 当level层次大于0时，同一层的各个文件之间的Rowkey区间不会重叠。所以在level n与level n+1的数据块进行合并时，可以明确的知道某个key值处在哪个数据块中，可以一个数据块一个数据块的合并，合并后生成新块就丢掉老块。不用一直到所有合并完成后才能删除老的块。
3）整体执行流程是从L0->L1->L2，依次合并的过程，如下图所示。

由上图，我们可以得知，越是level较低的块，它的数据就越新，在满足向下归约合并的过程中，就会按照文件的Rowkey的区间，进行合并，去除多余的版本，或者执行相关删除操作。因此，在读请求最极端的情况下，从Level0开始读数据，一直读到最下层Level n。

这种Compaction的优势在于：
1）大部分的读操作如果有LRU特性，都会落入较低的Level上。因此，数据越"热"，Level就越低。从而有利于未来HFile多种存储介质的定位问题。
2）在合并的过程中，仅需在由上到下的部分文件参与，而不是要对所有文件执行Compaction操作。这样会加快Compaction执行的效率。

劣势在于，如果层次太多，在递归合并的过程中，容易造成某个区间的Compaction风暴，影响该区间数据操作的吞吐。
因此，HBase-Stripe Compaction的方案中，只有两层，Level 0和Level1，这种方法在保留分层压缩的优势的同时，降低了总文件个数，有利于RS执行Split、Merge等操作。

参考文献：
[1] HBase-7667 https://issues.apache.org/jira/browse/HBASE-7667

本系列文章属于Binos_ICT在Binospace个人技术博客原创，原文链接为http://www.binospace.com/index.php/hbase-new-features-stripe-compaction,未经允许，不得转载。

From Binospace, post HBase新特性—Stripe Compaction

文章的脚注信息由WordPress的wp-posturl插件自动生成