HBase之一：HBase原理和設計

1、簡介

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位置。

 

2、架構

上面提到，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.一、Zookeeper：

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

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.三、HRegionServer：

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

HRegionServer管理一些列HRegion對象；
每一個HRegion對應Table中一個Region，HRegion由多個HStore組成；
每一個HStore對應Table中一個Column Family的存儲；
Column Family就是一個集中的存儲單元，故將具備相同IO特性的Column放在一個Column Family會更高效

2.四、HStore：

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

Client寫入 -> 存入MemStore，一直到MemStore滿 -> Flush成一個StoreFile，直至增加到必定閾值 -> 觸發Compact合併操做 -> 多個StoreFile合併成一個StoreFile，同時進行版本合併和數據刪除 -> 當StoreFiles Compact後，逐步造成愈來愈大的StoreFile ->單個StoreFile大小超過必定閾值後，觸發Split操做，把當前Region Split成2個Region，Region會下線，新Split出的2個孩子Region會被HMaster分配到相應的HRegionServer 上，使得原先1個Region的壓力得以分流到2個Region上。
由此過程可知，HBase只是增長數據，全部的更新和刪除操做，都是在Compact階段作的，因此，用戶寫操做只須要進入到內存便可當即返回，從而保證I/O高性能。

2.五、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，完成數據恢復。

 

2.5.一、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實現。

2.5.二、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上進行恢復。

3、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.一、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.二、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.三、目錄表（.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緩存。

 A、啓動時序

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

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

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

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

5.META 隨RegionServer 分配更新(若是須要) ， RegionServer 啓動區域開啓代碼(RegionServer 啓動時進程)

B、故障轉移

當regionServer故障退出時：

1.區域當即不可獲取，由於區域服務器退出。

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

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

C、預寫日誌（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的合併和拆分等等功能。

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地址後緩存。這裏有幾個問題：

• 既然ZK中能保存-ROOT-信息，那麼爲何不把.META.信息直接保存在ZK中，而須要經過-ROOT-表來定位？
• 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的變更只會在極少數狀況下發生，通常變更不會很大，因此在整個集羣訪問過程當中，影響能夠忽略。

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進行)

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。

Memstore

數據存儲

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鎖，寫盤結束後該鎖被釋放。

StoreFile

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

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降到必定的範圍內才釋放鎖。

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是一個分佈式數據庫，其性能的好壞主要取決於內部表的設計和資源的分配是否合理。

Rowkey設計

rowkey是HBase實現分佈式的基礎，HBase經過rowkey範圍劃分不一樣的region，分佈式系統的基本要求就是在任什麼時候候，系統的訪問都不要出現明顯的熱點現象，因此rowkey的設計相當重要，通常咱們建議rowkey的開始部分以hash或者MD5進行散列，儘可能作到rowkey的頭部是均勻分佈的。禁止採用時間、用戶id等明顯有分段現象的標誌直接看成rowkey來使用。

列簇設計

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

TTL設計

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

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現象。