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

热点问题

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

一、加盐

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

三、哈希

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

四、翻转key

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

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

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

六、尽可能减小行和列的大小

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

　　大多时候较小的低效率是可有可无的，可是在这种状况下，任何访问模式都须要列族名，列名，rowkey，因此它们会被访问数十亿次在你的数据中。

七、列族越短越好

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