Hbase性能优化

  1. 云栖社区>
  2. 博客>
  3. 正文

Hbase性能优化

ylwang 2018-07-18 21:25:26 浏览864
展开阅读全文
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/tomnic_ylwang/article/details/81105619

一、性能优化

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

 

网友评论

登录后评论
0/500
评论