?最近在線上往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秒后會恢復。

? ? ? 這里天梧有提一個改進的compact算法，優先去compact從父region引用過來的hfile，讓region有split的可能，能在一定程度上緩解這個問題http://kelude.taobao.net/issues/543434?，這個方法我使用過，只能在一定程度上緩解問題，對于800G大小的region，一天都沒有compact掉。所以只適合100G以內的region，并且這時候業務方還不能有大量的寫操作。但有趣的是一般如此程度的寫入壓力都是在業務方新導入數據的時候造成的，所以和業務方溝通一下讓他們重導數據比自己慢慢郁悶的compact這個大region來的要快的多。但是在重新導之前就要好好改進一下了：

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

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

轉載于:https://www.cnblogs.com/bluecoder/p/3890820.html

總結

以上是生活随笔為你收集整理的Hbase写入量大导致region过大无法split问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。