Hbase_rowKey的设计原则

RowKey的设计原则

1. 设计原则

1.1 唯一原则

保证rowKey的唯一性。由于在HBase中数据存储是Key-Value形式，若HBase中同一表插入相同RowKey，则原先的数据会被覆盖掉（如果表的version设置为1的话）。

1.2 散列原则

设计的RowKey应保证同一时间段内的数据能够被均匀的分配给不同的HBase节点。
举一个反面的例子: 针对实时产生的事件连续的数据, 如果RowKey是按系统时间戳的方式递增，即RowKey的第一部分(类似寻址位的高位)是时间戳，将造成所有新数据都在一个RegionServer堆积的热点现象（访问可能是读、写或者其他操作），导致单个RegionServer机器自身负载过高.

2. 具体思路

2.1 散列原则

将所有的数据散列到全部的Region上。这是可以做到的，比如，在rowkey前面加上一个非线程序列，常常有如下选择：

(1) Hash散列

您可以使用一个Hash前缀来保证所有的行被分发到多个Region服务器上。例如：
byte prefix =
(byte) (Long.hashCode(timestamp) % );
byte[] rowkey =
Bytes.add(Bytes.toBytes(prefix), Bytes.toBytes(timestamp);

这个公式可以产生足够的数字，将数据散列到所有的Region服务器上。当然，公式里假定了Region服务器的数目。如果您打算后期扩容您的集群，那么您可以把它先设置为集群的整数倍。生成的rowkey类似下面：

0myrowkey-1,
1myrowkey-2, 2myrowkey-3, 0myrowkey-4, 1myrowkey-5,
2myrowkey-6, …

当他们将按如下顺序被发送到各个Region服务器上去：
0myrowkey-1
0myrowkey-4
1myrowkey-2
1myrowkey-5
…
换句话说，对于0myrowkey-1和0myrowkey-4的更新操作会被发送到同一个region服务器上去（假定它们没有被散列到两个region上去），1myrowkey-2和1myrowkey-5会被发送到同一台服务器上。

这种方式的缺点是，rowkey的范围必须通过代码来控制，同时对数据的访问，可能要访问多台region服务器。当然，可以通过多个线程同时访问，来实现并行化的数据读取。这种类似于只有map的MapReduce任务，可以大大增加IO的性能。

(2)字段位置交换

在前面提到了Key部分扫描，您可以移动timestamp字段，将它放在前一个字段的前面。这种方法通过rowkey的组合来将一个顺序递增的timestamp字段放在rowkey的第二个位置上。
如果你的rowkey不单单含有一个字段，您可以交换它们的位置。如果你现在的rowkey只有一个timestamp字段，您有必要再选出一个字段放在rowkey中。当然，这也带来了一个缺点，即您常常只能通过rowkey的范围查询来访问数据，比如timestamp的范围。

(3) Reverse反转

针对固定长度的RowKey反转后存储，这样可以使RowKey中经常改变的部分放在最前面，可以有效的随机RowKey。反转RowKey的例子通常以手机举例，可以将手机号反转后的字符串作为RowKey，这样就避免了以手机号那样比较固定开头导致热点问题。这样做的缺点是牺牲了RowKey的有序性。

(4) salting

当你思考行健的构成时，salting是另一种技巧。假设你在读取时知道时间范围，但不想做全表扫描。对时间戳做散列运算然后把散列值作为行健的做法需要做全表扫描，这是很低效的，尤其是在你有办法限制扫描范围的时候。使用散列值作为行健在这里不是办法，但是你可以在时间戳前面加上一个随机数前缀。

(5)时间戳反转

一个常见的数据处理问题是快速获取数据的最新版本，使用反转的时间戳作为RowKey的一部分对这个问题十分有用，可以用Long.Max_Value - timestamp追加到key的末尾。举例，在设计推帖流表时，你的焦点是为读优化行健，目的是把推帖流里最新的推帖存储在一起，以便于它们可以被快速读取，而不用做开销很大的硬盘搜索。在推贴流表里，你使用倒序时间戳（Long.MAX_VALUE - 时间戳）然后附加上用户ID来构成行健。现在你基于用户ID扫描紧邻的n行就可以找到用户需要的n条最新推帖。这里行健的结构对于读性能很重要。把用户ID放在开头有助于你设置扫描，可以轻松定义起始键。

3. 案例参考