HBase Compaction策略

简介: HBase Compaction策略 StripeCompactionPolicy、DateTieredCompactionPolicy、RatioBasedCompactionPolicy、ExploringCompactionPolicy、FIFOCompactionPolicy

StripeCompactionPolicy

Stripes表示条纹,意为将Region分为多个条纹区间分别做compact,类似于将Region分为多个Sub-Region。
适用场景:

  1. Region较大:相对于较小的Region而言,对MemStore和Region的管理带来的负担更小。
  2. 新产生的行键不均匀分布在各Region:如基于时间序列的行键生成方式,新生成的数据行均分布在Region的同一个Sub-Region区间,只有新产生的那一部分行键相关数据会被合并,旧的数据行会很少合并或者根本不合并。

DateTieredCompactionPolicy

按时间分层合并,顾名思义,该合并策略与时间相关,适用于数据写入基于时间产生且无更新删除,数据读取会指定数据读取区间,并且读取新产生的数据的频率较大。
按时间分层合并策略通过感知需要合并的HFile的数据写入相关时间戳,并不会将新老数据合并为一个大的HFile,而是按时间分层结构来组织合并HFile,所以不同时间写入的相邻行键数据可能被放入不同的HFile,这样对基于时间区间的扫描效率是一个很大的提升,但是对基于行键的区间扫描效率会是一个很不友好的策略。

RatioBasedCompactionPolicy

基于比列的合并策略,该策略在0.98版本之前是HBase默认的策略,之后的版本使用了基于比例策略的一个改进版本(ExploringCompactionPolicy),如果是Major合并,那么该策略会将所有的StoreFile文件合并为一个大的文件,如果是Minor合并,使用如下策略选择需要合并的文件:
前提:假设最老的StoreFile文件大小最大,选择待合并的文件按时间排序,最旧的文件排最前。
配置项hbase.hstore.compaction.ratio合并参数,命名为R
配置项hbase.hstore.compaction.min最小待合并文件数,命名为A。
配置项hbase.hstore.compaction.max最大待合并文件数,命名为B。
配置项hbase.hstore.compaction.min.size最小合并文件总大小,命名为C,以R=0.1,A=3,B=5,C=20,待合并的文件为O=[50,40,30,30,20,10,5]为例子

  1. 计算一个待合并文件总大小的数组fileSizes[i,i+A-1) ,得到X = [150, 120, 90, 65, 35, 15, 5]。
  2. 从旧到新文件,逐一判断文件大小是否满足 fileSizes[i] > Math.max(C, (X[i + 1] * R)) ,当条件不满足后,i即为待合并的文件开始位置,该步骤是为了过滤掉大的文件,此处得到i=4。
  3. 最后得到需要合并的文件列表为O.subList(4,O.size-1),得出结果为[20, 10, 5]。

简化后的代码片段如下所示

package com.mt.hbase.chpt07.compact;

import java.util.Arrays;
import java.util.LinkedList;
import java.util.List;

/**
 * @author pengxu
 * @Date 2018/12/9.
 */
public class RatioCompactPolicy {

    public static List<integer> applyCompactionPolicy(List<integer> candidates , boolean mayBeStuck){
        int minFileToCompact = 3;
        int maxFileToCompact = 5;
        int minCompactSize = 20;
        double ratio = 0.1;
        int start = 0;
        // get store file sizes for incremental compacting selection.
        final int countOfFiles = candidates.size();
        long[] fileSizes = new long[countOfFiles];
        long[] sumSize = new long[countOfFiles];
        for (int i = countOfFiles - 1; i >= 0; --i) {
            fileSizes[i] = candidates.get(i);
            // calculate the sum of fileSizes[i,i+maxFilesToCompact-1) for algo
            int tooFar = i + maxFileToCompact - 1;
            sumSize[i] = fileSizes[i] + ((i + 1 < countOfFiles) ? sumSize[i + 1] : 0) - ((tooFar
                    < countOfFiles) ? fileSizes[tooFar] : 0);
        }

        while (countOfFiles - start >= minFileToCompact &&
                fileSizes[start] > Math.max(minCompactSize, (sumSize[start + 1] * ratio))) {
            ++start;
        }
        if (start < countOfFiles) {
            System.out.println("Default compaction algorithm has selected " + (countOfFiles - start)
                    + " files from " + countOfFiles + " candidates");
        } else if (mayBeStuck) {
            // We may be stuck. Compact the latest files if we can.
            int filesToLeave = candidates.size() - minFileToCompact;
            if (filesToLeave >= 0) {
                start = filesToLeave;
            }
        }
        System.out.println("sumSize=" + Arrays.toString(sumSize));
        System.out.println("start=" + start);
        candidates.subList(0, start).clear();
        System.out.println("fileToCompact =" + candidates);
        return candidates;
    }

    public static void main(String[] args) {
        int[] candidateIntArray = new int[] { 50, 40, 30, 30, 20, 10, 5 };
        List<integer> candidateList = new LinkedList<integer>();
        for(Integer candidate : candidateIntArray){
            candidateList.add(candidate);
        }
        applyCompactionPolicy(candidateList,true);

    }

}

ExploringCompactionPolicy

该策略继承自RatioBasedCompactionPolicy,其选择待合并的文件列表算法非常简单,即根据上述参数(最小待合并文件数、最大待合并文件数、合并参数、合并文件总大小)组合计算出一个文件数最多,文件总数最小的文件区间组合,这个计算类似用一个滑动窗口去计算窗口内文件数量与大小的比例,文件越小数量越多则为最优解。

FIFOCompactionPolicy

该策略继承自ExploringCompactionPolicy,仅仅选择所有数据均已经过期的StoreFile文件进行合并,所以表的列族需要指定数据的TTL,故该合并策略仅适用于临时存储数据,经过处理后会被全部丢弃的场景。


HBase从1.2.X开始到2.0.X,默认的压缩策略都是RatioBasedCompactionPolicy,可以通过如下两种方式修改默认的压缩策略:

  1. 修改hbase-site.xml配置项hbase.hstore.engine.class,该修改会应用到整个HBase集群。
  2. 执行表修改语句alter 's_behavior', CONFIGURATION => {'hbase.hstore.engine.class' => 'rg.apache.hadoop.hbase.regionserver.DefaultStoreEngine'},该修改方式只对语句指定的表生效
相关实践学习
云数据库HBase版使用教程
&nbsp; 相关的阿里云产品:云数据库 HBase 版 面向大数据领域的一站式NoSQL服务,100%兼容开源HBase并深度扩展,支持海量数据下的实时存储、高并发吞吐、轻SQL分析、全文检索、时序时空查询等能力,是风控、推荐、广告、物联网、车联网、Feeds流、数据大屏等场景首选数据库,是为淘宝、支付宝、菜鸟等众多阿里核心业务提供关键支撑的数据库。 了解产品详情:&nbsp;https://cn.aliyun.com/product/hbase &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
1月前
|
SQL 存储 分布式数据库
bigdata-28-HBase基本调优策略
bigdata-28-HBase基本调优策略
34 0
|
1月前
|
存储 搜索推荐 关系型数据库
用户画像系列——HBase 在画像标签过期策略中的应用
用户画像系列——HBase 在画像标签过期策略中的应用
78 0
|
存储 测试技术 分布式数据库
技术篇-HBase 2.0 新特性之 In-Memory Compaction
In-Memory Compaction 是 HBase2.0 中的重要特性之一,通过在内存中引入 LSM 结构,减少多余数据,实现降低 flush 频率和减小写放大的效果。本文根据 HBase2.0 中相关代码以及社区的讨论、博客,介绍 In-Memory Compaction 的使用和实现原理。
4907 0
|
存储 缓存 Java
技术篇-HBase 最佳实践-读性能优化策略
任何系统都会有各种各样的问题,有些是系统本身设计问题,有些却是使用姿势问题。HBase也一样,在真实生产线上大家或多或少都会遇到很多问题,有些是 HBase 还需要完善的,有些是我们确实对它了解太少。总结起来,大家遇到的主要问题无非是 Full GC 异常导致宕机问题、RIT 问题、写吞吐量太低以及读延迟较大。
2322 0
|
存储 缓存 Java
HBase最佳实践-读性能优化策略
任何系统都会有各种各样的问题,有些是系统本身设计问题,有些却是使用姿势问题。HBase也一样,在真实生产线上大家或多或少都会遇到很多问题,有些是HBase还需要完善的,有些是我们确实对它了解太少。总结起来,大家遇到的主要问题无非是Full GC异常导致宕机问题、RIT问题、写吞吐量太低以及读延迟较大。
2094 0
|
Java 分布式数据库 索引
阿里 Hbase的优化策略(上)
社区开源的做法 常见的HBASE的问题是GC的问题 社区里做的BucketCache MemSore 原生的memstore是跳跃列表 插入的复杂度很高 查询的复杂度很高 是基于ConcurrentSkipListMap实现 但是ConcurrentSkipListMap的MemSore也有很多.
1884 0
|
存储 分布式数据库 Hbase
HBase MetaStore和Compaction剖析
1.概述   客户端读写数据是先从HBase Master获取RegionServer的元数据信息,比如Region地址信息。在执行数据写操作时,HBase会先写MetaStore,为什么会写到MetaStore。
1861 0