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数目会长期不变。当然大region在compaction时也会更加缓慢。几十G的region启动和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。