RowKey的重要性
RowKey的特点：
- 类似于MySQL、Oracle中的主键，用于标示唯一的行；
- 完全是由用户指定的一串不重复的字符串；
- HBase中的数据永远是根据 Rowkey 的字典排序来排序的。
RowKey的作用：
- 读写数据时通过RowKey找到对应的Region；
- MemStore中的数据按RowKey字典顺序排序；
- HFile中的数据按RowKey字典顺序排序。
RowKey对查询的影响：
如果RowKey设计为uid+phone+name，那么这种设计可以很好的支持以下的场景：
- uid = 111 AND phone = 123 AND name = tom
- uid = 111 AND phone = 123
- uid = 111 AND phone = 12?
- uid = 111
难以支持的场景：
- phone = 123 AND name = tom
- phone = 123
- name = tom
RowKey对Region划分的影响：
HBase 表的数据是按照 Rowkey 来分散到不同 Region，不合理的 Rowkey 设计会导致热点问题。热点问题是大量的 Client 直接访问集群的一个或极少数个节点，而集群中的其他节点却处于相对空闲状态。
RowKey设计
一条数据的唯一标识就是rowkey，那么这条数据存储于哪个分区，取决于rowkey处于哪个一个预分区的区间内。
设计rowkey的主要目的，就是让数据均匀地分布于所有的region中，在一定程度上防止数据倾斜。
Salting
这里的加盐不是密码学中的加盐，而是在rowkey 的前面增加随机数。具体就是给 rowkey 分配一个随机前缀 以使得它和之前排序不同。分配的前缀种类数量应该和你想使数据分散到不同的 region 的数量一致。 如果你有一些 热点 rowkey 反复出现在其他分布均匀的 rwokey 中，加盐是很有用的。考虑下面的例子：它将写请求分散到多个 RegionServers，但是对读造成了一些负面影响。
假如你有下列 rowkey，你表中每一个 region 对应字母表中每一个字母。 以 ‘a’ 开头是同一个region, ‘b’开头的是同一个region。在表中，所有以 ‘f’开头的都在同一个 region， 它们的 rowkey 像下面这样：
1 | foo0001 |
2 | foo0002 |
3 | foo0003 |
4 | foo0004 |
现在，假如你需要将上面这个 region 分散到 4个 region。你可以用4个不同的盐：’a’, ‘b’, ‘c’, ‘d’.在这个方案下，每一个字母前缀都会在不同的 region 中。加盐之后，你有了下面的 rowkey:
1 | a-foo0003 |
2 | b-foo0001 |
3 | c-foo0004 |
4 | d-foo0002 |
所以，你可以向4个不同的 region 写。理论上说，如果这四个 Region 存放在不同的机器上，经过加盐之后你将拥有之前4倍的吞吐量。
现在，如果再增加一行，它将随机分配a,b,c,d中的一个作为前缀，并以一个现有行作为尾部结束：
1 | a-foo0003 |
2 | b-foo0001 |
3 | c-foo0003 |
4 | c-foo0004 |
5 | d-foo0002 |
因为分配是随机的，所以如果你想要以字典序取回数据，你需要做更多工作。加盐这种方式增加了写时的吞吐量，但是当读时有了额外代价。
Hashing
Hashing 的原理是计算 RowKey 的 hash 值，然后取 hash 的部分字符串和原来的 RowKey 进行拼接。这里说的 hash 包含 MD5、sha1、sha256或sha512等算法。比如我们有如下的 RowKey：
1 | foo0001 |
2 | foo0002 |
3 | foo0003 |
4 | foo0004 |
我们使用 md5 计算这些 RowKey 的 hash 值，然后取前 6 位和原来的 RowKey 拼接得到新的 RowKey：
1 | 95f18cfoo0001 |
2 | 6ccc20foo0002 |
3 | b61d00foo0003 |
4 | 1a7475foo0004 |
优缺点：可以一定程度打散整个数据集，但是不利于 Scan；比如我们使用 md5 算法，来计算Rowkey的md5值，然后截取前几位的字符串。subString(MD5(设备ID), 0, x) + 设备ID，其中x一般取5或6。
Reversing
Reversing 的原理是反转一段固定长度或者全部的键。比如我们有以下 URL ，并作为 RowKey：
1 | flink.github.com |
2 | www.github.com |
3 | hadoop.github.com |
4 | spark.github.com |
这些 URL 其实属于同一个域名，但是由于前面不一样，导致数据不在一起存放。我们可以对其进行反转，如下：
1 | moc.buhtig.knilf |
2 | moc.buhtig.www |
3 | moc.buhtig.poodah |
4 | moc.buhtig.kraps |
经过这个之后，这些 URL 的数据就可以放一起了。
RowKey的长度
RowKey 可以是任意的字符串，最大长度64KB（因为 Rowlength 占2字节）。建议越短越好，原因如下：
- 数据的持久化文件HFile中是按照KeyValue存储的，如果rowkey过长，比如超过100字节，1000w行数据，光rowkey就要占用100*1000w=10亿个字节，将近1G数据，这样会极大影响HFile的存储效率；
- MemStore将缓存部分数据到内存，如果rowkey字段过长，内存的有效利用率就会降低，系统不能缓存更多的数据，这样会降低检索效率；
- 目前操作系统都是64位系统，内存8字节对齐，控制在16个字节，8字节的整数倍利用了操作系统的最佳特性。