HBase核心参数配置-Toy模板网

这篇具有很好参考价值的文章主要介绍了HBase核心参数配置。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

参数配置是一个富有技巧性的工作，每个参数的背后都有着对应模块的工作原理。接下来对HBase中常见的参数进行分类整理，解释每个参数的实际意义以及在生产线上的配置注意事项。

1、Region相关参数

hbase.hregion.max.filesize：默认10G，简单理解为，Region中最大的Store中所有文件大小一旦大于该值整个Region就会执行分裂。（可以指定单表设置）
解读：实际生产环境中该值不建议太大，也不能太小。太大会导致系统后台执行compaction消耗大量系统资源，一定程度上影响业务响应；太小会导致Region分裂比较频繁（分裂本身其实对业务读写会有一定影响），太多Region会消耗大量的系统资源，并且在regionServer故障恢复时比较耗时。综合考虑，建议线上设置为50G～80G左右。

2、BlockCache相关参数

BlockCache相关的参数非常多，而且比较容易混淆。不同BlockCache策略对应不同的参数，而且这里参数配置会影响到Memstore相关参数的配置。笔者对BlockCache策略一直持有这样的观点：RS内存在20G以内的就选择LRUBlockCache，大于20G的就选择BucketCache中的Offheap模式。接下来所有的相关配置都基于BucketCache的offheap模型进行说明。

file.block.cache.size：默认0.4，该值用来设置LRUBlockCache块缓存的大小，默认为堆大小的40%。
解读：当前HBase系统默认采用LRUBlockCache策略，BlockCache大小和Memstore大小均为JVM的40%。但对于BucketCache策略来讲，Cache分为了两层，L1采用LRUBlockCache，主要存储HFile中的元数据Block，L2采用BucketCache，主要存储业务数据Block。因为只用来存储元数据Block，所以只需要设置很小的Cache即可。建议线上设置为0.05～0.1左右。

开启L2缓存需要配置相关参数，例如hbase.bucketcache.combinedcache.enabled、hbase.bucketcache.ioengine和hbase.bucketcache.size。

hbase.bucketcache.combinedcache.enabled：默认为true,意思是combinedcache里面包括了LRU和bucketcache
hbase.bucketcache.ioengine：BucketCache策略的模式选择，可选项包括heap、offheap以及file三种，分别表示堆内内存、堆外内存以及SSD硬盘做为缓存存储介质。
hbase.bucketcache.size：堆外存大小，设置多大就看自己的物理内存大小喽。

3、MemStore相关参数

hbase.hregion.memstore.flush.size：MemStore级别限制，默认128M（134217728），单个region里memstore的缓存大小，超过那么整个Region就会flush。如果当前系统flush比较频繁，并且内存资源比较充足，可以适当将该值调整为256M。
hbase.hregion.memstore.block.multiplier：Region级别限制，默认4，表示一旦某region中所有写入memstore的数据大小总和达到或超过阈值hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size，会阻止继续往该 memstore 写数据，就会执行flush操作，并抛出RegionTooBusyException异常。
hbase.regionserver.global.memstore.size：默认0.4，regionServer的全局memstore的大小，超过该大小会触发flush到磁盘的操作,默认是堆大小的40%,而且regionserver级别的flush，会阻塞客户端读写
hbase.regionserver.global.memstore.lowerLimit：默认0.95。不需要修改。可以理解为一个安全的设置，有时候集群的“写负载”非常高，写入量一直超过flush的量，这时，我们就希望memstore不要超过一定的安全设置。在这种情况下，写操作就要被阻塞一直到memstore恢复到一个“可管理”的大小, 这个大小就是默认值是堆大小 * 0.4 * 0.95，也就是当regionserver级别的flush操作发送后,会阻塞客户端写,一直阻塞到整个regionserver级别的memstore的大小为堆大小 * 0.4 *0.95为止。
hbase.regionserver.optionalcacheflushinterval：默认1h（3600000ms），内存中的文件在自动刷新之前能够存活的最长时间。（是当前内存第一条数据到达一个小时，还是最后一条数据到达一个小时？）

4、Compaction相关参数

compaction模块主要用来合并小文件，删除过期数据、deleted数据等。涉及参数较多，对于系统读写性能影响也很重要，下面主要介绍部分比较核心的参数。文章来源地址https://www.toymoban.com/news/detail-561442.html

hbase.hstore.compactionThreshold
默认为3，compaction的触发条件之一，当store中文件数超过该阈值就会触发compaction。通常建议生产线上写入qps较高的系统调高该值，比如5～10之间。
hbase.hstore.flusher.count
执行flush操作的线程数,设置小了刷新操作会排队，大了会增加底层hdfs的负载压力
hbase.hstore.compaction.max
默认为10，最多可以参与minor compaction的文件数。该值通常设置hbase.hstore.compactionThreshold值的2～3倍
hbase.regionserver.thread.compaction.throttle
默认为2G，评估单个compaction为small或者large的判断依据。为了防止large compaction长时间执行阻塞其他small compaction，hbase将这两种compaction进行了分离处理，每种compaction会分配独立的线程池。
hbase.regionserver.thread.compaction.large/small
默认为1，large和small compaction的处理线程数。生产线上建议设置为5，强烈不建议再调太大（比如10），否则会出现性能下降问题。
hbase.hstore.blockingStoreFiles
默认为10，表示一旦某个store中文件数大于该阈值，就会导致所有更新阻塞。生产线上建议设置该值为100，避免出现阻塞更新，一旦发现日志中打印too many store files，就要查看该值是否设置正确。
hbase.hregion.majorcompaction
默认为1周（10006060247），表示major compaction的触发周期。生产线上建议大表major compaction手动执行，需要将此参数设置为0，即关闭自动触发机制。

5、HLog相关参数

hbase.regionserver.maxlogs
默认为32，region flush的触发条件之一，wal日志文件总数超过该阈值就会强制执行flush操作。该默认值对于很多集群来说太小，生产线上具体设置参考HBASE-14951
hbase.regionserver.hlog.splitlog.writer.threads
默认为3，regionserver恢复数据时日志按照region切分之后重新写入hdfs的线程数。生产环境因为region个数普遍较多，为了加速数据恢复，建议设置为10。

6、请求队列（call Queue）相关参数

hbase.regionserver.handler.count
默认为30，服务器端用来处理用户请求的线程数。生产线上通常需要将该值调到100～200。
解读：response time = queue time + service time，用户关心的请求响应时间由两部分构成，优化系统需要经常关注queue time，如果用户请求排队时间很长，首要关注的问题就是hbase.regionserver.handler.count是否没有调整。
hbase.ipc.server.callqueue.handler.factor
默认为0，服务器端设置队列个数，假如该值为0.1，那么服务器就会设置handler.count * 0.1 = 30 * 0.1 = 3个队列。
hbase.ipc.server.callqueue.read.ratio
默认为0，服务器端设置读写业务分别占用的队列百分比以及handler百分比。假如该值为0.5，表示读写各占一半队列，同时各占一半handler。
hbase.ipc.server.call.queue.scan.ratio
默认为0，服务器端为了将get和scan隔离设置了该参数

7、其他重要参数

hbase.online.schema.update.enable
默认为true，表示更新表schema的时候不再需要先disable再enable，直接在线更新。该参数在HBase 2.0之后将会默认为true。生产线上建议设置为true。
hbase.quota.enabled
默认为false，表示是否开启quota功能，quota功能主要用来限制用户/表的QPS，起到限流作用。生产线上建议设置为true。
hbase.snapshot.enabled
默认为false，表示是否开启snapshot功能，snapshot功能主要用来备份HBase数据。生产线上建议设置为true。
zookeeper.session.timeout
默认180s，表示zookeeper客户端与服务器端session超时时间，超时之后RegionServer将会被踢出集群。
解读：有两点需要重点关注，其一是该值需要与Zookeeper服务器端session相关参数一同设置才会生效，一味的将该值增大而不修改ZK服务端参数，可能并不会实际生效。其二是通常情况下离线集群可以将该值设置较大，在线业务需要根据业务对延迟的容忍度考虑设置。
hbase.zookeeper.useMulti
默认为false，表示是否开启zookeeper的multi-update功能，该功能在某些场景下可以加速批量请求完成，而且可以有效防止部分异常问题。生产线上建议设置为true。注意设置为true的前提是Zookeeper服务端的版本在3.4以上，否则会出现zk客户端夯住的情况。
hbase.coprocessor.master.classes
生产线上建议设置org.apache.hadoop.hbase.security.access.AccessController，可以使用grant命令对namespace\table\cf设置访问权限。
hbase.coprocessor.region.classes
生产线上建议设置org.apache.hadoop.hbase.security.token.TokenProvider,org.apache.hadoop.hbase.security.access.AccessController，同上。