设计HBase RowKey需要注意的二三事

在HBase中，定位一条数据（即一个Cell）需要4个维度的限定：行键（RowKey）、列族（Column Family）、列限定符（Column Qualifier）、时间戳（Timestamp）。其中，RowKey是最容易出现问题的。除了根据业务和查询需求来设计之外，还需要注意以下三点。

1. 打散RowKey
   HBase中的行是按照RowKey字典序排序的。

这对Scan操作非常友好，因为RowKey相近的行总是存储在相近的位置，顺序读的效率比随机读要高。
但是，如果大量的读写操作总是集中在某个RowKey范围，那么就会造成Region热点，拖累RegionServer的性能。
因此，要适当地将RowKey打散。
加盐（salting）+哈希（hashing）
这里的“加盐”与密码学中的“加盐”不是一回事。
它是指在RowKey的前面增加一些前缀。
加盐的前缀种类越多，RowKey就被打得越散。
前缀不可以是随机的，因为必须要让客户端能够完整地重构RowKey。
我们一般会拿原RowKey或其一部分计算hash值，然后再对hash值做运算作为前缀。
反转固定格式的数值
以手机号为例，手机号的前缀变化比较少（如152、185等），但后半部分变化很多。
如果将它反转过来，可以有效地避免热点。
不过其缺点就是失去了有序性。
反转时间
这个操作严格来讲不算“打散”，但可以调整数据的时间排序。
如果将时间按照字典序排列，最近产生的数据会排在旧数据后面。
如果用一个大值减去时间（比如用99999999减去yyyyMMdd，或者Long.MAX_VALUE减去时间戳），最新的数据就可以排在前面了。

1. 控制RowKey长度
   在HBase中，RowKey、列族、列名等都是以byte[]形式传输的。

RowKey的最大长度限制为64KB，但在实际应用中最多不会超过100B。
设计短RowKey有以下两方面考虑：
在HBase的底层存储HFile中，RowKey是KeyValue结构中的一个域。假设RowKey长度100B，那么1000万条数据中，只算RowKey就占用掉将近1G空间，会影响HFile的存储效率。

HBase中设计有MemStore和BlockCache，分别对应列族/Store级别的写入缓存，和RegionServer级别的读取缓存。如果RowKey过长，缓存中存储数据的密度就会降低，影响数据落地或查询效率。

另外，我们目前使用的服务器操作系统都是64位系统，内存是按照8B对齐的，因此设计RowKey时一般做成8B的整数倍，如16B或者24B，可以提高寻址效率。
同样地，列族、列名的命名在保证可读的情况下也应尽量短。HBase官方不推荐使用3个以上列族，因此实际上列族命名几乎都用一个字母，比如‘c’或‘f’。

1. 保证RowKey唯一性
   这个就是显而易见的了，不再赘述。

举个例子
我们的业务中，有一部分是用户在日历上记录自己的行为。需要储存在RowKey中的维度有：用户ID（uid，不会超过十亿）、日历上的日期（date，yyyyMMdd格式）、记录行为的类型（type，0~99之间）。记录的详细数据则存储在列f:data中。根据查询逻辑，我们设计的RowKey格式如下：
9~79809782~05~0008839540
长度正好是24B。以字符‘~’为分界（‘~’的ASCII码是最大的，方便），各个部分的含义如下：

uid.toString().hashCode() % 10

99999999 - date

StringUtils.leftPad(type, 2, "0")

StringUtils.leftPad(uid, 10, "0")

基于这种设计，我们在建表阶段就可以将其预分区，使得数据在一开始就均匀分布在不同的Region上。建表语句参考：

create 'user_calendar_record', {
NAME => 'f',
VERSIONS => '1',
BLOCKCACHE => 'true',
BLOCKSIZE => '65536',
BLOOMFILTER => 'row',
COMPRESSION => 'SNAPPY'
}, {
SPLITS => ['1', '2', '3', '4', '5', '6', '7', '8', '9']
}

如果不做预分区，那么表刚开始只会有一个Region。随着数据量增大，就会频繁触发Region split，影响效率。关于Region split应该另外写文章讨论，这里就不提了。