因官方Book Performance Tuning部分章節(jié)沒有按配置項進(jìn)行索引，不能達(dá)到快速查閱的效果。所以我以配置項驅(qū)動，重新整理了原文，并補(bǔ)充一些自己的理解，如有錯誤，歡迎指正。
配置優(yōu)化
zookeeper.session.timeout
默認(rèn)值：3分鐘（180000ms）
說明：RegionServer與Zookeeper間的連接超時時間。當(dāng)超時時間到后，ReigonServer會 被Zookeeper從RS集群清單中移除，HMaster收到移除通知后，會對這臺server負(fù)責(zé)的regions重新balance，讓其他存活的 RegionServer接管.
調(diào)優(yōu)：
這個timeout決定了RegionServer是否能夠及時的failover。設(shè)置成1分鐘或更低，可以減少因等待超時而被延長的failover時間。
不過需要注意的是，對于一些Online應(yīng)用，RegionServer的宕機(jī)到恢復(fù)時間本身就很短的（網(wǎng)絡(luò)閃斷，crash等故障，運維可快速介入）， 如果調(diào)低timeout時間，會得不償失。因為當(dāng)ReigonServer被正式從RS集群中移除時，HMaster就開始做balance了，當(dāng)故障的 RS快速恢復(fù)后，這個balance動作是毫無意義的，反而會使負(fù)載不均勻，給RS帶來更多負(fù)擔(dān)。
hbase.regionserver.handler.count
默認(rèn)值：10
說明：RegionServer的請求處理IO線程數(shù)。
調(diào)優(yōu)：
這個參數(shù)的調(diào)優(yōu)與內(nèi)存息息相關(guān)。
較少的IO線程，適用于處理單次請求內(nèi)存消耗較高的Big PUT場景（大容量單次PUT或設(shè)置了較大cache的scan，均屬于Big PUT）或ReigonServer的內(nèi)存比較緊張的場景。
較多的IO線程，適用于單次請求內(nèi)存消耗低，TPS要求非常高的場景。
這里需要注意的是如果server的region數(shù)量很少，大量的請求都落在一個region上，因快速充滿memstore觸發(fā)flush導(dǎo)致的讀寫鎖會影響全局TPS，不是IO線程數(shù)越高越好。
壓測時，開啟Enabling RPC-level logging，可以同時監(jiān)控每次請求的內(nèi)存消耗和GC的狀況，最后通過多次壓測結(jié)果來合理調(diào)節(jié)IO線程數(shù)。
這里是一個案例 Hadoop and HBase Optimization for Read Intensive Search Applications，作者在SSD的機(jī)器上設(shè)置IO線程數(shù)為100，僅供參考。
hbase.hregion.max.filesize
默認(rèn)值：256M
說明：在當(dāng)前ReigonServer上單個Reigon的大小，單個Region超過指定值時，這個Region會被自動split成更小的region。
調(diào)優(yōu)：
小region對split和compaction友好，因為拆分region或compact小region里的storefile速度很快，內(nèi)存占用低。缺點是split和compaction會很頻繁。
特別是數(shù)量較多的小region不停地split, compaction，會使響應(yīng)時間波動很大，region數(shù)量太多不僅給管理上帶來麻煩，甚至引發(fā)一些Hbase的bug。
一般512以下的都算小region。
大region，則不太適合經(jīng)常split和compaction，因為做一次compact和split會產(chǎn)生較長時間的停頓，對應(yīng)用的讀寫性能沖擊非常大。此外，大region意味著較大的storefile，compaction時對內(nèi)存也是一個挑戰(zhàn)。
當(dāng)然，大region還是有其用武之地，你只要在某個訪問量低峰的時間點統(tǒng)一做compact和split，大region就可以發(fā)揮優(yōu)勢了，畢竟它能保證絕大多數(shù)時間平穩(wěn)的讀寫性能。
既然split和compaction如此影響性能，有沒有辦法去掉？
compaction是無法避免的，split倒是可以從自動調(diào)整為手動。
只要通過將這個參數(shù)值調(diào)大到某個很難達(dá)到的值，比如100G，就可以間接禁用自動split（RegionServer不會對未到達(dá)100G的region做split）。
再配合RegionSplitter這個工具，在需要split時，手動split。
手動split在靈活性和穩(wěn)定性上比起自動split要高很多，相反，管理成本增加不多，比較推薦online實時系統(tǒng)使用。
內(nèi)存方面，小region在設(shè)置memstore的大小值上比較靈活，大region則過大過小都不行，過大會導(dǎo)致flush時app的IO wait增高，過小則因store file過多讀性能降低。
hbase.regionserver.global.memstore.upperLimit/lowerLimit
默認(rèn)值：0.4/0.35
upperlimit說明：hbase.hregion.memstore.flush.size 這個參數(shù)的作用是 當(dāng)單個memstore達(dá)到指定值時，flush該memstore。但是，一臺ReigonServer可能有成百上千個memstore，每個 memstore也許未達(dá)到flush.size，jvm的heap就不夠用了。該參數(shù)就是為了限制memstores占用的總內(nèi)存。
當(dāng)ReigonServer內(nèi)所有的memstore所占用的內(nèi)存綜合達(dá)到heap的40%時，HBase會強(qiáng)制block所有的更新并flush這些memstore以釋放所有memstore占用的內(nèi)存。
lowerLimit說明： 同upperLimit，只不過當(dāng)全局memstore的內(nèi)存達(dá)到35%時，它不會flush所有的memstore，它會找一些內(nèi)存占用較大的 memstore，個別flush，當(dāng)然更新還是會被block。lowerLimit算是一個在全局flush前的補(bǔ)救措施。可以想象一下，如果 memstore需要在一段時間內(nèi)全部flush，且這段時間內(nèi)無法接受寫請求，對HBase集群的性能影響是很大的。
調(diào)優(yōu)：這是一個Heap內(nèi)存保護(hù)參數(shù)，默認(rèn)值已經(jīng)能適用大多數(shù)場景。它的調(diào)整一般是為了配合某些專屬優(yōu)化，比如讀密集型應(yīng)用，將讀緩存開大，降低該值，騰出更多內(nèi)存給其他模塊使用。
這個參數(shù)會給使用者帶來什么影響？
比如，10G內(nèi)存，100個region，每個memstore 64M，假設(shè)每個region只有一個memstore，那么當(dāng)100個memstore平均占用到50%左右時，就會達(dá)到lowerLimit的限制。 假設(shè)此時，其他memstore同樣有很多的寫請求進(jìn)來。在那些大的region未flush完，就可能又超過了upperlimit，則所有 region都會被block，開始觸發(fā)全局flush。
hfile.block.cache.size
默認(rèn)值：0.2
說明：storefile的讀緩存占用Heap的大小百分比，0.2表示20%。該值直接影響數(shù)據(jù)讀的性能。
調(diào)優(yōu)：當(dāng)然是越大越好，如果讀比寫少，開到0.4-0.5也沒問題。如果讀寫較均衡，0.3左右。如果寫比讀多，果斷 默認(rèn)吧。設(shè)置這個值的時候，你同時要參考 hbase.regionserver.global.memstore.upperLimit ，該值是 memstore占heap的最大百分比，兩個參數(shù)一個影響讀，一個影響寫。如果兩值加起來超過80-90%，會有OOM的風(fēng)險，謹(jǐn)慎設(shè)置。
hbase.hstore.blockingStoreFiles
默認(rèn)值：7
說明：在compaction時，如果一個Store（Coulmn Family）內(nèi)有超過7個storefile需要合并，則block所有的寫請求，進(jìn)行flush，限制storefile數(shù)量增長過快。
調(diào)優(yōu)：block請求會影響當(dāng)前region的讀寫性能，將值設(shè)為單個region可以支撐的最大store file數(shù)量會是個不錯的選擇。最大storefile數(shù)量可通過region size/memstore size來計算。如果你將region size設(shè)為無限大，那么你需要預(yù)估一個region可能產(chǎn)生的最大storefile數(shù)。
hbase.hregion.memstore.block.multiplier
默認(rèn)值：2
說明：當(dāng)一個region里的memstore超過單個memstore.size兩倍的大小時，block該 region的所有請求，進(jìn)行flush，釋放內(nèi)存。雖然我們設(shè)置了memstore的總大小，比如64M，但想象一下，在最后63.9M的時候，我 Put了一個100M的數(shù)據(jù)或?qū)懻埱罅勘┰觯詈笠幻腌妏ut了1萬次，此時memstore的大小會瞬間暴漲到超過預(yù)期的memstore.size。 這個參數(shù)的作用是當(dāng)memstore的大小增至超過memstore.size時，block所有請求，遏制風(fēng)險進(jìn)一步擴(kuò)大。
調(diào)優(yōu)： 這個參數(shù)的默認(rèn)值還是比較靠譜的。如果你預(yù)估你的正常應(yīng)用場景（不包括異常）不會出現(xiàn)突發(fā)寫或?qū)懙牧靠煽兀敲幢３帜J(rèn)值即可。如果正常情況下，你的寫量 就會經(jīng)常暴增，那么你應(yīng)該調(diào)大這個倍數(shù)并調(diào)整其他參數(shù)值，比如hfile.block.cache.size和 hbase.regionserver.global.memstore.upperLimit/lowerLimit，以預(yù)留更多內(nèi)存，防止HBase server OOM。
其他
啟用LZO壓縮
LZO對比Hbase默認(rèn)的GZip，前者性能較高，后者壓縮比較高，具體參見 Using LZO Compression 。對于想提高HBase讀寫性能的開發(fā)者，采用LZO是比較好的選擇。對于非常在乎存儲空間的開發(fā)者，則建議保持默認(rèn)。
不要在一張表里定義太多的Column Family
Hbase目前不能良好的處理超過2-3個CF的表。因為某個CF在flush發(fā)生時，它鄰近的CF也會因關(guān)聯(lián)效應(yīng)被觸發(fā)flush，最終導(dǎo)致系統(tǒng)產(chǎn)生很多IO。
批量導(dǎo)入
在批量導(dǎo)入數(shù)據(jù)到Hbase前，你可以通過預(yù)先創(chuàng)建region，來平衡數(shù)據(jù)的負(fù)載。詳見 Table Creation: Pre-Creating Regions
Hbase客戶端優(yōu)化
AutoFlush
將HTable的setAutoFlush設(shè)為false，可以支持客戶端批量更新。即當(dāng)Put填滿客戶端flush緩存時，才發(fā)送到服務(wù)端。
默認(rèn)是true。
Scan Caching
scanner一次緩存多少數(shù)據(jù)來scan（從服務(wù)端一次抓多少數(shù)據(jù)回來scan）。
默認(rèn)值是 1，一次只取一條。
Scan Attribute Selection
scan時建議指定需要的Column Family，減少通信量，否則scan默認(rèn)會返回整個row的所有數(shù)據(jù)（所有Coulmn Family）。
Close ResultScanners
通過scan取完數(shù)據(jù)后，記得要關(guān)閉ResultScanner，否則RegionServer可能會出現(xiàn)問題。
Optimal Loading of Row Keys
當(dāng)你scan一張表的時候，返回結(jié)果只需要row key（不需要CF, qualifier,values,timestaps）時，你可以在scan實例中添加一個filterList，并設(shè)置 MUST_PASS_ALL操作，filterList中add FirstKeyOnlyFilter或KeyOnlyFilter。這樣可以減少網(wǎng)絡(luò)通信量。
Turn off WAL on Puts
當(dāng)Put某些非重要數(shù)據(jù)時，你可以設(shè)置writeToWAL(false)，來進(jìn)一步提高寫性能。writeToWAL(false)會在Put時放棄寫WAL log。風(fēng)險是，當(dāng)RegionServer宕機(jī)時，可能你剛才Put的那些數(shù)據(jù)會丟失，且無法恢復(fù)。
啟用Bloom Filter
Bloom Filter通過空間換時間，提高讀操作性能。
轉(zhuǎn)載請注明原文鏈接：http://kenwublog.com/hbase-performance-tuning