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.7YCK09360-60-1638290482900-9011D6L00124    76.1YCK09360-60-1638290483900-9011D6L00124    18.6YCK09360-60-1638290484900-9011D6L00124    150.1YCK09360-60-1638290485900-9011D6L00124    96.1YCK09360-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.79011D6L00124-YCK09360-60-1638290482900    76.19011D6L00124-YCK09360-60-1638290483900    18.69011D6L00124-YCK09360-60-1638290484900    150.19011D6L00124-YCK09360-60-1638290485900    96.19011D6L00124-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-07XX_手机号_年月日 时分秒startRow:05_13412341234_2021-09-07stopRow :05_13412341234_2021-09-0805_13412341234_2021-09-07|XX_年月日 时分秒_手机号startRow:05_2021-09-07 00:00:00_13412341234stopRow :05_2021-09-08 00:00:00_13412341234​13412341234 2021-09  2021-11XX_手机号_年月日 时分秒startRow:05_13412341234_2021-09stopRow :05_13412341234_2021-09|05_13412341234_2021-10​startRow:03_13412341234_2021-10stopRow :03_13412341234_2021-11​startRow:04_13412341234_2021-11stopRow :04_13412341234_2021-12