场景
HBase的region随着大小的不断变大会触发一个阈值，默认为256M，一旦触发那么他就会自动的分裂开来，随着region变多hbase管理起来也越发困难，性能也会明显下降。当然更多的region使得高并发成为可能。一种较好的实践方案就是一方面预切分HBase的region，确定region的个数，保证并发性能，另一方面设置较高的region size分裂阈值，保证region数量不变。
方案
预切分方法：
./bin/hbase org.apache.hadoop.hbase.util.RegionSplitter -c 500 test -f t1:t2:t3 上面的命令行工具给以为你切分一个500region的test表，分别包含了三个列族：t1,t2,t3。
然后在hbase-site.xml设置hbase.hregion.max.filesize为104857600（=1024*1024*100=100G），设置为100G，这样很长一段时间内不会出现region分裂。建议一个节点分到1000region，可以满足并发，而且不至于让master压力过大。
rowkey设计方案：
需要指出的是这种预切分方法用了一种默认算法md5stringsplit来分配region的startkey，endkey。这种得到的是一个8位的右移一位的md5的字符串。实际上就是md5前八位然后右移。这样在设计rowkey的时候就要千万注意了！因为这样分配出来的region是00000000~7fffffff。所以为了让rowkey能够均匀落入到这个范围需要md5(id)>>1 + id。提示一下：如果你使用的md5（id）+id的方法设计了rowkey，入库时如果数据量很大则会导致hot region。rs就会频繁的挂掉了，因为大部分数据都落入最后一个region了。
rowkey生成的具体的java代码如下：
private String makeRowKey(String id){String md5_content = null;try {MessageDigest messageDigest = MessageDigest.getInstance("MD5");messageDigest.reset();messageDigest.update(id.getBytes());byte[] bytes = messageDigest.digest();md5_content = new String(Hex.encodeHex(bytes));} catch (NoSuchAlgorithmException e1) {e1.printStackTrace();}//turn right md5String right_md5_id = Integer.toHexString(Integer.parseInt(md5_content.substring(0,7),16)>>1);while(right_md5_id.length()<7){right_md5_id = "0" + right_md5_id;}return right_md5_id + "::" + id;}
这样做的好处就是在写入数据时可以使rowkey均匀的写入，当然读取的时候还需要拿着id变成md5再去读取，批量读取与时间戳前置方法相比肯定没有任何优势了。不过随机读取也会使rs的负载均衡。
上面的这种设计适合绝大多数场景。可以作为一个良好的实践。