HBASE REGION SPLIT策略

hbase 0.94.0版本中,对于region的split方式引入了一个非常方便的SplitPolicy,通过这个SplitPolicy,可以主动的干预控制region split的方式。在org.apache.Hadoop.hbase.regionserver包中,可以找到这么几个自带的splitPolicy: ConstantSizeRegionSplitPolicyIncreasingToUpperBoundRegionSplitPolicy, and KeyPrefixRegionSplitPolicy

从名字上就可以分辨出这三种split策略的适用场景:

ConstantSizeRegionSplitPolicy:按固定长度分割region,固定长度取值优先获取table的”MAX_FILESIZE” 值,若没有设定该属性,则采用在hbase-site.xml中配置的hbase.hregion.max.filesize值,在0.94版本中这个值的缺省值已经被调整为:10 * 1024 * 1024 * 1024L 也就是10G,网上很多关于 hbase.hregion.max.filesize 默认值 1G的文章应该都是基于0.92的hbase的。这个在使用中需要明确具体的hbase版本号。这个策略是0.94版本之前默认使用的,采用该策略后,当table的某一region中的某一store大小超过了预定的最大固定长度时,对该region进行split。splitPoint算法的选择还是依据“数据对半”原则,找到该region的最大store的中间长度的rowkey进行split。

IncreasingToUpperBoundRegionSplitPolicy:按照region数量累增划分region,该策略为Hbase 0.94默认使用的策略,采用该策略分割的region大小是不相等的,每次新region的大小随着region数量的增多而增大。具体增长方法为:Min (R^2 *  ”MEMSTORE_FLUSHSIZE”||”hbase.hregion.memstore.flush.size”, “hbase.hregion.max.filesize”);其中R 为当前这个region所在regionserver中对应此table的region数,MEMSTORE_FLUSHSIZE 为table创建时指定大小,若table指定了此属性则忽略下面的hbase.hregion.memstore.flush.size 。

hbase.hregion.memstore.flush.size 为hbase-site中设定大小 默认128M

hbase.hregion.max.filesize 为hbase-site中设定的单个region大小,默认10G

每次region大小是取上述两个size中较小的那个。

假设使用hbase.hregion.memstore.flush.size 128M, hregion.max.filesize为10G, 那么每次region增长情况为:512M,1152M,2G,3,2G,4,6G,6,2G,etc。当region增长到9个时,9*9*128M/1024=10.125G >10G,至此以后region split大小都固定为10G。

KeyPrefixRegionSplitPolicy:指定rowkey前缀位数划分region,通过读取table的prefix_split_key_policy.prefix_length属性,该属性为数字类型,表示前缀长度,

在进行split时,按此长度对splitPoint进行截取。个人理解是rowkey前缀不相等,则划分region。此种策略比较适合固定前缀的rowkey。当table中没有设置prefix_split_key_policy.prefix_length属性,或prefix_split_key_policy.prefix_length属性不为Integer类型时,指定此策略效果等同与使用IncreasingToUpperBoundRegionSplitPolicy

附上代码,在创建或修改table时,指定splicpolicy

[java] view plain copy

  1. // 更新现有表的split策略
  2. HBaseAdmin admin = new HBaseAdmin( conf);
  3. HTable hTable = new HTable( conf, ”test” );
  4. HTableDescriptor htd = hTable.getTableDescriptor();
  5. HTableDescriptor newHtd = new HTableDescriptor(htd);
  6. newHtd.setValue(HTableDescriptor. SPLIT_POLICY, KeyPrefixRegionSplitPolicy.class .getName());// 指定策略
  7. newHtd.setValue(“prefix_split_key_policy.prefix_length”, ”2″);
  8. newHtd.setValue(“MEMSTORE_FLUSHSIZE”, ”5242880″); // 5M
  9. admin.disableTable( ”test”);
  10. admin.modifyTable(Bytes. toBytes(“test”), newHtd);
  11. admin.enableTable( ”test”);

目前使用的HBASE1.0.1.1使用的REGION SPLIT策略是IncreasingToUpperBoundRegionSplitPolicy

验证方式如下:通过HBASE前端查看系统中的TDC_TWEETS_201604表,发现该表被拆分成18个REGION,截图如下:

通过HADOOP命令查看每个REGION大小,发现最大的7.4G,最小的88M,符合REGION拆分逻辑,截图如下:

时间: 2024-10-24 17:46:29

HBASE REGION SPLIT策略的相关文章

hbase split 源码分析之split策略

在工作中接触到split,于是查看了这块的源代码,先看到了split的策略,今天就说说这个吧,后续还会有split的其他源码分析和compact相关的源码分析. 看了很多其他人的博客,很多都是转发的,原创的也都没有注明是哪个版本.其实给很多读者造成混淆,我这里是基于Hbase-0.98.13  版本作为分析的,注意:不同版本的此部分源码很可能不一样. 在这个版本中使用的split策略是IncreasingToUpperBoundRegionSplitPolicy.确切来说他是0.94版本以后的策

Hbase Region Server整体架构

Region Server的整体架构 本文主要介绍Region的整体架构,后续再慢慢介绍region的各部分具体实现和源码 RegionServer逻辑架构图 RegionServer职责 1.      监听协作,通过zk来侦听master.meta位置.集群状态等信息的变化,更新本地数据. 2.      管理region的offline.online.open.close等操作,这些操作是和hmaster配合这来做的,region的状态有如下这些 offline.opening.open.

HBase的split分析

HBase在新建一个表的时候,默认会把所有数据都会放在一个HRegion上,主节点HMaster根据一定的策略把HRegion分配到不同的HRegionServer从节点上,客户端在进行读写操作的时候,就会访问对应HRegionServer的HRegion.当HRegion的数据量超过阀值的时候,为了防止单个热点访问带来的压力,HBase就会对HRegion进行split操作,一个父HRegion分为两个子HRegion,后续的数据写入操作就会分配到两个HRegion里,减轻了单个热点的负载.由

region split流程分析

region split流程分析 splitregion的发起主要通过client端调用regionserver.splitRegion或memstore.flsuh时检查并发起. Client通过rpc调用regionserver的splitRegion方法 client端通过HBaseAdmin.split传入regionname与splitpoint(切分的rowkey,能够不传入), 通过meta得到此region所在的server,发起rpc请求,调用HRegionServer.spl

HBase Region的flush过程

触发region flush的因素有很多,如手动触发,memstore压力触发,memstore到达限制触发,flush时间触发等. regionserver的flush由 flush实际操作步骤为 1.获得region写锁,将region的所有store执行prepare,产生snapshort,释放region写锁 2.将region的所有store执行flushcache,将数据写入hdfs中的一个或多个临时文件中 3.将临时文件移到region/store相应的目录下,删除memstor

浅析HBase region的单点问题

很长一段时间以来,一个region同一时间只能在一台RS(Region Server)中打开.如果一个region同时在多个RS上打开,就是multi-assign问题,会导致数据不一致甚至丢数据的情况,这是要避免和解决的.对于正常情况而言,region本质上是单点服务的,当RS宕机时,这个RS上的region无法提供服务,直到他们在另外的RS上重新上线为止.我们首先讨论这种单点服务会导致哪些问题,然后,看看有什么解决方案. region单点导致的问题 从正常和异常两个方面对region单点可能

org.apache.hadoop.hbase.MasterNotRunningException解决策略

执行HBase时常会遇到个错误,我就有这种经历. ERROR: org.apache.hadoop.hbase.MasterNotRunningException: Retried 7 times 检查日志:org.apache.hadoop.ipc.RPC$VersionMismatch: Protocol org.apache.hadoop.hdfs.protocol.ClientProtocol version mismatch. (client = 42, server = 41) 假设

Hbase region 某个regionserver挂掉后的处理

现象描述:某个regionserver服务挂掉后,此节点的Regions为0. 重启及数据恢复过程如下:() 切记在hadoop用户下: 第一步启动regionserver /hbaseStallDir/bin/graceful_stop.sh 192.168.5.164 /hbaseStallDir/bin/hbase-daemon.sh start regionserver /app/cloud/hadoop/bin/hadoop-daemon.sh start datanode 第二部:启

hbase region与内存的关系

http://hbase.apache.org/book.html#ops.capacity.regions.count In production scenarios, where you have a lot of data, you are normally concerned with the maximum number of regions you can have per server. too many regions has technical discussion on th