Hbase13：HBase 调优策略

最新推荐文章于 2023-10-12 09:06:04 发布

做一个有趣的人Zz

最新推荐文章于 2023-10-12 09:06:04 发布

阅读量996

点赞数

分类专栏： hbase 文章标签： hadoop hive hbase

本文链接：https://blog.csdn.net/weixin_40612128/article/details/123282368

版权

hbase 专栏收录该内容

14 篇文章 3 订阅

订阅专栏

一、预分区

HBase默认新建的表中只有一个Region，这个Region的Rowkey是没有边界的，即没有startRowkey和endRowkey，在数据写入时，所有数据都会写入这个默认的Region

随着数据量的不断增加，此Region已经不能承受不断增长的数据量，会进行Split，分裂成2个Region。
在这个过程中，会产生两个问题：

1、数据往一个Region上写,会有写热点问题。
2、Region split会消耗宝贵的集群IO资源。

基于此我们可以控制在建表的时候，创建多个空Region，并确定每个Region的起始和终止Rowkey，这样只要我们设计的Rowkey能均匀的命中各个Region，就不会存在写热点问题。Region分裂的几率也会大大降低。当然随着数据量的不断增长，该分裂还是要进行分裂的。

像这种预先给HBase表创建多个Region的方式，称之为预分区。

hbase(main):001:0> create 't20', 'c1', SPLITS => ['10', '20', '30', '40']
Created table t20
Took 3.3741 seconds                                                   
=> Hbase::Table - t20

到HBase的界面中查看这个表的region信息

http://bigdata01:16010/

在这里插入图片描述

通过这个图可以看出来，此时创建的这个表会提前创建多个Region。

默认情况下创建的表是只有1个Region的。
以表t1为例：
在这里插入图片描述

二、RowKey的设计原则

1、Rowkey长度原则

Rowkey底层存储是一个二进制流，可以是任意字符串，最大长度 64kb ，实际应用中一般是10-100字节，以 byte[] 形式保存，一般设计为定长。
建议越短越好，不要超过16个字节，原因如下：

1、数据的持久化文件HFile中是按照KeyValue存储的，如果Rowkey过长，比如超过100字节，1000w行数据，Rowkey就要占用100*1000w=10亿字节，将近1G数据，这样会极大影响HFile的存储效率；

2、MemStore会缓存部分数据到内存，如果Rowkey字段过长，内存的有效利用率就会降低，系统不能缓存更多的数据，这样会降低检索效率。

3、目前操作系统都是64位系统，内存8字节对齐，控制在16个字节，8字节的整数倍利用了操作系统的最佳特性

2、Rowkey散列原则

Rowkey散列原则，主要是为了避免数据热点问题。

虽然我们可以在建表的时候提前设计预分区，但是假设数据的Rowkey都是手机号，那么都是1开头，按照前面的设计，那么所有的数据都会写到10-20之间的Region中，仍然没有做到负载均衡。

如何保证我们的数据能够均匀的分布到预先设计好的分区中呢？
解决思路（以手机号为例）：

1、手机号反转，将手机号的最后一位前置，这样第一位就是0-9之间的任意一个数字了。

2、按照一定规则使用hashCode获取余数，拼在手机号前面。
例如：根据手机号后四位使用hashCode获取余数。这里的规则一定要是可以反推出来的，这样后期还可以根据这个规则找到对应的手机号，尽量不要使用随机数。

3、Rowkey唯一性原则

必须在设计上保证其唯一性，因为Rowkey相同则会覆盖。

Rowkey是HBase里面唯一的索引,对于某些查询频繁的限定条件可以把它的内容存放在Rowkey里面，提高查询效率。

例如：需要经常使用姓名和年龄这两个字段进行查询，那么可以考虑把姓名和年龄拼接到一块作为Rowkey。

三、列族的设计原则

在设计列族的时候，建议把经常读取的字段存储到一个列族中，不经常读取的字段放到另一个列族中。

这样在读取部分数据的时候，就只需要读取一个列族文件即可，可以提高读取效率。

四、批量处理

Table.get(Get)方法可以根据一个指定的Rowkey获取一行记录，同样HBase提供了另一个方法：通过调用Table.get(List)方法可以根据一个指定的Rowkey列表，批量获取多行记录，这样做的好处是批量执行，只需要一次网络IO开销，这样可以带来明显的性能提升。

同理 Table.delete(List) 和 Table.put(List)

如果一次操作的数据量不是特别多，例如：100~1000条左右的数据量，可以考虑这种方式。

如果是一次需要批量操作上千万的数据，建议使用前面讲的批量导入导出方法，效率更高。

五、Region的request计数

HBase UI界面table Regions中的Requests参数值
这个参数的意义在于，可以分析哪个Region被频繁请求，是否存在读写热点的问题。

注意：HBase集群重启之后，Requests参数值会被清空。

以student表为例：
在这里插入图片描述

六、HBase核心参数优化

1、hbase.hregion.majorcompaction

配置大合并的间隔时间，默认为604800000毫秒(7天)，可设置为0，禁止自动的大合并，大合并的执行可能会持续数小时，为减少对业务的影响，建议在业务低峰期进行手动或者通过脚本或者API定期进行大合并。

2、hbase.hregion.max.filesize

默认为10737418240 Byte(10G)，当Region达到这个阈值时，会自动分裂。Region分裂会有短暂的Region下线时间(通常在5s以内)，为减少对业务端的影响，建议调大该值，并在业务低峰期定时手动进行分裂。

3、hbase.regionserver.handler.count

默认30，对于大负载的Put（达到了M范围）或是大范围的Scan操作，handler数目不易过大，易造成OOM（内存溢出）。对于小负载的put、get，delete等操作，handler数要适当调大。handler属于一个处理器，实现底层数据的发送。

4、hbase.hregion.memstore.flush.size

默认值134217728 Byte (128M)，单位字节，这个参数是Memstore中数据持久化到Storefile的时机，超过该阈值，则会把Memstore中的数据持久化到Storefile中，如果Regionserver的JVM内存比较充足(例如：16G以上)，可以适当调大该值，例如：调整为256M。这样可以减少Memstore中数据溢写文件的次数。

5、hbase.hregion.memstore.block.multiplier

默认值4，如果一个Memstore的内存大小已经超过hbase.hregion.memstore.flush.size * hbase.hregion.memstore.block.multiplier，则会阻塞该Memstore的写操作，为避免阻塞，可以适当调大，例如6~8，但如果太大，则会有OOM的风险。如果在Regionserver日志中出现"Blocking updates for ‘’ on region : memstore size <多少M> is >= than blocking <多少M> size"的信息时，说明这个值该调整了。