一、性能优化
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)管理差