HBase StochasticLoadBalancer组件介绍
总体交互示意图
集群状态更新
主要包含以下两部分,分别代表集群负载和region分布;
clusterMetrics
各个regionserver会定时上报其负载数据到master,并存放在ServerManager组件中,ClusterStatusChore每分钟会将其连同其它信息一起更新到LoadBalancer中,LoadBalancer会保留最近15次的数据,后续在进行ReadRequest、WriteRequest和MemStoreSize等相关计算时,可以根据这些历史数据计算出最近一段时间的平均值;
clusterLoad
代表region在各个regionserver的分配情况,从AssignmentManager中获取;
生成plan
所谓plan,就是一些action的集合,action的类型有AssignRegionAction、MoveRegionAction和SwapRegionsAction三种;
而action由CandidateGenerator产生,目前主要是以下几种:
RandomCandidateGenerator
- 随机选择2个server,1个称为thisServer,另1个称为otherServer;
- 对于region数量更多的那个server,随机选出1个region;
- 对于region数量更少的那个server,有50%概率选出0个region,有50%概率选出1个region;
- 如果第3步选出了0个region,则返回MoveRegionAction,否则返回SwapRegionsAction;
LoadCandidateGenerator
- 将所有server按regionCount排序;
- 找出region最多和最少的2个server;
- 后续步骤与RandomCandidateGenerator一致;
LocalityBasedCandidateGenerator
- 将所有region打乱顺序;
- 遍历这些region;
- 获取当前这个region(称为fromRegion)的mostLocalServer(称为toServer),如果与当前所在server(称为fromServer)一致,则回到第2步,否则到下一步;
- 如果toServer的region数量小于平均值,则直接返回一个MoveRegionAction,否则到下一步;
- 遍历toServer上的region(称为toRegion),如果能找到一个region,与fromRegion交换可使得总体locality增加,则返回一个SwapRegionsAction,否则回到第2步;
CandidateGenerator每次生成一个action,都会对其进行收益判断,这个判断涉及到很多因子,每一种都对应一个CostFunction的实现,目前有如下这些:
CostFunction可以理解为损失函数,取值区间为0到1,越接近最佳状态,值越小;
对于MoveCostFunction来说,初始状态就是最佳状态,因为不需要任何移动,而移动所有region则是最差状态;
而对于其它CostFunciton,则需要分别去考虑最差和最佳时的值具体是什么,比如对于RegionCountSkewCostFunction,最差状态是所有reigon都集中在单个regionserver上,而最佳状态是所有regionserver上的region数量都等于平均数;
值得注意的是,对于ServerLocalityCostFunction及其它数据本地化相关因子来说,最佳状态并非是完全本地化,而是基于当前hdfs的block分布状态,所能达到的最大本地化值,
收益的判断需要对doAction之前和之后的totalCost进行比较,而totalCost是对各个因子的cost加权求和得到的,如下所示,实线框为初始状态时的cost,模拟执行了action之后得到了虚线框代表的cost,有的增加有的减小,最后综合下来的增减情况就代表了执行该action是否有价值;
CandidateGenerator生成action的次数有一定限制,称为maxStep,该值与集群配置以及集群规模相关;
执行plan
plan的执行本质上是执行一系列的MoveRegionProcedure,MoveRegionAction会对应一个MoveRegionProcedure,而SwapRegionsAction会对应两个MoveRegionProcedure;
计划执行时,会进行总体执行时间的限制,默认取balance执行间隔的值(hbase.balancer.max.balancing),即300s,另外,还可限制总体处于rit状态的region的比例(hbase.master.balancer.maxRitPercent),默认为1.0,即不限制;
一些配置参数
判断阶段
1、hbase.master.balancer.stochastic.minCostNeedBalance
需要balance的最小cost,即与理想状态的偏差,默认值为0.05;
生成plan
1、hbase.master.balancer.stochastic.maxSteps
生成后选action的最大次数,默认值为1000000;
2、hbase.master.balancer.stochastic.runMaxSteps
该值本质上是用来决定把maxSteps作为上限还是作为下限,默认false,即作为上限;
(实际的最大步数,会由动态计算的一个值,与maxSteps进行比较,来选取一个)
3、hbase.master.balancer.stochastic.maxRunningTime
生成plan最多可用时间,默认值为30s;
4、hbase.master.balancer.stochastic.stepsPerRegion
默认800次,该参数会和region数量以及server数量相乘,来得到动态计算的step值;
cost计算相关
MoveCostFunction
1、hbase.master.balancer.stochastic.moveCost
moveCost权重,默认值为7;
2、hbase.master.balancer.stochastic.maxMovePercent
最大可移动的region比例,默认值为0.25;
3、DEFAULT_MAX_MOVES
常量值600,会与maxMovePercent得到的值取max,作为实际可移动数,这意味着max_moves至少为600;
4、当超出实际maxMove时,cost会返回1个很大的值1000000,从而否决掉当前action;
RegionCountSkewCostFunction
1、hbase.master.balancer.stochastic.regionCountCost
regionCountCost权重,默认值为500;
CostFromRegionLoadFunction(abstract)
1、hbase.master.balancer.stochastic.numRegionLoadsToRemember
最多保留的历史regionLoad数量,默认值为15,基于这些历史load,会先算出每次的增量,然后取平均后作为实际load(适用于MemStoreSizeCostFunction、ReadRequestCostFunction、WriteRequestCostFunction);
MemStoreSizeCostFunction
1、hbase.master.balancer.stochastic.memstoreSizeCost
默认值为5;
StoreFileCostFunction
1、hbase.master.balancer.stochastic.storefileSizeCost
默认值为5;
ReadRequestCostFunction
1、hbase.master.balancer.stochastic.readRequestCost
默认值为5;
WriteRequestCostFunction
1、hbase.master.balancer.stochastic.writeRequestCost
默认值为5;
ServerLocalityCostFunction
1、hbase.master.balancer.stochastic.localityCost
默认值为25;
RackLocalityCostFunction
1、hbase.master.balancer.stochastic.rackLocalityCost
默认值为15;
TableSkewCostFunction
1、hbase.master.balancer.stochastic.tableSkewCost
默认值为35;
PrimaryRegionCountSkewCostFunction
1、hbase.master.balancer.stochastic.primaryRegionCountCost
默认值为500;
RegionReplicaHostCostFunction
1、hbase.master.balancer.stochastic.regionReplicaHostCostKey
默认值为100000,主要识别region的各个副本集中到相同host的程度,权重很高,意味着基本上不允许出现;
RegionReplicaRackCostFunction
1、hbase.master.balancer.stochastic.regionReplicaRackCostKey
默认值为10000,主要识别region的各个副本集中到相同rack的程度,权重较高,意味着不赞成这种状态;
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
HBase blockcache原理介绍
1.核心组件 总入口是CacheConfig,这个类根据配置信息,来返回不同的具体cache组件; 默认会返回LruBlockCache,所有类型的block都会存入; 启用了BucketCache时,会返回CombinedBlockCache,此类中根据block类型,data block存入BucketCache,其它存入LruBlockCache; 2.LruBlockCache LruBlockCache内部较为简单,主要就是一个map,如上图所示,由hfilename+offset来唯一标识一个block; LruBlockCache所能够使用的内存为堆的一定比例,通过hfile.block.cache.size设置,默认是0.4; so,maxSize = heapSize * hfile.block.cache.size,以下参数都根据maxSize计算; acceptSize: 使用量达到一定比例时会触发驱逐,该阈值通过hbase.lru.blockcache.acceptable.factor设置,默认是0.99; minSize: 驱逐后最少剩余比例,该阈值通过hb...
- 下一篇
【云栖号案例 | 政府】海关总署通过数据底盘的建设 得到“人脑”归类智能模型
云栖号案例库:【点击查看更多上云案例】不知道怎么上云?看云栖号案例库,了解不同行业不同发展阶段的上云方案,助力你上云决策! 公司介绍 中国海关总署是中华人民共和国国务院下属的正部级直属机构,统一管理全国海关。近年来,海关顺应互联网发展潮流,坚持“顶层设计”与“摸着石头过河”相结合,充分尊重并积极发挥基层首创精神。 选择阿里云 对报关单的商品归类进行征管审核需要非常强的专业技巧,经常出现人手不足的情况,通过大数据咨询与实施服务,阿里云帮助海关实现了数据底盘的汇聚层、公共层等的建设,为海关大数据云的亮点应用及十几个大数据应用的上线提供了强大的数据底座和技术支撑,使海关可以对海量商品名称、品牌、规格型号进行自然语言分析学习,并对归类结果进行训练,从而得到一个趋近于“人脑”的归类智能模型,可以对所有报关单进行智能预审核。在上海海关试点,对有税差报关单的查货能力提升了5倍之多。 获得的成效 通过数据底盘的建设,打造了数据应用的生长平台,扫除了缺少数据及计算瓶颈等障碍,同时提高了整体计算效率与数据质量。 相关产品和服务 相关产品: DataWorks DataWorks是一个提供了大数据OS能力、...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7设置SWAP分区,小内存服务器的救世主
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题