HBase RowKey散列和预分区

RowKey设计三大原则

1、散列原则，不要用类似于时间戳这样的数据直接作为RowKey，如果确实需要用时间戳，可以把它放在低位，高位用散列来占位。

2、长度原则，其实总结就一句话，rowkey只是一个唯一标识符，并没有更多的实际意义，所以不要搞得太长，但是，我想说但是，如果我的rowkey是有意义的，那么让他长一些是不是也可以呢？

3、唯一性原则，这一点没什么好说的，RowKey需要唯一确定一条数据，所以必须唯一。

后面2条原则没什么好说的，我们重点来看一下散列原则，为什么会有这样的建议。

在HBase当中，表会被划分为1…n个Region，被托管在RegionServer中。Region二个重要的属性:StartKey与EndKey表示这个 Region维护的rowKey范围，当我们要读/写数据时，如果rowKey落在某个start-end key范围内，那么就会定位到目标region并且读/写到相关的数据。

如果我们在建表的时候，不预先设定好分区，随着表内数据的增多，HBase会自动把表进行split，但是这样做有几点问题，第一，分区的原则，可能并不是我们想要的；第二，在表内数据相对较少的时候，无法充分展现分布式并发处理的优势；第三，split操作，其实是比较耗资源的，如果数据增长过快，可能会相对频繁的发生。

那么，预分区又是如何实现的，我们看下面这个语句：

create 'testtable', 'common', 'data', {SPLITS => ['1','2','3']}

建好之后，我们可以在HBase的web页面当中，看到表的分区的分布情况：

我们看到，我们用1,2,3三个数，把一个table划分为了4个region，这四个region分别是：

x<1, 1<=x<2, 2<=x<3, 3<=x

那么我们在insert的数据的时候，又该怎么做呢？看下面的scala代码：

val p = new Put(Bytes.toBytes(String.valueOf(random.nextInt(4)) + new Date().getTime))

这句话是为一条新的数据，生成一个RowKey，那么我们的key值由2部分组成，随机散列+时间戳，其中随机散列包括：【0,1,2,3】一共4个值，根据上面我们划分的region，这4个值，将会映射到4个不同的region当中。