Hbase寫入量大導緻region過大無法split問題

最近線上上往hbase導資料，因為hbase寫入能力比較強，沒有太在意寫的問題。讓業務方進行曆史資料的導入操作，中間發現一個問題，寫入速度太快，并且業務資料集中到其中一個region，這個region無法split掉，處于不可用狀态。這裡描述一整個過程——

        事情的起因：業務方按照userid和商品id作為rowkey字首，并沒有進行hash散列。我當時咨詢過業務方，認為：1.業務方式按照oracle的rowid順序來進行遷移的，相對來說對應到rowkey裡面就不會集中化；2.即使出現部分集中的情況，hbase也能夠通過自動split來hold住寫入。

        結果線上寫入的時候，12台機器的情況下業務方寫入達到50~60w tps，基本上5w tps每台的寫入速度。開始的時候region還能夠自動split，比較好，寫入速度也能夠保持，但是到了第二天，發現寫入在region次元的分布很不均衡，于是檢視表的region size 情況，有一個region資料量特别大——800GB，700+個檔案。

       這裡也分析一下為什麼hbase會讓這麼大的region存在，其實這塊hbase的控制機制也是值得商榷的。首先，大量的寫入會刷大量的HFile，一個region就會對這大量的hfile進行compact操作。如果這時候觸發了split操作，這個region會成為父region，而兩個子region會保留父region的引用檔案。而在這其間，子region會繼續寫入資料。那麼又可能觸發子region的compact，這裡的關鍵點來了——子region如果做compact的檔案都是新寫入的檔案，而遲遲不去compact父region

引用的檔案，會導緻一個問題——就是這個子region無法被split掉了（因為含有父region引用的region是不能被split的）。那麼子region越來越大，由于寫入檔案數量急劇增長，父region的ref檔案總也得不到機會compact，就形成了大region的惡性循環情況——由于region太大，compact無法完成，但是由于compact無法完成導緻region無法split，無法分攤compact的壓力給其他regionserver。當然還得加上最後一點外部大量的寫入沒有停止——這裡我們通常了解，hbase有一個參數hbase.hstore.blockingStoreFiles=30,當region下的hfile達到30個的時候是會阻塞寫的。那我都bolck住寫了，為什麼region裡hfile會到700這麼多呢？原來還有另一個參數hbase.hstore.blockingWaitTime=30000.hbase考慮到對應用的影響不會長時間block住寫，30秒後會恢複。

      這裡總結一下這個問題，對于大批量導入資料，1、還是必須讓業務方對rowkey進行預分片，對業務資料rowkey進行md5或者其他的hash政策，讓資料盡量随機分布而不是順序寫入。2、随時觀察region的大小，是否出現大region的情況。

      這個問題預防為主，如果出現大region——優先考慮重導資料，其次使用patch。