問題描述：
HBASE表的管理以REGION分割槽為核心，通常面臨如下幾個問題：
1） 資料如何儲存到指定的region分割槽，即rowkey設計，region splitkey設計
2）設計的splitkey是否可以解決熱點問題
3）設計的splitkey是否可以解決均勻分佈，避免自動分裂的問題
4）region的建立和刪除問題
對於1）問題 比如：對於按照時間儲存的資料，region splitkey 可以是2019,2020 ； 201901,201902；20190101 等等類似方式，可以把指定時間段的資料儲存到響應splitkey的region中，達到按照時間儲存的效果。
對於2）問題，同一天的資料，可以通過對rowkey或者資料中的一個或多個欄位取hash方式，解決熱點問題；如果資料存在重複入庫，則需要保證用於hash的欄位值在兩次入庫時不能變更，否則會存在兩個rowkey資料 即splitkey中包含hash值部分，同樣要求rowkey包含hash值
對於3）問題，需要考慮資料量和region分割槽的關係，比如一天有150G的資料量，hbase 單個region建議10~20G大小，設計時則需要考慮一天需要劃分多少的region，才能避免region在資料入庫時發生頻繁split，會影響hbase服務（split會涉及資料移動，資料通過網路傳輸和落盤，影響網路和磁碟IO）
對於4）問題，未來的region是否應該提前建立，如何建立？叢集儲存是否足夠，歷史的region是否下線或者刪除？
此篇文章是在提前建立region分割槽時遇到的問題
一般的設計方法是，在hbase 尾部region切分新的多個region，用於新的資料儲存，通常使用定時任務，提前建立
切分方式是通過呼叫HBASE split region方法，region尾部splitkey為 20210600 ~“” 需要切分的splitkey為20210601，20210602，20210603，20210700
採用的方法是： 先20210601切分，得到如下兩個region： 20210600 ~20210601， 20210601~“” 然後等待 20210601~“” 此region上線，再使用20210602切分
以此類推
但是在實際專案中發現，只切分了一個region就任務結束了，程式本身在等待新切分region上線時，可以等待1s~60秒中，發現此問題後，可以配置等待時長，
但是實際效果不好，仍會存在上述問題
1） 觀察Hbase regionServer端日誌，發現如下日誌，debug日誌顯示待切分region對應的儲存檔案正在被引用使用，導致region split請求切分失敗
2）分析Hbase 原始碼：
原因分析：hbase split請求呼叫的為非同步請求，通過原始碼並結合hbase regionserver日誌可以看出，hbase接收到split請求後，
如果發現需要被切分的region有引用檔案時，就返回失敗；因為時非同步請求，所以程式等待新切分region上線不可行
即Hbase接收到請求後，由於儲存檔案被引用使用，導致請求失敗，region未切分，索引新切分region不會上線，從而失敗
修改後方法邏輯為：切分region，等待一段時間上線，不上線則再次切分region，以此多次，仍不成功，則等待下次定時任務觸發切分
額外說明：
實際專案中被切分region如果裡面有大量資料，切分速度會很快，但是對切分後的region再次切分時，檔案引用有較長時間不會消失，無法再次切分
因此實際專案中考慮切分沒有資料的尾部region為佳，此外重試切分的時間間隔建議可配置，以免region未及時切分，導致所有資料存入到尾部一個region中