hbase优化相关参数说明

时间:2021-01-21 08:24:09

1、hbase.regionserver.handler.count 

RegionServers处理远程请求的线程数,如果注重TPS,可以调大,默认10         note1:值设得越大,意味着内存开销变大,hbase.client.write.buffer * hbase.regionserver.handler.count,hbase.client.write.buffer默认大小为2M         note2:  对于提高write的速度,如果瓶颈在做flush、compact、split的速度,磁盘io跟不上,提高线程数,意义不大。

2、hfile.block.cache.size

        默认0.25,hfile/StoreFile的最大读缓存空间,所占堆空间比例。         note1:参数设定根据应用场景,如果读比写多,建议调大,读写平衡,建议设成0.3,如果读少于写,建议调小         note2:block.cache.size memstore limits 这些内存加起来不要超过60%。因为剩余的内存还要用来做其他事情。否则容易OOM

3、hbase.regionserver.global.memstore.upperLimit

    默认0.4,memstores所占最大堆空间比例,如果达到上限,阻塞更新,强制flush数据

4、hbase.regionserver.global.memstore.lowerLimit

    默认0.35,menstores达到上限,做flush,知道memstores降到该值,停止flush。

5、hbase.hstore.blockingStoreFiles

    默认7,如果一个hstore里面storefile超过这个数字(每次memstore做flush时会生成一个hstore),会阻塞相应hregion的更新,知道一个compact压缩过程结束,或者阻塞时间超过hbase.hstore.blockingWaitTime(默认90s)     note1:hbase.hstore.compactionThreshold,默认3,如果一个hstore里面的storefile数量超过这个数字,一个压缩任务会启动,将所有的storefile合并成一个。如果数量较多,那么会推迟合并过程,但是再执行时,将会消耗更多时间。     note2:对于持续写的系统,这个参数的设置,是为了compact与flush的速度平衡,如果compact的速度远小于flush的速度,有可能造成 文件io过多,造成too many openfile异常,以及给namenode带来更大的压力。

6、hbase.hregion.memstore.flush.size、hbase.hregion.memstore.block.multiplier

   默认134217728、2    第一个参数:如果一个memstore大小超过flushsize,则启动flush。后台会有一个线程在周期hbase.server.thread.wakefrequency内,定时检查    第二个参数:如果一个memstore大小超过 该值*flushsize,则阻塞更新。该参数可以平衡,写入速度、flush速度、compact速度、split速度

7、hbase.regionserver.checksum.verify

   默认false,决定,hbase使用自己的数据校验,而不是hdfs的校验。

8、hbase.hregion.max.filesize

   默认10G,一个region下,任一列簇的hfiles的大小,超过这个值,该region将split成2个region。    note:如果你的数据量增长的比较快,那么还是建议把这个大小调高,可以调成100G,因为越少的region你的集群越流畅,100G的阈值基本可以避免你的region增长过快,甚至你的region数目会长期不变。当然大regioncompaction时也会更加缓慢。几十Gregion启动和compaction都非常的慢,如果storefile较多,一个compaction可能会持续几天。

9、谈谈region数量设置、以及region split过程

   个人观点,如果可以尽早对region进行规划,可以提前预判规划好region的数量,这样可以节省split带来的消耗。    note1:人工进行split    设置hbase.hregion.max.filesize的值为LONG.MAX_VALUE,但是建议设成一个较大的值。预先设计region数量为10,或者更少,然后看数据发展情况。    如果数据较少,可以讲major compact的周期调大。如果数据增长比较快,那么可以调用org.apache.hadoop.hbase.util.RegionSplitter接口,主动进行split。