Rowkey是什么？

  • 类似MySql，Oracle中的主键，用于表示唯一的行。
  • 完全是由用户指定的一串不重复的字符串。

HBase中的数据是根据Rowkey的字典顺序来排序的。

Rowkey的作用？

  • 读写数据时通过Rowkey找到对应的Region.
  • MemStore中的数据按照Rowkey的字典顺序排序。

HFile中的数据按照Rowkey的字典顺序排序。

Rowkey对查询的影响

如果Rowkey设计为 uid+phone+name,那么这种设计可以很好地支持以下的场景：

  • uid = 111 AND phone = 123 And name = iteblog
  • uid = 111 AND phone = 123
  • uid = 111 AND phone = 12?
  • uid = 111

难支持的场景：

  • phone =123 AND name = iteblog
  • phone =123
  • name = iteblog

Rowkey对Region划分影响

HBase表的数据是按照RowKey来分散到不同Region，不合理的Rowkey设计会导致热点问题。

热点问题是大量的Client直接访问集群的一个或极少数个节点，而集群中的其他节点却处于相对空闲状态。

Region1 上的数据是Region2 的10倍，这样会导致Region1 的访问频率比较高，进而影响这个Region所在机器

的其他Region。

RowKey设计技巧

如何避免热点问题？有三种方法。

避免热点的方法 - Salting

这里的加盐不是密码学中的加盐，而是在rowkey的前面增加随机数。具体就是给rowkey分配一个

随机前缀以使得它和之前排序不同。分配的前缀种类数量应该和你想使数据分散到不同的region的数量一致。

 如果你有一些 热点 rowkey 反复出现在其他分布均匀的 rwokey 中，加盐是很有用的。

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

foo0001
foo0002
foo0003
foo0004

现在，假如你需要将上面这个 region 分散到 4个 region。你可以用4个不同的盐：'a', 'b', 'c', 'd'.在这个方案下，每一个字母前缀都会在不同的 region 中。加盐之后，你有了下面的 rowkey:

a-foo0003
b-foo0001
c-foo0004
d-foo0002

所以，你可以向4个不同的 region 写，理论上说，如果所有人都向同一个region 写的话，你将拥有之前4倍的吞吐量。

现在，如果再增加一行，它将随机分配a,b,c,d中的一个作为前缀，并以一个现有行作为尾部结束

a-foo0003
b-foo0001
c-foo0003
c-foo0004
d-foo0002

因为分配是随机的，所以如果你想要以字典序取回数据，你需要做更多工作。加盐这种方式增加了写时的吞吐量，但是当读时有了额外代价。

避免热点的方法 -Hashing

Hashing 的原理是计算机 RowKey 的 hash 值，然后取hash的部分字符串和原来的 RowKey 进行拼接。这里说的 hash 包含 MD5丶sha1 或 sha512 等算法。比如有如下的 RowKey:

foo0001
foo0002
foo0003
foo0004

我们使用 md5 计算这些 RowKey 的值，然后取前6位和原来的 RowKey 拼接得到新的 Row Key：

95f18cfoo0001
6ccc20foo0002
b61d00foo0003
1a7475foo0004

优缺点：可以一定程度打散整个数据集，但是不利于Scan. 比如使用 md5算法，来计算 RowKey 的 md5 值，

然后截取前几位的字符串。subString(MD5(设备ID),0,x)+设备ID,其中x一半取5或6.

 

避免热点的方法 - Reversing

Reversing 的原理是反转一段固定长度或全部的键。例如我们有以下 URL ,并作为 RowKey:

flink.iteblog.com
www.iteblog.com
carbondata.iteblog.com
def.iteblog.com

这些 URL 其实属于同一个域名，但是由于前面不一样，导致数据不在一起存放。我们可以对其进行反转，如下：

moc.golbeti.knilf
moc.golbeti.www
moc.golbeti.atadnobrac
moc.golbeti.fed

之后，这些 URL 的数据就可以放一起了。

 

RowKey 的长度：

RowKey可以是任意的字符串，最大长度64kb(因为 Rowlength 占2字节). 建议越短越好，原因如下：

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

 

RowKey设计案例：

交易类表 RowKey 设计

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

      sellerld + timeStamp + orderld

  • 查询某个买家某段时间的交易记录

       buyerld + timestamp + orderld

  • 根据订单号查询

       orderNo

  • 如果某个商家卖了很多商品，可以设计如下 Rowkey 实现快速搜索

     salt + sellerld + timestamp 其中，salt 是随机数。

可以支持的场景：

  • 全表Scan
  • 按照 sellerld 查询
  • 按照 sellerld + timestamp 查询

 

金融风控 RowKey 设计

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

  • prefix + uid
  • prefix + idcard
  • prefix + tele
  • 其中 prefix = substr(md5(uid),0,x),x 取 5-6. uid丶idcard 以及 tele 分别表示用户唯一标识符丶身份证丶手机号码。

车联网 RowKey 设计

  • 查询某辆车在某个时间范围的交易记录

    carld + timestamp

  • 某批次的车太多，造成热点

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

查询最近的数据

查询用户最近的操作记录或查询永和某段时间的操作记录，RowKey 设计如下：

uid + Long.Max_Value - timestamp

支持的 场景

  • 查询用户最新操作记录

   Scan [uid] startRow [uid][000000000000] stopRow [uid][Long.Max_Value - timestamp]

  • 查询用户某段时间的操作记录

Scan [uid] startRow [uid] [Long.Max_Value -startTime] stopRow [uid][Long.Max_Value -endTime]