#### 前言
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