HBase的RowKey设计原则含案例(全)

前言

HBase的RowKey的行由行键按字典顺序排序，这样的设计优化了扫描，允许存储相关的行或者那些将被一起读的邻近的行。然而，设计不好的行键是导致 hotspotting 的常见原因。当大量的客户端流量（ traffic ）被定向在集群上的一个或几个节点时，就会发生 hotspotting。这些流量可能代表着读、写或其他操作。流量超过了承载该地域的单个机器所能负荷的量，这就会导致性能下降并有可能造成地域的不可用。在同一 RegionServer 上的其他地域也可能会受到其不良影响，因为主机无法提供服务所请求的负载。设计使集群能被充分均匀地使用的数据访问模式是至关重要的。

为了防止在写操作时出现hotspotting，设计行键时应该使得数据尽量同时往多个RegionServer 上写，而避免只向一个RegionServer 写，除非那些行真的有必要写在一个RegionServer 里。HBase的排序问题按字典序rowkey排序,从小到大,如果任务为了获得最新的时间数据可用用时间戳反转,或者用long.maxvalue - timestamp

设计原则

按照  散列 唯一  长度 顺序

散列

散列和预分区可以放在一起 比如预先分10个region  减少热点问题

可以将id %10 做开头 但是如果id规律性强的话 可以用(id+年月日)%10

唯一

必须在设计上保证其唯一性，rowkey是按照字典顺序排序存储的，

因此，设计rowkey的时候，要充分利用这个排序的特点，可以将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。

可以用时间戳放在其中 hbase是按字典序排序 要考虑一直单分区写情况

长度

rowkey作为二进制码流最大为64kb 最好不要超过16个字节 设计过长会占memstore空间

顺序 

HBase的rowkey安装字典序顺序排列 从小到大,所以需要最新数据时需要翻转时间戳或者自增id    

可枚举属性值较少的属性放在rowkey前面

rowkey是由多个字段组合而成，这多个字段的先后次序和访问的效率有直接的关系。一个普遍的规则是：数量较少，可控的字段放在rowkey靠前位置（如eengine_type，provinc等）；反之放在后面（如vin,timestamp等）。这样做的原因是可控属性放在前面，对各种不同查询需求的平衡性强一些，反之平衡性较差。

案例1：

YCK09360-60-1638290481900-9011D6L00124    434.7

YCK09360-60-1638290482900-9011D6L00124    76.1

YCK09360-60-1638290483900-9011D6L00124    18.6

YCK09360-60-1638290484900-9011D6L00124    150.1

YCK09360-60-1638290485900-9011D6L00124    96.1

YCK09360-60-1638290586900-9011D6L00124    35.7

ENGINE_TYPE 可枚举，并且数量较少，放在前面；而vin确很多，因此放在后面。这样的设计能够适应如下两种需求，复杂度都比较小：

1） 查询,某段时间内 YCK09360-60的所有数据。这种需求设置scan的startrow=‘YCK09360-60_时间戳’，endrow=‘YCK09360-60_时间戳’，即可。

2） 查询某段时间内的所有9011D6L00124 的数据。这种需求下，根据scan rowkey连续的原则，这种需求设置scan的startrow=‘YCK09360-60_时间戳_9011D6L00124 ’，endrow=‘YCK09360-60_时间戳_9011D6L00124 ’，即可。

但是，如果将vin放在前面，如下所示，适应性就差一些，如下所示案例2：

9011D6L00124-YCK09360-60-1638290481900    434.7

9011D6L00124-YCK09360-60-1638290482900    76.1

9011D6L00124-YCK09360-60-1638290483900    18.6

9011D6L00124-YCK09360-60-1638290484900    150.1

9011D6L00124-YCK09360-60-1638290485900    96.1

9011D6L00124-YCK09360-60-1638290586900    35.7

1）查询某段时间内的所有9011D6L00124 的数据。这种需求下，设置scan的startrow=‘9011D6L00124-YCK09360-60-时间戳，endrow=‘9011D6L00124-YCK09360-60-时间戳’，即可。

2） 查询某段时间内 YCK09360-60的所有数据。这种需求设置scan是要取的YCK09360-60小所有的vin号并放在rowkey的最前段,启动多个scan 去扫描多组数据

HBase的rowkey安装字典序顺序排列 从小到大,所以需要最新数据时需要翻转时间戳或者自增id  ,所以在使用时间戳字段是最好是使用long.maxvalue-timestamp/1000 ,这样保证最新的数据总是在较新的位置,方便读取

预分区的设置也是由必要的,防止数据热点问题.,可以使用hash取余的方式去关键分区字段,保证了分区均匀性

所以最后设计的方案

分区字段-标识字段-标识字段-long.maxvalue-timestamp

其他我觉得有意义的点

减少列族及减少数据存储的开销,必要时减少限定符 ,直接将数据写成单独一条,其余处理代码中进行分割. 

在HBase中，value永远和它的key一起传输的。当具体的值在系统间传输时，它的rowkey，列名，时间戳也会一起传输。如果你的rowkey和列名很大，HBase storefiles中的索引（有助于随机访问）会占据HBase分配的大量内存，因为具体的值和它的key很大。可以增加block大小使得storefiles索引再更大的时间间隔增加，或者修改表的模式以减小rowkey和列名的大小。压缩也有助于更大的索引。

控制rowkey在16个字节以下 并维持在8的整数倍,符合64位系统的8字节对齐 ,最大不要超过64位

业务访问中权重高的key放在前面

例如URLRecords表的主要用途是用来计算当天的URL访问排名。根据业务需求，需要访问某天的所有URL，因此date是主键，权重更高，放在前面，而URL则放在后面。

构造冗余数据

例如，percontent的数据包含了URL Records的数据，URL Records的数据是冗余存储的，区别在于percontent的URL放在date前面，而URL Records表的URL放在date后面。这就是由于URL在满足不同需求的时候，权重不同，由于URL Records需要的数据量不大，因此采用冗余的机制解决该矛盾。权衡需求的重要性和系统忍受度选择一种方案当两种需求有矛盾，但其中一方属于次要需求，并且在系统忍受度范围之内的话，可以舍弃一种方案。优先满足需求更强的一方

Rowkey的时间属性问题

循环key使用（1）存在问题如果rowkey中有时间属性，并且随着时间的增加，rowkey会不断的增大下去的话，会造成region数量不断地增加。如果使用TTL来控制数据的生命周期，一些老的数据就会过期，进而导致老的region数据量会逐渐减少甚至成为空的region。这样一方面region总数在不断增加，另外一方面老的region在不断的成为空的region，而空的region不会自动合并，进而造成过多空的region占用负载和内存消耗的情况。（2）解决办法这种情况下，可以使用循环key的方法来解决。思路是根据数据的生命周期设定rowkey的循环周期，当一个周期过去以后，通过时间映射的方法，继续使用老的过期数据的rowkey。例如，key的格式如下：YY-MM-DD-URL。如果数据的生命周期是一年，则可以使用MM-DD-URL的格式。这样当前一年过去以后，数据已经老化，后一年的数据可以继续写入前一年的位置，使用前一年数据的rowkey。这样可以避免空的region占用资源的情况。

根据hbase的原理，key的周期需要至少比TTL大2* hbase.hregion.majorcompaction（默认24小时）的时间，才能够保证过期的数据能够在key循环回来之前得到完全清理。按照时间周期进行建表的方式也可以解决空region的问题，和循环key方法相比较，循环key的优点如下：

操作简单，不需要重复建表，系统自动处理

同样，循环key具有如下劣势：

需要使用TTL来老化数据，可能会增加compact负担

需要保证查询操作不会查询到过期数据，否则会影响系统性能。

如果在系统压力不是特别大，需要长期运行，能够控制查询不会查询到过期数据的场景下，建议使用TTL+循环key的方式，否则建议使用按照时间周期进行建表的方式。

通过rowkey设计来控制并发度

在相同业务模式下，不同的rowkey设计系统的并发度不一样。和按天建表的思路类似，通过rowkey控制并发度的原则是激活的region总数适中，每个regionserver的激活Region数大于1，小于（写操作内存/flushsize）为宜。

为了实现这一点，可以将可枚举、数量有限的属性放在rowkey的前面，时间放在后面的方式来提高并发度；通过将大粒度的时间属性（如天、小时等）放在rowkey前面，数量很大的可枚举属性（如电话号码、URL等）放在后面的方法来控制激活的region数。

 电信手机行业案例

案例一

xx_yy_zz_时间戳

xx为分区字段 必须散列

yy 和zz为标识查询字段  若可枚举按照字段枚举个数从小到大 方便查询

时间戳为最好查询字段标识

若表的用途是为了统计当天数据 可以将年月日放入rowkey 并排在yy之前

场景题

使用场景:

电信案例:查询某个人(手机号)某年[某月某日](时间)的通话详情。

1) 预分区

(1) 评估未来半年到一年的数据增长,不让其自动分区(10G)

    (2) 确定分区键

    00| 01| 02| ...

    000| 001| ...

2) 设计RowKey

(1) 确定分区号   (散列性)

    00_ 01_ 02_...

​

手机号%分区数            不够散列

(手机号+年月日)%分区数   按照月份、年进行查询  不方便

    (手机号+年月)%分区数

(2) 拼接字段     (唯一性、长度)

    XX_手机号_时间戳

    XX_手机号_年月日 时分秒

    XX_时间戳_手机号

    XX_年月日 时分秒_手机号

(3) 校验

    13412341234 2021-09-07

    XX_手机号_年月日 时分秒

    startRow:05_13412341234_2021-09-07

    stopRow :05_13412341234_2021-09-08

            05_13412341234_2021-09-07|

    XX_年月日 时分秒_手机号

    startRow:05_2021-09-07 00:00:00_13412341234

    stopRow :05_2021-09-08 00:00:00_13412341234

​

13412341234 2021-09  2021-11

XX_手机号_年月日 时分秒

    startRow:05_13412341234_2021-09

    stopRow :05_13412341234_2021-09|

            05_13412341234_2021-10

​

    startRow:03_13412341234_2021-10

    stopRow :03_13412341234_2021-11

​

    startRow:04_13412341234_2021-11

    stopRow :04_13412341234_2021-12