一、性能优化
1.1性能优化的目标
（1）读VS写
a、读需要合并HFile，因此文件越少越好
b、写需要减少Compation操作，因此文件越多越好
c、优化读或者写之一，而不是全部
（2）顺序VS随机
（3）参考值——每个RegionServer吞吐率>20MB/s
读吞吐率>3000ops/s，写吞吐率>10000ops/s
（4）尽量在Hbase表结构设计时就考虑解决性能问题，而不是通过设置参数来调整Hbase性能
1.2性能优化
（1）预分配region
（2）启用压缩以减少HDFS数据量，可提读高性能
（3）Region Server进程配置大内存（>16G）,但不要太大(<100G)
（4）每个Region server拥有的region数量<200
（5）优化表结构设计，防止少数几个Region成为瓶颈
一个简单的经验公式：每台Region server纯写入时高负载应能 达到>1万条记录/秒（每条记录200字节）
1.3Region数目
（1）通常每台服务器能服务的Region数目为20到150个，集群粗略估计可按100个Region为上限，具体视服务器能力（CPU内核）及访问压力（每个Region的服务量）而定
（2）过多Region的症状
a、CPU线程切换频繁
b、内存使用过大，造成GC频繁，服务Timeout
c、每个region的memstore太小，磁盘flush频繁，HFile文件过多小文件
1.4Compaction
（1）检测：通过Hbase管理页面查看CompactionQueue长度及Region中的HFile的个数，如果CompactionQueue长度过长（如>10）或增长过快，则需要考虑调整Compaction参数
a、注意查看Region以及HFile的大小，确认是否因为太多过小文件的原因导致文件数目多，如是，需要检查内存使用及设置
（2）主要参数
a、hstore.compactionThreshold（Hstore压缩阀值），建议值10；
b、hstore.blockingStoreFiles，建议值30
c、更大的hregion.memstore.flush.size能减少Compaction的次数（缺省值128MB，一般不用修改）
1.5Major Compaction
（1）HBase根据时间来计划执行Major compaction
hregion.majorcompaction=604800000（缺省值为一周）
hregion.majorcompation.jitter=0.5（缺省值为半周）
（2）执行过程非常长，且非常耗资源
无法控制只在合适的时间执行
（3）建议在生产环境禁用计划Major Compation，通过命令行手工触发或自己进行物理数据删除
1.6HBase的特点以及GC优化建议
（1）由单个RPC带来的操作类垃圾对象是短期的
（2）Memstore是相对长期驻留的，按2MB为单位分配
（3）Blockcache是长期驻留的，按64KB为单位
（4）如何有效的回收RPC操作带来的临时对象是HBase的GC重点
（5）不建议HBase的堆大小操作超过64GB，否则GC压力大、执行时间太长
1.7RegionServer硬件建议
（1）服务器硬盘空间不大于6TB*RegionServer
（2）足够的内存堆大小（约等于硬盘空间/200）
（3）HBase对于Cpu要求高，越多core越好
（4）磁盘与网络的速度匹配
比如如果是24块硬盘，吞吐率为2.4GB/s，则网络需要至少万兆网络。而千兆网一般配4到6块硬盘
（5）更多的硬盘数量增加并发，提高HBASE的读性能
1.8读性能优化
（1）使用Redis、Memcache等第三方缓存
（2）使用Read Replica
（3）使用Bloom Filter
（4）Filter等过滤结果数据
（5）Block cache大小(查看cache的命中率)
（6）StoreFile（HFile）过多，导致查找效率降低。手工使用Compact（相比单个文件，10个StoreFile文件性能下降约50%-100%）
（7）本地化读写太差，网络IO消耗严重
1.9Hbase客户端性能优化
（1）使用批量数据处理接口
（2）保持2MB的chunk Size
（3）使用内存POOL缓存HTable及其他可重用对象
（4）使用多线程并发技术（Parallel Scanner）
（5）使用异步调用接口（AsyncClient）
（6）使用数据预取以及预缓存
1.10写性能优化
（1）Hbase理论平均写延时<10ms，时间复杂度为O(1)
（2）没有可用的handler响应（考虑增加handler数目或硬件资源）
（3）更常见的情况是95%-99%的写入都很快，但有些写入非常慢，甚至慢上万倍，一般问题都在服务端：
a、写入Memstore慢
①Hlog写入超时——考虑HDFS及硬盘异常
②GC——考虑优化内存使用（GC参数及算法调优有限）
b、Flush慢
①HFile写入超时——考虑HDFS及硬盘异常
②Compation被触发且运行时间长——优化高峰期Compaction策略
二、HBASE适用场景
（1）高并发高性能读写访问场景
数据有随机更新、删除
数据写入性能高于读取性能，适合写多读少或数据加载有实时性要求的场景
（2）需按主键排序的半结构化数据存储
（3）支持基于固定有限条件的高并发高性能查询
（4）高速计数器aggregation类型任务
HBase强一致性（Strongly consistent）读写保证
（5）其他适用Hadoop的NOSQL场景
HBase基于HDFS存储，和MapReduce/Hive/Spark等紧密结合
三、HBASE缺点
（1）SQL（传统BI）不友好，不支持很多传统的DBMS功能，如外键，约束
（2）数据无类型
（3）非RowKey查询性能差
（4）Column Family限制（数目，Partition对齐）
（5）Region资源消耗大，实例数目不能太多
（6）无法保证服务质量
（7）多租户隔离能力差
（8）大内存（>100GB）管理差
