hbase如何判斷數據寫入哪一個region

HBase中，表會被劃分爲1...n個Region，被託管在RegionServer中。Region二個重要的屬性:StartKey與EndKey表示這個Region維護的rowKey範圍，當咱們要讀/寫數據時，若是rowKey落在某個start-end key範圍內，那麼就會定位到目標region而且讀/寫到相關的數據。簡單地說，有那麼一點點相似人羣劃分，1-15歲爲小朋友,16-39歲爲年輕人，40-64爲中年人,65歲以上爲老年人。(這些數值都是拍腦殼出來的，只是舉例，非真實),而後某人找隊伍，而後根據年齡，處於哪一個範圍，就找到它所屬的隊伍。
    而後，默認地，當咱們只是經過HBaseAdmin指定TableDescriptor來建立一張表時，只有一個region,正處於混沌時期，start-end key無邊界,可謂海納百川。啥樣的rowKey均可以接受，都往這個region裏裝，然而，當數據愈來愈多，region的size愈來愈大時，大到必定的閥值，hbase認爲再往這個region裏塞數據已經不合適了，就會找到一個midKey將region一分爲二，成爲2個region,這個過程稱爲分裂(region-split).而midKey則爲這二個region的臨界。

    如何找到midKey?涉及的內容比較多，暫且不去討論，最簡單的能夠認爲是region的總行數 / 2 的那一行數據的rowKey.雖然實際上比它會稍複雜點。
    若是咱們就這樣默認地，建表，表裏不斷地Put數據，更嚴重的是咱們的rowkey仍是順序增大的，是比較可怕的。存在的缺點比較明顯。
    首先是熱點寫，咱們老是會往最大的start-key所在的region寫東西，由於咱們的rowkey老是會比以前的大，而且hbase的是按升序方式排序的。因此寫操做老是被定位到那個region中。
    其次，因爲寫熱點，咱們老是往最大start-key的region寫記錄，以前分裂出來的region不會再被寫數據，有點被打進冷宮的趕腳，它們都處於半滿狀態，這樣的分佈也是不利的。
    若是在寫比較頻率的場景下，數據增加快，split的次數也會增多，因爲split是比較耗時耗資源的，因此咱們並不但願這種事情常常發生。

    看到這些缺點，咱們知道，在集羣的環境中，爲了獲得更好的並行性，咱們但願有好的load blance，讓每一個節點提供的請求處理都是均等的。咱們也但願，region不要常常split，由於split會使server有一段時間的停頓，如何能作到呢？
隨機散列與預分區。兩者結合起來，是比較完美的，預分區一開始就預建好了一部分region,這些region都維護着自已的start-end keys，再配合上隨機散列，寫數據能均等地命中這些預建的region，就能解決上面的那些缺點，大大地提升了性能。

   有時候根據本身的業務場景咱們可能只須要將rowkey隨機散列，所隨機出的rowkey有可能會小於第二個region的startkey並大於第一個region的startkey，這時候就與第一個region通訊，以此類推。雖然rowkey隨機化處理，不是將整個遞增的rowkey數據均雲分佈到全部的region，可是能夠保證大體的分佈