hbase的rowkey设计决定了数据的分区和查询的方式，是使用hbase前一定要想清楚的，以下简单列举了设计hbase rowkey时需要考虑的问题

1. rowkey是唯一的吗？

rowkey相同的记录在hbase里被认为是同一条数据的多个版本，查询时默认返回最新版本的数据，所以通常rowkey都需要保证唯一，除非用到多版本特性

最佳设计实践：

rowkey就好比数据库的里的主键，他唯一确定了一条记录，它可以是一个字段也可以是多个字段拼接起来:

每个用户只有一条记录： [userid]

每个用户有多条交易记录：[userid][orderid]

2. 满足查询场景吗？

rowkey的设计限制了数据的查询方式，hbase只有两种查询方式：

1. 根据完整的rowkey查询（get）

类似传统DB的sql:

select * from table where rowkey = ‘abcde’

这种查询方式需要知道完整的rowkey，即组成rowkey的所有字段的值都是确定的

2. 根据rowkey的范围查询（scan):

类似传统DB的sql:

select * from table where ‘abc’ < rowkey <’abcx’

这种查询方式需要知道数据rowkey左边的值，就好像一本英文字典，你可以查询pre开头的所有单词，也可以查询prefi开头的所有单词，但是没办法查询中间是efi或结尾是ix的所有单词，除非翻阅整个字典

最佳设计实践：

在有限的查询方式下如何实现复杂查询：

1.再建另外一张表作为索引表，应用双写

2.使用filter，在服务端过滤掉不需要的数据

3.使用二级索引

4.如何实现倒序（新的数据排在前面，如：order by orderTime desc）：

  使用反向scan：scan.setReverse(true)

  #反向scan的性能比正常scan要差，如果倒序的场景占大头可以设计上就把数据倒序：

  [hostname][log-event][timestamp]  => [hostname][log-event][Long.MAX_VALUE – timestamp]

3. 数据足够分散，会产生热点吗？

散列的目的是数据可以分散到不同的分区，不至于产生热点，把某一台服务器累死，其他服务器闲置，充分发挥分布式和并发的优势

最佳设计实践：

1.md5

  [userId][orderid]  =>  [md5(userid).subStr(0,4)][userId][orderid]

2.反转

  [userId][orderid] => [reverse(userid)][orderid]

3.取模

  [timestamp][hostname][log-event]  => [bucket][timestamp][hostname][log-event]

  long bucket = timestamp % numBuckets;

4.增加随机数

  [userId][orderid] => [userId][orderid][random(100)]

4. rowkey可以再短点吗?

短的rowkey可以减少数据量 ，提高查询写入性能

最佳设计实践：

1. 使用long或int型代替String

  如： '2015122410' => Long(2015122410)

2. 使用编码代替名称

  如：’淘宝‘ => tb

5. scan时会不会查询出不需要的数据？

假设有以下场景：

table1的rowkey是: colume1+ colume2+ colume3

现在需要查询colume1= host1 的所有数据：

scan 'table1',{startkey=> 'host1',endkey=> 'host2'}

此时如果有一条记录colume1=host12，这条记录也会被查询出来：因为:

'host1' < 'host12' < 'host2'

但显然这条记录不是我们想要的

最佳设计实践：

1. 字段定长

  [colume1][colume2] => [rpad(colume1,'x',20)][colume2]

2. 添加分隔符

  [colume1][colume2] => [colume1][_][colume2]

常见设计实例：

日志类、时间序列数据

查询场景：

1.查询某台机器某个指标某段时间内的数据

[hostname][log-event][timestamp]

2.查询某台机器某个指标最新的几条数据

timestamp = Long.MAX_VALUE – timestamp

[hostname][log-event][timestamp]

3.数据只有时间一个维度或某一个维度数据量特别大

long bucket = timestamp % numBuckets;

[bucket][timestamp][hostname][log-event]

交易类数据

查询场景：

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

[seller id][timestmap][order number]

2.查询某个买家某段时间内的交易记录

[buyer id][timestmap][order number]

3.根据订单号查询

[order number]

4.同时满足1，2，3

三张表：

一张买家维度表，rowkey为：

[buyer id][timestmap][order number]

一张卖家维度表，rowkey为：

[seller id][timestmap][order number]

一张订单索引表，rowkey为：

[order number]