HBase Compaction策略
StripeCompactionPolicy
Stripes表示条纹,意为将Region分为多个条纹区间分别做compact,类似于将Region分为多个Sub-Region。
适用场景:
- Region较大:相对于较小的Region而言,对MemStore和Region的管理带来的负担更小。
- 新产生的行键不均匀分布在各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]为例子
- 计算一个待合并文件总大小的数组fileSizes[i,i+A-1) ,得到X = [150, 120, 90, 65, 35, 15, 5]。
- 从旧到新文件,逐一判断文件大小是否满足 fileSizes[i] > Math.max(C, (X[i + 1] * R)) ,当条件不满足后,i即为待合并的文件开始位置,该步骤是为了过滤掉大的文件,此处得到i=4。
- 最后得到需要合并的文件列表为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,可以通过如下两种方式修改默认的压缩策略:
- 修改hbase-site.xml配置项hbase.hstore.engine.class,该修改会应用到整个HBase集群。
- 执行表修改语句alter 's_behavior', CONFIGURATION => {'hbase.hstore.engine.class' => 'rg.apache.hadoop.hbase.regionserver.DefaultStoreEngine'},该修改方式只对语句指定的表生效
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
数据集成到MaxCompute的N种最佳实践(持续更新)
本文汇总数据集成到MaxCompute的各种最佳实践,希望可以帮助到正在或者即将使用MaxCompute的企业和开发者们。 | Hadoop数据迁移MaxCompute| 理论与实践:如何从Hadoop迁移到MaxCompute| Hadoop迁移MaxCompute神器之DataX-On-Hadoop使用指南| RDS迁移到MaxCompute实现动态分区最佳实践 | MaxCompute_2_MaxCompute数据迁移文档| JSON数据从OSS迁移到MaxCompute最佳实践| JSON数据从MongoDB迁移到MaxCompute最佳实践 更多交流可扫码加入“MaxCompute开发者社区” 钉钉群
- 下一篇
Apache Atlas容错与高可用方案
笔者近期在和团队的小伙伴进行数据资产管理方向的探索,本书的翻译基于Apache Atlas v1.1版本。笔者翻译的《Atlas开发指南(中文版)》地址为: https://mantoudev.com 置顶文章 。希望对大家有帮助,阅读过程中遇到问题欢迎留言或与我联系。 1. 介绍 Apache Atlas使用各种系统并与之交互,为数据管理员提供元数据管理和数据血缘信息。通过适当地选择和配置这些依赖关系,可以使用Atlas实现服务的高可用性。本文档介绍了Atlas中的高可用性支持状态,包括其功能和当前限制,以及实现此高级别可用性所需的配置。 在Atlas文档高级架构章节(请参阅我翻译的《Atlas开发指南(中文版)》)概述了构成Atlas的各种组件。下面提到的各种组件的选项,都是基于上述文档中的架构描述,在继续阅读本文之前推荐先行阅读文档中相关章节。 2. Atlas Web Service 目前,Atlas Web Service有一个限制,即它一次只能有一个活动实例。在早期版本的Atlas中,可以配置备份实例并使其可用。但是,需要手动故障转移才能使此备份实例处于活动状态。 从此版本...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS6,CentOS7官方镜像安装Oracle11G
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Hadoop3单机部署,实现最简伪集群
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果