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具體的處理流程如下圖：

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 運維利器:)