HBase最佳實踐－讀性能優(yōu)化策略 – 有態(tài)度的HBase/Spark/BigData http://hbasefly.com/2016/11/11/hbase%e6%9c%80%e4%bd%b3%e5%ae%9e%e8%b7%b5%ef%bc%8d%e8%af%bb%e6%80%a7%e8%83%bd%e4%bc%98%e5%8c%96%e7%ad%96%e7%95%a5/
任何系統(tǒng)都會有各種各樣的問題，有些是系統(tǒng)本身設計問題泥张，有些卻是使用姿勢問題集侯。HBase也一樣，在真實生產(chǎn)線上大家或多或少都會遇到很多問題，有些是HBase還需要完善的跳纳，有些是我們確實對它了解太少疟暖。總結起來蜜葱，大家遇到的主要問題無非是Full GC異常導致宕機問題全景、RIT問題、寫吞吐量太低以及讀延遲較大笼沥。
Full GC問題之前在一些文章里面已經(jīng)講過它的來龍去脈蚪燕，主要的解決方案目前主要有兩方面需要注意，一方面需要查看GC日志確認是哪種Full GC奔浅，根據(jù)Full GC類型對JVM參數(shù)進行調優(yōu)馆纳，另一方面需要確認是否開啟了BucketCache的offheap模式，建議使用LRUBlockCache的童鞋盡快轉移到BucketCache來汹桦。當然我們還是很期待官方2.0.0版本發(fā)布的更多offheap模塊鲁驶。
RIT問題，我相信更多是因為我們對其不了解舞骆，具體原理可以戳這里钥弯，解決方案目前有兩個，優(yōu)先是使用官方提供的HBCK進行修復（HBCK本人一直想拿出來分享督禽，但是目前案例還不多脆霎，等后面有更多案例的話再拿出來說），使用之后還是解決不了的話就需要手動修復文件或者元數(shù)據(jù)表狈惫。
而對于寫吞吐量太低以及讀延遲太大的優(yōu)化問題睛蛛，筆者也和很多朋友進行過探討，這篇文章就以讀延遲優(yōu)化為核心內容展開胧谈，具體分析HBase進行讀延遲優(yōu)化的那些套路忆肾，以及這些套路之后的具體原理。希望大家在看完之后能夠結合這些套路剖析自己的系統(tǒng)菱肖。
一般情況下客冈，讀請求延遲較大通常存在三種場景，分別為：
- 僅有某業(yè)務延遲較大稳强，集群其他業(yè)務都正常
- 整個集群所有業(yè)務都反映延遲較大
- 某個業(yè)務起來之后集群其他部分業(yè)務延遲較大
這三種場景是表象场仲，通常某業(yè)務反應延遲異常和悦，首先需要明確具體是哪種場景，然后針對性解決問題燎窘。下圖是對讀優(yōu)化思路的一點總結摹闽，主要分為四個方面：客戶端優(yōu)化、服務器端優(yōu)化褐健、列族設計優(yōu)化以及HDFS相關優(yōu)化付鹿，下面每一個小點都會按照場景分類，文章最后進行歸納總結蚜迅。下面分別進行詳細講解：
HBase客戶端優(yōu)化
和大多數(shù)系統(tǒng)一樣舵匾，客戶端作為業(yè)務讀寫的入口，姿勢使用不正確通常會導致本業(yè)務讀延遲較高實際上存在一些使用姿勢的推薦用法谁不，這里一般需要關注四個問題：
1. scan緩存是否設置合理坐梯？
優(yōu)化原理：在解釋這個問題之前，首先需要解釋什么是scan緩存刹帕，通常來講一次scan會返回大量數(shù)據(jù)吵血，因此客戶端發(fā)起一次scan請求，實際并不會一次就將所有數(shù)據(jù)加載到本地偷溺，而是分成多次RPC請求進行加載蹋辅，這樣設計一方面是因為大量數(shù)據(jù)請求可能會導致網(wǎng)絡帶寬嚴重消耗進而影響其他業(yè)務，另一方面也有可能因為數(shù)據(jù)量太大導致本地客戶端發(fā)生OOM挫掏。在這樣的設計體系下用戶會首先加載一部分數(shù)據(jù)到本地侦另，然后遍歷處理，再加載下一部分數(shù)據(jù)到本地處理尉共，如此往復褒傅，直至所有數(shù)據(jù)都加載完成。數(shù)據(jù)加載到本地就存放在scan緩存中袄友，默認100條數(shù)據(jù)大小殿托。
通常情況下，默認的scan緩存設置就可以正常工作的剧蚣。但是在一些大scan（一次scan可能需要查詢幾萬甚至幾十萬行數(shù)據(jù)）來說支竹，每次請求100條數(shù)據(jù)意味著一次scan需要幾百甚至幾千次RPC請求，這種交互的代價無疑是很大的券敌。因此可以考慮將scan緩存設置增大唾戚，比如設為500或者1000就可能更加合適柳洋。筆者之前做過一次試驗待诅，在一次scan掃描10w+條數(shù)據(jù)量的條件下，將scan緩存從100增加到1000熊镣，可以有效降低scan請求的總體延遲卑雁，延遲基本降低了25%左右募书。
優(yōu)化建議：大scan場景下將scan緩存從100增大到500或者1000，用以減少RPC次數(shù)
2. get請求是否可以使用批量請求测蹲？
優(yōu)化原理：HBase分別提供了單條get以及批量get的API接口莹捡，使用批量get接口可以減少客戶端到RegionServer之間的RPC連接數(shù)，提高讀取性能扣甲。另外需要注意的是米酬，批量get請求要么成功返回所有請求數(shù)據(jù)照弥，要么拋出異常。
優(yōu)化建議：使用批量get進行讀取請求
3. 請求是否可以顯示指定列族或者列？
優(yōu)化原理：HBase是典型的列族數(shù)據(jù)庫娄琉，意味著同一列族的數(shù)據(jù)存儲在一起，不同列族的數(shù)據(jù)分開存儲在不同的目錄下胜蛉。如果一個表有多個列族掌桩，只是根據(jù)Rowkey而不指定列族進行檢索的話不同列族的數(shù)據(jù)需要獨立進行檢索，性能必然會比指定列族的查詢差很多矾麻，很多情況下甚至會有2倍～3倍的性能損失纱耻。
優(yōu)化建議：可以指定列族或者列進行精確查找的盡量指定查找
4. 離線批量讀取請求是否設置禁止緩存？
優(yōu)化原理：通常離線批量讀取數(shù)據(jù)會進行一次性全表掃描险耀，一方面數(shù)據(jù)量很大弄喘，另一方面請求只會執(zhí)行一次。這種場景下如果使用scan默認設置胰耗，就會將數(shù)據(jù)從HDFS加載出來之后放到緩存限次。可想而知柴灯，大量數(shù)據(jù)進入緩存必將其他實時業(yè)務熱點數(shù)據(jù)擠出卖漫，其他業(yè)務不得不從HDFS加載，進而會造成明顯的讀延遲毛刺
優(yōu)化建議：離線批量讀取請求設置禁用緩存赠群，scan.setBlockCache(false)
HBase服務器端優(yōu)化
一般服務端端問題一旦導致業(yè)務讀請求延遲較大的話羊始，通常是集群級別的，即整個集群的業(yè)務都會反映讀延遲較大查描⊥晃可以從4個方面入手：
5. 讀請求是否均衡？
優(yōu)化原理：極端情況下假如所有的讀請求都落在一臺RegionServer的某幾個Region上冬三，這一方面不能發(fā)揮整個集群的并發(fā)處理能力匀油，另一方面勢必造成此臺RegionServer資源嚴重消耗（比如IO耗盡、handler耗盡等）勾笆，落在該臺RegionServer上的其他業(yè)務會因此受到很大的波及敌蚜。可見窝爪，讀請求不均衡不僅會造成本身業(yè)務性能很差弛车，還會嚴重影響其他業(yè)務齐媒。當然，寫請求不均衡也會造成類似的問題纷跛，可見負載不均衡是HBase的大忌喻括。
觀察確認：觀察所有RegionServer的讀請求QPS曲線，確認是否存在讀請求不均衡現(xiàn)象
優(yōu)化建議：RowKey必須進行散列化處理（比如MD5散列）贫奠，同時建表必須進行預分區(qū)處理
6. BlockCache是否設置合理唬血？
優(yōu)化原理：BlockCache作為讀緩存，對于讀性能來說至關重要唤崭。默認情況下BlockCache和Memstore的配置相對比較均衡（各占40%）刁品，可以根據(jù)集群業(yè)務進行修正，比如讀多寫少業(yè)務可以將BlockCache占比調大浩姥。另一方面挑随，BlockCache的策略選擇也很重要，不同策略對讀性能來說影響并不是很大勒叠，但是對GC的影響卻相當顯著兜挨，尤其BucketCache的offheap模式下GC表現(xiàn)很優(yōu)越。另外眯分，HBase 2.0對offheap的改造（HBASE-11425）將會使HBase的讀性能得到2～4倍的提升拌汇，同時GC表現(xiàn)會更好！
觀察確認：觀察所有RegionServer的緩存未命中率弊决、配置文件相關配置項一級GC日志噪舀，確認BlockCache是否可以優(yōu)化
優(yōu)化建議：JVM內存配置量 < 20G，BlockCache策略選擇LRUBlockCache飘诗；否則選擇BucketCache策略的offheap模式与倡；期待HBase 2.0的到來！
7. HFile文件是否太多昆稿？
優(yōu)化原理：HBase讀取數(shù)據(jù)通常首先會到Memstore和BlockCache中檢索（讀取最近寫入數(shù)據(jù)&熱點數(shù)據(jù)）纺座，如果查找不到就會到文件中檢索。HBase的類LSM結構會導致每個store包含多數(shù)HFile文件溉潭，文件越多净响，檢索所需的IO次數(shù)必然越多，讀取延遲也就越高喳瓣。文件數(shù)量通常取決于Compaction的執(zhí)行策略馋贤，一般和兩個配置參數(shù)有關：hbase.hstore.compactionThreshold和hbase.hstore.compaction.max.size，前者表示一個store中的文件數(shù)超過多少就應該進行合并畏陕，后者表示參數(shù)合并的文件大小最大是多少配乓，超過此大小的文件不能參與合并。這兩個參數(shù)不能設置太’松’（前者不能設置太大，后者不能設置太腥鸥丁），導致Compaction合并文件的實際效果不明顯仁讨，進而很多文件得不到合并羽莺。這樣就會導致HFile文件數(shù)變多。
觀察確認：觀察RegionServer級別以及Region級別的storefile數(shù)洞豁，確認HFile文件是否過多
優(yōu)化建議：hbase.hstore.compactionThreshold設置不能太大盐固，默認是3個；設置需要根據(jù)Region大小確定丈挟，通车蟛罚可以簡單的認為hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold
8. Compaction是否消耗系統(tǒng)資源過多？
優(yōu)化原理：Compaction是將小文件合并為大文件曙咽，提高后續(xù)業(yè)務隨機讀性能蛔趴，但是也會帶來IO放大以及帶寬消耗問題（數(shù)據(jù)遠程讀取以及三副本寫入都會消耗系統(tǒng)帶寬）。正常配置情況下Minor Compaction并不會帶來很大的系統(tǒng)資源消耗例朱，除非因為配置不合理導致Minor Compaction太過頻繁孝情，或者Region設置太大情況下發(fā)生Major Compaction。
觀察確認：觀察系統(tǒng)IO資源以及帶寬資源使用情況洒嗤，再觀察Compaction隊列長度箫荡，確認是否由于Compaction導致系統(tǒng)資源消耗過多
優(yōu)化建議：
（1）Minor Compaction設置：hbase.hstore.compactionThreshold設置不能太小，又不能設置太大渔隶，因此建議設置為5～6羔挡；hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold
（2）Major Compaction設置：大Region讀延遲敏感業(yè)務（ 100G以上）通常不建議開啟自動Major Compaction，手動低峰期觸發(fā)间唉。小Region或者延遲不敏感業(yè)務可以開啟Major Compaction绞灼，但建議限制流量；
（3）期待更多的優(yōu)秀Compaction策略呈野，類似于stripe-compaction盡早提供穩(wěn)定服務
HBase列族設計優(yōu)化
HBase列族設計對讀性能影響也至關重要镀赌，其特點是只影響單個業(yè)務，并不會對整個集群產(chǎn)生太大影響际跪。列族設計主要從兩個方面檢查：
9. Bloomfilter是否設置商佛？是否設置合理？
優(yōu)化原理：Bloomfilter主要用來過濾不存在待檢索RowKey或者Row-Col的HFile文件姆打，避免無用的IO操作良姆。它會告訴你在這個HFile文件中是否可能存在待檢索的KV，如果不存在幔戏，就可以不用消耗IO打開文件進行seek玛追。很顯然，通過設置Bloomfilter可以提升隨機讀寫的性能。
Bloomfilter取值有兩個痊剖，row以及rowcol韩玩，需要根據(jù)業(yè)務來確定具體使用哪種。如果業(yè)務大多數(shù)隨機查詢僅僅使用row作為查詢條件陆馁，Bloomfilter一定要設置為row找颓，否則如果大多數(shù)隨機查詢使用row+cf作為查詢條件，Bloomfilter需要設置為rowcol叮贩。如果不確定業(yè)務查詢類型击狮，設置為row。
優(yōu)化建議：任何業(yè)務都應該設置Bloomfilter益老，通常設置為row就可以彪蓬，除非確認業(yè)務隨機查詢類型為row+cf，可以設置為rowcol
HDFS相關優(yōu)化
HDFS作為HBase最終數(shù)據(jù)存儲系統(tǒng)捺萌，通常會使用三副本策略存儲HBase數(shù)據(jù)文件以及日志文件档冬。從HDFS的角度望上層看，HBase即是它的客戶端桃纯，HBase通過調用它的客戶端進行數(shù)據(jù)讀寫操作捣郊，因此HDFS的相關優(yōu)化也會影響HBase的讀寫性能。這里主要關注如下三個方面：
10. Short-Circuit Local Read功能是否開啟慈参？
優(yōu)化原理：當前HDFS讀取數(shù)據(jù)都需要經(jīng)過DataNode呛牲，客戶端會向DataNode發(fā)送讀取數(shù)據(jù)的請求，DataNode接受到請求之后從硬盤中將文件讀出來驮配，再通過TPC發(fā)送給客戶端娘扩。Short Circuit策略允許客戶端繞過DataNode直接讀取本地數(shù)據(jù)。（具體原理參考此處）
優(yōu)化建議：開啟Short Circuit Local Read功能壮锻，具體配置戳這里
11. Hedged Read功能是否開啟琐旁？
優(yōu)化原理：HBase數(shù)據(jù)在HDFS中一般都會存儲三份，而且優(yōu)先會通過Short-Circuit Local Read功能嘗試本地讀猜绣。但是在某些特殊情況下灰殴，有可能會出現(xiàn)因為磁盤問題或者網(wǎng)絡問題引起的短時間本地讀取失敗，為了應對這類問題掰邢，社區(qū)開發(fā)者提出了補償重試機制 – Hedged Read牺陶。該機制基本工作原理為：客戶端發(fā)起一個本地讀，一旦一段時間之后還沒有返回辣之，客戶端將會向其他DataNode發(fā)送相同數(shù)據(jù)的請求掰伸。哪一個請求先返回，另一個就會被丟棄怀估。
優(yōu)化建議：開啟Hedged Read功能狮鸭，具體配置參考這里
12. 數(shù)據(jù)本地率是否太低合搅？
數(shù)據(jù)本地率：HDFS數(shù)據(jù)通常存儲三份，假如當前RegionA處于Node1上歧蕉，數(shù)據(jù)a寫入的時候三副本為(Node1,Node2,Node3)灾部，數(shù)據(jù)b寫入三副本是(Node1,Node4,Node5)，數(shù)據(jù)c寫入三副本(Node1,Node3,Node5)惯退，可以看出來所有數(shù)據(jù)寫入本地Node1肯定會寫一份赌髓，數(shù)據(jù)都在本地可以讀到，因此數(shù)據(jù)本地率是100%≌舯裕現(xiàn)在假設RegionA被遷移到了Node2上，只有數(shù)據(jù)a在該節(jié)點上呛哟，其他數(shù)據(jù)（b和c）讀取只能遠程跨節(jié)點讀叠荠，本地率就為33%（假設a，b和c的數(shù)據(jù)大小相同）扫责。
優(yōu)化原理：數(shù)據(jù)本地率太低很顯然會產(chǎn)生大量的跨網(wǎng)絡IO請求榛鼎，必然會導致讀請求延遲較高，因此提高數(shù)據(jù)本地率可以有效優(yōu)化隨機讀性能鳖孤。數(shù)據(jù)本地率低的原因一般是因為Region遷移（自動balance開啟者娱、RegionServer宕機遷移、手動遷移等）,因此一方面可以通過避免Region無故遷移來保持數(shù)據(jù)本地率苏揣，另一方面如果數(shù)據(jù)本地率很低黄鳍，也可以通過執(zhí)行major_compact提升數(shù)據(jù)本地率到100%。
優(yōu)化建議：避免Region無故遷移平匈，比如關閉自動balance框沟、RS宕機及時拉起并遷回飄走的Region等；在業(yè)務低峰期執(zhí)行major_compact提升數(shù)據(jù)本地率
HBase讀性能優(yōu)化歸納
在本文開始的時候提到讀延遲較大無非三種常見的表象增炭，單個業(yè)務慢忍燥、集群隨機讀慢以及某個業(yè)務隨機讀之后其他業(yè)務受到影響導致隨機讀延遲很大。了解完常見的可能導致讀延遲較大的一些問題之后隙姿，我們將這些問題進行如下歸類梅垄，讀者可以在看到現(xiàn)象之后在對應的問題列表中進行具體定位：
HBase讀性能優(yōu)化總結
性能優(yōu)化是任何一個系統(tǒng)都會遇到的話題，每個系統(tǒng)也都有自己的優(yōu)化方式输玷。 HBase作為分布式KV數(shù)據(jù)庫队丝，優(yōu)化點又格外不同，更多得融入了分布式特性以及存儲系統(tǒng)優(yōu)化特性欲鹏。文中總結了讀優(yōu)化的基本突破點炭玫，有什么不對的地方還望指正，有補充的也可以一起探討交流貌虾！
