HBase Client API 簡析

昨天在飛機上的2個小時看了一遍HBase的Client API，有幾點心得：

1.在Put小記錄時最好關閉autoFlush，并合理設定WriterBuffer：

因為每次Put都要進行一次RPC調用+WAL（關閉對寫入提升非常大）+Server端處理，如果對于大批量小資料寫入的話RPC的RTT消耗的時間就會成為寫入的損耗點，是以可以通過本地緩沖批量送出的方式；預設的WriteBuffer大小是2MB，當autoFlush關閉時，用戶端每次put都會寫入到一個ArrayList内，每10次檢查一次，當size超過WriteBuffer size時則進行一次flushCommit，會将WB的Put按照RS進行分組，每個RS進行一次RPC調用處理；

當送出到Server端後，如果發生異常，則會将WB中已經寫入的Put删除，保留送出失敗的進行異常處理；

不過WB的大小需要合理設定，因為占用本地和RS的記憶體.

本地記憶體占用很好估計，而服務端的記憶體最大消耗則是：hbase.client.write.buffer * hbase.regionserver.handler.count * number ofregion server

2.Scanner的batch/cache設定：

Scan具體的處理流程如下圖：

<a href="http://blog.51cto.com/attachment/201310/022351370.png" target="_blank"></a>

Caching的設定主要影響RSnext的調用(可以了解成面向“行”的batch)，而batch則是RSRegionScanner每次nextInternal擷取的keyvalue數（可以了解成面向“列”的batch）；

是以具體SCAN調用RPC次數由兩個參數共同決定=cells總數/（caching*min(batch,cells/row)）；

那這裡scanner的next(n)其實和MYSQL JDBC裡的fetch類似，其實是在用戶端loop模拟的，而不是真的在server端進行batch fetch，其實這裡的scan和mysql 裡的cursor是非常類似的，是以了解了一個了解另外一個就是水到渠成了.

不過這裡也有WB同樣的問題就是記憶體消耗，以及網絡傳輸,處理完畢時及時關閉.

3.HConnection的處理：

簡稱HC，都是由shared的HCManager産生，而一個HC是存儲在HCManager的HBASE_INSTANCES的MAP類型裡，也就是說同一個Client+Conf是共享HC的，這樣有個好處就是首先共享了 ZK連接配接，其實就是在split/merge時隻對一個HC進行metadata refresh就OK了.

缺點就是這些連接配接會一直保持到用戶端程序退出，會導緻ZK連接配接超maxClientCnxns異常.

4.Coprocessor：

類似對比MySQL的trigger和procedure.稍候再詳細介紹

5.Counter

這個計數器非常好用，不過用HBase做計數compared to redis是不是略重了：P

6.RowLock

這個應該是被禁用掉的東西，RS殺手啊...可以把rpc handler hold住lease.period...

7.管理API：

Split/Compact 運維利器:)

本文轉自MIKE老畢 51CTO部落格，原文連結：http://blog.51cto.com/boylook/1316037，如需轉載請自行聯系原作者