827
Hbase客戶端優化
Scan Caching
scanner一次緩存多少數據來scan（從服務端一次抓多少數據回來scan）。
默認值是 1，一次隻取一條。
Scan Attribute Selection
scan時建議指定需要的Column Family，減少通信量，否則scan操作默認會返回整個row的所有數據（所有Coulmn Family）。
Close ResultScanners
通過scan取完數據後，記得要關閉ResultScanner，否則RegionServer可能會出現問題（對應的Server資源無法釋放）。
Optimal Loading of Row Keys
當你scan一張表的時候，返回結果隻需要row key（不需要CF, qualifier,values,timestaps）時，你可以在scan實例中添加一個filterList，並設置 MUST_PASS_ALL操作，filterList中add FirstKeyOnlyFilter或KeyOnlyFilter。這樣可以減少網絡通信量
Turn off WAL on Puts
當Put某些非重要數據時，你可以設置writeToWAL(false)，來進一步提高寫性能。writeToWAL(false)會在Put時放棄寫WAL log。風險是，當RegionServer宕機時，可能你剛才Put的那些數據會丟失，且無法恢複
啟用Bloom Filter
Bloom Filter通過空間換時間，提高讀操作性能
什麼時候需要Write Buffer？
默認情況下，一次Put操作即要與Region Server執行一次RPC操作，其執行過程可以被拆分為以下三個部分：
T1：RTT(Round-Trip Time)，即網絡往返時延，它指從客戶端發送數據開始，到客戶端收到來自服務端的確認，總共經曆的時延，不包括數據傳輸的時間；
T2：數據傳輸時間，即Put所操作的數據在客戶端與服務端之間傳輸所消耗的時間開銷，當數據量大的時候，T2的開銷不容忽略；
T3：服務端處理時間，對於Put操作，即寫入WAL日誌（如果設置了WAL標識為true）、更新MemStore等。
其中，T2和T3都是不可避免的時間開銷，那麼能不能減少T1呢？假設我們將多次Put操作打包起來一次性提交到服務端，則可以將T1部分的總時間從T1 * N降低為T1，其中T1為一次RTT時間，N為Put的記錄條數。
正是出於上述考慮，HBase為用戶提供了客戶端緩存批量提交的方式（即Write Buffer）。假設RTT的時間較長，如1ms，則該種方式能夠顯著提高整個集群的寫入性能。
那麼，什麼場景下適用於該種模式呢？下麵簡單分析一下：
如果Put提交的是小數據（如KB級別甚至更小）記錄，那麼T2很小，因此，通過該種模式減少T1的開銷，能夠明顯提高寫入性能。
如果Put提交的是大數據（如MB級別）記錄，那麼T2可能已經遠大於T1，此時T1與T2相比可以被忽略，因此，使用該種模式並不能得到很好的性能提升，不建議通過增大Write Buffer大小來使用該種模式。
如何配置使用Write Buffer？
如果要啟動Write Buffer模式，則調用HTable的以下API將auto flush設置為false：
void setAutoFlush(boolean autoFlush)
默認配置下，Write Buffer大小為2MB，可以根據應用實際情況，通過以下任意方式進行自定義：
1） 調用HTable接口設置，僅對該HTable對象起作用：
void setWriteBufferSize(long writeBufferSize) throws IOException
2） 在hbase-site.xml中配置，所有HTable都生效（下麵設置為5MB）：
hbase.client.write.buffer
5242880
該種模式下向服務端提交的時機分為顯式和隱式兩種情況：
1） 顯式提交：用戶調用flushCommits()進行提交；
2） 隱式提交：當Write Buffer滿了，客戶端會自動執行提交；或者調用了HTable的close()方法時無條件執行提交操作。
Write Buffer有什麼潛在的問題？
首先，Write Buffer存在於客戶端的本地內存中，那麼當客戶端運行出現問題時，會導致在Write Buffer中未提交的數據丟失；由於HBase服務端還未收到這些數據，因此也無法通過WAL日誌等方式進行數據恢複。
其次，Write Buffer方式本身會占用客戶端和HBase服務端的內存開銷，具體見下節的詳細分析。
如何預估Write Buffer占用的內存？
客戶端通過Write Buffer方式提交的話，會導致客戶端和服務端均有一定的額外內存開銷，Write Buffer Size越大，則占用的內存越大。客戶端占用的內存開銷可以粗略地使用以下公式預估：
hbase.client.write.buffer * number of HTable object for writing
而對於服務端來說，可以使用以下公式預估占用的Region Server總內存開銷：
hbase.client.write.buffer hbase.regionserver.handler.count number of region server
其中，hbase.regionserver.handler.count為每個Region Server上配置的RPC Handler線程數。
最後更新：2017-11-04 22:03:48