hbase（二）-hbase設計以及原理

一、簡介

HBase —— Hadoop Database的簡稱，Google BigTable的另一種開源實現方式，從問世之初，就爲了解決用大量廉價的機器高速存取海量數據、實現數據分佈式存儲提供可靠的方案。從功能上來講，HBase不折不扣是一個數據庫，與我們熟悉的Oracle、MySQL、MSSQL等一樣，對外提供數據的存儲和讀取服務。而從應用的角度來說，HBase與一般的數據庫又有所區別，HBase本身的存取接口相當簡單，不支持複雜的數據存取，更不支持SQL等結構化的查詢語言；HBase也沒有除了rowkey以外的索引，所有的數據分佈和查詢都依賴rowkey。所以，HBase在表的設計上會有很嚴格的要求。架構上，HBase是分佈式數據庫的典範，這點比較像MongoDB的sharding模式，能根據鍵值的大小，把數據分佈到不同的存儲節點上，MongoDB根據configserver來定位數據落在哪個分區上，HBase通過訪問Zookeeper來獲取-ROOT-表所在地址，通過-ROOT-表得到相應.META.表信息，從而獲取數據存儲的region位置。

二、架構

上面提到，HBase是一個分佈式的架構，除去底層存儲的HDFS外，HBase本身從功能上可以分爲三塊：Zookeeper羣、HMaster羣和HRegionServer羣。

• Zookeeper羣：HBase集羣中不可缺少的重要部分，主要用於存儲Master地址、協調Master和RegionServer等上下線、存儲臨時數據等等。
• HMaster羣：Master主要是做一些管理操作，如：region的分配，手動管理操作下發等等，一般數據的讀寫操作並不需要經過Master集羣，所以Master一般不需要很高的配置即可。
• HRegionServer羣：RegionServer羣是真正數據存儲的地方，每個HRegionServer由若干個region組成，而一個region維護了一定區間rowkey值的數據，整個結構如下圖：
  
  HBase結構圖 ——注：準確的說位於上圖下半部分的組建應該是hdfs而非hadoop，hbase並不依賴於hadoop，但是它構建於hdfs之上。

2.1、Zookeeper：

Zookeeper Quorum存儲-ROOT-表地址、HMaster地址
HRegionServer把自己以Ephedral方式註冊到Zookeeper中，HMaster隨時感知各個HRegionServer的健康狀況
Zookeeper避免HMaster單點問題

2.2、HMaster：

（HMaster沒有單點問題，HBase中可以啓動多個HMaster，通過Zookeeper的MasterElection機制保證總有一個Master在運行。）
主要負責Table和Region的管理工作：
1 管理用戶對錶的增刪改查操作
2 管理HRegionServer的負載均衡，調整Region分佈
3 Region Split後，負責新Region的分佈
4 在HRegionServer停機後，負責失效HRegionServer上Region遷移
5 HDFS上的垃圾文件回收
6 處理schema更新請求

2.3、HRegionServer：

HBase中最核心的模塊，主要負責響應用戶I/O請求，向HDFS文件系統中讀寫數據

2.4、HStore：

HBase存儲的核心。由MemStore和StoreFile組成。
MemStore是Sorted Memory Buffer。用戶寫入數據的流程：

2.5、HLog

引入HLog原因：
在分佈式系統環境中，無法避免系統出錯或者宕機，一旦HRegionServer意外退出，MemStore中的內存數據就會丟失，引入HLog就是防止這種情況
工作機制：
每 個HRegionServer中都會有一個HLog對象，HLog是一個實現Write Ahead Log的類，每次用戶操作寫入Memstore的同時，也會寫一份數據到HLog文件，HLog文件定期會滾動出新，並刪除舊的文件(已持久化到 StoreFile中的數據)。當HRegionServer意外終止後，HMaster會通過Zookeeper感知，HMaster首先處理遺留的 HLog文件，將不同region的log數據拆分，分別放到相應region目錄下，然後再將失效的region重新分配，領取到這些region的 HRegionServer在Load Region的過程中，會發現有歷史HLog需要處理，因此會Replay HLog中的數據到MemStore中，然後flush到StoreFiles，完成數據恢復。

LogFlusher

前面提到，數據以KeyValue形式到達HRegionServer，將寫入WAL，之後，寫入一個SequenceFile。看過去沒問題，但是因爲數據流在寫入文件系統時，經常會緩存以提高性能。這樣，有些本以爲在日誌文件中的數據實際在內存中。這裏，我們提供了一個LogFlusher的類。它調用HLog.optionalSync(),後者根據 hbase.regionserver.optionallogflushinterval (默認是10秒)，定期調用Hlog.sync()。另外，HLog.doWrite()也會根據 hbase.regionserver.flushlogentries (默認100秒)定期調用Hlog.sync()。Sync() 本身調用HLog.Writer.sync()，它由SequenceFileLogWriter實現。

LogRoller

Log的大小通過$HBASE_HOME/conf/hbase-site.xml 的 hbase.regionserver.logroll.period 限制，默認是一個小時。所以每60分鐘，會打開一個新的log文件。久而久之，會有一大堆的文件需要維護。首先，LogRoller調用HLog.rollWriter()，定時滾動日誌，之後，利用HLog.cleanOldLogs()可以清除舊的日誌。它首先取得存儲文件中的最大的sequence number，之後檢查是否存在一個log所有的條目的“sequence number”均低於這個值，如果存在，將刪除這個log。

每個region server維護一個HLog，而不是每一個region一個，這樣不同region（來自不同的table）的日誌會混在一起，這樣做的目的是不斷追加單個文件相對於同時寫多個文件而言，可以減少磁盤尋址次數，因此可以提高table的寫性能。帶來麻煩的時，如果一個region server下線，爲了恢復其上的region，需要講region server上的log進行拆分，然後分發到其他region server上進行恢復。

三、HBase存儲格式

HBase中的所有數據文件都存儲在Hadoop HDFS文件系統上，格式主要有兩種：
1 HFile HBase中KeyValue數據的存儲格式，HFile是Hadoop的二進制格式文件，實際上StoreFile就是對HFile做了輕量級包裝，即StoreFile底層就是HFile
2 HLog File，HBase中WAL（Write Ahead Log） 的存儲格式，物理上是Hadoop的Sequence File

3.1、HFile

HFile文件不定長，長度固定的塊只有兩個：Trailer和FileInfo
Trailer中指針指向其他數據塊的起始點
File Info中記錄了文件的一些Meta信息，例如：AVG_KEY_LEN,AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等
Data Index和Meta Index塊記錄了每個Data塊和Meta塊的起始點
Data Block是HBase I/O的基本單元，爲了提高效率，HRegionServer中有基於LRU的Block Cache機制
每個Data塊的大小可以在創建一個Table的時候通過參數指定，大號的Block有利於順序Scan，小號Block利於隨機查詢
每個Data塊除了開頭的Magic以外就是一個個KeyValue對拼接而成, Magic內容就是一些隨機數字，目的是防止數據損壞

HFile裏面的每個KeyValue對就是一個簡單的byte數組。這個byte數組裏麪包含了很多項，並且有固定的結構。

KeyLength和ValueLength：兩個固定的長度，分別代表Key和Value的長度
Key部分：Row Length是固定長度的數值，表示RowKey的長度，Row 就是RowKey
Column Family Length是固定長度的數值，表示Family的長度
接着就是Column Family，再接着是Qualifier，然後是兩個固定長度的數值，表示Time Stamp和Key Type（Put/Delete）
Value部分沒有這麼複雜的結構，就是純粹的二進制數據

3.2、HLog

　　HLog文件就是一個普通的Hadoop Sequence File，Sequence File 的Key是HLogKey對象，HLogKey中記錄了寫入數據的歸屬信息，除了table和region名字外，同時還包括 sequence number和timestamp，timestamp是“寫入時間”，sequence number的起始值爲0，或者是最近一次存入文件系統中sequence number。
HLog Sequece File的Value是HBase的KeyValue對象，即對應HFile中的KeyValue。

3.3、目錄表（.meta.和-root-）

-ROOT-： 保存 .META. 表存在哪裏的蹤跡。 -ROOT- 表結構如下:

Key:

.META. region key (.META.,,1)

Values:

info:regioninfo (序列化.META.的 HRegionInfo 實例 )

info:server ( 保存 .META.的RegionServer的server:port)

info:serverstartcode ( 保存 .META.的RegionServer進程的啓動時間)

.META. ：保存系統中所有region列表。 .META.表結構如下:

Key:

Region key 格式 ([table],[region start key],[region id])

Values:

info:regioninfo (序列化.META.的 HRegionInfo 實例 )

info:server ( 保存 .META.的RegionServer的server:port)

info:serverstartcode ( 保存 .META.的RegionServer進程的啓動時間)

以上是官網文檔對於.meta.和-root-的描述，簡而言之，-root-中存儲了.meta.的位置，而在.meta.中保存了具體數據（region）的存儲位置。如圖：

Zookeeper中記錄了-ROOT-表的location
客戶端訪問數據的流程：
Client -> Zookeeper -> -ROOT- -> .META.-> 用戶數據表
多次網絡操作，不過client端有cache緩存。

四、設計結構

4.1、起動時序

1.啓動時主服務器調用AssignmentManager.

2.AssignmentManager 在META中查找已經存在的區域分配。

3.如果區域分配還有效(如 RegionServer 還在線)，那麼分配繼續保持。

4.如果區域分配失效，LoadBalancerFactory 被調用來分配區域。 DefaultLoadBalancer 將隨機分配區域到RegionServer.

5.META 隨RegionServer 分配更新(如果需要) ， RegionServer 啓動區域開啓代碼(RegionServer 啓動時進程)

4.2、故障轉移

當regionServer故障退出時：

1.區域立即不可獲取，因爲區域服務器退出。

2.主服務器會檢測到區域服務器退出。

3.區域分配會失效並被重新分配，如同啓動時序。

4.3、預寫日誌（wal）

每個RegionServer會將更新(Puts, Deletes)先記錄到預寫日誌中(WAL)，然後將其更新在Store的MemStore裏面。這樣就保證了HBase的寫的可靠性。如果沒有WAL,當RegionServer宕掉的時候，MemStore還沒有flush，StoreFile還沒有保存，數據就會丟失。HLog 是HBase的一個WAL實現，一個RegionServer有一個HLog實例。

WAL 保存在HDFS 的 /hbase/.logs/ 裏面，每個region一個文件。

五、數據組織

整個架構中，ZK用於服務協調和整個集羣運行過程中部分信息的保存和-ROOT-表地址定位，Master用於集羣內部管理，所以剩下的RS主要用於處理數據。
RS是處理數據的主要場所，那麼在RS內部的數據是怎麼分佈的？其實RS本身只是一個容器，其定義了一些功能線程，比如：數據合併線程(compact thread)、storeFile分割線程(split thread)等等。容器中的主要對象就是region，region是一個表根據自身rowkey範圍劃分的一部分，一個表可以被劃分成若干部分，也就是若干個region，region可以根據rowkey範圍不同而被分佈在不同的RS上(當然也可以在同一個RS上，但不建議這麼做)。一個RS上可以包含多個表的region，也可以只包含一個表的部分region，RS和表是兩個不同的概念。
這裏還有一個概念——列簇。對HBase有一些瞭解的人，或多或少聽說過：HBase是一個列式存儲的數據庫，而這個列式存儲中的列，其實是區別於一般數據庫的列，這裏的列的概念，就是列簇，列簇，顧名思義就是很多列的集合，而在數據存儲上來講，不同列簇的數據，一定是分開存儲的，即使是在同一個region內部，不同的列簇也存儲在不同的文件夾中，這樣做的好處是，一般我們定義列簇的時候，通常會把類似的數據放入同一個列簇，不同的列簇分開存儲，有利於數據的壓縮，並且HBase本身支持多種壓縮方式。

六、原理

前面介紹了HBase的一般架構，我們知道了HBase有ZK、Master和RS等組成，本節我們來介紹下HBase的基本原理，從數據訪問、RS路由到RS內部緩存、數據存儲和刷寫再到region的合併和拆分等等功能。

6.1、RegionServer定位

訪問HBase通過HBase客戶端(或API)進行，整個HBase提供給外部的地址，其實是ZK的入口，前面也介紹了，ZK中有保存-ROOT-所在的RS地址，從-ROOT-表可以獲取.META.表信息，根據.META.表可以獲取region在RS上的分佈，整個region尋址過程大致如下：

RS定位過程

1.首先，Client通過訪問ZK來請求目標數據的地址。
2.ZK中保存了-ROOT-表的地址，所以ZK通過訪問-ROOT-表來請求數據地址。
3.同樣，-ROOT-表中保存的是.META.的信息，通過訪問.META.表來獲取具體的RS。
4..META.表查詢到具體RS信息後返回具體RS地址給Client。
5.Client端獲取到目標地址後，然後直接向該地址發送數據請求。

上述過程其實是一個三層索引結構，從ZK獲取-ROOT-信息，再從-ROOT-獲取.META.表信息，最後從.META.表中查到RS地址後緩存。這裏有幾個問題：
1.既然ZK中能保存-ROOT-信息，那麼爲什麼不把.META.信息直接保存在ZK中，而需要通過-ROOT-表來定位？
2.Client查找到目標地址後，下一次請求還需要走ZK —> -ROOT- —> .META.這個流程麼？

先來回答第一個問題：爲什麼不直接把.META.表信息直接保存到ZK中？主要是爲了保存的數據量考慮，ZK中不宜保存大量數據，而.META.表主要是保存Region和RS的映射信息，region的數量沒有具體約束，只要在內存允許的範圍內，region數量可以有很多，如果保存在ZK中，ZK的壓力會很大。所以，通過一個-ROOT-表來轉存到RS中是一個比較理想的方案，相比直接保存在ZK中，也就多了一層-ROOT-表的查詢，對性能來說影響不大。

第二個問題：每次訪問都需要走ZK –> -ROOT- —> .META.的流程麼？當然不需要，Client端有緩存，第一次查詢到相應region所在RS後，這個信息將被緩存到Client端，以後每次訪問都直接從緩存中獲取RS地址即可。當然這裏有個意外：訪問的region若果在RS上發生了改變，比如被balancer遷移到其他RS上了，這個時候，通過緩存的地址訪問會出現異常，在出現異常的情況下，Client需要重新走一遍上面的流程來獲取新的RS地址。總體來說，region的變動只會在極少數情況下發生，一般變動不會很大，所以在整個集羣訪問過程中，影響可以忽略。

6.2、Region數據寫入

HBase通過ZK —> -ROOT- —> .META.的訪問獲取RS地址後，直接向該RS上進行數據寫入操作，整個過程如下圖：

RegionServer數據操作過程

Client通過三層索引獲得RS的地址後，即可向指定RS的對應region進行數據寫入，HBase的數據寫入採用WAL(write ahead log)的形式，先寫log，後寫數據。HBase是一個append類型的數據庫，沒有關係型數據庫那麼複雜的操作，所以記錄HLog的操作都是簡單的put操作(delete/update操作都被轉化爲put進行)

6.3、HLog

HLog寫入

HLog是HBase實現WAL方式產生的日誌信息，其內部是一個簡單的順序日誌，每個RS上的region都共享一個HLog，所有對於該RS上的region數據寫入都被記錄到該HLog中。HLog的主要作用就是在RS出現意外崩潰的時候，可以儘量多的恢復數據，這裏說是儘量多，因爲在一般情況下，客戶端爲了提高性能，會把HLog的auto flush關掉，這樣HLog日誌的落盤全靠操作系統保證，如果出現意外崩潰，短時間內沒有被fsync的日誌會被丟失。

HLog過期

HLog的大量寫入會造成HLog佔用存儲空間會越來越大，HBase通過HLog過期的方式進行HLog的清理，每個RS內部都有一個HLog監控線程在運行，其週期可以通過hbase.master.cleaner.interval進行配置。
HLog在數據從memstore flush到底層存儲上後，說明該段HLog已經不再被需要，就會被移動到.oldlogs這個目錄下，HLog監控線程監控該目錄下的HLog，當該文件夾下的HLog達到hbase.master.logcleaner.ttl設置的過期條件後，監控線程立即刪除過期的HLog。

6.4Memstore

數據存儲

memstore是region內部緩存，其大小通過HBase參數hbase.hregion.memstore.flush.size進行配置。RS在寫完HLog以後，數據寫入的下一個目標就是region的memstore，memstore在HBase內部通過LSM-tree結構組織，所以能夠合併大量對於相同rowkey上的更新操作。
正是由於memstore的存在，HBase的數據寫入都是異步的，而且性能非常不錯，寫入到memstore後，該次寫入請求就可以被返回，HBase即認爲該次數據寫入成功。這裏有一點需要說明，寫入到memstore中的數據都是預先按照rowkey的值進行排序的，這樣有利於後續數據查找。

數據刷盤

memstore中的數據在一定條件下會進行刷寫操作，使數據持久化到相應的存儲設備上，觸發memstore刷盤的操作有多種不同的方式如下圖：

Memstore刷寫流程

以上1,2,3都可以觸發memstore的flush操作，但是實現的方式不同：

• 1通過全局內存控制，觸發memstore刷盤操作。memstore整體內存佔用上限通過參數hbase.regionserver.global.memstore.upperLimit進行設置，當然在達到上限後，memstore的刷寫也不是一直進行，在內存下降到hbase.regionserver.global.memstore.lowerLimit配置的值後，即停止memstore的刷盤操作。這樣做，主要是爲了防止長時間的memstore刷盤，會影響整體的性能。
• 在該種情況下，RS中所有region的memstore內存佔用都沒達到刷盤條件，但整體的內存消耗已經到一個非常危險的範圍，如果持續下去，很有可能造成RS的OOM，這個時候，需要進行memstore的刷盤，從而釋放內存。
• 2手動觸發memstore刷盤操作
• HBase提供API接口，運行通過外部調用進行memstore的刷盤
• 3 memstore上限觸發數據刷盤
• 前面提到memstore的大小通過hbase.hregion.memstore.flush.size進行設置，當region中memstore的數據量達到該值時，會自動觸發memstore的刷盤操作。

刷盤影響

memstore在不同的條件下會觸發數據刷盤，那麼整個數據在刷盤過程中，對region的數據寫入等有什麼影響？memstore的數據刷盤，對region的直接影響就是：在數據刷盤開始到結束這段時間內，該region上的訪問都是被拒絕的，這裏主要是因爲在數據刷盤結束時，RS會對改region做一個snapshot，同時HLog做一個checkpoint操作，通知ZK哪些HLog可以被移到.oldlogs下。從前面圖上也可以看到，在memstore寫盤開始，相應region會被加上UpdateLock鎖，寫盤結束後該鎖被釋放。

6.5、StoreFile

memstore在觸發刷盤操作後會被寫入底層存儲，每次memstore的刷盤就會相應生成一個存儲文件HFile，storeFile即HFile在HBase層的輕量級分裝。數據量的持續寫入，造成memstore的頻繁flush，每次flush都會產生一個HFile，這樣底層存儲設備上的HFile文件數量將會越來越多。不管是HDFS還是Linux下常用的文件系統如Ext4、XFS等，對小而多的文件上的管理都沒有大文件來的有效，比如小文件打開需要消耗更多的文件句柄；在大量小文件中進行指定rowkey數據的查詢性能沒有在少量大文件中查詢來的快等等。

6.6、Compact

大量HFile的產生，會消耗更多的文件句柄，同時會造成RS在數據查詢等的效率大幅度下降，HBase爲解決這個問題，引入了compact操作，RS通過compact把大量小的HFile進行文件合併，生成大的HFile文件。
RS上的compact根據功能的不同，可以分爲兩種不同類型，即：minor compact和major compact。

• Minor Compact

minor compact又叫small compact，在RS運行過程中會頻繁進行，主要通過參數hbase.hstore.compactionThreshold進行控制，該參數配置了HFile數量在滿足該值時，進行minor compact，minor compact只選取region下部分HFile進行compact操作，並且選取的HFile大小不能超過hbase.hregion.max.filesize參數設置。

• Major Compact

相反major compact也被稱之爲large compact，major compact會對整個region下相同列簇的所有HFile進行compact，也就是說major compact結束後，同一個列簇下的HFile會被合併成一個。major compact是一個比較長的過程，對底層I/O的壓力相對較大。
major compact除了合併HFile外，另外一個重要功能就是清理過期或者被刪除的數據。前面提到過，HBase的delete操作也是通過append的方式寫入，一旦某些數據在HBase內部被刪除了，在內部只是被簡單標記爲刪除，真正在存儲層面沒有進行數據清理，只有通過major compact對HFile進行重組時，被標記爲刪除的數據才能被真正的清理。
compact操作都有特定的線程進行，一般情況下不會影響RS上數據寫入的性能，當然也有例外：在compact操作速度跟不上region中HFile增長速度時，爲了安全考慮，RS會在HFile達到一定數量時，對寫入進行鎖定操作，直到HFile通過compact降到一定的範圍內才釋放鎖。

6.7、Split

compact將多個HFile合併單個HFile文件，隨着數據量的不斷寫入，單個HFile也會越來越大，大量小的HFile會影響數據查詢性能，大的HFile也會，HFile越大，相對的在HFile中搜索的指定rowkey的數據花的時間也就越長，HBase同樣提供了region的split方案來解決大的HFile造成數據查詢時間過長問題。
一個較大的region通過split操作，會生成兩個小的region，稱之爲Daughter，一般Daughter中的數據是根據rowkey的之間點進行切分的，region的split過程大致如下圖：

region split流程

• 1.region先更改ZK中該region的狀態爲SPLITING。
• 2.Master檢測到region狀態改變。
• 3.region會在存儲目錄下新建.split文件夾用於保存split後的daughter region信息。
• 4.Parent region關閉數據寫入並觸發flush操作，保證所有寫入Parent region的數據都能持久化。
• 5.在.split文件夾下新建兩個region，稱之爲daughter A、daughter B。
• 6.Daughter A、Daughter B拷貝到HBase根目錄下，形成兩個新的region。
• 7.Parent region通知修改.META.表後下線，不再提供服務。
• 8.Daughter A、Daughter B上線，開始向外提供服務。
• 9.如果開啓了balance_switch服務，split後的region將會被重新分佈。

上面1 ~ 9就是region split的整個過程，split過程非常快，速度基本會在秒級內，那麼在這麼快的時間內，region中的數據怎麼被重新組織的？
其實，split只是簡單的把region從邏輯上劃分成兩個，並沒有涉及到底層數據的重組，split完成後，Parent region並沒有被銷燬，只是被做下線處理，不再對外部提供服務。而新產生的region Daughter A和Daughter B，內部的數據只是簡單的到Parent region數據的索引，Parent region數據的清理在Daughter A和Daughter B進行major compact以後，發現已經沒有到其內部數據的索引後，Parent region纔會被真正的清理。

七、HBase設計

HBase是一個分佈式數據庫，其性能的好壞主要取決於內部表的設計和資源的分配是否合理。

7.1、Rowkey設計

rowkey是HBase實現分佈式的基礎，HBase通過rowkey範圍劃分不同的region，分佈式系統的基本要求就是在任何時候，系統的訪問都不要出現明顯的熱點現象，所以rowkey的設計至關重要，一般我們建議rowkey的開始部分以hash或者MD5進行散列，儘量做到rowkey的頭部是均勻分佈的。禁止採用時間、用戶id等明顯有分段現象的標誌直接當作rowkey來使用。

7.2、列簇設計

HBase的表設計時，根據不同需求有不同選擇，需要做在線查詢的數據表，儘量不要設計多個列簇，我們知道，不同的列簇在存儲上是被分開的，多列簇設計會造成在數據查詢的時候讀取更多的文件，從而消耗更多的I/O。

7.3、TTL設計

選擇合適的數據過期時間也是表設計中需要注意的一點，HBase中允許列簇定義數據過期時間，數據一旦超過過期時間，可以被major compact進行清理。大量無用歷史數據的殘餘，會造成region體積增大，影響查詢效率。

7.4、Region設計

一般地，region不宜設計成很大，除非應用對階段性性能要求很多，但是在將來運行一段時間可以接受停服處理。region過大會導致major compact調用的週期變長，而單次major compact的時間也相應變長。major compact對底層I/O會造成壓力，長時間的compact操作可能會影響數據的flush，compact的週期變長會導致許多刪除或者過期的數據不能被及時清理，對數據的讀取速度等都有影響。
相反，小的region意味着major compact會相對頻繁，但是由於region比較小，major compact的相對時間較快，而且相對較多的major compact操作，會加速過期數據的清理。
當然，小region的設計意味着更多的region split風險，region容量過小，在數據量達到上限後，region需要進行split來拆分，其實split操作在整個HBase運行過程中，是被不怎麼希望出現的，因爲一旦發生split，涉及到數據的重組，region的再分配等一系列問題。所以我們在設計之初就需要考慮到這些問題，儘量避免region的運行過程中發生split。
HBase可以通過在表創建的時候進行region的預分配來解決運行過程中region的split產生，在表設計的時候，預先分配足夠多的region數，在region達到上限前，至少有部分數據會過期，通過major compact進行清理後， region的數據量始終維持在一個平衡狀態。
region數量的設計還需要考慮內存上的限制，通過前面的介紹我們知道每個region都有memstore，memstore的數量與region數量和region下列簇的數量成正比,一個RS下memstore內存消耗：

Memory = memstore大小 * region數量 * 列簇數量

如果不進行前期數據量估算和region的預分配，通過不斷的split產生新的region，容易導致因爲內存不足而出現OOM現象。