从0开始的hbase

标签：磁盘   效果   全表扫描   调整   compact   事件   修复   压力   tca   

2016马上要结束了，回顾一下这一年对hbase的学习历程。

1，年初hbase的状态

使用场景：主要是用来存储业务线的mysql表，增量同步到hbase，然后每天晚上全量导入hdfs做离线计算。 hbase集群状态：除了调大了regionserver的heap size。其他基本没有动。经常发生的问题是晚上高峰导表的时候，不时会有regionserver宕机。 故障恢复：非常慢，碰到问题像无头的苍蝇，各种重启，然后表各种RIT。年初的时候经历过一次故障，两个人折腾了一天，而且还导致了数据的丢失。 对hbase掌握情况：组里之前没人有对hbase有较为深入的了解，面对这些情况，所以决定拿出一个部分精力对hbase做一些学习，以便更好地为生产环境服务。

2，年末hbase的状态

使用场景：除了原有的业务表同步（增量写入，全量读取）以外，另外新增了各种数据导出业务，另外还有用户访问行为分析业务（增量写入，随机读取）。其实，hbase更适合这种随机读写业务，因为总的来说hbase全表扫描是很慢的。 hbase集群状态：regionserver宕机的情况大大减少，半年里发生的次数差不多三四次，都是客户端对hbase突然的大量请求导致的。 故障恢复：因为表处于RIT状态卡主导致无法读写的故障，恢复时间在10min以内，而且数据不会丢失。 对hbase掌握情况: 对split，compact，flush，客户端请求等流程有大致的了解，碰到问题，能够根据源码去找问题，解决问题。另外，对故障恢复有了一定的经验。

3，干过的事

梳理下来，主要的hbase做了以下事情：

1，使用LruBlockCache+BucketCache替换掉hbase默认使用的LruBlockCache。

LruBlockCache所有的内存都分配在Heap上，一般来说对于Region Server配置的内存不超过20G的情况下，采用LruBlockCache还能应付的过去。但是超过以后，GC的压力会很大，因为heap内存大了以后，Full GC时Stop the world的时间会很长，而一旦超过regionserver和zk的心跳时间，region server就死掉了。 采用LruBlockCache+BucketCache以后,相关的data block的索引，bloom过滤器等会存放在LruBlockCache（分配在堆上），而data block会存放在Bucket Cache上（这个不经过heap，直接分配在堆外内存上），由hbase自己去管理堆外内存，这样就避免了GC的压力，region server的稳定性增强了很多。

2，每天对需要导出的表做major compact。

我们hbase的使用场景是读多写少，hbase请求的高峰是0点全量导表的时候，而写入主要是增量同步数据。hbase默认是一周左右做一次major compaction。 major compaction会使得同一个region下的storeFile会合并成一个大的storeFile，所以在做major compaction的时候会耗费磁盘和cpu，并且时间可能会很长,而带来的好处是带来读性能的极大提升。为此，我们每天手工对需要的表做major compaction，而带来的效果也很明显，晚上导表时间减少了50%。

3，参数调整。

针对集群中每台regin server的region数已将近500，而正常情况每台regionserver应该在100-200左右。为此，将单个region的size（hbase.hregion.max.filesize）从默认的1G增到2G。 另外，针对集群的读写请求比例，对写请求相关的memstore size和读请求相关的block cache size参数做了对应的调整。

4，使用YCSB测试hbase集群

使用YCSB对hbase集群的对写性能做了摸底，并且通过测试验证参数调整效果。另外，在测试中发现，读写请求数据量的大小对读写性能有着非常重要的影响。

5，hbase运维

碰到region server当机了，表读写卡住了怎么办？ 首先，不要慌，哈哈。一两台region server宕机，对集群没影响。备份好日志，先启动死掉的region server，然后慢慢分析日志就好了。一次region server宕机了，发现宕机之前有大量的flush，所以怀疑是写请求量增加导致的。但是当时，相关hbase读写请求的指标没有采集，所以没法验证，于是只好直接问组里小伙伴，然后发现真是这样。此次事件后，开始收集hbase各种指标。可以说，故障激励着我们进步和成长。 其次，碰到table在RIT状态时，首先用hbase hbck去查看是否有状态不一致，一旦发现有以后，可以尝试通过hbase hbck repair来修复。 最后，很多时候，table处于RIT状态，都是集群中一两台region server有异常导致的，这个时候可以让这台有问题的region server先下线。待恢复后，再上线。

总结

从当初到hbase一无所知，到现在基本能够保证线上运行，我们经历了好多，可是说是故障伴随我们成长。目前最大的欣慰就是，碰到问题大部分情况下能够通过查看源码来分析和解决问题。hbase水很深，未来的路还很长。正所谓：路漫漫其修远兮，吾将上下而求索~

从0开始的hbase

标签：磁盘   效果   全表扫描   调整   compact   事件   修复   压力   tca   

原文地址：http://www.cnblogs.com/superhedantou/p/6158657.html