Hbase优化
本文对hbase集群进行优化，主要涵盖硬件和操作系统，网络通信，JVM，查询，写入，核心服务，配置参数，zookeeper，表设计等多方面。
我们对hbase的应用主要是用户画像，根据自身使用场景做一些优化。难免有片面之处。
一、软硬件优化：
1. 配置内存，cpu
HBase的LSM树结构，缓存机制和日志机制对内存消耗非常大，所以内存越大越好。
其中过滤器，数据压缩，多条件组合扫描等场景都是cpu密集型的，所以cpu也要够强悍
2. 操作系统
选择主流linux发行版，JVM推荐用Sun HotSpot64位的，能发挥hadoop最好的性能
使用noatime挂载磁盘：一般数据库的挂载磁盘没有特殊要求情况下最好都设置位为noatime以提高性能
关闭系统交换区: Linux内存反复交换会影响JVM性能，典型的异常就是导致zookeeper超时。所以设置vm.swappiness设置的比较低较好。
3. 网络通信
由于hdfs对集群网络吞吐有很高的要求，所以网络必须保证低延迟高吞吐
添加机架感知：机架感知是提升hadoop的写入和读取本地化。在core-site.xml中配置topology.script.file.name
4. JVM优化
根据网络上很多成熟引用验证比较优秀的垃圾回收器搭配组合CMS+ParNew
二、进入主题：Hbase本身优化
1. Hbase查询优化：
a. 设置scan缓存：scan的时候setCaching来设置缓存大小
b. 确定所需要的列：scan时候addColumn来添加所需要的列减少数据的传输
c. 如果批量进行全表扫描请禁用块缓存，因为全表扫描每条记录只读取一遍
d. 优化行键查询：全表scan时，如果只需要行键，可以使用过滤器来减少服务器返回的数据量。
e. 通过HBaseTool访问：HTable对象对于客户端读写数据来说不是线程安全的，多线程时要为每个线程创建一个HBase对象。而HBaseTool链接线程池机制可以解决线程安全问题，同事维持一定数量的HBase
f. 使用批量读：HTable.get(List<Get>)
g. 使用Coprocessor统计行数: 具体原理请看协处理器原理
h. 缓存查询结果：对于查询频繁的应用场景
2. HBase写入优化：
a. 关闭WAL日志：如果能容忍一定的数据丢失风险，则可以关闭WAL
b. 设置AutoFlush: 关闭此功能等put到达到缓存阀值时候才提交到服务器
c. 预创建Region: 预先创建region来避免写入时region到达一定阀值而split影响性能，和mongodb预分片原理一致
d. 延迟WAL flush：如果开启WAL则可以将WAL flush到磁盘的时间间隔调大一些来提高性能
e. 使用批量写HTable.put(List<Put>)
3. HBase基本核心服务优化
a. 优化分裂操作： 如果写多读少的场景则可以调高hbase.hregion.max.filesize来减少region分裂
b. 优化合并操作：大合并非常消耗资源，且合并时候会阻塞写操作。应该在集群不繁忙的时候进行大合并
4. Hbase配置参数优化：
a. 设置regionserver handler数量：如果写请求比较多则可以适当调高hbase.regionserver.handler.count的数量以提高写吞吐。此参数调高很消耗内存，请注意。
b. 调整blockCache大小：hfile.block.cache.size来设置regionserver查询的内存设置。默认0.25指读缓存占用堆内存25%。读场景比较多可以适当调高。
c. 设置MemStore的上下限：hbase.regionserver.global.memstore.upperLimit表示regionserver上所有region的Memstore的大小上限，超过上限会引发全局flush，这个参数主要防止regionserver内存占用过大被OOM Kill掉。
读为主的集群中，可以调小此参数，调高blockCache; 写则相反
d. 调整影响合并的文件数：hbase.hstore.blockingStoreFiles值用于控制超过此值的storefile则会出发合并。可以调大此值减少合并次数
e. 调整MemStore的flush因子：当Memstore占用内存大小超过hbase.hregion.memstore.flush.size倍数时将阻塞region所有请求，出发flush，释放内存。如果正常不会出现写入或写入数据量突然增大则可以保持默认，否则要调高此值。
f. 调整单个文件大小：hbase.hregion.max.filesize用于定义单个hstorefile大小，超过此值则引发region文件split。 Region比较小则合并和split都很快，当然会造成集群响应时间波动。 大合并和split则造成较长时间阻塞。应该根据自己场景来定义
5. 分布式协调系统zookeeper的优化：zookeeper的优化方法也很多，我就主要讲hbase优化。只是说明下zookeeper优化也非常重要。
6. 表设计优化
a. 开启布隆过滤器：布隆过滤器可以减少读盘次数以降低延迟。原理和redis的hyperloglog一样(我们以前有用此功能对用户数量进行估算)
b. 调整列族块大小：较小的块大小可以提高随机读的速度，同时导致块索引变大。
c. 设置in memory属性：对于经常访问的列族可以设置in memory，但是要考虑消耗内存的问题
d. 调整列族最大版本数量：数量大占用磁盘空间，且导致集群变大。根据自己应用场景来选择。像我们做画像由于要统计用户场景变化，所以版本数量有根据自己需求设置
e. 设置TTL属性：超过TTL的列将自动删除。这个也根据自己场景选择。我们做用户画像时会将某些用户行为超过时间的就认为没有必要在进行存储分析了，所以可以设置TTL来自动删除
7. 关闭mapreduce的预测执行功能：若使用mapreduce来访问hbase集群应该关闭，否则有可能导致hbase客户端链接数陡增影响集群运行
8. 修改负载均衡执行周期：当集群写入频繁时，可以调小，否则可以调大。