HBase Rowkey的设计

本文主要是介绍HBase Rowkey的设计，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

HBase Rowkey的设计

1、Rowkey为什么这么重要？

2、解决热点问题方法

1、预分区

2、Rowkey设计技巧

3、Rowkey设计案例

1、交易类表 Rowkey 设计

2、金融风控 Rowkey 设计

3、车联网 Rowkey 设计

参考

HBase Rowkey的设计

1、Rowkey为什么这么重要？

首先，先介绍一下什么是Rowkey。

类似于 MySQL、Oracle中的主键，用于标示唯一的行；
完全是由用户指定的一串不重复的字符串；
HBase 中的数据永远是根据 Rowkey 的字典排序来排序的。

那么，Rowkey的作用又是什么呢？

读写数据时通过 RowKey 找到对应的 Region；
MemStore 中的数据按 RowKey 字典顺序排序；
HFile 中的数据按 RowKey 字典顺序排序。

由于HFile中的数据是按Rowkey的字典顺序排序的，且当Region当中的数据过大时，HBase将会进行自动的split。若Rowkey设计不合理的话，那么很容易造成热点问题，即Rowkey对Region划分会产生影响。

先解释一下什么是热点问题。

在实际操作中，当大量请求访问HBase集群的一个或少数几个节点，造成少数RegionServer的读写请求过多，负载过大，而其他RegionServer负载却很小，这样就造成热点现象。举个例子就是：假设存在A、B两个地区，这两个地区的人都玩游戏，但是两个地区的人数不一样，A地区的人数远远大于B地区，且A地区的人比B地区的人更热衷玩游戏。那么如果A和B地区的集群节点数量一样的情况下，A地区的节点的访问请求肯定远大于B地区的节点访问请求。那么，就有可能请求过多，负载过大，导致热点现象。

2、解决热点问题方法

1、预分区

首先，我们需要想明白数据的分布情况，然后根据数据的分布进行预分区，规划需要分成多少个region，并且每个region的startKey和endKey是多少。例如如果分成10个region，划分key的如下：

0001|

0002|

0003|

0004|

0005|

0006|

0007|

0008|

0009|

为什么后面会跟着一个"|"，是因为在ASCII码中，"|"的值是124，大于所有的数字和字母等符号，当然也可以用“~”（ASCII-126）。分隔文件的第一行为第一个region的stopkey，每行依次类推，最后一行不仅是倒数第二个region的stopkey，同时也是最后一个region的startkey。也就是说分区文件中填的都是key取值范围的分隔点。

具体实际分多少个区，取决于之后未来发展的数据量的大小以及机器规模有关。一般每台机器放2~3个region。若以后未来数据发展迅速，可以考虑重新数据导入进去，进行重新分区。

一般分区的好坏，需要看Rowkey的设计。

2、Rowkey设计技巧

首先是Rowkey设计的三大原则：

1) 长度性：RowKey 可以是任意的字符串，最大长度64KB（因为 Rowlength 占2字节）。建议越短越好(一般长度10-100byte)，以byte[]数组形式保存，一般设计成定长。官方建议越短越好，不要超过16个字节，原因如下：

数据的持久化文件HFile中是按照KeyValue存储的，如果rowkey过长，比如超过100字节，1000w行数据，光rowkey就要占用100*1000w=10亿个字节，将近1G数据，这样会极大影响HFile的存储效率；
MemStore将缓存部分数据到内存，如果rowkey字段过长，内存的有效利用率就会降低，系统不能缓存更多的数据，这样会降低检索效率；
目前操作系统都是64位系统，内存8字节对齐，控制在16个字节，8字节的整数倍利用了操作系统的最佳特性。

2) 唯一性：由于RowKey用来唯一标识一行记录，所以必须在设计上保证RowKey的唯一性。需要注意，由于HBase中数据存储的格式是Key-Value对格式，所以如果向HBase中同一张表插入相同RowKey的数据，则原先存在的数据会被新的数据给覆盖掉（和HashMap效果相同）。

3) 散列原则：设计出的RowKey需要能够均匀的分布到各个RegionServer上。比如设计RowKey的时候，当Rowkey 是按时间戳的方式递增，就不要将时间放在二进制码的前面，可以将 Rowkey 的高位作为散列字段，由程序循环生成，可以在低位放时间字段，这样就可以提高数据均衡分布在每个Regionserver实现负载均衡的几率。

接下来是Rowkey设计(避免热点现象)的方法：

1) 加盐：这里的加盐不是密码学中的加盐，而是在rowkey 的前面增加随机数。具体就是给 rowkey 分配一个随机前缀以使得它和之前排序不同。分配的前缀种类数量应该和你想使数据分散到不同的 region 的数量一致。如果你有一些热点 rowkey 反复出现在其他分布均匀的 rwokey 中，加盐是很有用的。考虑下面的例子：它将写请求分散到多个 RegionServers，但是对读造成了一些负面影响。

举个例子：

假如你有下列 rowkey，你表中每一个 region 对应字母表中每一个字母。以 'a' 开头是同一个region, 'b'开头的是同一个region。在表中，所有以 'f'开头的都在同一个 region，它们的 rowkey 像下面这样：

foo0001
foo0002
foo0003
foo0004

现在，假如你需要将上面这个 region 分散到 4个 region。你可以用4个不同的盐：'a', 'b', 'c', 'd'.在这个方案下，每一个字母前缀都会在不同的 region 中。加盐之后，你有了下面的 rowkey:

a-foo0003
b-foo0001
c-foo0004
d-foo0002

缺点：

因为添加的是随机数，基于原RowKey查询时无法知道随机数是什么，那样在查询的时候就需要去各个可能的Regions中查找，Salting对于读取是利空的。并且加盐这种方式增加了读写时的吞吐量。

2) 反转：反转的原理是反转一段固定长度或者全部的键。比如我们有以下 URL ，并作为 RowKey：

flink.iteblog.com
www.iteblog.com
carbondata.iteblog.com
def.iteblog.com

这些 URL 其实属于同一个域名，但是由于前面不一样，导致数据不在一起存放。我们可以对其进行反转，如下：

moc.golbeti.knilf
moc.golbeti.www
moc.golbeti.atadnobrac
moc.golbeti.fed

如果经初步设计出的RowKey在数据分布上不均匀，但RowKey尾部的数据却呈现出了良好的随机性，此时，可以考虑将RowKey的信息翻转，或者直接将尾部的bytes提前到RowKey的开头。Reversing可以有效的使RowKey随机分布，但是牺牲了RowKey的有序性。

3) 哈希：基于 RowKey 的完整或部分数据进行 Hash，而后将Hashing后的值完整替换或部分替换原RowKey的前缀部分。这里说的 hash 包含 MD5、sha1、sha256 或 sha512 等算法。比如我们有如下的 RowKey：

foo0001
foo0002
foo0003
foo0004

我们使用 md5 计算这些 RowKey 的 hash 值，然后取前 6 位和原来的 RowKey 拼接得到新的 RowKey：

95f18cfoo0001
6ccc20foo0002
b61d00foo0003
1a7475foo0004

优缺点：可以一定程度打散整个数据集，但是不利于 Scan；比如我们使用 md5 算法，来计算Rowkey的md5值，然后截取前几位的字符串。subString(MD5(设备ID), 0, x) + 设备ID，其中x一般取5或6。

3、Rowkey设计案例

1、交易类表 Rowkey 设计

查询某个卖家某段时间内的交易记录
sellerId + timestamp + orderId
查询某个买家某段时间内的交易记录
buyerId + timestamp ＋orderId
根据订单号查询
orderNo
如果某个商家卖了很多商品，可以如下设计 Rowkey 实现快速搜索
salt + sellerId + timestamp 其中，salt 是随机数。可以支持的场景：
- 全表 Scan
- 按照 sellerId 查询
- 按照 sellerId + timestamp 查询