HBase性能調優方法(2)

　　hbase.hstore.blockingStoreFiles

　　默認值：7

　　說明：在compaction時，如果一個Store?oulmn Family)內有超過7個storefile需要合并，則block所有的寫請求，進行flush，限制storefile數量增長過快。

　　調優：block請求會影響當前region的讀寫性能，將值設為單個region可以支撐的最大store file數量會是個不錯的選擇。最大storefile數量可通過region size/memstore size來計算。如果你將region size設為無限大，那么你需要預估一個region可能產生的最大storefile數。

　　hbase.hregion.memstore.block.multiplier

　　默認值：2

　　說明：當一個region里的memstore超過單個memstore.size兩倍的大小時，block該region的所有請求，進行flush，釋放內存。雖然我們設置了memstore的總大小，比如64M，但想象一下，在最后63.9M的時候，我Put了一個100M的數據或寫請求量暴增，最后一秒鐘put了1萬次，此時memstore的大小會瞬間暴漲到超過預期的memstore.size。這個參數的作用是當memstore的大小增至超過memstore.size時，block所有請求，遏制風險進一步擴大。

　　調優： 這個參數的默認值還是比較靠譜的。如果你預估你的正常應用場景(不包括異常)不會出現突發寫或寫的量可控，那么保持默認值即可。如果正常情況下，你的寫量就會經常暴增，那么你應該調大這個倍數并調整其他參數值，比如hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit/lowerLimit，以預留更多內存，防止HBase server OOM。

　　其他

　　啟用LZO壓縮

　　LZO對比Hbase默認的GZip，前者性能較高，后者壓縮比較高，具體參見 Using LZO Compression 。對于想提高HBase讀寫性能的開發者，采用LZO是比較好的選擇。對于非常在乎存儲空間的開發者，則建議保持默認。

　　不要在一張表里定義太多的Column Family

　　Hbase目前不能良好的處理超過2-3個CF的表。因為某個CF在flush發生時，它鄰近的CF也會因關聯效應被觸發flush，最終導致系統產生很多IO。

　　批量導入

　　在批量導入數據到Hbase前，你可以通過預先創建region，來平衡數據的負載。詳見 Table Creation: Pre-Creating Regions

　　Hbase客戶端優化

　　AutoFlush

　　將HTable的setAutoFlush設為false，可以支持客戶端批量更新。即當Put填滿客戶端flush緩存時，才發送到服務端。

　　默認是true。

　　Scan Caching

　　scanner一次緩存多少數據來scan(從服務端一次抓多少數據回來scan)。

　　默認值是 1，一次只取一條。

　　Scan Attribute Selection

　　scan時建議指定需要的Column Family，減少通信量，否則scan默認會返回整個row的所有數據(所有Coulmn Family)。

　　Close ResultScanners

　　通過scan取完數據后，記得要關閉ResultScanner，否則RegionServer可能會出現問題。

　　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通過空間換時間，提高讀操作性能。

原文轉自：http://kenwublog.com/hbase-performance-tuning