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.     ……

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值