hbase优化
一.读优化
1.客户端：
scan。cache 设置是否合理：大scan场景下将scan缓存从100增大到500或者1000，用以减少RPC次数
使用批量get进行读取请求
离线批量读取请求设置禁用缓存，scan.setBlockCache(false)
以指定列族或者列进行精确查找的尽量指定查找
2.服务器：
读请求是否均衡：：RowKey必须进行散列化处理（比如MD5散列），同时建表必须进行预分区处理
BlockCache是否设置合理：VM内存配置量 < 20G，BlockCache策略选择LRUBlockCache；否则选择BucketCache策略的offheap模式
HFile文件是否太多：hbase.hstore.compactionThreshold设置不能太大，默认是3个；设置需要根据Region大小确定，通常可以简单的认为hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold
Compaction是否消耗系统资源过多：（1）Minor Compaction设置：hbase.hstore.compactionThreshold设置不能太小，又不能设置太大，因此建议设置为5～6；hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold
（2）Major Compaction设置：大Region读延迟敏感业务（ 100G以上）通常不建议开启自动Major Compaction，手动低峰期触发。小Region或者延迟不敏感业务可以开启Major Compaction，但建议限制流量
3.列簇：是否过多、
是否使用布隆过滤器：任何业务都应该设置Bloomfilter，通常设置为row就可以，除非确认业务随机查询类型为row+cf，可以设置为rowcol
是否设置ttl
4.hdfs优化：
启Short Circuit Local Read功能
开启Hedged Read功能
. 数据本地率是否太低：避免Region无故迁移，比如关闭自动balance、RS宕机及时拉起并迁回飘走的Region等；在业务低峰期执行major_compact提升数据本地率
二、写优化
是否需要写WAL？WAL是否需要同步写入
用批量put进行写入请求
在业务可以接受的情况下开启异步批量提交，使用方式：setAutoFlush(false)
：在Num(Region of Table) < Num(RegionServer)的场景下切分部分请求负载高的Region并迁移到其他RegionServer
检查RowKey设计以及预分区策略，保证写入请求均衡
写入KeyValue数据是否太大