Hbae配置优化-致所有准备找工作的人

HBASE配置优化
致所有在找工作的朋友：
一、谈到的硬件配置
编号硬件说明
1
内存32G 服务器端接收客户端的数据可以缓存在内存中以及排序，速度也就越快
2
CPU 8核要想速度快，数据必须离CPU最近，CPU性能高也可提高MR的运算速度
3
网络分布式系统致命的地方，cpu、内存不是问题，但是网络绝对是问题，推荐用千兆双网卡绑定，万兆交换机
4
硬盘
推荐使用500GB的SATA/SAS盘，7200转
二、你的集群规模
60台机器做集群，分配规则如下：
编号名称数量
1 Master 2
2 ZK 5
3 RegionServer 15
4 DataNode 37
5 监控服务器 1
三、性能优化
1)hbase.hregion.max.filesize
这个参数是单个region的最大字节数，当region中的数据达到这个值之后就会平均分裂成2个region
2)hbase.hregion.memstore.flush.size
这个参数是每次内存能缓存的数据最大字节数，当memstore中缓存的数据达到这个值，hbase就将数据flush到硬盘上
3)hbase.regionserver.handler.count
这个参数决定了每个regionserver能够开启的最大handler数量，即接受客户端请求的句柄数，这个数量越大能接受的客户端以及线程数越多
4)HBASE_HEAPSIZE
这个参数决定了hbase最多能调用物理机的内存大小，尽量配置大一些
hbase.hregion.max.filesize和hbase.hregion.memstore.flush.size参数的配置有讲究。

目前有2种设计思路：
1、建表时预划分region，对数据有清楚的把握（数据量、rowkey分布），能够进行将region分好，而无需启用hbase的自split策略，这种方式能够提高集群稳定性，缺点是操作上较困难。

在此情况下hbase.hregion.max.filesize设置为1TB或更大值
2、数据无法估量，采用hbase自身split机制。

灵活性高，易操作，缺点是存在不稳定风险。

在此情况下将hbase.hregion.max.filesize设置为1GB-2GB较合理
3、无论上述哪种情况，hbase.hregion.memstore.flush.size在200MB 左右是经过多次测试后一个较理想值
四、Hadoop配置参数
hbase是基于hadoop构建的，要调优hbase入库性能必然少不了调优hdfs。

这里发现了几个比较有用的参数
dfs.replication.interval：默认为3秒，就是hadoop检查备份的时间间隔，这个时间稍微设长一点可以避免hdfs频繁备份，提高hdfs吞吐
效率
dfs.datanode.handler.count：datanode的handler，增加datanode的handler 数
node.handler.count：namenode的handler数。

五、系统架构因素
Client端
入库时对client的数量和开启的线程数量有要求，对client机器性能也有一定的要求，因为实际测试的时候发现client端开启50个线程后机器性能占用比较满。

Regionserver端
Regionserver端越多，能同时接受的请求就越多，入库速度就越快。

六、配套软件
操作系统：64位centOS
JDK：sun64位jdk1.7
Hadoop：hadoop2.6版
Hbase：hbase0.98
七、hbase表设计因素
hbase表如果设计成多列族会比单列族的时候入库速度慢。

因为多列族的时候hbase做memstore的flush时对一个store文件的flush会同时触发其他store的flush，这个可能是hbase的一个bug，目前来说设计表的时候不要将列族设计到3个以上。

八、入库程序设计因素
入库程序的设计上最好在创建Htable的时候就设置好region的数量，start_key和end_key，这样就能够使程序开始运行的时候向每个regionserver传递请求。

另外start_key和end_key的设计可以让数据较紧凑的平均分发到各个region上。

入库程序不要手动做table.flushcommit()，而是使用hbase自带的memstore->硬盘的写入机制，只需要table.put即可。

然后设置table
的自动提交功能为false（如果为true的话每次调用table.put的时候都会触发一次操作）。

数据入库时只对自动提交选项设为false，而不对writebuffersize做设置效果会比较好，看了hbase的代码不设置的话默认值是2MB，writebuffersize的设置不能太大，也不能太小，实际测试中2-5MB之间比较合理
入库程序设计要开尽可能多的线程，推荐20-25线程，在多个机器上运行，同时读取本地文件，在并发数量大的情况下入库效率会得到较大提升。

BlukLoad入库：除了client方式之外，可以通过mr来生成hfile，之后将hfile直接导入hbase的方式入库。

目前以这种方式进行大文件批量入库是最为理想的方法。

九、性能分析
1、regionserver的内存设置为20000M,
2、修改region的最大大小为100G（目的是为了不做分裂）；
3、提前划分region 1000个；region的flush大小为4G，
4、client的writebuffersize为64MB，每个开50线程。

5、入库速度能达到60MB/s，hbase的request到20w。

祝愿所有找工作的朋友都能找到好的工作。