HBase Compaction策略

栏目: 数据库 · 发布时间: 7年前

内容简介:Stripes表示条纹,意为将Region分为多个条纹区间分别做compact,类似于将Region分为多个Sub-Region。适用场景:按时间分层合并,顾名思义,该合并策略与时间相关,适用于数据写入基于时间产生且无更新删除,数据读取会指定数据读取区间,并且读取新产生的数据的频率较大。

HBase Compaction旨在减少StoreFile的数量,提高读取效率,HBase提供了如下compact策略:

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 Compaction策略》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

C++ How to Program (5th Edition) (How to Program)

C++ How to Program (5th Edition) (How to Program)

Harvey & Paul) Deitel & Associates / Prentice Hall / 2005-01-05 / USD 98.00

With over 250,000 sold, Harvey and Paul Deitel's C++ How to Program is the world's best-selling introduction to C++ programming. Now, this classic has been thoroughly updated! The Deitels' groundbreak......一起来看看 《C++ How to Program (5th Edition) (How to Program)》 这本书的介绍吧!

MD5 加密
MD5 加密

MD5 加密工具

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具