Hbase性能优化

简介: 版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/tomnic_ylwang/article/details/81105619 一、性能优化1.
版权声明:本文为博主原创文章,未经博主允许不得转载。 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)管理差

 

相关实践学习
lindorm多模间数据无缝流转
展现了Lindorm多模融合能力——用kafka API写入,无缝流转在各引擎内进行数据存储和计算的实验。
云数据库HBase版使用教程
&nbsp; 相关的阿里云产品:云数据库 HBase 版 面向大数据领域的一站式NoSQL服务,100%兼容开源HBase并深度扩展,支持海量数据下的实时存储、高并发吞吐、轻SQL分析、全文检索、时序时空查询等能力,是风控、推荐、广告、物联网、车联网、Feeds流、数据大屏等场景首选数据库,是为淘宝、支付宝、菜鸟等众多阿里核心业务提供关键支撑的数据库。 了解产品详情:&nbsp;https://cn.aliyun.com/product/hbase &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
6月前
|
存储 缓存 分布式数据库
HBase的性能优化有哪些方法?
HBase的性能优化有哪些方法?
259 0
|
6月前
|
缓存 分布式计算 分布式数据库
巧用ChatGPT 解决 Hbase 快照方式读性能优化问题
巧用ChatGPT 解决 Hbase 快照方式读性能优化问题
87 0
|
存储 缓存 Java
HBase最佳实践-读性能优化策略
任何系统都会有各种各样的问题,有些是系统本身设计问题,有些却是使用姿势问题。HBase也一样,在真实生产线上大家或多或少都会遇到很多问题,有些是HBase还需要完善的,有些是我们确实对它了解太少。总结起来,大家遇到的主要问题无非是Full GC异常导致宕机问题、RIT问题、写吞吐量太低以及读延迟较大。
2137 0
|
存储 缓存 Java
技术篇-HBase 最佳实践-读性能优化策略
任何系统都会有各种各样的问题,有些是系统本身设计问题,有些却是使用姿势问题。HBase也一样,在真实生产线上大家或多或少都会遇到很多问题,有些是 HBase 还需要完善的,有些是我们确实对它了解太少。总结起来,大家遇到的主要问题无非是 Full GC 异常导致宕机问题、RIT 问题、写吞吐量太低以及读延迟较大。
2439 0
|
存储 监控 分布式数据库
HBase学习笔记——基于HBase的日志系统的性能优化
我之前参与过一个日志系统的开发,存储用HBase。我简单罗列下用到的HBase优化,备忘。以后把它整理成更友好的介绍性文章。 # 系统简介 * 有一张大的日志数据表,保存所有日志。row key是 hash + app id + log-severity + timestamp + host等,cell保存日志正文数据。 * 可以看到row key的hash保证日志散列在各
1318 0
|
存储 监控 Java
Hbase万亿级存储性能优化总结
背景       hbase主集群在生产环境已稳定运行有1年半时间,最大的单表region数已达7200多个,每天新增入库量就有百亿条,对hbase的认识经历了懵懂到熟的过程。为了应对业务数据的压力,hbase入库也由最初的单机多线程升级为有容灾机制的分布式入库,为及早发现集群中的问题,还开发了一套对hbase集群服务和应用全面监控的报警系统。
3016 0
|
存储 算法 Java
HBase性能优化指南
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq1010885678/article/details/51957401 垃圾回收...
1205 0