HBase的热点问题及解决思路

Hbase的表会被划分为1…n个Region,被托管在RegionServer中。Region二个重要的属性：Startkey与EndKey表示这个Region维护的rowkey的范围，当我们要读写数据时，如果rowkey落在某个start-end key范围内，那么就会定位到目标region并且读写到相关的数据。
默认情况下，当我们通过hbaseAdmin指定TableDescriptor来创建一张表时，只有一个region正处于混沌时期，start-end key无边界，可谓海纳百川。所有的rowkey都写入到这个region里，然后数据越来越多，region的size越来越大时，大到一定的阀值，hbase就会将region一分为二，成为2个region，这个过程称为分裂（region-split）。
如果我们就这样默认建表，表里不断的put数据，更严重的是我们的rowkey还是顺序增大的，是比较可怕的。存在的缺点比较明显：首先是热点写，我们总是向最大的start key所在的region写数据，因为我们的rowkey总是会比之前的大，并且hbase的是按升序方式排序的。所以写操作总是被定位到无上界的那个region中；其次，由于热点，我们总是往最大的start key的region写记录，之前分裂出来的region不会被写数据，有点打入冷宫的感觉，他们都处于半满状态，这样的分布也是不利的。
如果在写比较频繁的场景下，数据增长太快，split的次数也会增多，由于split是比较耗费资源的，所以我们并不希望这种事情经常发生。
在集群中为了得到更好的并行性，我们希望有好的load blance，让每个节点提供的请求都是均衡的，我们也希望，region不要经常split，因为split会使server有一段时间的停顿，如何能做到呢？
随机散列与预分区二者结合起来，是比较完美的。预分区一开始就预建好了一部分region，这些region都维护着自己的start-end keys，在配合上随机散列，写数据能均衡的命中这些预建的region，就能解决上面的那些缺点，大大提高性能。

一、解决思路
提供两种思路：hash与partition。
1、hash方案
hash就是rowkey前面由一串随机字符串组成，随机字符串生成方式可以由SHA或者MD5方式生成，只要region所管理的start-end keys范围比较随机，那么就可以解决写热点问题。例如：
java代码

1.	long currentId = 1L;  
2.	byte [] rowkey = Bytes.add(MD5Hash.getMD5AsHex(Bytes.toBytes(currentId))  
3.	                    .substring(0, 8).getBytes(),Bytes.toBytes(currentId));  

假如rowkey原本是自增长的long型，可以将rowkey转为hash再转为bytes，加上本身id转为bytes，这样就生成随便的rowkey。那么对于这种方式的rowkey设计，如何去进行预分区呢？

1. 取样，先随机生成一定数量的rowkey，将取样数据按升序排序放到一个集合里。
2. 根据预分区的region个数，对整个集合平均分割，即是相关的splitkeys。
3. HBaseAdmin.createTable(HTableDescriptor tableDescriptor,byte[][] splitkeys)可以指定预分区的spl