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

 

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之上。apache

各個組件的功能說明:api

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),而後將其更新在StoreMemStore裏面。這樣就保證了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現象。

相關文章
相關標籤/搜索