[[176416]]

任何系統(tǒng)都會(huì)有各種各樣的問題，有些是系統(tǒng)本身設(shè)計(jì)問題，有些卻是使用姿勢(shì)問題。HBase也一樣，在真實(shí)生產(chǎn)線上大家或多或少都會(huì)遇到很多問題，有些是HBase還需要完善的，有些是我們確實(shí)對(duì)它了解太少?？偨Y(jié)起來，大家遇到的主要問題無非是Full GC異常導(dǎo)致宕機(jī)問題、RIT問題、寫吞吐量太低以及讀延遲較大。

Full GC問題之前在一些文章里面已經(jīng)講過它的來龍去脈，主要的解決方案目前主要有兩方面需要注意，一方面需要查看GC日志確認(rèn)是哪種Full GC，根據(jù)Full GC類型對(duì)JVM參數(shù)進(jìn)行調(diào)優(yōu)，另一方面需要確認(rèn)是否開啟了BucketCache的offheap模式，建議使用LRUBlockCache的童鞋盡快轉(zhuǎn)移到BucketCache來。當(dāng)然我們還是很期待官方2.0.0版本發(fā)布的更多offheap模塊。

RIT問題，我相信更多是因?yàn)槲覀儗?duì)其不了解，具體原理可以戳 這里 ，解決方案目前有兩個(gè)，優(yōu)先是使用官方提供的HBCK進(jìn)行修復(fù)(HBCK本人一直想拿出來分享，但是目前案例還不多，等后面有更多案例的話再拿出來說)，使用之后還是解決不了的話就需要手動(dòng)修復(fù)文件或者元數(shù)據(jù)表。

而對(duì)于寫吞吐量太低以及讀延遲太大的優(yōu)化問題，筆者也和很多朋友進(jìn)行過探討，這篇文章就以讀延遲優(yōu)化為核心內(nèi)容展開，具體分析HBase進(jìn)行讀延遲優(yōu)化的那些套路，以及這些套路之后的具體原理。希望大家在看完之后能夠結(jié)合這些套路剖析自己的系統(tǒng)。

一般情況下，讀請(qǐng)求延遲較大通常存在三種場(chǎng)景，分別為：

1. 僅有某業(yè)務(wù)延遲較大，集群其他業(yè)務(wù)都正常

2. 整個(gè)集群所有業(yè)務(wù)都反映延遲較大

3. 某個(gè)業(yè)務(wù)起來之后集群其他部分業(yè)務(wù)延遲較大

這三種場(chǎng)景是表象，通常某業(yè)務(wù)反應(yīng)延遲異常，首先需要明確具體是哪種場(chǎng)景，然后針對(duì)性解決問題。下圖是對(duì)讀優(yōu)化思路的一點(diǎn)總結(jié)，主要分為四個(gè)方面：客戶端優(yōu)化、服務(wù)器端優(yōu)化、列族設(shè)計(jì)優(yōu)化以及HDFS相關(guān)優(yōu)化，下面每一個(gè)小點(diǎn)都會(huì)按照?qǐng)鼍胺诸?，文?**進(jìn)行歸納總結(jié)。下面分別進(jìn)行詳細(xì)講解：

HBase客戶端優(yōu)化

和大多數(shù)系統(tǒng)一樣，客戶端作為業(yè)務(wù)讀寫的入口，姿勢(shì)使用不正確通常會(huì)導(dǎo)致 本業(yè)務(wù)讀延遲較高 實(shí)際上存在一些使用姿勢(shì)的推薦用法，這里一般需要關(guān)注四個(gè)問題：

1. scan緩存是否設(shè)置合理?

優(yōu)化原理：在解釋這個(gè)問題之前，首先需要解釋什么是scan緩存，通常來講一次scan會(huì)返回大量數(shù)據(jù)，因此客戶端發(fā)起一次scan請(qǐng)求，實(shí)際并不會(huì)一次就將所有數(shù)據(jù)加載到本地，而是分成多次RPC請(qǐng)求進(jìn)行加載，這樣設(shè)計(jì)一方面是因?yàn)榇罅繑?shù)據(jù)請(qǐng)求可能會(huì)導(dǎo)致網(wǎng)絡(luò)帶寬嚴(yán)重消耗進(jìn)而影響其他業(yè)務(wù)，另一方面也有可能因?yàn)閿?shù)據(jù)量太大導(dǎo)致本地客戶端發(fā)生OOM。在這樣的設(shè)計(jì)體系下用戶會(huì)首先加載一部分?jǐn)?shù)據(jù)到本地，然后遍歷處理，再加載下一部分?jǐn)?shù)據(jù)到本地處理，如此往復(fù)，直至所有數(shù)據(jù)都加載完成。數(shù)據(jù)加載到本地就存放在scan緩存中，默認(rèn)100條數(shù)據(jù)大小。

通常情況下，默認(rèn)的scan緩存設(shè)置就可以正常工作的。但是在一些大scan(一次scan可能需要查詢幾萬(wàn)甚至幾十萬(wàn)行數(shù)據(jù))來說，每次請(qǐng)求100條數(shù)據(jù)意味著一次scan需要幾百甚至幾千次RPC請(qǐng)求，這種交互的代價(jià)無疑是很大的。因此可以考慮將scan緩存設(shè)置增大，比如設(shè)為500或者1000就可能更加合適。筆者之前做過一次試驗(yàn)，在一次scan掃描10w+條數(shù)據(jù)量的條件下，將scan緩存從100增加到1000，可以有效降低scan請(qǐng)求的總體延遲，延遲基本降低了25%左右。

優(yōu)化建議：大scan場(chǎng)景下將scan緩存從100增大到500或者1000，用以減少RPC次數(shù)

2. get請(qǐng)求是否可以使用批量請(qǐng)求?

優(yōu)化原理：HBase分別提供了單條get以及批量get的API接口，使用批量get接口可以減少客戶端到RegionServer之間的RPC連接數(shù)，提高讀取性能。另外需要注意的是，批量get請(qǐng)求要么成功返回所有請(qǐng)求數(shù)據(jù)，要么拋出異常。

優(yōu)化建議：使用批量get進(jìn)行讀取請(qǐng)求

3. 請(qǐng)求是否可以顯示指定列族或者列?

優(yōu)化原理：HBase是典型的列族數(shù)據(jù)庫(kù)，意味著同一列族的數(shù)據(jù)存儲(chǔ)在一起，不同列族的數(shù)據(jù)分開存儲(chǔ)在不同的目錄下。如果一個(gè)表有多個(gè)列族，只是根據(jù)Rowkey而不指定列族進(jìn)行檢索的話不同列族的數(shù)據(jù)需要獨(dú)立進(jìn)行檢索，性能必然會(huì)比指定列族的查詢差很多，很多情況下甚至?xí)?倍～3倍的性能損失。

優(yōu)化建議：可以指定列族或者列進(jìn)行精確查找的盡量指定查找

4. 離線批量讀取請(qǐng)求是否設(shè)置禁止緩存?

優(yōu)化原理：通常離線批量讀取數(shù)據(jù)會(huì)進(jìn)行一次性全表掃描，一方面數(shù)據(jù)量很大，另一方面請(qǐng)求只會(huì)執(zhí)行一次。這種場(chǎng)景下如果使用scan默認(rèn)設(shè)置，就會(huì)將數(shù)據(jù)從HDFS加載出來之后放到緩存?？上攵罅繑?shù)據(jù)進(jìn)入緩存必將其他實(shí)時(shí)業(yè)務(wù)熱點(diǎn)數(shù)據(jù)擠出，其他業(yè)務(wù)不得不從HDFS加載，進(jìn)而會(huì)造成明顯的讀延遲毛刺

優(yōu)化建議：離線批量讀取請(qǐng)求設(shè)置禁用緩存，scan.setBlockCache(false)

HBase服務(wù)器端優(yōu)化

一般服務(wù)端端問題一旦導(dǎo)致業(yè)務(wù)讀請(qǐng)求延遲較大的話，通常是集群級(jí)別的，即整個(gè)集群的業(yè)務(wù)都會(huì)反映讀延遲較大?？梢詮?個(gè)方面入手：

1. 讀請(qǐng)求是否均衡?

優(yōu)化原理：極端情況下假如所有的讀請(qǐng)求都落在一臺(tái)RegionServer的某幾個(gè)Region上，這一方面不能發(fā)揮整個(gè)集群的并發(fā)處理能力，另一方面勢(shì)必造成此臺(tái)RegionServer資源嚴(yán)重消耗(比如IO耗盡、handler耗盡等)，落在該臺(tái)RegionServer上的其他業(yè)務(wù)會(huì)因此受到很大的波及?？梢?，讀請(qǐng)求不均衡不僅會(huì)造成本身業(yè)務(wù)性能很差，還會(huì)嚴(yán)重影響其他業(yè)務(wù)。當(dāng)然，寫請(qǐng)求不均衡也會(huì)造成類似的問題，可見負(fù)載不均衡是HBase的大忌。

觀察確認(rèn)：觀察所有RegionServer的讀請(qǐng)求QPS曲線，確認(rèn)是否存在讀請(qǐng)求不均衡現(xiàn)象

優(yōu)化建議：RowKey必須進(jìn)行散列化處理(比如MD5散列)，同時(shí)建表必須進(jìn)行預(yù)分區(qū)處理

2. BlockCache是否設(shè)置合理?

優(yōu)化原理：BlockCache作為讀緩存，對(duì)于讀性能來說至關(guān)重要。默認(rèn)情況下BlockCache和Memstore的配置相對(duì)比較均衡(各占40%)，可以根據(jù)集群業(yè)務(wù)進(jìn)行修正，比如讀多寫少業(yè)務(wù)可以將BlockCache占比調(diào)大。另一方面，BlockCache的策略選擇也很重要，不同策略對(duì)讀性能來說影響并不是很大，但是對(duì)GC的影響卻相當(dāng)顯著，尤其BucketCache的offheap模式下GC表現(xiàn)很優(yōu)越。另外，HBase 2.0對(duì)offheap的改造(HBASE-11425)將會(huì)使HBase的讀性能得到2～4倍的提升，同時(shí)GC表現(xiàn)會(huì)更好!

觀察確認(rèn)：觀察所有RegionServer的緩存未***率、配置文件相關(guān)配置項(xiàng)一級(jí)GC日志，確認(rèn)BlockCache是否可以優(yōu)化

優(yōu)化建議：JVM內(nèi)存配置量 < 20G，BlockCache策略選擇LRUBlockCache;否則選擇BucketCache策略的offheap模式;期待HBase 2.0的到來!

3. HFile文件是否太多?

優(yōu)化原理：HBase讀取數(shù)據(jù)通常首先會(huì)到Memstore和BlockCache中檢索(讀取最近寫入數(shù)據(jù)&熱點(diǎn)數(shù)據(jù))，如果查找不到就會(huì)到文件中檢索。HBase的類LSM結(jié)構(gòu)會(huì)導(dǎo)致每個(gè)store包含多數(shù)HFile文件，文件越多，檢索所需的IO次數(shù)必然越多，讀取延遲也就越高。文件數(shù)量通常取決于Compaction的執(zhí)行策略，一般和兩個(gè)配置參數(shù)有關(guān)：hbase.hstore.compactionThreshold和hbase.hstore.compaction.max.size，前者表示一個(gè)store中的文件數(shù)超過多少就應(yīng)該進(jìn)行合并，后者表示參數(shù)合并的文件大小***是多少，超過此大小的文件不能參與合并。這兩個(gè)參數(shù)不能設(shè)置太’松’(前者不能設(shè)置太大，后者不能設(shè)置太小)，導(dǎo)致Compaction合并文件的實(shí)際效果不明顯，進(jìn)而很多文件得不到合并。這樣就會(huì)導(dǎo)致HFile文件數(shù)變多。

觀察確認(rèn)：觀察RegionServer級(jí)別以及Region級(jí)別的storefile數(shù)，確認(rèn)HFile文件是否過多

優(yōu)化建議：hbase.hstore.compactionThreshold設(shè)置不能太大，默認(rèn)是3個(gè);設(shè)置需要根據(jù)Region大小確定，通常可以簡(jiǎn)單的認(rèn)為hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold

4. Compaction是否消耗系統(tǒng)資源過多?

優(yōu)化原理：Compaction是將小文件合并為大文件，提高后續(xù)業(yè)務(wù)隨機(jī)讀性能，但是也會(huì)帶來IO放大以及帶寬消耗問題(數(shù)據(jù)遠(yuǎn)程讀取以及三副本寫入都會(huì)消耗系統(tǒng)帶寬)。正常配置情況下Minor Compaction并不會(huì)帶來很大的系統(tǒng)資源消耗，除非因?yàn)榕渲貌缓侠韺?dǎo)致Minor Compaction太過頻繁，或者Region設(shè)置太大情況下發(fā)生Major Compaction。

觀察確認(rèn)：觀察系統(tǒng)IO資源以及帶寬資源使用情況，再觀察Compaction隊(duì)列長(zhǎng)度，確認(rèn)是否由于Compaction導(dǎo)致系統(tǒng)資源消耗過多

優(yōu)化建議：

(1)Minor Compaction設(shè)置：hbase.hstore.compactionThreshold設(shè)置不能太小，又不能設(shè)置太大，因此建議設(shè)置為5～6;hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold

(2)Major Compaction設(shè)置：大Region讀延遲敏感業(yè)務(wù)( 100G以上)通常不建議開啟自動(dòng)Major Compaction，手動(dòng)低峰期觸發(fā)。小Region或者延遲不敏感業(yè)務(wù)可以開啟Major Compaction，但建議限制流量;

(3)期待更多的優(yōu)秀Compaction策略，類似于stripe-compaction盡早提供穩(wěn)定服務(wù)

HBase列族設(shè)計(jì)優(yōu)化

HBase列族設(shè)計(jì)對(duì)讀性能影響也至關(guān)重要，其特點(diǎn)是只影響單個(gè)業(yè)務(wù)，并不會(huì)對(duì)整個(gè)集群產(chǎn)生太大影響。列族設(shè)計(jì)主要從兩個(gè)方面檢查：

1. Bloomfilter是否設(shè)置?是否設(shè)置合理?

優(yōu)化原理：Bloomfilter主要用來過濾不存在待檢索RowKey或者Row-Col的HFile文件，避免無用的IO操作。它會(huì)告訴你在這個(gè)HFile文件中是否可能存在待檢索的KV，如果不存在，就可以不用消耗IO打開文件進(jìn)行seek。很顯然，通過設(shè)置Bloomfilter可以提升隨機(jī)讀寫的性能。

Bloomfilter取值有兩個(gè)，row以及rowcol，需要根據(jù)業(yè)務(wù)來確定具體使用哪種。如果業(yè)務(wù)大多數(shù)隨機(jī)查詢僅僅使用row作為查詢條件，Bloomfilter一定要設(shè)置為row，否則如果大多數(shù)隨機(jī)查詢使用row+cf作為查詢條件，Bloomfilter需要設(shè)置為rowcol。如果不確定業(yè)務(wù)查詢類型，設(shè)置為row。

優(yōu)化建議：任何業(yè)務(wù)都應(yīng)該設(shè)置Bloomfilter，通常設(shè)置為row就可以，除非確認(rèn)業(yè)務(wù)隨機(jī)查詢類型為row+cf，可以設(shè)置為rowcol

HDFS相關(guān)優(yōu)化

HDFS作為HBase最終數(shù)據(jù)存儲(chǔ)系統(tǒng)，通常會(huì)使用三副本策略存儲(chǔ)HBase數(shù)據(jù)文件以及日志文件。從HDFS的角度望上層看，HBase即是它的客戶端，HBase通過調(diào)用它的客戶端進(jìn)行數(shù)據(jù)讀寫操作，因此HDFS的相關(guān)優(yōu)化也會(huì)影響HBase的讀寫性能。這里主要關(guān)注如下三個(gè)方面：

1. Short-Circuit Local Read功能是否開啟?

優(yōu)化原理：當(dāng)前HDFS讀取數(shù)據(jù)都需要經(jīng)過DataNode，客戶端會(huì)向DataNode發(fā)送讀取數(shù)據(jù)的請(qǐng)求，DataNode接受到請(qǐng)求之后從硬盤中將文件讀出來，再通過TPC發(fā)送給客戶端。Short Circuit策略允許客戶端繞過DataNode直接讀取本地?cái)?shù)據(jù)。(具體原理參考 此處 )

優(yōu)化建議：開啟Short Circuit Local Read功能，具體配置戳 這里

2. Hedged Read功能是否開啟?

優(yōu)化原理：HBase數(shù)據(jù)在HDFS中一般都會(huì)存儲(chǔ)三份，而且優(yōu)先會(huì)通過Short-Circuit Local Read功能嘗試本地讀。但是在某些特殊情況下，有可能會(huì)出現(xiàn)因?yàn)榇疟P問題或者網(wǎng)絡(luò)問題引起的短時(shí)間本地讀取失敗，為了應(yīng)對(duì)這類問題，社區(qū)開發(fā)者提出了補(bǔ)償重試機(jī)制 – Hedged Read。該機(jī)制基本工作原理為：客戶端發(fā)起一個(gè)本地讀，一旦一段時(shí)間之后還沒有返回，客戶端將會(huì)向其他DataNode發(fā)送相同數(shù)據(jù)的請(qǐng)求。哪一個(gè)請(qǐng)求先返回，另一個(gè)就會(huì)被丟棄。

優(yōu)化建議：開啟Hedged Read功能，具體配置參考 這里

3. 數(shù)據(jù)本地率是否太低?

數(shù)據(jù)本地率：HDFS數(shù)據(jù)通常存儲(chǔ)三份，假如當(dāng)前RegionA處于Node1上，數(shù)據(jù)a寫入的時(shí)候三副本為(Node1,Node2,Node3)，數(shù)據(jù)b寫入三副本是(Node1,Node4,Node5)，數(shù)據(jù)c寫入三副本(Node1,Node3,Node5)，可以看出來所有數(shù)據(jù)寫入本地Node1肯定會(huì)寫一份，數(shù)據(jù)都在本地可以讀到，因此數(shù)據(jù)本地率是100%?，F(xiàn)在假設(shè)RegionA被遷移到了Node2上，只有數(shù)據(jù)a在該節(jié)點(diǎn)上，其他數(shù)據(jù)(b和c)讀取只能遠(yuǎn)程跨節(jié)點(diǎn)讀，本地率就為33%(假設(shè)a，b和c的數(shù)據(jù)大小相同)。

優(yōu)化原理：數(shù)據(jù)本地率太低很顯然會(huì)產(chǎn)生大量的跨網(wǎng)絡(luò)IO請(qǐng)求，必然會(huì)導(dǎo)致讀請(qǐng)求延遲較高，因此提高數(shù)據(jù)本地率可以有效優(yōu)化隨機(jī)讀性能。數(shù)據(jù)本地率低的原因一般是因?yàn)镽egion遷移(自動(dòng)balance開啟、RegionServer宕機(jī)遷移、手動(dòng)遷移等),因此一方面可以通過避免Region無故遷移來保持?jǐn)?shù)據(jù)本地率，另一方面如果數(shù)據(jù)本地率很低，也可以通過執(zhí)行major_compact提升數(shù)據(jù)本地率到100%。

優(yōu)化建議：避免Region無故遷移，比如關(guān)閉自動(dòng)balance、RS宕機(jī)及時(shí)拉起并遷回飄走的Region等;在業(yè)務(wù)低峰期執(zhí)行major_compact提升數(shù)據(jù)本地率

HBase讀性能優(yōu)化歸納

在本文開始的時(shí)候提到讀延遲較大無非三種常見的表象，單個(gè)業(yè)務(wù)慢、集群隨機(jī)讀慢以及某個(gè)業(yè)務(wù)隨機(jī)讀之后其他業(yè)務(wù)受到影響導(dǎo)致隨機(jī)讀延遲很大。了解完常見的可能導(dǎo)致讀延遲較大的一些問題之后，我們將這些問題進(jìn)行如下歸類，讀者可以在看到現(xiàn)象之后在對(duì)應(yīng)的問題列表中進(jìn)行具體定位：

HBase讀性能優(yōu)化總結(jié)

性能優(yōu)化是任何一個(gè)系統(tǒng)都會(huì)遇到的話題，每個(gè)系統(tǒng)也都有自己的優(yōu)化方式。 HBase作為分布式KV數(shù)據(jù)庫(kù)，優(yōu)化點(diǎn)又格外不同，更多得融入了分布式特性以及存儲(chǔ)系統(tǒng)優(yōu)化特性。文中總結(jié)了讀優(yōu)化的基本突破點(diǎn)，有什么不對(duì)的地方還望指正，有補(bǔ)充的也可以一起探討交流!