《HBase性能調優小結》要點：
本文介紹了HBase性能調優小結，希望對您有用。如果有疑問，可以聯系我們。

HBase官方性能調優文檔( 點擊這里 )中比擬詳細的介紹了相關的調優技巧,我在網上也找到了一篇不錯的中文總結,轉載之.需要注意下,文章發布時間有點久遠,隨著版本的更新有些地方可能有所變化,文章中的知識僅供參考.

(一)配置優化

zookeeper.session.timeout

默認值：3分鐘(180000ms)

闡明：RegionServer與Zookeeper間的連接超時時間.當超時時間到后,ReigonServer會被Zookeeper從RS集群清單中移除,HMaster收到移除通知后,會對這臺server負責的regions重新balance,讓其他存活的 RegionServer接管.

調優：這個timeout決定了RegionServer是否能夠及時的failover.設置成1分鐘或更低,可以減少因等待超時而被延長的failover時間.不過需要注意的是,對于一些Online應用,RegionServer的宕機到恢復時間自己就很短的(網絡閃斷,crash等故障,運維可快速介入),如果調低timeout時間,會得不償失.因為當ReigonServer被正式從RS集群中移除時,HMaster就開始做balance了,當故障的RS快速恢復后,這個balance動作是毫無意義的,反而會使負載不均勻,給RS帶來更多負擔.

hbase.regionserver.handler.count

默認值：10

說明：RegionServer的哀求處理IO線程數.

調優：這個參數的調優與內存息息相關.較少的IO線程,適用于處理單次哀求內存消耗較高的Big PUT場景(大容量單次PUT或設置了較大cache的scan,均屬于Big PUT)或ReigonServer的內存比較緊張的場景.較多的IO線程,適用于單次哀求內存消耗低,TPS要求非常高的場景.這里需要注意的是如果server的region數量很少,大量的哀求都落在一個region上,因快速充滿memstore觸發flush導致的讀寫鎖會影響全局TPS,不是IO線程數越高越好.壓測時,開啟Enabling RPC-level logging,可以同時監控每次哀求的內存消耗和GC的狀況,最后通過多次壓測結果來合理調節IO線程數.這里是一個案例 Hadoop and HBase Optimization for Read Intensive Search Applications ,作者在SSD的機器上設置IO線程數為100,僅供參考.

hbase.hregion.max.filesize

默認值：256M

闡明：在當前ReigonServer上單個Reigon的大小,單個Region超過指定值時,這個Region會被自動split成更小的region.

調優：小region對split和compaction友好,因為拆分region或compact小region里的storefile速度很快,內存占用低.缺點是split和compaction會很頻繁.特別是數量較多的小region不停地split, compaction,會使響應時間波動很大,region數量太多不僅給管理上帶來麻煩,甚至引發一些Hbase的bug.一般512以下的都算小region.大region,則不太適合經常split和compaction,因為做一次compact和split會產生較長時間的停頓,對應用的讀寫性能沖擊非常大.此外,大region意味著較大的storefile,compaction時對內存也是一個挑戰.當然,大region還是有其用武之地,你只要在某個訪問量低峰的時間點統一做compact和split,大region就可以發揮優勢了,畢竟它能保證絕大多數時間安穩的讀寫性能.既然split和compaction如此影響性能,有沒有辦法去掉?compaction是無法避免的,split倒是可以從自動調整為手動.只要通過將這個參數值調大到某個很難達到的值,比如100G,就可以間接禁用自動split(RegionServer不會對未到達100G的region做split).再配合RegionSplitter這個工具,在需要split時,手動split.手動split在靈活性和穩定性上比起自動split要高很多,相反,管理成本增加不多,比較推薦online實時系統使用.內存方面,小region在設置memstore的大小值上比較靈活,大region則過大過小都不行,過大會導致flush時app的IO wait增高,過小則因store file過多讀性能降低.

hbase.regionserver.global.memstore.upperLimit/lowerLimit

默認值：0.4/0.35

upperlimit說明：hbase.hregion.memstore.flush.size這個參數的作用是當單個memstore達到指定值時,flush該memstore.但是,一臺ReigonServer可能有成百上千個memstore,每個memstore也許未達到flush.size,jvm的heap就不夠用了.該參數便是為了限制memstores占用的總內存.當ReigonServer內所有的memstore所占用的內存綜合達到heap的40%時,HBase會強制block所有的更新并flush這些memstore以釋放所有memstore占用的內存.

lowerLimit說明：同upperLimit,只不過當全局memstore的內存達到35%時,它不會flush所有的memstore,它會找一些內存占用較大的memstore,個別flush,當然更新還是會被block.lowerLimit算是一個在全局flush前的補救措施.可以想象一下,如果memstore需要在一段時間內全部flush,且這段時間內無法接受寫哀求,對HBase集群的性能影響是很大的.調優：這是一個Heap內存保護參數,默認值已經能適用大多數場景.它的調整一般是為了配合某些專屬優化,比如讀密集型應用,將讀緩存開大,降低該值,騰出更多內存給其他模塊使用.這個參數會給使用者帶來什么影響?比如,10G內存,100個region,每個memstore 64M,假設每個region只有一個memstore,那么當100個memstore平均占用到50%左右時,就會達到lowerLimit的限制.假設此時,其他memstore同樣有很多的寫哀求進來.在那些大的region未flush完,就可能又超過了upperlimit,則所有 region都會被block,開始觸發全局flush.

hfile.block.cache.size

默認值：0.2

說明：storefile的讀緩存占用Heap的大小百分比,0.2表現20%.該值直接影響數據讀的性能.

調優：當然是越大越好,如果讀比寫少,開到0.4-0.5也沒問題.如果讀寫較均衡,0.3左右.如果寫比讀多,果斷默認吧.設置這個值的時候,你同時要參考hbase.regionserver.global.memstore.upperLimit,該值是 memstore占heap的最大百分比,兩個參數一個影響讀,一個影響寫.如果兩值加起來跨越80-90%,會有OOM的風險,謹慎設置.

hbase.hstore.blockingStoreFiles

默認值：7

說明：在compaction時,如果一個Store(Coulmn Family)內有超過7個storefile需要合并,則block所有的寫哀求,進行flush,限制storefile數量增長過快.

調優：block哀求會影響當前region的讀寫性能,將值設為單個region可以支撐的最大store file數量會是個不錯的選擇.最大storefile數量可通過region size/memstore size來計算.如果你將regionsize設為無限大,那么你需要預估一個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通過空間換光陰,提高讀操作性能.

歡迎參與《HBase性能調優小結》討論，分享您的想法，維易PHP學院為您提供專業教程。

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/8695.html