本文主要是介绍HBase启动过于缓慢的原因及其优化策略，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
当HBASE导入了几十亿的数据记录时，某一天重启一下HBASE，发现启动过于缓慢，一直在提示PleaseHoldException:Master is initializing, 打开日志实时查看了下，其提示的信息一直是region transition 状态的各种变化。然而最惨的是，运行到最近，直接由于zookeeper超时，导致无法启动。
网上关于master is initalizing的问题解决都没有相应的问题。于是针对这个问题，只能仔细去摸一下Region的内核。
特别是从http://hbasefly.com/2016/09/08/hbase-rit/这篇博客中看到了整个region的状态迁移原理。
整个unassign操作是一个比较复杂的过程，涉及HMaster、RegionServer和Zookeeper三个组件：
1. HMaster负责维护Region在整个操作过程中的状态变化，起到一个枢纽的作用。它有两个重要的HashMap数据结构，分别为regionStates和regionsInTransition，前者用来存储整个集群中所有Region及其当时状态，而后者主要存储在变迁过程中的Region及其状态，后者是前者的一个子集，不包含OPEN状态的Regions；
2. RegionServer负责接收HMaster的指令执行具体unassign操作，实际上就是关闭region操作；
3. Zookeeper负责存储操作过程中的事件，它有一个路径为/hbase/region-in-transition的节点。一旦一个Region发生unssign操作，就会在这个节点下生成一个子节点，子节点的内容是一个“事件”经过序列化的字符串，并且Master会监听在这个子节点上，一旦发生任何事件，Master就会监听到并更新Region的状态。
通过上面的这段引摘，也就知道了自己的核心问题所在。由于自己在创建HBase表的时候，按照每个月建立一张独立的表，而在每个表里面则按小时创建了几百个预分区。从而一下子创建了太多的预分区。每次重启，都需要对预分区对应的region进行状态更新，而这一问题当超过了zookeeper的时间限制，则被强迫中止。这就是每次启动异常缓慢甚至中断的原因。
因此，在创建预分区的时候，所有的文章都没有说创建多少个预分区才合适，针对自己的应用，看来只有设置每个region大一些，同时再减少分区的个数，如减少到10个。这样看起来每次重启速度居然变得很快。可见region状态的迁移与其占用文件大小（在一定范围内）没有什么关系。
测试至此，终于要全部抛弃之前已有的数据，而在HBase无法正常启动的情况下，只能暴力进行HBase库的删除了。
这篇关于HBase启动过于缓慢的原因及其优化策略的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
