Hbase的表会被划分为1....n个Region,被托管在RegionServer中。Region二个重要的属性:Startkey与EndKey表示这个Region维护的rowkey的范围,当我们要读写数据时,如果rowkey落在某个start-end key范围内,那么就会定位到目标region并且读写到相关的数据。
默认情况下,当我们通过hbaseAdmin指定TableDescriptor来创建一张表时,只有一个region正处于混沌时期,start-end key无边界,可谓海纳百川。所有的rowkey都写入到这个region里,然后数据越来越多,region的size越来越大时,大到一定的阀值,hbase就会将region一分为二,成为2个region,这个过程称为分裂(region-split)。
如果我们就这样默认建表,表里不断的put数据,更严重的是我们的rowkey还是顺序增大的,是比较可怕的。存在的缺点比较明显:首先是热点写,我们总是向最大的start key所在的region写数据,因为我们的rowkey总是会比之前的大,并且hbase的是按升序方式排序的。所以写操作总是被定位到无上界的那个region中;其次,由于热点,我们总是往最大的start key的region写记录,之前分裂出来的region不会被写数据,有点打入冷宫的感觉,他们都处于半满状态,这样的分布也是不利的。
如果在写比较频繁的场景下,数据增长太快,split的次数也会增多,由于split是比较耗费资源的,所以我们并不希望这种事情经常发生。
在集群中为了得到更好的并行性,我们希望有好的load blance,让每个节点提供的请求都是均衡的,我们也不希望,region不要经常split,因为split会使server有一段时间的停顿,如何能做到呢?
随机散列与预分区二者结合起来,是比较完美的。预分区一开始就预建好了一部分region,这些region都维护着自己的start-end keys,在配合上随机散列,写数据能均衡的命中这些预建的region,就能解决上面的那些缺点,大大提供性能。
一、解决思路
提供两种思路:hash与partition。
1、hash方案
hash就是rowkey前面由一串随机字符串组成,随机字符串生成方式可以由SHA或者MD5方式生成,只要region所管理的start-end keys范围比较随机,那么就可以解决写热点问题。例如:
long currentId = 1L; byte [] rowkey = Bytes.add(MD5Hash.getMD5AsHex(Bytes.toBytes(currentId)) .substring(0, 8).getBytes(),Bytes.toBytes(currentId));
假如rowkey原本是自增长的long型,可以将rowkey转为hash再转为bytes,加上本身id转为bytes,这样就生成随便的rowkey。那么对于这种方式的rowkey设计,如何去进行预分区呢?
- 取样,先随机生成一定数量的rowkey,将取样数据按升序排序放到一个集合里。
- 根据预分区的region个数,对整个集合平均分割,即是相关的splitkeys。
- HBaseAdmin.createTable(HTableDescriptor tableDescriptor,byte[][] splitkeys)可以指定预分区的splitkey,即指定region间的rowkey临界值。
创建split计算器,用于从抽样数据生成一个比较合适的splitkeys
public class HashChoreWoker implements SplitKeysCalculator{ //随机取机数目 private int baseRecord; //rowkey生成器 private RowKeyGenerator rkGen; //取样时,由取样数目及region数相除所得的数量. private int splitKeysBase; //splitkeys个数 private int splitKeysNumber; //由抽样计算出来的splitkeys结果 private byte[][] splitKeys; public HashChoreWoker(int baseRecord, int prepareRegions) { this.baseRecord = baseRecord; //实例化rowkey生成器 rkGen = new HashRowKeyGenerator(); splitKeysNumber = prepareRegions - 1; splitKeysBase = baseRecord / prepareRegions; } public byte[][] calcSplitKeys() { splitKeys = new byte[splitKeysNumber][]; //使用treeset保存抽样数据,已排序过 TreeSet<byte[]> rows = new TreeSet<byte[]>(Bytes.BYTES_COMPARATOR); for (int i = 0; i < baseRecord; i++) { rows.add(rkGen.nextId()); } int pointer = 0; Iterator<byte[]> rowKeyIter = rows.iterator(); int index = 0; while (rowKeyIter.hasNext()) { byte[] tempRow = rowKeyIter.next(); rowKeyIter.remove(); if ((pointer != 0) && (pointer % splitKeysBase == 0)) { if (index < splitKeysNumber) { splitKeys[index] = tempRow; index ++; } } pointer ++; } rows.clear(); rows = null; return splitKeys; } }
KeyGenerator及实现
//interface public interface RowKeyGenerator { byte [] nextId(); } //implements public class HashRowKeyGenerator implements RowKeyGenerator { private long currentId = 1; private long currentTime = System.currentTimeMillis(); private Random random = new Random(); public byte[] nextId() { try { currentTime += random.nextInt(1000); byte[] lowT = Bytes.copy(Bytes.toBytes(currentTime), 4, 4); byte[] lowU = Bytes.copy(Bytes.toBytes(currentId), 4, 4); return Bytes.add(MD5Hash.getMD5AsHex(Bytes.add(lowU, lowT)).substring(0, 8).getBytes(), Bytes.toBytes(currentId)); } finally { currentId++; } } }
unit test case测试
@Test public void testHashAndCreateTable() throws Exception{ HashChoreWoker worker = new HashChoreWoker(1000000,10); byte [][] splitKeys = worker.calcSplitKeys(); HBaseAdmin admin = new HBaseAdmin(HBaseConfiguration.create()); TableName tableName = TableName.valueOf("hash_split_table"); if (admin.tableExists(tableName)) { try { admin.disableTable(tableName); } catch (Exception e) { } admin.deleteTable(tableName); } HTableDescriptor tableDesc = new HTableDescriptor(tableName); HColumnDescriptor columnDesc = new HColumnDescriptor(Bytes.toBytes("info")); columnDesc.setMaxVersions(1); tableDesc.addFamily(columnDesc); admin.createTable(tableDesc ,splitKeys); admin.close(); }
查看建表结果,执行:scan 'hbase:meta'
以上我们只是显示了部分region的信息,可以看到region的start-end key还是比较随机散列的。同样可以查看hdfs的目录结构,的确和预期的38个预分区一致:
以上就是按照hash方式,预建好分区,以后再插入数据的时候,也是按照此rowkeyGenerator的方式生成rowkey。
2、partition的方式
partition顾名思义就是分区式,这种分区有点类似于mapreduce中的partitioner,将区域用长整数作为分区号,每个region管理着相应的区域数据,在rowkey生成时,将ID取模后,然后拼上ID整体作为rowkey,这个比较简单,不需要取样,splitkeys也非常简单,直接是分区号即可。直接上代码:
public class PartitionRowKeyManager implements RowKeyGenerator, SplitKeysCalculator { public static final int DEFAULT_PARTITION_AMOUNT = 20; private long currentId = 1; private int partition = DEFAULT_PARTITION_AMOUNT; public void setPartition(int partition) { this.partition = partition; } public byte[] nextId() { try { long partitionId = currentId % partition; return Bytes.add(Bytes.toBytes(partitionId), Bytes.toBytes(currentId)); } finally { currentId++; } } public byte[][] calcSplitKeys() { byte[][] splitKeys = new byte[partition - 1][]; for(int i = 1; i < partition ; i ++) { splitKeys[i-1] = Bytes.toBytes((long)i); } return splitKeys; } }
calcSplitKeys方法比较单纯,splitkey就是partition的编号,测试类如下:
@Test public void testPartitionAndCreateTable() throws Exception{ PartitionRowKeyManager rkManager = new PartitionRowKeyManager(); //只预建10个分区 rkManager.setPartition(10); byte [][] splitKeys = rkManager.calcSplitKeys(); HBaseAdmin admin = new HBaseAdmin(HBaseConfiguration.create()); TableName tableName = TableName.valueOf("partition_split_table"); if (admin.tableExists(tableName)) { try { admin.disableTable(tableName); } catch (Exception e) { } admin.deleteTable(tableName); } HTableDescriptor tableDesc = new HTableDescriptor(tableName); HColumnDescriptor columnDesc = new HColumnDescriptor(Bytes.toBytes("info")); columnDesc.setMaxVersions(1); tableDesc.addFamily(columnDesc); admin.createTable(tableDesc ,splitKeys); admin.close(); }
同样我们可以看看meta表和hdfs的目录结果,其实和hash类似,region都会分好区。
通过partition实现的loadblance写的话,当然生成rowkey方式也要结合当前的region数目取模而求得,大家同样也可以做些实验,看看数据插入后的分布。
在这里也顺提一下,如果是顺序的增长型原id,可以将id保存到一个数据库,传统的也好,redis的也好,每次取的时候,将数值设大1000左右,以后id可以在内存内增长,当内存数量已经超过1000的话,再去load下一个,有点类似于oracle中的sqeuence.
随机分布加预分区也不是一劳永逸的。因为数据是不断地增长的,随着时间不断地推移,已经分好的区域,或许已经装不住更多的数据,当然就要进一步进行split了,同样也会出现性能损耗问题,所以我们还是要规划好数据增长速率,观察好数据定期维护,按需分析是否要进一步分行手工将分区再分好,也或者是更严重的是新建表,做好更大的预分区然后进行数据迁移。如果数据装不住了,对于partition方式预分区的话,如果让它自然分裂的话,情况分严重一点。因为分裂出来的分区号会是一样的,所以计算到partitionId的话,其实还是回到了顺序写年代,会有部分热点写问题出现,如果使用partition方式生成主键的话,数据增长后就要不断地调整分区了,比如增多预分区,或者加入子分区号的处理.(我们的分区号为long型,可以将它作为多级partition)
以上基本已经讲完了防止热点写使用的方法和防止频繁split而采取的预分区。但rowkey设计,远远也不止这些,比如rowkey长度,然后它的长度最大可以为char的MAXVALUE,但是看过之前我写KeyValue的分析知道,我们的数据都是以KeyValue方式存储在MemStore或者HFile中的,每个KeyValue都会存储rowKey的信息,如果rowkey太大的话,比如是128个字节,一行10个字段的表,100万行记录,光rowkey就占了1.2G+所以长度还是不要过长,另外设计,还是按需求来吧。
相关推荐
### HBase热点问题及其解决方案 #### 一、热点问题概述 **热点问题**是指在HBase数据库中,由于数据分布不均匀导致某些RegionServer负载过重的现象。这会导致整个系统的性能受到影响,特别是在读写操作频繁的情况...
HBase 元数据修复工具包。 ①修改 jar 包中的application.properties,重点是 zookeeper.address、zookeeper.nodeParent、hdfs....③开始修复 `java -jar -Drepair.tableName=表名 hbase-meta-repair-hbase-2.0.2.jar`
为了解决热点问题,一种常用的方法是结合预分区和随机散列。通过在rowkey前面添加一串随机字符串(如SHA或MD5生成的哈希值),使得数据能均匀地分散到各个预分区中。首先,确定rowkey生成策略,例如将自增的long型id...
本文将围绕"Hbase-2.0.0.3.0.0.0-1634-bin.tar.gz"这个压缩包,探讨如何在Ambari 2.7.x环境下进行HBase的编译和使用,以及该版本的HBase在特定环境下的特点和注意事项。 一、HBase 2.0.0.3.0.0.0-1634简介 HBase ...
- **预分区(Region Splitting)**:根据数据量和访问模式预先划分Region,避免数据分布不均。 - **BlockCache**:合理配置缓存大小,提高数据读取速度。 - **Compaction**:定期合并HFile以减少文件数量,提高读取...
赠送jar包:hbase-prefix-tree-1.1.3.jar; 赠送原API文档:hbase-prefix-tree-1.1.3-javadoc.jar; 赠送源代码:hbase-prefix-tree-1.1.3-sources.jar; 赠送Maven依赖信息文件:hbase-prefix-tree-1.1.3.pom; ...
hbase hbck2修复工具hbase-operator-tools-1.0.0.1.0.0.0-618-bin.tar.gz,hbase1版本的hbck已经不支持修复命令,hbase2.1版本需要用这个新版的工具
赠送jar包:hbase-hadoop-compat-1.1.3.jar; 赠送原API文档:hbase-hadoop-compat-1.1.3-javadoc.jar; 赠送源代码:hbase-hadoop-compat-1.1.3-sources.jar; 赠送Maven依赖信息文件:hbase-hadoop-compat-1.1.3....
赠送jar包:hbase-metrics-api-1.4.3.jar; 赠送原API文档:hbase-metrics-api-1.4.3-javadoc.jar; 赠送源代码:hbase-metrics-api-1.4.3-sources.jar; 赠送Maven依赖信息文件:hbase-metrics-api-1.4.3.pom; ...
赠送jar包:hbase-prefix-tree-1.4.3.jar; 赠送原API文档:hbase-prefix-tree-1.4.3-javadoc.jar; 赠送源代码:hbase-prefix-tree-1.4.3-sources.jar; 赠送Maven依赖信息文件:hbase-prefix-tree-1.4.3.pom; ...
赠送jar包:hbase-hadoop-compat-1.1.3.jar; 赠送原API文档:hbase-hadoop-compat-1.1.3-javadoc.jar; 赠送源代码:hbase-hadoop-compat-1.1.3-sources.jar; 赠送Maven依赖信息文件:hbase-hadoop-compat-1.1.3....
在实际应用中,为了最大化利用Phoenix和HBase的性能,我们需要关注索引设计、分区策略、数据模型优化等方面。例如,合理创建覆盖索引可以减少HBase的扫描操作,而恰当的分区策略则可以平衡数据分布,避免热点问题。...
赠送jar包:phoenix-core-4.7.0-HBase-1.1.jar; 赠送原API文档:phoenix-core-4.7.0-HBase-1.1-javadoc.jar; 赠送源代码:phoenix-core-4.7.0-HBase-1.1-sources.jar; 赠送Maven依赖信息文件:phoenix-core-4.7.0...
ambari-2.7.5 编译过程中四个大包下载很慢,所以需要提前下载,包含:hbase-2.0.2.3.1.4.0-315-bin.tar.gz ,hadoop-3.1.1.3.1.4.0-315.tar.gz , grafana-6.4.2.linux-amd64.tar.gz ,phoenix-5.0.0.3.1.4.0-315....
赠送jar包:hbase-hadoop-compat-1.2.12.jar; 赠送原API文档:hbase-hadoop-compat-1.2.12-javadoc.jar; 赠送源代码:hbase-hadoop-compat-1.2.12-sources.jar; 赠送Maven依赖信息文件:hbase-hadoop-compat-...
赠送jar包:hbase-prefix-tree-1.2.12.jar; 赠送原API文档:hbase-prefix-tree-1.2.12-javadoc.jar; 赠送源代码:hbase-prefix-tree-1.2.12-sources.jar; 赠送Maven依赖信息文件:hbase-prefix-tree-1.2.12.pom;...
HBase(hbase-2.4.9-bin.tar.gz)是一个分布式的、面向列的开源数据库,该技术来源于 Fay Chang 所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统(File System...
赠送jar包:hbase-hadoop-compat-1.4.3.jar; 赠送原API文档:hbase-hadoop-compat-1.4.3-javadoc.jar; 赠送源代码:hbase-hadoop-compat-1.4.3-sources.jar; 赠送Maven依赖信息文件:hbase-hadoop-compat-1.4.3....