HBase中,表会被划分为1...n个Region,被托管在RegionServer中。Region二个重要的属性:StartKey与 EndKey表示这个Region维护的rowKey范围,当我们要读/写数据时,如果rowKey落在某个start-end key范围内,那么就会定位到目标region并且读/写到相关的数据。简单地说,有那么一点点类似人群划分,1-15岁为小朋友,16-39岁为年轻 人,40-64为中年人,65岁以上为老年人。(这些数值都是拍脑袋出来的,只是举例,非真实),然后某人找队伍,然后根据年龄,处于哪个范围,就找到它 所属的队伍。 : ( 有点废话了。。。。
然后,默认地,当我们只是通过HBaseAdmin指定TableDescriptor来创建一张表时,只有一个region,正处于混沌时 期,start-end key无边界,可谓海纳百川。啥样的rowKey都可以接受,都往这个region里装,然而,当数据越来越多,region的size越来越大时,大到 一定的阀值,hbase认为再往这个region里塞数据已经不合适了,就会找到一个midKey将region一分为二,成为2个region,这个过 程称为分裂(region-split).而midKey则为这二个region的临界,左为N无下界,右为M无上界。< midKey则为阴被塞到N区,> midKey则会被塞到M区。
如何找到midKey?涉及的内容比较多,暂且不去讨论,最简单的可以认为是region的总行数 / 2 的那一行数据的rowKey.虽然实际上比它会稍复杂点。
如果我们就这样默认地,建表,表里不断地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,就能解决上面的那些缺点,大大地提高了性能。
提供2种思路: hash 与 partition.
一、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设计,如何去进行预分区呢?
1.取样,先随机生成一定数量的rowkey,将取样数据按升序排序放到一个集合里
2.根据预分区的region个数,对整个集合平均分割,即是相关的splitKeys.
3.HBaseAdmin.createTable(HTableDescriptor tableDescriptor,byte[][] splitkeys)可以指定预分区的splitKey,即是指定region间的rowkey临界值.
1.创建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++; } } }
@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(); }
以上,就已经按hash方式,预建好了分区,以后在插入数据的时候,也要按照此rowkeyGenerator的方式生成rowkey,有兴趣的话,也可以做些试验,插入些数据,看看数据的分布。
二、partition故名思义,就是分区式,这种分区有点类似于mapreduce中的partitioner,将区域用长整数(Long)作为分区号,每 个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(); }
通过partition实现的loadblance写的话,当然生成rowkey方式也要结合当前的region数目取模而求得,大家同样也可以做些实验,看看数据插入后的分布。
在这里也顺提一下,如果是顺序的增长型原id,可以将id保存到一个数据库,传统的也好,redis的也好,每次取的时候,将数值设大1000左右,以后 id可以在内存内增长,当内存数量已经超过1000的话,再去load下一个,有点类似于oracle中的sqeuence.
随机分布加预分区也不是一劳永逸的。因为数据是不断地增长的,随着时间不断地推移,已经分好的区域,或许已经装不住更多的数据,当然就要进一步进行 split了,同样也会出现性能损耗问题,所以我们还是要规划好数据增长速率,观察好数据定期维护,按需分析是否要进一步分行手工将分区再分好,也或者是 更严重的是新建表,做好更大的预分区然后进行数据迁移。
相关推荐
在分布式大数据存储领域,HBase是一个广泛使用的列式存储系统,尤其适合处理大规模的数据。预分区(Pre-Partitioning)是...在实际应用中,需要根据业务需求合理设计RowKey和预分区策略,以实现最佳的存储和查询效率。
预分区是HBase表设计中的一个重要策略,它能有效解决因region split带来的资源消耗问题。在表创建时,用户可以根据一定的规则预先划分region,避免在数据快速增长时频繁进行split操作。这不仅可以提高HBase的性能,...
HBase的高可用性、数据压缩、预分区等高级特性也为系统设计提供了更多优化空间。针对特定应用场景,深入理解HBase的原理和操作,结合专业的指导和参考文献,是设计高效、可扩展HBase数据结构的关键。
分区(Region Splitting)是HBase表设计的另一个关键点。HBase表在底层被切分为多个区域(Region),每个区域包含了表的一部分行键范围。当一个区域的数据量超过一定的阈值时,它会自动分裂成两个较小的区域,这个...
- **分区键**:RowKey 设计至关重要,因为它决定了数据的物理分布和访问性能。RowKey 应该尽可能地反映数据的访问模式。 - **数据模型**:理解业务需求并选择合适的数据模型,如行键(RowKey)、列族(Column Family...
此外,预分区(Region Splitting)和负载均衡也是提高系统性能的关键策略。 书中还详细讲解了HBase的API,包括Java API和Shell命令,让开发者能够熟练地进行数据的插入、更新、删除和查询操作。同时,对于HBase的...
11. **优化策略**:包括合理设置Region大小、预分区表、选择合适的Column Family、启用BlockCache等,以提升HBase的性能。 12. **安全配置**:在生产环境中,可能需要配置HBase与Kerberos进行集成,以实现身份验证...
2. **表的预分区**:为了优化数据写入,开发者可以在创建表时预先定义Region的数量和边界,这称为预分区。这样可以避免数据集中写入某一区域,导致热点现象。 3. **HBase的Compaction**:Compaction是HBase中用于...
- **表设计**:合理的表结构设计对性能影响很大,例如选择合适的行键、预分区等。 - **配置调整**:如Region大小、缓存设置、Compaction策略等,都需要根据实际负载进行调整。 - **监控与诊断**:使用HBase提供的...
9. HBase的预分区设计是为了优化表的分布和读写性能,合理地设置分区可以避免数据倾斜和热点问题,使得数据能够均匀分布在不同的RegionServer上。 10. HBase的rowkey设计技巧包括rowkey的长度原则、散列原则和唯一...
2. **预分区表**:根据数据分布预测表的大小,并预先创建Region,以减少数据增长时的Region分裂。 3. **使用合适的数据模型**:根据业务需求选择合适的列族和列,避免过度设计或数据冗余。 4. **优化过滤器**:...
7. **性能优化**:HBase提供了多种优化策略,如表分区、布隆过滤器、压缩等,可以根据实际场景调整以提升性能。 8. **安全性**:HBase支持Kerberos认证,可以实现安全的集群环境。同时,可以利用Hadoop的权限管理来...
HBase设计用于处理PB级的数据,并且可以在数千台服务器上扩展。`hbase-1.2.0-cdh5.14.2.tar.gz` 是针对Cloudera Distribution Including Apache Hadoop (CDH) 5.14.2的一个特定版本的HBase打包文件。CDH是一个流行的...
优化包括合理设置Region大小,选择合适的行键,以及使用预分区等策略。 7. **监控与管理**:学习如何使用HBase的管理工具,如HBase Master和Region Server的监控,以及如何进行故障排查。 8. **备份与恢复**:...
总之,HBase的架构和组件设计体现了它作为一个分布式NoSQL数据库的优势和特点,通过合理的数据划分、负载均衡和故障转移机制,保证了数据存储的高可靠性和系统的高性能。HBase特别适用于处理大量数据的实时读写操作...
- **预分区**:根据预期的数据分布预先创建Region,避免数据热点。 - **Compaction**:定期合并Region中的StoreFile以减少I/O开销。 - **BlockCache**和**MemStore**:缓存机制用于提高读写性能。 8. **扩展性**...