某大数据项目批处理集群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及其业务全部恢复正常。
hbase重启时，由于hfile文件较多，导致调整hbase.hstore.compaction参数后，产生大量的compaction.
hbase重启时，hbase在做region rebalance和split，进一步加剧了集群的负担，最终导致重启缓慢。
hbase集群region数较多，平均每个regionserver节点已经超过350个region。
hbase balance策略需要调整，rebalance一段时间后，又会分部不均。
制定hbase定期巡检计划，完善现有监控指标，实时掌握hbase集群健康情况。
随着hbase接入应用和数据的增加，定期和应用厂商反馈各方对hbase的使用情况，并要求应用定期对过期表进行清理。
常用hbase表建议应用使用天表。
改进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的热点问题。
更多精彩干货分享
点击下方名片关注
IT那活儿
