参数列表：
hbase.client.write.buffer 写入是BUFFER大小，默认2M，一般2-5M左右，插入时先插入缓存即表示完成，明显速度比不使用缓存要快
hbase.client.scanner.caching 通过ResultScanner获取结果的时候，默认next()方法一次一条，通过设置cache，一次可以多条，默认值100，这个值越大，需要内存越多
hbase.master.handler.count Master RPC数量
hbase.regionserver.handler.count regionserver RPC数量
hbase.regionserver.global.memstore.upperLimit, 默认0.4表示memstore最多使用JAVA HEAP的40%
hbase.regionserver.global.memstore.lowerLimit, 默认0.38 表示使用到了38%就要进行刷盘了
hbase.hregion.memstore.flush.size 默认128M，当memstore 使用达到128M，就刷新为Hfile,并关闭次memstore
hbase.hregion.max.filesize HFILE最大值，超过了就要split
hbase.hstore.compactionThreshold 默认3， 一个region下有3个HFILE就会合并
hbase.hstore.blockingStoreFiles 默认10， 如果达到这个数字，就会阻塞插入和更新，等待合并完成， 但是这个参数不是强制性的，看下面的blockwait time
hbase.hstore.blockingWaitTime 默认90秒，如果超过这个时间合并还没有完成，重启启用更新插入
hbase.hregion.majorcompaction 默认7天，有公式来支撑，大致是比较当前时间和HFILE时间做比较，看是否有超过7天
hfile.block.cache.size 读缓存，默认java heap的40%
IncreasingToUpperBoundRegionSplitPolicy split policy， 默认值， 如果要关闭自动SPLIT，建议使用第三种策略，然后增大HFILE最大大小，这样自动SPLIT基本就关闭了
KeyPrefixRegionSplitPolicy
ConstantSizeRegionSplitPolicy
以上这些参数通常都要根据业务情况进行微调，不需要太大调整，要完整的说怎么使用，不太可能，业务不同，规则不同。
比如BLOCK CACHE，读缓存，按照数据库的规则来说，譬如MySQL, ORACLE，我们希望这个值的命中率为99%， 但是对HBASE来说99%基本不可能，有些大的表可能就偶尔做一次SCAN，数据进入内存之后，把其他经常需要缓存的数据刷出去了，这种情况，建议关闭这种表的BLOCK CACHE， 那如果有些表经常要读，可能我们希望会设置IN MEMORY。
再比如memstore为128M，是否这个值能否修改为256？ 或者64 ？ 我觉得是看刷新频率，如果你几秒钟就128M了，我觉得是否这个值应该加大，另外minor合并默认为3，是否小了？ 修改为5，或者8或者更大是否合适呢?
了解整个参数的意义，配合实际情况，再做调整比较合适，最好要测试，否者你没有办法证明你的调整是对的。
hbase.client.write.buffer 写入是BUFFER大小，默认2M，一般2-5M左右，插入时先插入缓存即表示完成，明显速度比不使用缓存要快
hbase.client.scanner.caching 通过ResultScanner获取结果的时候，默认next()方法一次一条，通过设置cache，一次可以多条，默认值100，这个值越大，需要内存越多
hbase.master.handler.count Master RPC数量
hbase.regionserver.handler.count regionserver RPC数量
hbase.regionserver.global.memstore.upperLimit, 默认0.4表示memstore最多使用JAVA HEAP的40%
hbase.regionserver.global.memstore.lowerLimit, 默认0.38 表示使用到了38%就要进行刷盘了
hbase.hregion.memstore.flush.size 默认128M，当memstore 使用达到128M，就刷新为Hfile,并关闭次memstore
hbase.hregion.max.filesize HFILE最大值，超过了就要split
hbase.hstore.compactionThreshold 默认3， 一个region下有3个HFILE就会合并
hbase.hstore.blockingStoreFiles 默认10， 如果达到这个数字，就会阻塞插入和更新，等待合并完成， 但是这个参数不是强制性的，看下面的blockwait time
hbase.hstore.blockingWaitTime 默认90秒，如果超过这个时间合并还没有完成，重启启用更新插入
hbase.hregion.majorcompaction 默认7天，有公式来支撑，大致是比较当前时间和HFILE时间做比较，看是否有超过7天
hfile.block.cache.size 读缓存，默认java heap的40%
IncreasingToUpperBoundRegionSplitPolicy split policy， 默认值， 如果要关闭自动SPLIT，建议使用第三种策略，然后增大HFILE最大大小，这样自动SPLIT基本就关闭了
KeyPrefixRegionSplitPolicy
ConstantSizeRegionSplitPolicy
以上这些参数通常都要根据业务情况进行微调，不需要太大调整，要完整的说怎么使用，不太可能，业务不同，规则不同。
比如BLOCK CACHE，读缓存，按照数据库的规则来说，譬如MySQL, ORACLE，我们希望这个值的命中率为99%， 但是对HBASE来说99%基本不可能，有些大的表可能就偶尔做一次SCAN，数据进入内存之后，把其他经常需要缓存的数据刷出去了，这种情况，建议关闭这种表的BLOCK CACHE， 那如果有些表经常要读，可能我们希望会设置IN MEMORY。
再比如memstore为128M，是否这个值能否修改为256？ 或者64 ？ 我觉得是看刷新频率，如果你几秒钟就128M了，我觉得是否这个值应该加大，另外minor合并默认为3，是否小了？ 修改为5，或者8或者更大是否合适呢?
了解整个参数的意义，配合实际情况，再做调整比较合适，最好要测试，否者你没有办法证明你的调整是对的。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/17036462/viewspace-2141418/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
