资讯专栏INFORMATION COLUMN

Hbase regionserver服务重启后region加载慢问题分析

IT那活儿 / 3596人阅读
Hbase regionserver服务重启后region加载慢问题分析

某大数据项目批处理集群hbase出现查询超时,应客户和应用侧要求,重启了hbase服务。重启hbase后,在加载region的时候速度较慢,导致日志中心业务无法正常写入、数据汇聚业务无法正常读取。


由于应用侧反馈无法正常查询hbase表,因此和客户及应用侧协商确认后,针对hbase修改hbase.hstore.compaction.max=30参数,然后重启hbase集群。

重启后发现hbase加载region很慢,登入hbase集群后从后台查看hbase表发现很多表region未上线,后台查询hbase表失败。


查看hmaster ui界面发现很多region处于regions in transition状态。且重启前region数正常有7.5w左右,而目前加载的只有2w7左右。

排查hmaster日志,发现hbase正在做major compact和balance,且compact持续了很久,日志中显示region注册时,从hdfs上获取block失败,导致大量的skip信息。

恢复配置,重新重启hbase集群,发现重启仍然很慢。

全部停止hbase集群,只启动hbase master节点上的的hmaster服务,然后重启regionserver,发现重启仍然很慢,查看日志,发现master初始化超时失败:


修改参数


hbase.master.namespace.init.timeout=36000000

hbase.master.initializationmonitor.timeout=48000000


参数调整完毕后,重新启动整个hbase(只启动226节点的hmaster),等待region加载上线。

后台测试hbase,新建表和读写都正常,日志中心业务恢复正常,但针对部分历史大数据量的表读写仍然失败。

查看region,仍有处于RIT状态的:

针对部分上线困难的region使用assign regionname命令手动上线:


经过处理后,region全部加载完成,没有发现处于RIT状态的region,hbase及其业务全部恢复正常。


故障原因


  1. hbase重启时,由于hfile文件较多,导致调整hbase.hstore.compaction参数后,产生大量的compaction.

  2. hbase重启时,hbase在做region rebalance和split,进一步加剧了集群的负担,最终导致重启缓慢。


遗留问题


  1. hbase集群region数较多,平均每个regionserver节点已经超过350个region。

  2. hbase balance策略需要调整,rebalance一段时间后,又会分部不均。


改进措施


  1. 制定hbase定期巡检计划,完善现有监控指标,实时掌握hbase集群健康情况。

  2. 随着hbase接入应用和数据的增加,定期和应用厂商反馈各方对hbase的使用情况,并要求应用定期对过期表进行清理。

  3. 常用hbase表建议应用使用天表。

  4. 改进hbase rebalance策略,确保regionserver上region均衡分部。


结合此次故障暴露出的问题,我们总结了Hbase模型设计方面的一些规范和建议:

  • HBase在新建一个表时如果不指定预分配Region,则默认为该表只分配一个Region。在数据加载时,所有数据都会加载到该Region,导致单节点负载过高,加载性能降低,从而影响入库性能。因此需要在建表时预先为该表在所有节点上分配多个Region,从而将所有节点高效利用起来。

  • 预建Region的个数需要根据话单文件大小和节点个数来确定。由于每个Region大小超过一定数值后,HBase会自动进行Region分裂,导致Region不均匀,使得各台节点的压力不均,影响HBase的性能,因此预建Region的基本原则是尽量避免Region的自动分裂。

  • 根据最佳实践经验,每个RegionServer上的Region个数为100左右的情况下HBase性能最好。因此每张表预建的Region数目应当小于等于100*RegionServer个数/表的个数。同时每个Region的文件大小(hbase.hregion.max.filesize)推荐配置为10GB,并在每天晚上空闲时对表做major_compact处理,以提高HBase的查询性能。

  • 访问模式是HBase设计的主要部分,弄清应用将如何访问数据,识别被访问的数据类型。大多数应用可以分成读操作密集或写操作密集两种,以及读写均密集型,需要针对不同的访问模型来设计不同的rowkey。

  • 使用salted或promoted字段行键可以在写的分布和顺序读取得较好的平衡,如果你只做随机读,使用随机key是最合理的。可以避免region的热点问题。


END


更多精彩干货分享

点击下方名片关注

IT那活儿

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/129917.html

相关文章

  • HBase运维基础——元数据逆向修复原理

    摘要:本文就运维的原理基础开始入手,重点讲解数据完整性,以及元数据逆向工程恢复数据完整性的原理方法。小结本文介绍了运维基础原理中的数据完整性以及逆向元数据修复原理,并举例介绍两个逆向修复元数据的工具和实用执行步骤。 背景鉴于上次一篇文章——云HBase小组成功抢救某公司自建HBase集群,挽救30+T数据的读者反馈,对HBase的逆向工程比较感兴趣,并咨询如何使用相应工具进行运维等等。总的来...

    ctriptech 评论0 收藏0
  • HBase 托管Hadoop集群 UHadoop

    摘要:如果频繁遇到这个问题可能是的参数或者其他方面设置的不合理,需要调整一下。 HBase本篇目录HBase某一个表数据无法写入,也无法读取,从WebUI界面查看到有多个Region状态为region in transaction是因为?读取、写入数据时,为什么找不到region?HBase某一个表数据无法写入,也无法读取,从WebUI界面查看到有多个Region状态为region in tran...

    ernest.wang 评论0 收藏183

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<