1. HBase的存储形式

hbase的内部使用KeyValue的形式存储，其key时rowKey：family：column：logTime，value是其存储的内容。

其在region内大多以升序的形式排列，唯一的时logTime是以降序的形式进行排列。

所以，rowKey里越靠近左边的信息越容易被检索到。其设计时，要考虑把重要的信息放左边，不重要的信息放到右边。这样可以提高查询数据的速度。最重要的提高索引速度的就是设计合适的rowKey。

在做RowKey设计时，请先考虑业务是读比写多，还是读比写少，HBase本身是为写优化的，即便是这样，也可能会出现热点问题，而如果我们读比较多的话，除了考虑以上RowKey设计原则外，还可以考虑HBase的Coprocessor甚至elasticSearch结合的方法，无论哪种方式，都建议做实际业务场景下数据的压力测试以得到最优结果。

2. RowKey的设计原则

2.1 长度原则

rowKey是一个二进制，RowKey的长度被很多开发者建议说设计在10~100个字节，以byte[]形式保存，最大不能超过64kb。建议越短越好，不要超过16个字节。

太长的影响有几点点：

一是HBase的持久化文件HFile是按照KeyValue存储的，如果RowKey过长，比如说500个字节，1000万列数据，光是RowKey就要占用500*1000万=50亿个字节，将近1G数据，极大影响了HFile的存储效率。
二是缓存MemStore缓存部分数据到内存中，如果RowKey字段过长，内存的有效利用率会降低，系统无法缓存更多的数据，降低检索效率。
目前操作系统都是64位系统，内存8字节对齐，控制在16字节，8字节的整数倍利用了操作系统的最佳特性。

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

2.2 唯一原则

保证rowKey的唯一性。由于在HBase中数据存储是Key-Value形式，若HBase中同一表插入相同RowKey，则原先的数据会被覆盖掉（如果表的version设置为1的话）。

2.3 散列原则

设计的RowKey应均匀分布在各个HBase节点上。如RowKey是按系统时间戳的方式递增，RowKey的第一部分如果是时间戳的话，将造成所有新数据都在一个RegionServer堆积的热点现象，也就是通常说的Region热点问题，热点发生在大量的client直接访问集中在个别RegionServer上（访问可能是读、写或者其他操作），导致单个RegionServer机器自身负载过高，引起性能下降甚至Region不可用，常见的是发生jvm full gc或者显示region too busy异常情况。

3. 在不同访问模式下设计行健

3.1 为写优化（解决热点问题）

当往HBase表写入大量数据时，需要在RegionServer上分散负载来进行优化。这并不难，但是你可能不得不在读模式优化上付出代价。比如，时间序列数据的例子，如果你的数据直接使用时间戳做行健，在写入时在单个region上会遇到热点问题。

许多使用场景下，并不需要基于单个时间戳访问数据。你可能要运行一个作业在一个时间区间上做聚合计算，如果对时间延迟不敏感，可以考虑跨多个region做并行扫描来完成任务。但问题是，应该如何把数据分散在多个region上呢？有几个选项可以考虑，答案取决于你想让行健包含什么信息。

散列。如果你愿意在行健里放弃时间戳信息（每次你做什么事情都要扫描全表，或者每次要读数据时你都知道精确的键，这些情况下也是可行的），使用原始数据的散列值作为行健是一种可能的解决方案：

每次当你需要访问以这个散列值为键的行时，需要精确知道“TheRealMT”。时间序列数据一般不这样处理。当你访问数据时，可能记住了一个时间范围，但不大可能知道精确的时间戳。但是有些情况下，能够计算散列值从而找到正确的行。为了得到一种跨所有region的、优秀的分布策略，你可以使用MD5、SHA-1或者其他提供随机分布的散列数。

2.salting。当你思考行健的构成时，salting是另一种技巧。让我们考虑之前的时间序列数据例子。假设你在读取时知道时间范围，但不想做全表扫描。对时间戳做散列运算然后把散列值作为行健的做法需要做全表扫描，这是很低效的，尤其是在你有办法限制扫描范围的时候。使用散列值作为行健在这里不是办法，但是你可以在时间戳前面加上一个随机数前缀。

例如，你可以先计算时间戳的散列码，然后用RegionServer的数量取模来生成随机salt数：

取到salt数后，加到时间戳的前面生成行健：

　　　现在行健如下所示：

　　　你可以想到，这些行将会基于键的第一部分，也就是随机salt数，分布在各个region。

　　　但并非一切都是完美的。现在读操作需要把扫描命令分散到所有region上来查找相应的行。因为它们不再存储在一起，所以一个短扫描不能解决问题了。这是一种权衡，为了搭建成功的应用你需要做出选择。这是一个利用信息的位置来获得跨region分布的经典例子。

3. Reverse反转。针对固定长度的RowKey反转后存储，这样可以使RowKey中经常改变的部分放在最前面，可以有效的随机RowKey。反转RowKey的例子通常以手机举例，可以将手机号反转后的字符串作为RowKey，这样就避免了以手机号那样比较固定开头导致热点问题。这样做的缺点是牺牲了RowKey的有序性。

3.2 为读优化

时间戳反转。一个常见的数据处理问题是快速获取数据的最新版本，使用反转的时间戳作为RowKey的一部分对这个问题十分有用，可以用Long.Max_Value - timestamp追加到key的末尾。举例，在设计推帖流表时，你的焦点是为读优化行健，目的是把推帖流里最新的推帖存储在一起，以便于它们可以被快速读取，而不用做开销很大的硬盘搜索。在推贴流表里，你使用倒序时间戳（Long.MAX_VALUE - 时间戳）然后附加上用户ID来构成行健。现在你基于用户ID扫描紧邻的n行就可以找到用户需要的n条最新推帖。这里行健的结构对于读性能很重要。把用户ID放在开头有助于你设置扫描，可以轻松定义起始键。

4. HBase的RowKey设计应用实例

4.1 设计订单状态表

设计模式：反转+时间戳反转

RowKey：reverser(order_id) + (Long.MAX_VALUE - timestamp)

这样设计的好处一是通过reverse订单号避免Region热点，二是可以按时间倒排显示，可以获取到最新的订单。

同样适用于需要保存一个用户的操作记录，按照操作时间倒序排序。设计的rowKey为：reverser(userId) + (Long.MAX_VALUE - timestamp)。如果需要查询某段时间的操作记录，startRow是[userId反转][Long.MAX_VALUE - 起始时间]，stopRow是[userId反转][Long.MAX_VALUE - 结束时间]。

4.2 登录、下单等等统称事件(event)的临时存储

HBase只存储了最近10分钟的热数据

设计模式：salt加盐

RowKey：两位随机数Salt + eventId + Date + kafka的Offset

这样设计的好处是：设计加盐的目的是为了增加查询的并发性，假如Salt的范围是0~n，那我们在查询的时候，可以将数据分为n个split同时做scan操作。经过我们的多次测试验证，增加并发度能够将整体的查询速度提升5~20倍以上。随后的eventId和Date是用来做范围Scan来使用的。在我们的查询场景中，大部分都是指定了eventId的，因此我们在eventId放在了第二个位置上，同时呢，通过Salt + eventId的方式可以保证不会形成热点。把date放在RowKey的第三个位置上可以实现date做scan，批量Scan性能甚至可以做到毫秒级返回。

这样的RowKey设计能够很好的支持如下几个查询场景：

全表scan。在这种情况下，我们仍然可以将全表数据切分成n份并发查询，从而实现查询的实时响应。
只按照event_id查询。
按照event_id和date查询。

5. HBase表设计关注点

HBase表设计通常可以是宽表（wide table）模式，即一行包括很多列。同样的信息也可以用高表（tall table）形式存储，通常高表的性能比宽表要高出50%以上，所以推荐大家使用高表来完成表设计。表设计时，我们也应该要考虑HBase数据库的一些特性：

在HBase表中是通过RowKey的字典序来进行数据排序的。
所有存储在HBase表中的数据都是二进制的字节。
原子性只在行内保证，HBase不支持跨行事务。
列簇（Column Family）在表创建之前就要定义好
列簇中的列标识（Column Qualifier）可以在表创建完以后动态插入数据时添加。

总结

参考资料：

《HBase实战》

https://www.cnblogs.com/parent-absent-son/p/10200202.html

https://blog.csdn.net/wangshuminjava/article/details/80575864

https://www.cnblogs.com/yuguoshuo/p/6265649.html

HBase RowKey设计模式