Hbase调优

人生有如两个橘子

已于 2024-09-09 17:13:20 修改

阅读量437

点赞数 2

分类专栏： hbase 文章标签： hbase 数据库大数据

于 2019-10-18 17:16:34 首次发布

本文链接：https://blog.csdn.net/qq_37706484/article/details/102619714

版权

hbase 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

架构图来一张：

HBaseæ¶æ

I am client：GO

大量数据通过client开始写入Hbase，作为一个有经验的程序员，此时我们应该有想到批量提交，设置为8M好了。

hbase.client.write.buffer = 2097152 #默认2M。hbase客户端每次写缓冲的大小(客户端批量提交到服务端)，会同时占用客户端和服务端，缓冲区更大可以减少RPC次数，但是更大意味着内存占用更多

既然是大量数据，也不能串行提交，所以强迫Hbase并行接受

hbase.regionserver.handler.count = 30 #默认开启的RPC监控实例数，即能够处理的IO请求线程数

经过客户端提交，数据提交到Hbase，Hbase中间吧啦吧啦一顿协调操作，最终由一个RegionServer来写数据

首先，数据第一次被写到HLog以防止丢失，HLog是Write ahead log，用于数据的容错和恢复，并且整个RS只有一个HLog对象，当HLog达到上限会触发MemStore的flush大风暴，因此我们把值设置的大一点。512M好了，不要过大，否则重启的时候RS慢的要死。

hbase.regionserver.maxlogs = 32
hbase.regionserver.hlog.blocksize = 536870912 #hdfs配置的block大小,128M

RS中有好多HRegion，看着都累，所以设置个上限值

hbase.regionserver.regionSplitLimit = 2000 #HRegionServer上的region数达到这个限制时，不会进行split切分

RS会在众多HRegion中找到正确的HRegion(每个HRegion对应表水平切分后的一部分，即一个切片)，每个HRegion里包含了好多Store(每个Store对应一个列族，这些Store是建表时就决定的)，最终数据会被分析拆解，找到各自对应的Store，每个Store里有一个MemStore内存，数据会被第二次写入MemStore里。这里需要注意一个RegionServer里会有好多MemStore，所以我们设置下全局MemStore内存的大小，内存优化等，

#regionServer的全局memstore的大小，超过该大小会触发flush到磁盘的操作,默认是堆大小的40%,
#而且regionserver级别的flush会阻塞客户端读写
hbase.regionserver.global.memstore.upperLimit = 0.4
hbase.regionserver.global.memstore.size = 0.4

hbase.hregion.memstore.mslab.enabled = true #有效减少在高并发写时候的内存碎片

至此，数据已经完成了一次批量写入。后续批次以此类推，随着时间增加，RS中某个HRegion中的MemStore内存也会越写越大，当然不可能一直在内存里不释放，所以会执行flush落盘操作，当达到一定值会触发flush操作，不会阻塞写入，默认值为128M，但是数据有可能写的很快超过该值，所以我们设置个上限，这里通过倍数来控制，当达到上限也会触发flush，且会阻塞写入。不管哪种flush都是针对整个Region进行的操作。

#单个HRegion上的memstore的大小满足multiplier * size时,这个HRegion会执行flush操作并阻塞对该HRegion的写入
hbase.hregion.memstore.block.multiplier = 8 #单个HRegion里memstore的缓存上限倍数
hbase.hregion.memstore.flush.size = 134217728 #单个HRegion里memstore的缓存大小，默认128M

由于一个RS里有很多HRegion，所以在大量写的时候也会有大量的flush操作，所以设置flush线程数

hbase.hstore.flusher.count = 8 #执行flush操作的线程数,设置小了刷新操作会排队，大了会增加底层hdfs的负载压力

既然flush是落盘，必然会生成文件，既然在Store里，就叫StoreFile，因为Hbase最终数据是存到HDFS，所以StoreFile经过处理落到HDFS的文件，就叫HFile。因为默认128M触发flush一次，而一次Region的flush操作会落盘等量于Store数量的StoreFile文件，落盘总和大小为128M，单个文件太小了，随着flush增多，单个Store会积累大量碎文件，所以要执行合并操作compaction，既然要合并，就设置每次合并操作的上限值和下限值，但是文件总不能一直生成，在设置个block值，休息wait值后继续干活

hbase.hstore.compactionThreshold = 3 #下限值，增大可以减少触发合并的时间，但是合并时间会越长
hbase.hstore.compaction.max = 30 #上限值,每个minor compaction操作的 允许的最大hfile文件上限 
hbase.hstore.blockingStoreFiles = 100000 #block值，达到该值会block写入请求
hbase.hstore.blockingWaitTime = 90000 #wait值，每个store阻塞更新请求的超时时间，超过这个时间合并还未完成，阻塞也会取消

compaction操作是针对Region的。所以为了提高并行度，设置线程池数量，这里根据合并文件的总大小设计了两种线程，hbase.regionserver.thread.compaction.throttle的设置值(一般在hbase-site.xml没有该值的设置)，默认值采用2 * compactionThreshold * memstoreFlushSize，如果大于throttle的值，则会提交到largeCompactions线程池进行处理，反之亦然。

#采用默认值throttle = 2 * compactionThreshold * memstoreFlushSize
hbase.regionserver.thread.compaction.throttle #使用small or large的分界值
hbase.regionserver.thread.compaction.large = 5 #默认1
hbase.regionserver.thread.compaction.small = 5 #默认1

此外还有一种major compaction，这种操作会合并HRegion上所有StoreFile文件，非常耗资源，建议关闭，设置为0。建议在空闲时手动调用：major_compact 'tableName'，这个操作会立马返回，具体进度可以到UI上看

hbase.hregion.majorcompaction = 0

文件合并减少了碎文件，但是随着时间推移，文件会越来越大，所以我们要设置下文件大小的上限。当达到上限时，采用split操作拆分HRegion，且会把Region所有Store进行拆分，以保证数据一致。父HRegion下线，两个子HRegion有RS管理

hbase.hregion.max.filesize = 10737418240 #当HRegion的某个Store的HStoreFile文件大小超过该值会进行HRegion拆分

OK，数据在写入过程中，我们设置了好多参数，现在再来查数据看看，为了查询快，首先想到得就是缓存，在Hbase里专门有个缓存BlockCache，阿里又贡献了BucketCache（如果设置为offheap模式，即使Hbase数据块时缓存在堆外内存，但是在读取的时候还是会首先将堆外内存中的Block加载到JVM内存中，再返回给用户。再Hbase 2.x 中，HBASE-11425 ISSUE已经通过引用计数的手段避免了堆外内存向堆内内存的额外拷贝，减少了GC压力），相关配置如下：

hfile.block.cache.size = 0.4 #LRUBlockCache块缓存的大小，默认为堆大小的40%，和memstore加和不能大于0.8
hbase.bucketcache.size = 0.4 #如果配置的值在0-1,表示占用堆内存的百分比,或者配置XXMB 
hbase.bucketcache.ioengine = offheap #在堆外内存申请资源，heap是在JVM内申请，file是SSD
hbase.bucketcache.combinedcache.enabled = true #blockcache保存index和bloom,bucketcache保留数据块

参数调优到此为止，接下来就是GC调优，移驾：Hbase GC调优

Hbase GC调优_cdh6.3.2 hbase组件调优-CSDN博客