HBase使用优化（持续更新）

这里只准备介绍我实际操作中遇到的一些使用优化或解决办法，想大致了解hbase优化的同学可以参考我之前转載的几篇博文。

1. 第一个我想说的是HBase的写操作，api层面上的优化（比如批量写，关闭wal之类的）我这里就不啰嗦了，我想要说的是rowKey的设计，这个问题一般会跟io的大小息息相关，io越大，rowKey的设计就必须更谨慎，避免出现数据热点，往往一个不好的设计会导致某些regionserver的负载非常大，而某些regionserver则非常空闲，严重影响读写性能及可用性。比如一个以时间戳作为rowkey的表设计，往往新产生的日志写入都是在最后的region，这样的话不管该表的regions怎么分布，所有的写入压力都只在管理最后region的regionserver上。如果存在多个这样的表，极有可能使某个regionserver的负载过大而导致regionserver宕掉，所以我们最好不要用时间戳作为rowkey前缀。我以前管理过这么一个hbase集群，规模不大，但每天的写入量不小，它的表基本都是以时间戳作为前缀，然后呢每次监控都会有某几台机器各种飘红，然后宕掉，最后整个集群瘫痪，无奈之下只能手动的均衡当前被写入的region，尽量把当前活跃的region平分到各个regionserver上，这样才稳定了集群。同时随着当前活跃region的变换，得定期做移动操作（hbase
shell move命令），所以这不是一个有效的解决办法，另外还有一个解决的办法就是自定义HBase的LoadBanlance，通过改变region的分布策略来均衡HBase集群的负载，这个功能在0.92及以后的版本中实现。可参考淘宝技术博的一遍文章《HBase中如何开发LoadBalance插件》

2. 第二个我想说的是Hbase的读操作，往往我们批量分析hbase数据的时候会用到scan，用提供的api，不得不说，性能不怎么样，拿count操作来举例，往往count一个表得等到你大眼瞪小眼，但这你怨不得它，单线程么，所以我们在批量读的时候可以把rowkey分段，通过多线程来读，这有点类似于hive的思路，但比hive简单，这样读起来性能会快很多。至于怎么分段，就看你的表设计和数据量了，提供一个简单的分段方法，就是按region的起始rowkey来分。

3. ……