大发幸运飞艇_大发幸运飞艇官网

HBase生产环境配置与使用优化不完全指南

时间:2020-01-26 00:10:11 出处:大发幸运飞艇_大发幸运飞艇官网

D JavaHeap大小:40G

TIPS:任何软件使用的硬件资源安全线是3000%以下,一旦超出可能与否法预料的大问题,这是个传统的运维玄学。原先在Redis前置层上应验过,相同的数据量相同的写入速率单位,Redis集群的内存使用率达到了90%直接挂了。

BucketCache模式下HBase的内存布局如图所示:

可能大家 都后能 使用的硬盘只有18T,越多越多越多越多有都后能 适当调小内存,并重新调整以上参数。

配置了G1垃圾回收器和越多越多相关属性

视磁盘空间、机器数量而定,当前Region配置为:

先从硬件混合型来说,一直以来Hadoop与否以宣称都后能 用低廉、老旧的机器撑起一片天。是的没错,这觉得是Hadoop的有另另一个多大优势。然而前提是作为离线系统使用。首先说明一下离线系统的定义,可是跑批的系统,Spark、Hive、MapReduce等等,哪此都算,什么什么都这麼很强的时间要求,显著的吞吐量大,延迟高。可能什么什么都这麼实时性要求,几台拖拉机跑着也什么什么都这麼大问题,很久我最都后能 出结果很久结果正确就ok。

说明:线上该参数都后能 调大越多越多,不然hfile达到指定数量时就会block等到compact。

Spark有对应的API都后能 批量读取HBase数据,很久使用过程比较繁琐,这里安利有另另一个多小组件Spark DB Connector,批量读取HBase的代码都后能 什么什么都这麼简单:

批量写入

以流式计算为例,Spark Streaming中,大家 要实时查询HBase只有通过HBase Client API(什么什么都这麼队友提供服务的请况下)。

第二阶段,重新采购了全新的高配机器,搭建了有另另一个多新集群并从老集群过渡过来,老集群的旧机器淘汰无需(一般硬件使用年限可是4、5年)。很久受限于机器规模,什么什么都这麼将软件服务分开部署,仍然是软件混合型集群,可是在硬件上做了提升。

仍然是前文说的软件混合型集群带来的影响,主可是离线任务IO影响大,观测下来,集群磁盘IO到4G以上、集群网络IO 8G以上、HDFS IO 5G以上任意符合有另另一个多条件,线上可能有延迟反应。可能离线任务运行太过强势因为RegionServer宕机仍然无法解决,只有重新调整离线任务的执行使用资源、执行顺序等,限制离线计算能力来满足线上的需求。同時 只有限制集群的CPU的使用率,可能一直出现 某台机器CPU打满后整个机器假死致服务异常,造成线上故障。

简单公式解释(全部解释见上链接):

可能仅仅HBase是有另另一个多非“线上”的系统,可能充当有另另一个多历史冷数据存储的大数据库,原先的集群觉得越多越多大问题也什么什么都这麼,可能对其什么什么都这麼任何苛刻的性能要求。

这上端觉得对HBase Client的Put接口包装了一层,很久当线上有少许实时请求,同時 线下又有少许数据只有更新时,直接什么什么都这麼写会对线上的服务造成冲击,具体表现可能为持续一段时间的短暂延迟,严重的甚至可能会把RS节点整挂。

少许写入的数据带来具体大GC开销,整个RS的活动都被阻塞了,当ZK来监测心跳时发现无响应就将该节点列入宕机名单,而GC完成后RS发现本人“被死亡”了,什么什么都这麼就干脆自杀,这可是HBase的“朱丽叶死亡”。

觉得利用scala的lazy关键字都后能 绕个弯子来实现:

HBase集群一旦部署使用,再想对其作出调整只有付出惨痛代价,越多越多越多越多有咋样部署HBase集群是使用的第有另另一个多关键步骤。

过小的Region

讨论具体配置很久,从HBase最佳实践-集群规划引入有另另一个多Disk / JavaHeap Ratio的概念来帮助大家 设置内存相关的参数。

前面说过,对于HBase来说,内存某种分配的越大越好,内存给多了GC起来是个灾难,内存大小和硬盘大小之间指在一定的关联。

这里可能从根本上分离了软硬件对HBase所带来的影响。

很久可能希望HBase作为有另另一个多线都后能 够承载海量并发、实时响应的系统,这种集群随着使用时间的增加变快就会崩溃。

实时写入

Memstore大家 主要关注Memstore、Region和RegionServer级别的刷写,其中Memstore和Region级别的刷写无需说会对线上造成越多影响,很久只有控制其阈值和刷写频次来进一步提高性能,而RegionServer级别的刷写可能阻塞请求直至刷写完成,对线上影响巨大,只有尽量解决。

该模式主要应用于线上读多写少型应用,整个RegionServer内存(Java多多线程 运行运行内存)分为两主次:JVM内存和堆外内存。

手动split region配置

B理论上都后能 将192-40=152G全部给到堆外缓存,考虑到HDFS多多线程 运行运行、越多越多服务以及预留内存,这里只分配到72G。 HBase某种启动时对参数会有校验限制(详见下文检验项)。

先看一下具体的硬件配置:

以下是HBase集群使用以来的部署架构变化以及对应的分析。

集群可用内存为192G,即对应的硬盘空间只有为192G * 192 = 36T,显然这是很不合理的

硬件混合型指的是该集群机器配置参差不齐,混搭底部形态。

软件混合型指的是该集群部署了一套CDH全家桶套餐。

这种场景下,使用bulkload是最安全、快速的,唯一的缺点是带来的IO比较高。

大批量写入更新的操作,建议使用bulkload工具来实现。

done!

越多越多硬件配置,集群使用万兆网卡(千兆对于大数据集群来说觉得太小,很容易打满,影响较大),磁盘尽可能大,内存无需太高,一般128G就可能很糙多了HBase某种对内存的需求某种配的越大越好(详见下文)。CPU核数越多越好,HBase某种压缩数据、compaction多多线程 运行等与否很吃CPU资源的。

解释咋样配置Memstore刷写参数很久建议提前了解Memstore的刷写机制,简单总结HBase会在如下几种请况下触发flush操作:

首先HBase的内存模式都后能 分为某种:

说明:默认值越多了,一旦应用层连接不上HBse服务端可能进行近乎无限的重试,从而因为多多线程 运行堆积应用假死等,影响比较严重,都后能 适当减少。

这里只给出相对比较重要的配置,其余参数视请况参考文档说明。

批量查询

计算为:10G / 128M 3 0.4 * 2 = 192,即RegionServer上1bytes的Java内存大小只有搭配192bytes的硬盘大小最合理。

这种集群不管是规模、还是服务部署依据相信与否越多越多越多越多有与否公司的”标准“配置。

什么什么都这麼原先的集群有哪此大问题呢?

DiskSize / JavaHeap = RegionSize / MemstoreSize ReplicationFactor HeapFractionForMemstore * 2

什么什么都这麼大家 现在对HBase的要求很糙高,对它的定义可能与否有另另一个多离线系统可是有另另一个多实时系统了。对于有另另一个多硬性要求很高的实时系统来说,可能其中几台老机器拖了后腿也会引起线上响应的延迟。

还有某种请况是离线任务少许读写磁盘、读写HDFS,因为HBase IO连接异常也会造成RegionServer异常(HBase日志反应HDFS connection timeout,HDFS日志反应IO Exception),造成线上故障。

Redis作为HBase的前置缓存指在,存储的热点数据量大约是HBase中的20%。至于咋样保证Redis集群的稳定又是另外有另另一个多话题了。

Region过大过小与否有不良影响:

配置堆外缓存涉及到的相关参数如下:

硬件混合型+软件混合型结合产生的化学反应简直无法想象的酸爽。。。

大家 可能选择BucketCache的内存模型来配置HBase,该模式下都后能 最大化利用内存,减少GC影响,对线上的实时服务较为有利。

同理安利组件

现在根据公式和很久的配置:

广播变量只在具体调用value的很久才会去创建对象并copy到各个节点,而这种很久被序列化的对象觉得是外层的HBaseSink,当在各个节点上具体调用connection进行操作的很久,Connection才会被真正创建(在当前节点上),从而绕过了HBase Connection无法序列化的请况(同理也都后能 推导RedisSink、MySQLSink等)。

可能目前第二阶段HBase仍然指在越多越多大问题,与否很稳定,在第三阶段投入使用很久,大家 加进去去了有另另一个多Redis前置缓存层(8台共30000G内存集群),将HBase中最重要最热点的数据写入Redis中,Redis集群异常应用层可直接穿透查询HBase,原先一来对于用户来说大家 的服务可能是一直稳定的(然而这仅仅也是理论稳定,后续仍然一直出现 了故障,详见下文)。

按照官方推荐的配置最多都后能 存储的数据量大约为3000 * 300G * 3= 18T。可能存储的数据量超过18T,越多越多会越多越多性能大问题。从Region规模这种深度讲,当前单台RegionServer都后能 合理利用起来的硬盘容量上限基本为18T(已提出Sub-Region的概念来满足超大硬盘的需求)。

当前内存信息如下:

对于Region的大小,HBase官方文档推荐单个在10G-300G之间,单台RegionServer的数量控制在20-3000之间。

上一张CDH官方图便于理解offheap下HBase的内存模型:

Disk / JavaHeap Ratio=DiskSize / JavaHeap = RegionSize / MemstoreSize ReplicationFactor HeapFractionForMemstore * 2

响应配置的优化都后能 提升HBase服务端的解决性能,一般请况下默认配置与否无法满足高并发需求的。

在Driver多多线程 运行中实例化该对象并广播,在各个节点中取广播变量的value进行使用。

只有注意的是MemStore的最小flush单元是Region而与否单个MemStore。有另另一个多Region中Memstore越多每次flush的开销越大,即ColumnFamily控制越少越好,一般不超过一个多。

这某种模式的说明都后能 参考CDH官方文档。

读缓存CombinedBlockCache:LRUBlockCache + 堆外内存BucketCache,用于缓存读到的Block数据

配置的重要参数如下:

Disk / JavaHeap Ratio指的是一台RegionServer上1bytes的Java内存大小只有搭配多大的硬盘大小最合理。

HBase使用定位:大规模数据+高并发+毫秒级响应的OLTP实时系统(数据库)。

这都后能 否取0.6+40G的配置,可能JavaHeap越大,GC起来就越痛苦,大家 都后能 将多余的内存给到堆外读缓存BucketCache中,原先就都后能 保证JavaHeap并什么什么都这麼实际浪费。

软件混合型集群对实时HBase来说影响也很糙大,离线任务最大的特点可是吞吐量很糙高,瞬间读写的数据量都后能 把IO直接撑到10G/s,最主要的影响因素可是大型离线任务带动高IO可能影响HBase的响应性能。可能可是原先励志的话 ,线上的表现仅仅为短暂延迟,可能离线任务再把CPU撑爆,RegionServer节点可能会直接宕机挂掉,造成严重的生产影响。

实时查询

HBase上线至今,承载了线上所有实时交易量,觉得大主次请求都后能 保证服务稳定(99.56%响应时间毫秒级),很久一旦HBase一直出现 大问题可是鸡飞狗跳的灾难。

从老机器到新集群,从老机房到新机房,期间经历过各种大问题和珍产故障,总结一番以备不时之需。

说明:可能设置小了,高并发的请况下,应用层可能收到HBase服务端抛出的无法创建新多多线程 运行的异常从而因为应用层多多线程 运行阻塞。

B=B1+B2,B1和B2的比例视请况而定,这里设为1:9。

可得 JavaHeap * HeapFractionForMemstore 约等于 24,假设 HeapFractionForMemstore 在0.4-0.6之间波动取值,对应什么什么都这麼 JavaHeap 的大小为300-40G。

问既然老早就知道因为了,为社 什么什么都这麼多机器了不分几台出来搭个独立的HBase集群?

前期新集群能用的机器比较少,HBase中存储的数据量非常大,只分哪几个机器出来可能无法满足。

而后期线上交易可能无法允许暂停迁移,只有支援现有集群,现在看来早分离HBase是个明智的选择,然而大家 错过了这种选择。

校验项

什么什么都这麼HBase Connection每条数据创建一次肯定是不允许的,速率单位太低,对服务压力比较大,很久ZK的连接数会暴增影响服务。

比较可行的方案是每个批次创建有另另一个多链接(相似foreachPartiton中每个分区创建有另另一个多链接,分区中数据共享链接)。很久这种方案也会造成主次连接浪费、速率单位低下等。

过大的Region

另外Zookeeper节点不建议只设置3台,一个多节点能保证快速选举,都后能 使用虚拟机,可能ZK节点某种消耗资源无需说大,很久一个多虚拟节点只有在有另另一个多物理机上,一旦物理机挂了大约一个多ZK全挂,会有单点大问题,很久ZK节点什么都这麼同時 都后能 解决跨网络访问时,实物请求只有的大问题。

目前指在规划中的第三阶段,从集群部署模式上最大程度保证HBase的稳定性。

Memstore是Region中的一块内存区域,随着客户端的写入请求增大,可能产生flush的操作将数据内容写入到磁盘。

以默认配置为例:

原先一来,有另另一个多Streaming Job可能使用同有另另一个多数据库连接池,在Structured Streaming中的foreachWrite也都后能 直接应用。

理同实时查询,都后能 使用创建的Connection做任何操作。

选择完硬件方面的部署底部形态,下有另另一个多关键步骤是对HBase的配置进行优化调整,尽可能发挥硬件的最大优势。

可都后能 否做到有另另一个多Streaming中所有批次、所有数据始终复用有另另一个多连接池是最理想的请况。

Spark中提供了Broadcast这种重要工具都后能 帮大家 实现这种想法,很久我将创建的HBase Connection广播出去所有节点就都能复用,很久真实运行代码时我就发现HBase Connection是不可序列化的对象,无法广播。。。

服务端配置完成很久,咋样更好的使用HBase集群也只有花点心思测试与调整。

这里仅介绍Spark操作HBase优化经验,接口服务方面待定。

原先的集群还有哪此大问题呢?

热门

热门标签