HBase新特性—Stripe Compaction

借鉴于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插件自动生成

---

Copyright © 2008
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
)