深度研究hbase的热点问题,和hbase 表rk的设计 和手动分区region

2019/2/20 星期三

深度研究hbase的热点问题,和hbase 表rk的设计 和手动分区region
在2019/1/25 星期五记录
hbase的热点问题:
hbase热点问题解决(预分区) https://blog.csdn.net/qq_31289187/article/details/80869906
Hbase split的三种方式和split的过程 https://www.cnblogs.com/niurougan/p/3976519.html

082 HBase的几种调优(GC策略,flush,compact,split)http://www.cnblogs.com/juncaoit/p/6170642.html
这上面讲解了这些,hbase 命令的使用
081 Region的预分区 https://www.cnblogs.com/juncaoit/p/6170510.html 的4中方法

—————————————————————————————————————————————————
什么是hbase的热点问题
出现热点问题原因
1、hbase的中的数据是按照字典序排序的,当大量连续的rowkey集中写在个别的region,各个region之间数据分布不均衡;
2、创建表时没有提前预分区,创建的表默认只有一个region,大量的数据写入当前region;
3、创建表已经提前预分区,但是设计的rowkey没有规律可循,设计的rowkey应该由regionNo+messageId组成。

如何解决热点问题
解决这个问题,关键是要设计出可以让数据分布均匀的rowkey,与关系型数据库一样,rowkey是用来检索记录的主键。访问hbase table中的行,rowkey 可以是任意字符串(最大长度 是 64KB,实际应用中长度一般为 10-100bytes),在hbase内部,rowkey保存为字节数组,存储时,数据按照rowkey的字典序排序存储。

创建表命令:
create ‘testTable’,{NAME => ‘cf’, DATA_BLOCK_ENCODING => ‘NONE’, BLOOMFILTER => ‘ROW’, REPLICATION_SCOPE=> ‘0’, VERSIONS => ‘1’, COMPRESSION => ‘snappy’, MIN_VERSIONS =>’0′, TTL => ‘15552000’, KEEP_DELETED_CELLS => ‘false’, BLOCKSIZE =>’65536′, IN_MEMORY => ‘false’, BLOCKCACHE => ‘true’, METADATA =>{‘ENCODE_ON_DISK’ => ‘true’}},{SPLITS_FILE=>’/app/soft/test/region.txt’}

https://blog.csdn.net/weixin_41279060/article/details/78855679 hbase系列-Hbase热点问题、数据倾斜和rowkey的散列设计

预分区和rowkey的散列设计——解决数据倾斜和热点问题
预分区,让表的数据可以均衡的分散在集群中,而不是默认只有一个region分布在集群的一个节点上。(预分区个数=节点的倍数,看数据量估算,region不足了会被分列,预分区后每个region的rowkey还是有序的)

如何给hbase表预分区
HBase预分区方法 https://www.cnblogs.com/quchunhui/p/7543385.html *****
Hbase 表的设计原则 ————总结 https://blog.csdn.net/m0_37138008/article/details/78985946

行键(RowKey)设计

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


预分区和rowkey的散列设计——解决数据倾斜和热点问题
预分区
预分区,让表的数据可以均衡的分散在集群中,而不是默认只有一个region分布在集群的一个节点上。(预分区个数=节点的倍数,看数据量估算,region不足了会被分列,预分区后每个region的rowkey还是有序的)
一个RegionServer能管理10-1000个Region,0.92.x版本后,默认的Region大小为10G,向下可以支持256MB,向上可以支持到20G,也就是说,每个RegionServer能管理的数据量为2.5GB-20TB。
如果有5个节点,3年内数据量为5T,那么分区数可以预设为:
5000G/10G=500个region
这500个Region就会被均衡的分布在集群各个节点上(具体分布看机器的性能和存储空间而定),机器硬盘不足可以添加硬盘,性能不足可以添加新节点(添加新机器)。
Rowkey长度原则(最好不超过16字节)
Rowkey是一个二进制码流,Rowkey的长度被很多开发者建议说设计在10~100个字节,不过建议是越短越好,不要超过16个字节。
原因如下:
(1)数据的持久化文件HFile中是按照KeyValue存储的,如果Rowkey过长比如100个字节,1000万列数据光Rowkey就要占用100*1000万=10亿个字节,将近1G数据,这会极大影响HFile的存储效率;
(2)MemStore将缓存部分数据到内存,如果Rowkey字段过长内存的有效利用率会降低,系统将无法缓存更多的数据,这会降低检索效率。因此Rowkey的字节长度越短越好。
(3)目前操作系统是都是64位系统,内存8字节对齐。控制在16个字节,8字节的整数倍利用操作系统的最佳特性。

rowkey散列原则
把主键哈希后当成rowkey的头部

rowkey唯一原则
必须在设计上保证其唯一性,rowkey是按照字典顺序排序存储的,因此,设计rowkey的时候,要充分利用这个排序的特点,将经常读取的数据存储到一块,将最近可能会被访问的数据放到一块。
时间戳反转
如果数据需要保留多个版本,可以使用反转的时间戳作为rowkey的一部分,用 Long.Max_Value – timestamp 追加到key的末尾,例如 [key][reverse_timestamp] , [key] 的最新值可以通过scan [key]获得[key]的第一条记录,因为HBase中rowkey是有序的,第一条记录是最后录入的数据。

整个rowkey(timestamp并不是必要的,视业务而定)
rowkey=哈希(主键<递增的id/手机号码等>)+Long.Max_Value – timestamp


作者:boat824109722
来源:CSDN
原文:https://blog.csdn.net/weixin_41279060/article/details/78855679
版权声明:本文为博主原创文章,转载请附上博文链接!

rk设计小结1:
1、首先先规划hbase表的大小,计算规划出合理的region数
2、rk长度设计(最好不超过16字节)
3、rk散列原则(把主键哈希后当成rk的头部,这里的散列理解为前缀指派的随机数添加到rk前面)
4、rk唯一原则(将经常读取的数据放在一起,将最近可能被访问的数据放在一个块)
5、版本数为3合理,如果过期数据不是很重要的话。

行键rk的设计小结2:
设计行键时应该使得数据尽量同时往多个region上写,而避免只向一个region写(避免hbase的热点问题),可用用前缀指派的随机数添加到rk的前面,这样就可以分散到不同的region中(salting),使用了顺序的key会将本没有顺序的数据变得有顺序,把负载压在一台机器上。所以要尽量避免时间戳或者序列(e.g. 1, 2, 3)这样的行键。(减少单调递增行键/时序数据)。

表模式经验法则
1、region规模大小在10到50GB之间;
2、单元的大小不要超过10MB,如果使用 Object Store(在下面介绍) ,可放宽到50MB;不然,可以考虑将单元数据存在HDFS中,或者在HBase中存一个指向这些数据的指针;
3、一个典型的模式每个表中含有1~3个列族
4、对于只有1~2个列族的表,50到100个region是一个比较合适的数量。需要提醒的是,每个region都是列族的一个连续段;
5、列族的名字越短越好,因为对每个值(忽略前缀编码, prefix encoding ),列族名都会存一次。它们不应当像典型RDNMS一样自记录( self-documenting ) 和描述。
6、如果在基于时间的机器上存储数据或日志信息,行键(Row Key)是由设备ID或服务器ID加上时间得到的,那最后能得到这样的模式:除了某个特定的时间段,旧的数据region没有额外的写。在这种情况下,得到的是少量的活跃region和大量的没有新写入的旧region。这时由于资源消耗仅来自于活跃的region,大量的region能被容纳接受;

大部分时候,细微的低效不会影响很大。但不幸的是,在这里却不能忽略。无论是列族、属性和行键都会在数据中重复上亿次。
1、列族:尽量使列族名小,最好一个字符。(如 "d" 表示 data/default).
2、属性:详细属性名 (如, "myVeryImportantAttribute") 易读,最好还是用短属性名 (e.g., "via") 保存到HBase.
3、行键长度:让行键短到可读即可,这样对获取数据有帮助(e.g., Get vs. Scan)。短键对访问数据无用,并不比长键对get/scan更好。设计行键需要权衡。
4、字节模式:long类型有8字节。8字节内可以保存无符号数字到18,446,744,073,709,551,615。 如果用字符串保存——假设一个字节一个字符——需要将近3倍的字节数。

行键永远不变:行键不能改变。唯一可以“改变”的方式是删除然后再插入。这是一个常问问题,所以要注意开始就要让行键正确(且/或在插入很多数据之前)。

原创文章,作者:3628473679,如若转载,请注明出处:https://blog.ytso.com/186961.html

(0)
上一篇 2021年11月4日
下一篇 2021年11月4日

相关推荐

发表回复

登录后才能评论