hbase 预分区_hbase的rowKey设计原则

前言

访问hbase table中的行，只有三种方式：

1 通过单个row key访问

2 通过row key的range

3 全表扫描

可以看出rowkey设计的好与坏直接决定了查询速度，在hbase中快速定位也是依靠布隆过滤器，然而布隆过滤器依靠的就是rowkey，所以设计一个好的row可以省不少事情。

但是下面列出的方式紧紧是提供一种设计原则，最重要的还是要具体问题具体分析，然后设计出比较符合业务内容的rowkey.

rowkey长度原则

rowkey是一个二进制码流，可以是任意字符串，最大长度64kb，实际应用中一般为10-100bytes，以byte[]形式保存，一般设计成定长。议越短越好，不要超过16个字节，设计过长会降低memstore内存的利用率和HFile存贮数据的效率。

这个需要着重说一下，首先一条数据是根据rowkey来当成索引的，如果过长就会快速占据memstore的128M，然后被刷写到磁盘，也就是说相同的空间存贮的内容被rowkey占据了一大部分，减少了主要内容的存贮

rowkey散列原则

建议将rowkey的高位作为散列字段，这样将提高数据均衡分布在每个RegionServer，以实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息。

所有的数据都会集中在一个RegionServer上，这样在数据检索的时候负载会集中在个别的RegionServer上，造成热点问题，会降低查询效率。

rowkey唯一原则

必须在设计上保证其唯一性，rowkey是按照字典顺序排序存储的，

因此，设计rowkey的时候，要充分利用这个排序的特点，可以将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。

hbase表的热点

1.什么是热点

检索habse的记录首先要通过row key来定位数据行。当大量的client访问hbase集群的一个或少数几个节点，造成少数region server的读/写请求过多、负载过大，而其他region server负载却很小，就造成了“热点”现象。

2.热点的解决办法

2.1预分区

预分区的目的让表的数据可以均衡的分散在集群中，而不是默认只有一个region分布在集群的一个节点上。

2.2加盐

这里所说的加盐不是密码学中的加盐，而是在rowkey的前面增加随机数，具体就是给rowkey分配一个随机前缀以使得它和之前的rowkey的开头不同。

2.3哈希

哈希会使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群，但是读却是可以预测的。使用确定的哈希可以让客户端重构完整的rowkey，可以使用get操作准确获取某一个行数据。

2.4反转

反转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分（最没有意义的部分）放在前面。这样可以有效的随机rowkey，但是牺牲了rowkey的有序性。

体会

rowkey既想要能够快速检索，就想要内容最好集中到少量的region中，但是一旦集中了，就会产生热点问题，所以，他们是相伴相生。

总结

点击关注不迷路，有啥想和我交流欢迎下方留言。