一、为什么Row这么重要
一张HBase表设计的好不好,就看它的RowKey设计的好不好。可见RowKey在HBase中的地位!
1、RowKey的特点:
类似于MySQL、Oracle中的主键,用于标识唯一的行;
完全是由用户指定的一串不重复的字符串;
HBase中的数据永远是根据RowKey的字典排序来排序的;
2、RowKey的作用
读写数据是通过RowKey找到对应的Region;
MemStore中的数据按RowKey字典顺序排序;
HFile中的数据按RowKey字典顺序排序;
3、RowKey对查询的影响
如果我们的RowKey设计为uid+phone+name,那么这种设计可以很好的支持一下的场景:
uid = 111 AND phone = 123 AND name = iteblog
uid = 111 AND phone = 123
uid = 111 AND phone = 12?
uid = 111
难以支持的场景:
phone = 123 AND name = iteblog
phone = 123
name = iteblog
4、RowKey对Region划分的影响
HBase表的数据是按照RowKey来分散到不同Region,不合理的RowKey设计会导致热点问题。热点问题是大量的client直接访问集群的一个或极少个节点,而集群中的其他节点却处于相对空闲状态。
如上图,Region1上的数据是Region2的5倍,这样会导致Region1的访问频率比较高,进而影响这个Region所在机器的其他Region
二、RowKey设计技巧
如何避免上面说到的热点问题呢?这里就说三种方法。
1、避免热点的方法----加盐(salting)
这里的加盐不是密码学中的加盐,而是在rowkey的前面增加随机数。具体就是给rowkey分配一个随机前缀,以是得它和之前的排序不同。分配的前缀种类数量应该和你想使数据分散到不同的region的数量一致。如果你有一些热点rowkey反复出现在其他分布均匀的rowkey中,加盐是很有用的。考虑下面的例子:它将写请求分散到多个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
所以,你可以向4个不同的 region 写。理论上说,如果这四个 Region 存放在不同的机器上,经过加盐之后你将拥有之前4倍的吞吐量。
现在,如果再增加一行,它将随机分配a,b,c,d中的一个作为前缀,并以一个现有行作为尾部结束:
a-foo0003
b-foo0001
c-foo0003
c-foo0004
d-foo0002
因为分配是随机的,所以如果你想要以字典序取回数据,你需要做更多工作。加盐这种方式增加了写时的吞吐量,但是当读时有了额外代价。
2、避免热点的方法 - (哈希)Hashing
Hashing 的原理是计算 RowKey 的 hash 值,然后取 hash 的部分字符串和原来的 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、避免热点的方法 - (反转)Reversing
Reversing 的原理是反转一段固定长度或者全部的键。比如我们有以下 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
经过这个之后,这些 URL 的数据就可以放一起了。
4、RowKey的长度
RowKey 可以是任意的字符串,最大长度64KB(因为 Rowlength 占2字节)。建议越短越好,原因如下:
- 数据的持久化文件HFile中是按照KeyValue存储的,如果rowkey过长,比如超过100字节,1000w行数据,光rowkey就要占用100*1000w=10亿个字节,将近1G数据,这样会极大影响HFile的存储效率;
- MemStore将缓存部分数据到内存,如果rowkey字段过长,内存的有效利用率就会降低,系统不能缓存更多的数据,这样会降低检索效率;
- 目前操作系统都是64位系统,内存8字节对齐,控制在16个字节,8字节的整数倍利用了操作系统的最佳特性。