Hbase RowKey设计

  作为Nosql数据库的一员，HBase查询只能通过其rowkey来查询(rowkey用来表示唯一一行记录)，HBase中的数据是按照rowkey的ASCII字典顺序进行全局排序的。HBase是三维有序存储的，通过rowkey（行键），column key（column family和qualifier）和TimeStamp（时间戳）这个三个维度可以对HBase中的数据进行快速定位。
  HBase中rowkey可以唯一标识一行记录，在HBase查询的时候，有以下几种方式：

• 通过get方式（org.apache.hadoop.hbase.client.Get），指定rowkey获取唯一一条记录
• 通过scan方式（org.apache.hadoop.hbase.client.Scan），设置startRow和stopRow参数进行范围匹配
• 全表扫描，即直接扫描整张表中所有行记录

get：
  按照RowKey获取唯一一条记录。get的方法处理分两种：设置了ClosestRowBefore和没有设置ClosestRowBefore的RowLock。主要用来保证行的事务性，即每个get是以一个row来标记的。

scan：
  按照指定的条件获取一批记录。实现条件查询功能使用的就是scan方式，scan在使用时有以下几点值得注意：

1. scan可以通过setCach与setBatch方法提高速度（以空间换时间）
2. scan可以通过setStartRow与setEndRow来限定范围。范围越小，性能越高。通过巧妙的RowKey设计使我们批量获取记录集合中的元素挨在一起（应该在同一个Region下），可以在遍历结果时获得很好的性能
3. scan可以通过setFilter方法添加过滤器，这也是分页、多条件查询的基础

Rowkey设计原则

Rowkey设计应遵循以下原则：
【1】Rowkey的唯一原则
  由于在HBase中数据存储是Key-Value形式，若HBase中同一表插入相同Rowkey，则原先的数据会被覆盖掉(如果表的version设置为1的话)，所以务必保证Rowkey的唯一性

【2】Rowkey的排序原则
  HBase的Rowkey是按照ASCII有序设计的，我们在设计Rowkey时要充分利用这点。比如视频网站上对影片的弹幕信息，这个弹幕是按照时间倒排序展示视频里，设计的Rowkey要和时间顺序相关。可以使用"Long.MAX_VALUE - 弹幕发表时间"的 long 值作为 Rowkey 的前缀

【3】 Rowkey的散列原则
  Rowkey应均匀的分布在各个HBase节点上。拿常见的时间戳举例，假如Rowkey是按系统时间戳的方式递增，Rowkey的第一部分如果是时间戳信息的话将造成所有新数据都在一个RegionServer上堆积的热点现象，即Region热点问题。热点发生在大量的client直接访问集中在个别RegionServer上（访问可能是读，写或者其他操作），导致单个RegionServer机器自身负载过高，引起性能下降甚至Region不可用，常见的是发生jvm full gc或者显示region too busy异常情况，当然这也会影响同一个RegionServer上的其他Region

  通常有3种办法来解决这个Region热点问题：

1. Reverse反转
     针对固定长度的Rowkey反转后存储，这样可以使Rowkey中经常改变的部分放在最前面，可以有效的随机Rowkey。反转Rowkey的例子通常以手机举例，可以将手机号反转后的字符串作为Rowkey，这样的就避免了以手机号那样比较固定开头(137x、15x等)导致热点问题，这样做的缺点是牺牲了Rowkey的有序性
2. Salt加盐
     Salting是将每一个Rowkey加一个前缀，前缀使用一些随机字符，使得数据分散在多个不同的Region，达到Region负载均衡的目标。比如在一个有4个Region(注：以 [ ,a)、[a,b)、[b,c)、[c, )为Region起至)的HBase表中，加Salt前的Rowkey：abc001、abc002、abc003。分别加上a、b、c前缀，加Salt后Rowkey为：a-abc001、b-abc002、c-abc003 。可以看到，加盐前的Rowkey默认会在第2个region中，加盐后的Rowkey数据会分布在3个region中，理论上处理后的吞吐量应是之前的3倍。由于前缀是随机的，读这些数据时需要耗费更多的时间，所以Salt增加了写操作的吞吐量，但同时增加了读操作的开销
3. Hash散列或者Mod
     用Hash散列来替代随机Salt前缀的好处是能让一个给定的行有相同的前缀，这在分散了Region负载的同时，使读操作也能够推断。确定性Hash(比如md5后取前4位做前缀)能让客户端重建完整的RowKey，可以使用get操作直接get想要的行。例如将上述的原始Rowkey经过hash处理，此处我们采用md5散列算法取前4位做前缀，结果如下：9bf0-abc001、7006-abc002、95e6-abc003；若以前4个字符作为不同分区的起止，上面几个Rowkey数据会分布在3个region中。实际应用场景是当数据量越来越大的时候，这种设计会使得分区之间更加均衡。如果Rowkey是数字类型的，也可以考虑Mod方法

【4】Rowkey的长度原则
  Rowkey长度设计原则：Rowkey是一个二进制，Rowkey的长度被很多开发者建议说设计在10~100个字节，建议是越短越好。原因有两点：

1. HBase的持久化文件HFile是按照KeyValue存储的，如果Rowkey过长比如500个字节，1000万列数据光Rowkey就要占用500*1000万=50亿个字节，将近1G数据，这会极大影响HFile的存储效率
2. MemStore缓存部分数据到内存，如果Rowkey字段过长内存的有效利用率会降低，系统无法缓存更多的数据，这会降低检索效率

需要指出的是不仅Rowkey的长度是越短越好，而且列族名、列名等尽量使用短名字，因为HBase属于列式数据库，这些名字都是会写入到HBase的持久化文件HFile中去，过长的Rowkey、列族、列名都会导致整体的存储量成倍增加。

预分区

什么是预分区
  HBase表在刚刚被创建时，只有1个分区（region），当一个region过大（达到hbase.hregion.max.filesize属性中定义的阈值，默认10GB）时，表将会进行split，分裂为2个分区。表在进行split的时候，会耗费大量的资源，频繁的分区对HBase的性能有巨大的影响。HBase提供了预分区功能，即用户可以在创建表的时候对表按照一定的规则创建分区

预分区的目的
  减少由于region split带来的资源消耗。从而提高HBase的性能。避免数据倾斜，热点等问题

设计实战

  在实际的设计中我们可能更多的是结合多种设计方法来实现Rowkey的最优化设计，比如设计订单状态表时使用：Rowkey: reverse(order_id) + (Long.MAX_VALUE – timestamp)，这样设计的好处一是通过reverse订单号避免Region热点，二是可以按时间倒排显示。
结合使用HBase作为事件的临时存储(HBase只存储了最近10分钟的热数据)来举例：
设计event事件的Rowkey为：两位随机数Salt + eventId + Date + kafka的Offset
这样设计的好处是：
设计加盐的目的是为了增加查询的并发性，假如Salt的范围是0~n，那我们在查询的时候，可以将数据分为n个split同时做scan操作。经过我们的多次测试验证，增加并发度能够将整体的查询速度提升5～20倍以上。随后的eventId和Date是用来做范围Scan使用的。在我们的查询场景中，大部分都是指定了eventId的，因此我们把eventId放在了第二个位置上，同时呢，eventId的取值有几十个，通过Salt + eventId的方式可以保证不会形成热点。在单机部署版本中，HBase会存储所有的event数据，所以我们把date放在rowkey的第三个位置上以实现按date做scan，批量Scan性能甚至可以做到毫秒级返回。
这样的rowkey设计能够很好的支持如下几个查询场景：
1、全表scan
在这种情况下，我们仍然可以将全表数据切分成n份并发查询，从而实现查询的实时响应。
2、只按照event_id查询
3、按照event_id和date查询
此外易观方舟也使用HBase做用户画像的标签存储方案，存储每个app的用户的人口学属性和商业属性等标签信息，由于其设计的更为复杂，后续会另起篇幅详细展开。
最后我们顺带提下HBase的表设计，HBase表设计通常可以是宽表（wide table）模式，即一行包括很多列。同样的信息也可以用高表（tall table）形式存储，通常高表的性能比宽表要高出 50%以上，所以推荐大家使用高表来完成表设计。表设计时，我们也应该要考虑HBase数据库的一些特性：
1、在HBase表中是通过Rowkey的字典序来进行数据排序的
2、所有存储在HBase表中的数据都是二进制的字节
3、原子性只在行内保证，HBase不支持跨行事务
4、列族(Column Family)在表创建之前就要定义好
5. 列族中的列标识(Column Qualifier)可以在表创建完以后动态插入数据时添加

时间戳反转
  一个常见的数据处理问题是快速获取数据的最近版本，使用反转的时间戳作为rowkey。可以用 Long.Max_Value - timestamp 追加到key的末尾，例如 [key][reverse_timestamp] , [key] 的最新值可以通过scan [key]获得[key]的第一条记录，因为HBase中rowkey是有序的，第一条记录是最后录入的数据。

比如需要保存一个用户的操作记录，按照操作时间倒序排序，在设计rowkey的时候，可以这样设计：
[userId反转][Long.Max_Value - timestamp]，在查询用户的所有操作记录数据的时候，直接指定反转后的userId，startRow是[userId反转][000000000000],stopRow是[userId反转][Long.Max_Value - timestamp]

如果需要查询某段时间的操作记录，startRow是[user反转][Long.Max_Value - 起始时间]，stopRow是[userId反转][Long.Max_Value - 结束时间]

RowKey设计案例剖析：

1. 查询某用户在某应用中的操作记录
   reverse(userid) + appid + timestamp

2. 查询某用户在某应用中的操作记录（优先展现最近的数据）
   reverse(userid) + appid + (Long.Max_Value - timestamp)

3. 查询某用户在某段时间内所有应用的操作记录
   reverse(userid) + timestamp + appid

4. 查询某用户的基本信息
   reverse(userid)

5. 查询某eventid记录信息
   salt + eventid + timestamp
   加盐的目的是为了增加查询的并发性，加入Slat的范围是0~n，可以将数据分为n个split同时做scan操作，有利于提高查询效率。

如果 userid是按数字递增的，并且长度不一，可以先预估 userid 最大长度，然后将userid进行翻转，再在翻转之后的字符串后面补0（至最大长度）；如果长度固定，直接进行翻转即可（如手机号码）