Hbase的优化解决方案

Hbase高并发读写优化

1.HBase的Periodic Flusher
一般HBase在默认情况下回自动触发Flush操作,初衷是为了防止有些memstore长时间不flush,在没有进行WAL的情况下,出现数据的丢失.由于我们的Hbase每个region server 有将近100个resign,几乎每分钟都有region因为达到一小时的时间间隔触发flush,而多数情况下每次flesh的文件都很小,flush次数多了,就是引起compact如此频繁的flush和compation使得region server处理速度明显变慢.在我们将这个配置调整10小时后,可以明显提高HBase性能
2.在clink高并发访问HBase的时候,Hregion Server 的执行者handler都在执行任务的过程中,新到的clink还在排队等待handler的执行,回到上timeOutExecption.所以此时可以降低并发访问HBase的进程数,为了不降低性能,在进程内部使用更多的线程.由于线程见是共享对HBase的连接的,所以增加对HBase的连接数.
3.避免HBase的热点问题.
​在作了较多优化改进后发现仍有几个worker比较慢，跟踪那几个慢的worker日志发现读HBase经常超时，找到超时的region server，从HMaster UI上观察到这个server的读写请求数明显是其它server的好几倍。开始怀疑是数据有倾斜，有热点region落到了这台机器上。在HBase UI上逐个检查Pora2用到的HBase表，果然在其中的一张表上发现它的第一个region的请求数比其它region高出一两个数量级。
按我们的设计预期，这个表的rowkey是加了hash前缀的(我们使用的rowKey设计是:3位随机数+表名+时间搓)，理论上不该有热点region，最终检查代码后才发现是生成rowkey的代码存在bug，生成前缀的代码用了 key.hashCode() % regionNum，结果有很多key的hashcode返回是负数，使得很多前缀是负数，全都落在了第一个region上。
而对hbase来说，一旦有一个region有热点，就会导致该region所在的region server变慢，进而使得这个server上其它表的region访问也慢，从而影响了整个hbase的性能。