hbase积累
细节点
1.Rowkey设计原则
1.1 长度原则 rowkey 在hbase以二进制码流,可以是任意字符串,
最大长度是64kb,实际应用主要是100~100bytes
长度尽量为8的整数倍,因为现在的系统主要是64位,内存8字节对齐.控制在16字节,符合操作系统特性
1.2 散列原则:因为hbase是分布式存储,rowkey的高位尽量是散列字段,散列性弱的尽量放在低位段.如Time AND Device_id的组合,相对而言device_id 应该量级较小,散列性高.而TIME散列性低,如果TIME放在高位,可能造成数据在某个RegeionServer上堆积的情况.所以较合理的rowkey组合应是
device_id+time.
1.3 RowKey唯一原则：必须在设计上保证其唯一性.
hbase 中以KeyValue形式存储,key若重复,行内容则会被覆盖.
2.Hbase的Regeion热点问题解决
因为在创建表是没有提前预分区,创建的表默认就只会有一个region,这个region的rowkey是没有边界的,即没有startkey与stopkey.数据在写入时,都会写入到这个region.随着数据的不断增加,达到某个阈值时,才会split成2个region.在这个过程中就会产生所有数据囤积在一个regionServer上,出现热点问题.另在split时,会占用集群的I/O资源.通过预分区可以解决该问题
2.1 预分区
预分区,”预”字是核心.我们在建表时,预先对表中要存放的数据形式和可能的量级,心中必然会有所估量,即这里应预估数据量.若数据量较大,则在建表时又应该预分区.即根据数据形式,量级,事先预设好一定量的region,后面数据写入时,则会写入到相应的分区.从而避免热点,减少split.
2.1.2 salting(加盐)
hbase rowkey设计,避免热点,常会用到该操作,这里的加盐本身不是加密操作,而是在原数据前加入一些随机数据,从而起到分散不同region的作用.
2.1.3 预习区具体方案
hbase预分区的相关操作,如shell形式,可直接在hbase shell
操作.如
[https://blog.csdn.net/xiao_jun_0820/article/details/24419793](Hbase shell 预分区操作.)
java形式
[https://blog.csdn.net/qq_20641565/article/details/56482407](Hbase 预分区 java API形式)
以上操作形式有个问题就是rowkey是随机生成的,虽起到了散列存储,避免了热点堆积,但因为加盐的缘故,想要直接的获取某行数据较为困难.若针对的是高频使用的数据,则会出现问题.
2.1.4 hash分区
在原先预分区的基础上,通过相关规则将原数据hash,从而获得这个原数据对应在哪个分区,使当拿到相关原数据,就能推演出相关rowkey.从而能准确的get数据.
hbase优化
确定优化目标
沟通交流后，业务方更看重降低成本。数据量梳理后略有降低，保证吞吐，无长期请求堆积前提下可以放宽延时要求。为了更快的进行优化，放宽稳定性可以要求接受短期波动。
另外，该分组的RegionServer之前存在不稳定的问题，这次优化也一并解决。
