1.1 pre-creating regions
預設情況下，在建立hbase表的時候會自動建立乙個region分割槽，當匯入資料的時候，所有的hbase客戶端都向這乙個region寫資料，直到這個region足夠大了才進行切分。一種可以加快批量寫入速度的方法是通過預先建立一些空的regions，這樣當資料寫入hbase時，會按照region分割槽情況，在集群內做資料的負載均衡。
有關預分割槽，詳情參見：table creation: pre-creating regions
下面是乙個例子：
byte startkey = ...; // your lowest key
byte endkey = ...; // your highest key
int numberofregions = ...; // # of regions to create
admin.createtable(table, startkey, endkey, numberofregions);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，這樣能保證新寫入的資料在讀取時可以被快速命中。
1.3 column family
不要在一張表裡定義太多的column family。目前hbase並不能很好的處理超過2~3個column family的表。因為某個column family在flush的時候，它鄰近的column family也會因關聯效應被觸發flush，最終導致系統產生更多的i/o。
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之效能優化
3.讀表操作 3.1 多htable併發讀 建立多個htable客戶端用於讀操作，提高讀資料的吞吐量，乙個例子 static final configuration conf hbaseconfiguration.create static final string table log name u...
Hbase效能優化之配置
減少zk 超時時間 建議 1分鐘 rs與zk的 timeout 預設為3 分鐘，由 zookeeper.session.timeout property 決定。也就是說，如果乙個 rs掛了，那麼 master需要3 分鐘之後才能對其進行重啟和恢復。建議調成 1分鐘會更低。然而，你調低之前應該先確保j...
Hbase效能優化
1 表的設計 1.1 pre creating regions 預設情況下，在建立hbase表的時候會自動建立乙個region分割槽，當匯入資料的時候，所有的hbase客戶端都向這乙個region寫資料，直到這個region足夠大了才進行切分。一種可以加快批量寫入速度的方法是通過預先建立一些空的re...