HBase Rowkey设计规范

1.Rowkey是什么

能够理解为关系型数据库MySQL Oracle的主键,用于标识惟一的行。
彻底是由用户指定的一串不重复的字符串。
HBase中的数据永远是根据Rowkey的字典排序来排序的。

2.Rowkey的做用

读写数据时 经过 RowKey 找到 对应 的 Region，例如须要查找一条数据确定须要知道他的RowKey ，写数据的时候也要根据RowKey 来写。
MemStore中的数据按Rowkey字典顺序排序，写数据的时候会先将数据放到MemStore也就是内存，内存中的数据是按照Rowkey字典顺序排序的。
HFile中的数据按RowKey字典顺序排序，内存中的数据最后也会持久化到磁盘中，磁盘的数据HFile也是按RowKey字典顺序排序。

3.RowKey对查询的影响

例：RowKey由uid+phone+name组成

1.能够很好的支持的场景

• uid=111 AND phone = 123 AND name = abc

• uid=111 AND phone = 123

• uid=111 AND phone = 12?

• uid=111

  这种场景下咱们都指定了uid部分,也就是RowKey的第一部分,第一种查询的RowKey是完整的格式,因此查询效率是最好的,后边的三个虽然没有指定完整RowKey,可是查询的支持度也还不错.

2.难支持的场景

• phone = 123 AND name = abc

• phone = 123

• name = abc

  这种场景下并无指定RowKey的第一部分uid,只经过phone跟name去作查询,也就是不指定先导部分,那么这种场景会致使HBase的查询的时候去进行全表扫描,下降了查询效率.

4.RowKey对Region划分影响

HBase表的数据是按照RowKey来分散到不一样的Region,不合理的RowKey设计会致使热点问题,热点问题是大量的Client直接访问集群的一个或极少数个节点,而集群中的其余节点却处于相对空闲的状态,从而影响对HBase表的读写性能.

5.RowKey的设计技巧

1.Salting(加盐)

Salting的原理是将固定长度的随机数放在行键的起始处,具体就是给 rowkey 分配一个随机前缀 以使得它和以前排序不一样。分配的前缀种类数量应该和你想使数据分散到不一样的 region 的数量一致。 若是你有一些 热点 rowkey 反复出如今其余分布均匀的 rwokey 中，加盐是颇有用的。

例:假如你有下列 rowkey，你表中每个 region 对应字母表中每个字母。 以 ‘a’ 开头是同一个region, 'b’开头的是同一个region。在表中，全部以 'f’开头的都在同一个 region， 它们的 rowkey 像下面这样：

foo0001 a-foo0001

foo0002 ===>    b-foo0002

foo0003 c-foo0003

foo0004 d-foo0004

假如你须要将上面这个 region 分散到 4个 region。你能够用4个不一样的盐：‘a’, ‘b’, ‘c’, ‘d’.在这个方案下，每个字母前缀都会在不一样的 region 中。加盐以后，就像上边的例子.

因此，你能够向4个不一样的 region 写，理论上说，若是全部人都向同一个region 写的话，你将拥有以前4倍的吞吐量。

优缺点:因为前缀是随机生成的,所以想要按照字典顺序找到这些行,则须要作更多的工做,从这个角度上看,salting增长了写操做的吞吐量,却也增长了读操做的开销.

2.Hashing

Hashing 的原理是计算 RowKey 的 hash 值，而后取 hash 的部分字符串和原来的 RowKey 进行拼接。这里说的 hash 包含 MD五、sha一、sha256或sha512等算法,并非仅限于Java的Hash值计算。

例:好比咱们有以下的 RowKey：

foo0001                 95f18cfoo0001

                foo0002     ===>        6ccc20foo0002

                foo0003                 b61d00foo0003

                foo0004                 1a7475foo0004

咱们使用 md5 计算这些 RowKey 的 hash 值，而后取前 6 位和原来的 RowKey 拼接获得新的 RowKey,如上

优缺点：能够必定程度打散整个数据集，可是不利于 Scan；好比咱们使用 md5 算法，来计算Rowkey的md5值，而后截取前几位的字符串。
常见用法:subString(MD5(设备ID), 0, x) + 设备ID，其中x通常取5或6。

3.Reversing(反转)

Reversing 的原理是反转一段固定长度或者所有的键。

例:好比咱们有如下 URL ，并做为 RowKey：

flink.iteblog.com                           moc.golbeti.knilf
                www.iteblog.com          ===>               moc.golbeti.www
                carbondata.iteblog.com                      moc.golbeti.atadnobrac
                def.iteblog.com                             moc.golbeti.fed

这些 URL 其实属于同一个域名，可是因为前面不同，致使数据不在一块儿存放。咱们能够对其进行反转,如上,通过这个以后，前缀就相同了,这些 URL 的数据就能够放一块儿了。

优缺点:有效的打乱了行键,可是却牺牲了行排序的属性.

6.RowKey的长度

RowKey 能够是任意的字符串，最大长度64KB（由于 Rowlength 占2字节）。建议越短越好，缘由以下：

• 数据的持久化文件HFile中是按照KeyValue存储的，若是rowkey过长，好比超过100字节，1000w行数据，光rowkey就要占用100*1000w=10亿个字节，将近1G数据，这样会极大影响HFile的存储效率；
• MemStore将缓存部分数据到内存，若是rowkey字段过长，内存的有效利用率就会下降，系统不能缓存更多的数据，这样会下降检索效率；
• 目前操做系统都是64位系统，内存8字节对齐，控制在16个字节，8字节的整数倍利用了操做系统的最佳特性。

7.设计案例剖析

1.交易类表 Rowkey 设计

• 查询某个卖家某段时间内的交易记录
  sellerId + timestamp + orderId

• 查询某个买家某段时间内的交易记录
  buyerId + timestamp ＋orderId

• 根据订单号查询
  orderNo

若是某个商家卖了不少商品，按第一种方式,就有可能会有大量RowKey前缀相同的数据在相同的Region上,形成热点问题,能够以下设计 Rowkey 实现快速搜索 salt + sellerId + timestamp 其中，salt 是随机数。

咱们在原来的结构以前进行了一步加盐salt操做,例如加上一个随机数,这样就能够把这些数据分散到不一样的Region上去了.

能够支持的场景：

• 全表 Scan,由于进行了加盐操做,数据分散到了不一样的Region上,Scan的时候就会去不一样的Region上去Scan,这样就提高高并发,也就提高检索效率.
• 按照 sellerId 查询
• 按照 sellerId + timestamp 查询

2.金融风控 Rowkey 设计

查询某个用户的用户画像数据

prefix + uid

prefix + idcard

prefix + tele

其中前缀的生成 prefix = substr(md5(uid),0 ,x)， x 取 5-6。uid、idcard以及 tele 分别表示用户惟一标识符、×××、手机号码。

3.车联网 Rowkey 设计

• 查询某辆车在某个时间范围的数据,例如发动机数据
  carId + timestamp

• 某批次的车太多，形成热点
  prefix + carId + timestamp

其中 prefix = substr(md5(uid),0 ,x)

4.倒序时间戳(时间倒排)

查询用户最新的操做记录或者查询用户某段时间的操做记录，RowKey 设计以下：
uid + Long.Max_Value - timestamp

支持的场景

• 查询用户最新的操做记录
  Scan [uid] startRow [uid][00000000000] stopRow [uid][uid][Long.Max_Value - timestamp]

  这样就能查出好比说最近100条数据

• 查询用户某段时间的操做记录
  Scan [uid] startRow [uid][Long.Max_Value - startTime] stopRow uid [uid][Long.Max_Value - endTime]

5.二级索引

例:有一张HBase表结构及数据以下

问:如何查找phone=13111111111的用户?

遇到这种需求的时候,HBase的设计确定是知足不了的,这时候就要引入二级索引,将phone当作RowKey,uid/name当作列名构建二级索引.

若是不依赖第三方组建的话,能够本身编码实现二级索引,同时也能够经过Phoenix或者Solr建立二级索引.

SQL+OLTP ==> Phonenix

全文检索+二级索引 ==> Solr/ES