HBase实践——HBase rowkey 设计实践总结小记

背景：

• 针对在hbase使用Scan+Filter进行查询时，必须要设置startKey和stopKey，限制扫描的范围分区，大数据量情况下不设置所要查询的分区会导致全表扫描。
• 由于需要设置分区，即startKey和stopKey，那么我们需要设计好我们的rowKey,目前没有发现适用所有情况的完美的rowKey设计方案，都需要根据业务和数据来进行合理的设计我们的rowKey。比如我们业务中，需要以某个字段的值作为查询条件，那么这个字段的值就可以作为rowKey的一部分，注意了，这里说的是作为rowKey的一部分，而不是直接用它来直接作为rowKey，比如我们目前需要查询最近两天的数据，那么在设计rowkey的时候就需要将时间包含在rowkey中，一般而言，原始数据表都是需要有时间这个因素在里面的，我们的离线任务都是需要根据时间来做的T+1。
• 为了遵循rowkey设计原则的散列原则结合我们的业务需求。也就是针对热点region的问题，需要结合进行预分区，在设计表的时候，我们就需要考虑到预分区，这个分区数，一方面取决于我们的写入数据量，并发量。另一方面，我们集群机器的配置。一般设置为50-200个分区，如果是测试服务器，极端情况下就一台机器，那么我强烈建议分区数在10左右，如果分区数过多，会导致regionServer的小合并拖慢Hbase，导致无法正常对外提供服务。

RowKey设计：

散列原则：

先来说一下各个方式的优缺点

• salting:salting的原理是把固定长度的随机数放在行键的起始处。
  

优缺点: 由于前缀是随机生成的,所以如果想要按照字典顺序找到这些行,就比较的麻烦,salting增加了写操作的吞吐量,但是也增大了读操作的开销,而且由于前缀是随机的,也没有办法按照Rowkey去查询一行数据.

• hashing:hash的原理是将rowkey进行hash计算,然后取hash后的部分字符串和原来的rowkey进行拼接。
  

优缺点: 可以在一定程度上打散整个数据集,但是不利于scan操作,由于不同数据的hash值有可能相同,所以在实际应用中,一般会使用md5计算,然后截取前几位的字符串.examples: substring(MD5(设备ID),0,x) + 设备的ID,x一般会取5到6位。

• Reversing:reversing的原理是反转一段固定长度或者全部的键.
  

优缺点:有效的打乱了行建,但是牺牲了行排序的属性.

唯一原则：

我们需要在查询的时候加入时间因素，时间不可以直接作为rowKey，这是因为，会导致数据倾斜，数据都会落在同一个分区上，还有一种方法就是，时间翻转，那么这个就会引发另外一个问题，就是相同时间段的同一类数据不是有序的，这样就大大降低了查询效率，需要遍历整张表。那么时间应该放在第二位，作为查询的条件使用，上面介绍了rowKey的分区前缀号，那么加上时间就变成了，09|1576337865|420624199311217865X，那么一般情况下，我们是需要时间逆序操作的，那么需要简单处理下，9999999999-时间戳,那么就是09|8423662134|420624199311217865X。