HBase之RowKey设计

HBase

工作中一直有使用到HBase，但是却一直没有好好的总结整理过，最近换工作过程中，经常会被问到HBase相关的知识（裸面被鞭打的惨不忍睹啊），在回顾、准备面试的同时，也借此机会记录一下，希望能够在帮助自己记忆理解的同时，可以方便大家！

HBase rowkey即是HBase的主键，HBase数据的查询，主要是基于rowkey进行，无论是通过rowkey进行唯一查询还是通过范围匹配查询，都是基于rowkey来实现，因此rowkey的设计就显得尤为重要。

HBase的存储

要介绍HBase rowkey的设计，还是应该要大概的了解下HBase的存储机制，这样可以更好的理解HBase rowkey设计原则。
HBase数据是按照rowkey字典排序存储的，因此相同前缀的rowkey（例如：1588610367312、1588610367334）大概率会紧密相连接，而HBase的数据是存储在region server内的region上，而region可以理解为是对HBase数据按行切割出来的分片，那么上面举例的rowkey对应的数据就会在同一个region里。那么如果有大量相连接rowkey的数据要写入HBase，或者有大量的相似rowkey查询请求就会请求到相同的region上，会带来很大的压力，那么应该怎么办呢？我们先来看下rowkey的设计原则，后面再回过头来看这个问题。

RowKey设计原则

RowKey设计主要有以下几个原则：

1. rowkey唯一原则，HBase通过rowkey来唯一确定一行数据，相当于关系型数据库的主键，因此要保证rowkey唯一，在写入（put）操作中，如果使用已经存在的rowkey，会更新相同rowkey的相应字段，可以简单理解类似HashMap对于同一个key进行覆盖操作。
2. 长度原则，HBase rowkey存储本质是二进制码流，可以是任意的字符串，最长为64kb，实际使用中通常为10-100byte，不建议太长，官方建议越短越好，最好不超过16字节。
   rowkey设计的太长的话，会影响memStore和HFile的存储效率。rowkey太长，会占用数据的空间。memStore相当于数据的内存缓存，如果rowkey太长，则会占据太多的缓存空间，导致缓存数据量减少，无论读写，都是降低效率。对于HFile来说，存储的是key-value数据，如果rowkey太长，会占用HFile中大量的空间，降低HFile的存储率，存储数据量减少。
3. 散列原则，由于HBase数据的存储会根据rowkey进行字典排序，如果使用时间戳当做rowkey的话，那么就会把所有的数据连续的存储到一起（或者说同一个region上），增大了regionserver的负载，降低效率，会出现上面说到的问题，热读或者热写，因此在设计rowkey的时候，要考虑散列原则，在rowkey的高位设计，尽量让数据均匀的分布到集群的不同region server上。

热点问题

热点问题是比较常见的问题，无论是热读还是热写，都是会遇到的，因此rowkey设计的重要性就体现出来了，那么怎样来避免热点问题呢？其实就是我们rowkey设计原则的散列原则，下面看几个常用的散列方法：
（1）加盐
加盐和我们密码学中的加盐是不同的，此处主要使用随机数（比如使用00-99的随机数）作为rowkey的前缀，这昂就会把不同的数据通过前缀的随机数将数据打散，同时因为前缀规则比较明确，可以再配合预分区（预分00-99,100个分区），就可以把数据比较均匀的分布到regionserver中。但是此方式也有缺点，数据虽然是比较分散，但是也因为随机前缀，将rowkey的排序规则打乱，在查询的时候，相当于要去匹配各个region上的数据。
（2）哈希
哈希是可以通过对rowkey或者部分rowkey进行哈希，然后将哈希后的数据放到rowkey前缀或者替换rowkey，此方式可以把数据打散，同时查询时可以通过相同的哈希算法将rowkey得到，但是也打乱了rowkey的排序，因此scan可能会有影响。
（3）反转
反转针对比如手机号这样的数据，后几位是比较随机的，所以可以考虑把手机号反转来当做rowkey，这样会把数据相对分散，但是同样的rowkey排序也被打乱，但是可以通过rowkey get查询比较方便。

rowkey的设计原则和常见散列方式大概介绍这些，有问题还希望大家指出，同样后面有其他的想法也会再补充进来。