Hbase的表结构中rowkey的设计---避免热点问题

热点问题

　　hbase 中的行是以 rowkey 的字典序排序的，这种设计优化了scan 操作，可以将相关的 行 以及会被一起读取的行 存取在临近位置，便于 scan 。 然而，糟糕的 rowkey 设计是 热点 的源头。 热点发生在大量的客户端直接访问集群的一个或极少数节点。访问可以是读，写，或者其他操作。大量访问会使 热点region 所在的单个机器超出自身承受能力，引起性能下降甚至是 region 不可用。这也会影响同一个 regionserver 的其他 regions，由于主机无法服务其他region 的请求。设计良好的数据访问模式以使集群被充分，均衡的利用。 
　　为了避免写热点，设计 rowkey 使得 不同行在同一个 region,但是在更多数据情况下，数据应该被写入集群的多个region，而不是一个。下面是一些常见的避免 热点的方法以及它们的优缺点：

1、加盐

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

3、哈希

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

4、翻转key

　　第三种防止热点的方法是翻转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分（最没意义的部分）放在前面。这样可以有效的随机 rowkey,但是牺牲了 rowkey 的有序性。 
100kr 
200kr 
300kr

5、单调递增 rowkey(时间连续序列)

　　当所有客户端一段时间内一致写入某一个region,然后再接着写入下一个 region。例如：像单调递增的 rowkey（时间戳） ，就会发生这种现象。应该尽量避免这种设计。 
打散数据的数据+时间序列

6、尽量减少行和列的大小

　　在Hbase中，value永远是和它的key一起传输的。当具体的值在系统间传输时，它的rowkey,列名，时间戳也会一起传输。如果你的rowkey和列名很大，甚至可以和具体的值相比较，那么你将会遇到一些有趣的情况。HBase storefiles中的索引（有助于随机访问）最终占据了HBase 分配的大量内存，因为具体的值和他的key很大。可以增加 block 大小使得 storefiles 索引在更大的时间间隔增加，或者修改表的模式以减小rowkey 和 列名的大小。压缩也有助于更大的索引。

　　大多时候较小的低效率是无关紧要的，但是在这种情况下，任何访问模式都需要列族名，列名，rowkey，所以它们会被访问数十亿次在你的数据中。

7、列族越短越好

尽可能使列族名越短越好，最好是一个字符。（例如：’d’ 代表data/default）。属性名也是一样的。