HBase入库调优

本文章只针对“微型集群处理大数据”的场景。

场景描述：

硬件：5个节点，每个节点可用硬盘1块（700G、500G等）、8核cpu，实验室环境（有时候还要跑其他程序跟你抢占资源），16G内存。

软件：hadoop-0.20.2-cdh3u2，hbase-0.90.4-cdh3u2。

业务：sina微博12亿转发微博，700w用户信息。bzip压缩后共150G。要求就是将这些数据入库并且恢复关注和粉丝列表，建立userId与昵称映射，找出Message的转发关系等等。

上述业务实际上比描述的复杂，后续需要做各种分析，再次略去，只说明一下跟入库效率相关的影响因素：

1.批量导入数据，需要入库一定要均衡

2.恢复关注和粉丝列表，需要在入库时遍历其中的一个来恢复另一个（因为只给出了关注列表），也就是说入库一条用户信息可能会随之入库千百条信息。

分析：

1.入库均衡。首先要使rowkey均衡，原始数据只能顺序读取，若id连续则会产生hot region的问题，所以方案就是：rowkey=md5(id)+id。我并没有做简单的md5,而是用了另一种方式，详细可见文章：http://www.cnblogs.com/colorfulkoala/archive/2013/05/14/3077390.html

2.避免region split。入库是持续进行的，region入库过程region过大则会导致region的分裂，另外，集群的数量一定，预切分region可以保证初始rigion个数，这样我们就可以了解每个节点支持并发的能力了。所以我的做法是：设置region的hbase.hregion.max.filesize 为100g，基本可以保证region不再分裂，保证平均每个节点有1000region。

3.本地入库客户端。为了节约磁盘，客户端选择了直接读取压缩文件，读取原始数据完全不会成为入库的瓶颈。应该采用多点入库，然是事实上，带宽并不是瓶颈，所以从一个zk入库完全够用了。对于客户端采取多线程入库，建议最好打印读取记录的位置（可以每隔1000个打印一次），这样使入库程序支持断点。

4.hbase配置

开启lzo压缩

为确保并发支持hbase.regionserver.handler.count设置为100.

zookeeper.session.timeout 180000000

hbase.rpc.timeout 180000000  为了建表时不超时。

hfile.block.cache.size 0.1 可以设置小一些，因为入库主要是写操作。

hbase.regionserver.global.memstore.upperLimit 0.5

hbase.regionserver.global.memstore.lowerLimit 0.45 这两个参数要尽量大(upperLimit+block.cache<=0.6)，因为写效率提升需要很大的内存，如果设置的过小，会造成内存中的memstore过快的flush到硬盘，从而短时间内产生很多的storefiles，超过阈值后会触发compaction，compaction的瓶颈在硬盘，如果硬盘不给力，compaction时间过长就是造成dn和rs的连接一直占用。一方面storfiles会逐渐增高（因为compact没完又flush进来很多的storefiles），一方面连接数越来越多，导致too many openfiles错误的发生。

hbase.zookeeper.property.maxClientCnxns 500 同一个ip与zk连接数限制

hbase.hregion.memstore.flush.size 默认是64m，可以翻倍，也可以不变，如果内存小基本上用不到这个配置，如果入库过快，没等到攒到64m就开始强制flush,最终你会看到flush进去的全是5m、6m等等。这对不给力的硬盘上的compaction是致命的。

5.关闭autoflush, 设置buffersize(10*1024*1024)。

运行状况

消息入库设置了50个线程，每次1000条（可能要比1000多，因为需要恢复转发关系）

用户信息50个线程，每次100条。（可能一条会连续入库上千条，因为user可能关注了很多人）

运行时发现，内存和硬盘的瓶颈非常大，内存小导致强制flush，产生storefiles的速度很快。从而导致需要更多的compaction操作。dn rs 连接数以及storefiles的数量持续增加。后来每写500w条就休息一个小时，可以保证入库程序的良好运行。

 

需要指出的是，150G（user3G,message120g）的压缩数据入库之后居然快接近1T，2备份。说明数据结构占用了不少空间。