Hbase效能優化

1… 表的設計

1.1 pre-creating regions

預設情況下，在建立hbase表的時候會自動建立乙個region分割槽，當匯入資料的時候，所有的hbase客戶端都向這乙個region寫資料，直到這個region足夠大了才進行切分。一種可以加快批量寫入速度的方法是通過預先建立一些空的regions，這樣當資料寫入hbase時，會按照region分割槽情況，在集群內做資料的負載均衡。

有關預分割槽，詳情參見：table creation: pre-creating regions，下面是乙個例子：

public static boolean createtable(hbaseadmin admin, htabledescriptor table, byte splits)
throws ioexception  catch (tableexist***ception e) 
}public static byte gethexsplits(string startkey, string endkey, int numregions) 
return splits;
}

1.2 row key

hbase中row key用來檢索表中的記錄，支援以下三種方式：

通過單個row key訪問：即按照某個row key鍵值進行get操作；

通過row key的range進行scan：即通過設定startrowkey和endrowkey，在這個範圍內進行掃瞄；

全表掃瞄：即直接掃瞄整張表中所有行記錄。

在hbase中，row key可以是任意字串，最大長度64kb，實際應用中一般為10~100bytes，存為byte位元組陣列，一般設計成定長的。

row key是按照字典序儲存，因此，設計row key時，要充分利用這個排序特點，將經常一起讀取的資料儲存到一塊，將最近可能會被訪問的資料放在一塊。

舉個例子：如果最近寫入hbase表中的資料是最可能被訪問的，可以考慮將時間戳作為row key的一部分，由於是字典序排序，所以可以使用long.max_value - timestamp作為row key，這樣能保證新寫入的資料在讀取時可以被快速命中。

rowkey規則：

1、越小越好

2、rowkey的設計是要根據實際業務來

3、雜湊性

a)取反 001 002 100 200

b)hash

1.3 column family

不要在一張表裡定義太多的column family。目前hbase並不能很好的處理超過2~3個column family的表。因為某個column family在flush的時候，它鄰近的column family也會因關聯效應被觸發flush，最終導致系統產生更多的i/o。感興趣的同學可以對自己的hbase集群進行實際測試，從得到的測試結果資料驗證一下。

1.4 in memory

建立表的時候，可以通過hcolumndescriptor.setinmemory(true)將表放到regionserver的快取中，保證在讀取的時候被cache命中。

1.5 max version

建立表的時候，可以通過hcolumndescriptor.setmaxversions(int maxversions)設定表中資料的最大版本，如果只需要儲存最新版本的資料，那麼可以設定setmaxversions(1)。

1.6 time to live

建立表的時候，可以通過hcolumndescriptor.settimetolive(int timetolive)設定表中資料的儲存生命期，過期資料將自動被刪除，例如如果只需要儲存最近兩天的資料，那麼可以設定settimetolive(2 * 24 * 60 * 60)。

1.7 compact & split

在hbase中，資料在更新時首先寫入wal 日誌(hlog)和記憶體(memstore)中，memstore中的資料是排序的，當memstore累計到一定閾值時，就會建立乙個新的memstore，並且將老的memstore新增到flush佇列，由單獨的執行緒flush到磁碟上，成為乙個storefile。於此同時，系統會在zookeeper中記錄乙個redo point，表示這個時刻之前的變更已經持久化了(minor compact)。

storefile是唯讀的，一旦建立後就不可以再修改。因此hbase的更新其實是不斷追加的操作。當乙個store中的storefile達到一定的閾值後，就會進行一次合併(major compact)，將對同乙個key的修改合併到一起，形成乙個大的storefile，當storefile的大小達到一定閾值後，又會對 storefile進行分割(split)，等分為兩個storefile。

由於對錶的更新是不斷追加的，處理讀請求時，需要訪問store中全部的storefile和memstore，將它們按照row key進行合併，由於storefile和memstore都是經過排序的，並且storefile帶有記憶體中索引，通常合併過程還是比較快的。

實際應用中，可以考慮必要時手動進行major compact，將同乙個row key的修改進行合併形成乙個大的storefile。同時，可以將storefile設定大些，減少split的發生。

hbase為了防止小檔案（被刷到磁碟的menstore）過多，以保證保證查詢效率，hbase需要在必要的時候將這些小的store file合併成相對較大的store file，這個過程就稱之為compaction。在hbase中，主要存在兩種型別的compaction：minor compaction和major compaction。

minor compaction:的是較小、很少檔案的合併。

major compaction 的功能是將所有的store file合併成乙個，觸發major compaction的可能條件有：major_compact 命令、majorcompact() api、region server自動執行（相關引數：hbase.hregion.majoucompaction 預設為24 小時、hbase.hregion.majorcompaction.jetter 預設值為0.2 防止region server 在同一時間進行major compaction）。

hbase.hregion.majorcompaction.jetter引數的作用是：對引數hbase.hregion.majoucompaction 規定的值起到浮動的作用，假如兩個引數都為預設值24和0,2，那麼major compact最終使用的數值為：19.2~28.8 這個範圍。

1、關閉自動major compaction

2、手動程式設計major compaction

timer類，contab

minor compaction的執行機制要複雜一些，它由一下幾個引數共同決定：

hbase.hstore.compaction.min :預設值為 3，表示至少需要三個滿足條件的store file時，minor compaction才會啟動

hbase.hstore.compaction.max 預設值為10，表示一次minor compaction中最多選取10個store file

hbase.hstore.compaction.min.size 表示檔案大小小於該值的store file 一定會加入到minor compaction的store file中

hbase.hstore.compaction.max.size 表示檔案大小大於該值的store file 一定會被minor compaction排除

hbase.hstore.compaction.ratio 將store file 按照檔案年齡排序（older to younger），minor compaction總是從older store file開始選擇

Hbase效能優化

Hbase效能優化

hbase資料讀取優化 HBase效能優化總結篇

Hbase查詢效能優化

Hbase效能優化

Hbase效能優化

hbase資料讀取優化 HBase效能優化 總結篇

Hbase查詢效能優化

相關推薦

hbase資料讀取優化 HBase效能優化總結篇