HBase笔记:Region拆分策略

Region 概念

Region是表获取和分布的基本元素,由每个列族的一个Store组成。对象层级图如下:

Table       (HBase table)
    Region       (Regions for the table)
         Store          (Store per ColumnFamily for each Region for the table)
              MemStore        (MemStore for each Store for each Region for the table)
              StoreFile       (StoreFiles for each Store for each Region for the table)
                    Block     (Blocks within a StoreFile within a Store for each Region for the table)

Region 大小

Region的大小是一个棘手的问题,需要考量如下几个因素。

  • Region是HBase中分布式存储和负载均衡的最小单元。不同Region分布到不同RegionServer上,但并不是存储的最小单元。
  • Region由一个或者多个Store组成,每个store保存一个columns family,每个Strore又由一个memStore和0至多个StoreFile 组成。memStore存储在内存中, StoreFile存储在HDFS上。
  • HBase通过将region切分在许多机器上实现分布式。也就是说,你如果有16GB的数据,只分了2个region, 你却有20台机器,有18台就浪费了。
  • region数目太多就会造成性能下降,现在比以前好多了。但是对于同样大小的数据,700个region比3000个要好。
  • region数目太少就会妨碍可扩展性,降低并行能力。有的时候导致压力不够分散。这就是为什么,你向一个10节点的HBase集群导入200MB的数据,大部分的节点是idle的。
  • RegionServer中1个region和10个region索引需要的内存量没有太多的差别。

最好是使用默认的配置,可以把热的表配小一点(或者受到split热点的region把压力分散到集群中)。如果你的cell的大小比较大(100KB或更大),就可以把region的大小调到1GB。region的最大大小在hbase配置文件中定义:

 <property>
    <name>hbase.hregion.max.filesize</name>
    <value>10 * 1024 * 1024 * 1024</value>
  </property>

说明:

  1. 当region中的StoreFile大小超过了上面配置的值的时候,该region就会被拆分,具体的拆分策略见下文。
  2. 上面的值也可以针对每个表单独设置,例如在hbase shell中设置:

create 't','f'
disable 't'
alter 't', METHOD => 'table_att', MAX_FILESIZE => '134217728'
enable 't'

Region 拆分策略

Region的分割操作是不可见的,因为Master不会参与其中。RegionServer拆分region的步骤是,先将该region下线,然后拆分,将其子region加入到META元信息中,再将他们加入到原本的RegionServer中,最后汇报Master。

执行split的线程是CompactSplitThread。

自定义拆分策略

可以通过设置RegionSplitPolicy的实现类来指定拆分策略,RegionSplitPolicy类的实现类有:

ConstantSizeRegionSplitPolicy
	IncreasingToUpperBoundRegionSplitPolicy
		DelimitedKeyPrefixRegionSplitPolicy
		KeyPrefixRegionSplitPolicy

对于split,并不是设置了hbase.hregion.max.filesize(默认10G)为很大就保证不split了,需要有以下的算法:

  • IncreasingToUpperBoundRegionSplitPolicy,0.94.0默认region split策略。根据公式min(r^2*flushSize,maxFileSize)确定split的maxFileSize,其中r为在线region个数,maxFileSize由hbase.hregion.max.filesize指定。
  • ConstantSizeRegionSplitPolicy,仅仅当region大小超过常量值(hbase.hregion.max.filesize大小)时,才进行拆分。
  • DelimitedKeyPrefixRegionSplitPolicy,保证以分隔符前面的前缀为splitPoint,保证相同RowKey前缀的数据在一个Region中
  • KeyPrefixRegionSplitPolicy,保证具有相同前缀的row在一个region中(要求设计中前缀具有同样长度)。指定rowkey前缀位数划分region,通过读取table的prefix_split_key_policy.prefix_length属性,该属性为数字类型,表示前缀长度,在进行split时,按此长度对splitPoint进行截取。此种策略比较适合固定前缀的rowkey。当table中没有设置该属性,或其属性不为Integer类型时,指定此策略效果等同与使用IncreasingToUpperBoundRegionSplitPolicy。

IncreasingToUpperBoundRegionSplitPolicy

这是0.94.0默认region split策略。根据根据公式min(r^2*flushSize,maxFileSize)确定split的maxFileSize,这里假设flushSize为128M:

第一次拆分大小为:min(10G,1*1*128M)=128M
第二次拆分大小为:min(10G,3*3*128M)=1152M
第三次拆分大小为:min(10G,5*5*128M)=3200M
第四次拆分大小为:min(10G,7*7*128M)=6272M
第五次拆分大小为:min(10G,9*9*128M)=10G
第五次拆分大小为:min(10G,11*11*128M)=10G

可以看到,只有在第四次之后的拆分大小才为10G

配置拆分策略

你可以在hbase配置文件中定义全局的拆分策略,设置hbase.regionserver.region.split.policy的值即可,也可以在创建和修改表时候指定:

// 更新现有表的split策略
HBaseAdmin admin = new HBaseAdmin( conf);
HTable hTable = new HTable( conf, "test" );
HTableDescriptor htd = hTable.getTableDescriptor();
HTableDescriptor newHtd = new HTableDescriptor(htd);
newHtd.setValue(HTableDescriptor. SPLIT_POLICY, KeyPrefixRegionSplitPolicy.class .getName());// 指定策略
newHtd.setValue("prefix_split_key_policy.prefix_length", "2");
newHtd.setValue("MEMSTORE_FLUSHSIZE", "5242880"); // 5M
admin.disableTable( "test");
admin.modifyTable(Bytes. toBytes("test"), newHtd);
admin.enableTable( "test");

说明:

  1. 上面的不同策略可以在不同的业务场景下使用,特别是第三种和第四种一般关注和使用的比较少。
  2. 如果想关闭自动拆分改为手动拆分,建议同时修改hbase.hregion.max.filesizehbase.regionserver.region.split.policy值。
时间: 2024-09-17 05:48:44

HBase笔记:Region拆分策略的相关文章

class-c++巨型类的拆分策略。问题标题是要多长?

问题描述 c++巨型类的拆分策略.问题标题是要多长? 在实际的项目中,对板卡进行升级,流程包括:解压升级包->格式化目录->升级固件->升级软件,每一步操作都很复杂,涉及到的业务函数很多,再加上有不同的板卡,可能在某些步骤不大相同,于是把不相同的部分涉及成虚函数,在子类中进行实现,但基类仍然很大,函数很多.想进一步的拆分,有没有好的思路借鉴? 看了看设计模式,参考策略模式,把流程每一大步都拆分成一个单独的类,然后再继承这个类用于实现不同的步骤,但是带来的问题就是每个特殊的板卡在多个继承体

HBase笔记:存储结构

从HBase的架构图上可以看出,HBase中的存储包括HMaster.HRegionServer.HRegion.Store.MemStore.StoreFile.HFile.HLog等,本篇文章统一介绍他们的作用即存储结构. 以下是网络上流传的HBase存储架构图: HBase中的每张表都通过行键按照一定的范围被分割成多个子表(HRegion),默认一个HRegion超过256M就要被分割成两个,这个过程由HRegionServer管理,而HRegion的分配由HMaster管理. HMast

设计模式学习笔记(三)—-Strategy策略模式

GOF<设计模式>一书对Strategy模式是这样描述的: 定义一系列的算法,把他们一个个封装起来,并且使它们可相互替换.Strategy模式使算法可独立于使用它的客户而变化. Strategy模式以下列几条原则为基础: 1)每个对象都是一个具有职责的个体. 2)这些职责不同的具体实现是通过多态的使用来完成的. 3)概念上相同的算法具有多个不同的实现,需要进行管理. 下面我将通过一个实例来说明它的具体使用,这个例子是关于数据库连接的.代码如下: interface DatabaseStrate

HBase中的一些注意事项

1. 安装集群前 配置SSH无密码登陆 DNS.HBase使用本地 hostname 才获得IP地址,正反向的DNS都是可以的.你还可以设置 hbase.regionserver.dns.interface 来指定主接口,设置hbase.regionserver.dns.nameserver 来指定nameserver,而不使用系统带的 安装NTP服务,并配置和检查crontab是否生效 操作系统调优,包括最大文件句柄,nproc hard 和 soft limits等等 conf/hdfs-s

HBase数据库性能优化总结笔记

垃圾回收优化 master基本不会遇到垃圾回收的问题.由于memstore的刷写机制是不连续的,所以java虚拟机的堆内存会出现孔洞.快速刷写到磁盘的数据会被划分到新生代,这种空间会被优先回收数据停留的时间太长,会被划分到老生代甚至终生代.而且老生代和终生代一般占据了好几个G,而新生代一般就几百M而已 新生代空间由此得出新生代的空间一般的分配如下     -XX:MaxNewSize=128m -XX:NewSize=128m   可以缩写为     -Xmn128m   设定好之后观察是否合理

HBase in Action前三章笔记

最近接触HBase,看了HBase In Action的英文版.开始觉得还行,做了些笔记,但是后续看下去,越来越感觉到实战这本书比较偏使用上的细节,对于HBase的详细设计涉及得非常少.把前三章的一些笔记帖一下,后面几章内容不打算整理了,并不是说书内容不好. key-value存储,强一致性,多个RegionServer节点对client端是不暴露细节的 使用场景:典型的web-search, capture incremental data, ad. click stream, content

HBase原理–所有Region切分的细节都在这里了

Region自动切分是HBase能够拥有良好扩张性的最重要因素之一,也必然是所有分布式系统追求无限扩展性的一副良药.HBase系统中Region自动切分是如何实现的?这里面涉及很多知识点,比如Region切分的触发条件是什么?Region切分的切分点在哪里?如何切分才能最大的保证Region的可用性?如何做好切分过程中的异常处理?切分过程中要不要将数据移动?等等,这篇文章将会对这些细节进行基本的说明,一方面可以让大家对HBase中Region自动切分有更加深入的理解,另一方面如果想实现类似的功能

HBase原理 – 所有Region切分的细节都在这里了

Region自动切分是HBase能够拥有良好扩张性的最重要因素之一,也必然是所有分布式系统追求无限扩展性的一副良药.HBase系统中Region自动切分是如何实现的?这里面涉及很多知识点,比如Region切分的触发条件是什么?Region切分的切分点在哪里?如何切分才能最大的保证Region的可用性?如何做好切分过程中的异常处理?切分过程中要不要将数据移动?等等,这篇文章将会对这些细节进行基本的说明,一方面可以让大家对HBase中Region自动切分有更加深入的理解,另一方面如果想实现类似的功能

《HBase权威指南》一1.4 结构

1.4 结构 本节首先介绍HBase的架构,然后介绍一些关于HBase起源的背景资料,之后将介绍其数据模型的一般概念和可用的存储API,最后在一个更高的层次上对其实现细节进行分析. 1.4.1 背景 2003年,Google发表了一篇论文,叫"The Google File System"(http://labs.google.com/papers/gfs.html).这个分布式文件系统简称GFS,它使用商用硬件集群存储海量数据.文件系统将数据在节点之间冗余复制,这样的话,即使一台存储