一、性能优化

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）管理差