HBase最佳實踐——讀性能優化策略

任何系統都會有各類各樣的問題，有些是系統自己設計問題，有些倒是使用姿式問題。HBase也同樣，在真實生產線上你們或多或少都會遇到不少問題，有些是HBase還須要完善的，有些是咱們確實對它瞭解太少。總結起來，你們遇到的主要問題無非是Full GC異常致使宕機問題、RIT問題、寫吞吐量過低以及讀延遲較大。

Full GC問題以前在一些文章裏面已經講過它的前因後果，主要的解決方案目前主要有兩方面須要注意，一方面須要查看GC日誌確認是哪一種Full GC，根據Full GC類型對JVM參數進行調優，另外一方面須要確認是否開啓了BucketCache的offheap模式，建議使用LRUBlockCache的童鞋儘快轉移到BucketCache來。固然咱們仍是很期待官方2.0.0版本發佈的更多offheap模塊。

RIT問題，我相信更可能是由於咱們對其不瞭解，具體原理能夠戳 這裏 ，解決方案目前有兩個，優先是使用官方提供的HBCK進行修復(HBCK本人一直想拿出來分享，可是目前案例還很少，等後面有更多案例的話再拿出來講)，使用以後仍是解決不了的話就須要手動修復文件或者元數據表。而對於寫吞吐量過低以及讀延遲太大的優化問題，筆者也和不少朋友進行過探討，這篇文章就以讀延遲優化爲核心內容展開，具體分析HBase進行讀延遲優化的那些套路，以及這些套路以後的具體原理。但願你們在看完以後可以結合這些套路剖析本身的系統。

通常狀況下，讀請求延遲較大一般存在三種場景，分別爲：

1. 僅有某業務延遲較大，集羣其餘業務都正常；

2. 整個集羣全部業務都反映延遲較大；

3. 某個業務起來以後集羣其餘部分業務延遲較大。

這三種場景是表象，一般某業務反應延遲異常，首先須要明確具體是哪一種場景，而後針對性解決問題。下圖是對讀優化思路的一點總結，主要分爲四個方面：客戶端優化、服務器端優化、列族設計優化以及HDFS相關優化，下面每個小點都會按照場景分類，文章最後進行概括總結。下面分別進行詳細講解：

HBase讀優化

HBase客戶端優化

和大多數系統同樣，客戶端做爲業務讀寫的入口，姿式使用不正確一般會致使 本業務讀延遲較高 實際上存在一些使用姿式的推薦用法，這裏通常須要關注四個問題：

1. scan緩存是否設置合理?

優化原理：在解釋這個問題以前，首先須要解釋什麼是scan緩存，一般來說一次scan會返回大量數據，所以客戶端發起一次scan請求，實際並不會一次就將全部數據加載到本地，而是分紅屢次RPC請求進行加載，這樣設計一方面是由於大量數據請求可能會致使網絡帶寬嚴重消耗進而影響其餘業務，另外一方面也有可能由於數據量太大致使本地客戶端發生OOM。在這樣的設計體系下用戶會首先加載一部分數據到本地，而後遍歷處理，再加載下一部分數據到本地處理，如此往復，直至全部數據都加載完成。數據加載到本地就存放在scan緩存中，默認100條數據大小。

一般狀況下，默認的scan緩存設置就能夠正常工做的。可是在一些大scan(一次scan可能須要查詢幾萬甚至幾十萬行數據)來講，每次請求100條數據意味着一次scan須要幾百甚至幾千次RPC請求，這種交互的代價無疑是很大的。所以能夠考慮將scan緩存設置增大，好比設爲500或者1000就可能更加合適。筆者以前作過一次試驗，在一次scan掃描10w+條數據量的條件下，將scan緩存從100增長到1000，能夠有效下降scan請求的整體延遲，延遲基本下降了25%左右。歡迎加入大數據學習交流分享羣： 658558542   一塊兒吹水交流學習（☛點擊便可加入羣聊）

優化建議：大scan場景下將scan緩存從100增大到500或者1000，用以減小RPC次數。

2. get請求是否可使用批量請求?

優化原理：HBase分別提供了單條get以及批量get的API接口，使用批量get接口能夠減小客戶端到RegionServer之間的RPC鏈接數，提升讀取性能。另外須要注意的是，批量get請求要麼成功返回全部請求數據，要麼拋出異常。

優化建議：使用批量get進行讀取請求。

3. 請求是否能夠顯示指定列族或者列?

優化原理：HBase是典型的列族數據庫，意味着同一列族的數據存儲在一塊兒，不一樣列族的數據分開存儲在不一樣的目錄下。若是一個表有多個列族，只是根據Rowkey而不指定列族進行檢索的話不一樣列族的數據須要獨立進行檢索，性能必然會比指定列族的查詢差不少，不少狀況下甚至會有2倍～3倍的性能損失。

優化建議：能夠指定列族或者列進行精確查找的儘可能指定查找。

4. 離線批量讀取請求是否設置禁止緩存?

優化原理：一般離線批量讀取數據會進行一次性全表掃描，一方面數據量很大，另外一方面請求只會執行一次。這種場景下若是使用scan默認設置，就會將數據從HDFS加載出來以後放到緩存。可想而知，大量數據進入緩存必將其餘實時業務熱點數據擠出，其餘業務不得不從HDFS加載，進而會形成明顯的讀延遲毛刺歡迎加入大數據學習交流分享羣： 658558542   一塊兒吹水交流學習（☛點擊便可加入羣聊）

優化建議：離線批量讀取請求設置禁用緩存，scan.setBlockCache(false)。

HBase服務器端優化

通常服務端端問題一旦致使業務讀請求延遲較大的話，一般是集羣級別的，即整個集羣的業務都會反映讀延遲較大。能夠從4個方面入手：

1. 讀請求是否均衡?

優化原理：極端狀況下假如全部的讀請求都落在一臺RegionServer的某幾個Region上，這一方面不能發揮整個集羣的併發處理能力，另外一方面勢必形成此臺RegionServer資源嚴重消耗(好比IO耗盡、handler耗盡等)，落在該臺RegionServer上的其餘業務會所以受到很大的波及。可見，讀請求不均衡不只會形成自己業務性能不好，還會嚴重影響其餘業務。固然，寫請求不均衡也會形成相似的問題，可見負載不均衡是HBase的大忌。

觀察確認：觀察全部RegionServer的讀請求QPS曲線，確認是否存在讀請求不均衡現象。

優化建議：RowKey必須進行散列化處理(好比MD5散列)，同時建表必須進行預分區處理。

2. BlockCache是否設置合理?

優化原理：BlockCache做爲讀緩存，對於讀性能來講相當重要。默認狀況下BlockCache和Memstore的配置相對比較均衡(各佔40%)，能夠根據集羣業務進行修正，好比讀多寫少業務能夠將BlockCache佔比調大。另外一方面，BlockCache的策略選擇也很重要，不一樣策略對讀性能來講影響並非很大，可是對GC的影響卻至關顯著，尤爲BucketCache的offheap模式下GC表現很優越。另外，HBase 2.0對offheap的改造(HBASE-11425)將會使HBase的讀性能獲得2～4倍的提高，同時GC表現會更好!

觀察確認：觀察全部RegionServer的緩存未命中率、配置文件相關配置項一級GC日誌，確認BlockCache是否能夠優化。

優化建議：JVM內存配置量 < 20G，BlockCache策略選擇LRUBlockCache;不然選擇BucketCache策略的offheap模式;期待HBase 2.0的到來!

3. HFile文件是否太多?

優化原理：HBase讀取數據一般首先會到Memstore和BlockCache中檢索(讀取最近寫入數據&熱點數據)，若是查找不到就會到文件中檢索。HBase的類LSM結構會致使每一個store包含多數HFile文件，文件越多，檢索所需的IO次數必然越多，讀取延遲也就越高。文件數量一般取決於Compaction的執行策略，通常和兩個配置參數有關：hbase.hstore.compactionThreshold和hbase.hstore.compaction.max.size，前者表示一個store中的文件數超過多少就應該進行合併，後者表示參數合併的文件大小最大是多少，超過此大小的文件不能參與合併。這兩個參數不能設置太’鬆’(前者不能設置太大，後者不能設置過小)，致使Compaction合併文件的實際效果不明顯，進而不少文件得不到合併。這樣就會致使HFile文件數變多。

觀察確認：觀察RegionServer級別以及Region級別的storefile數，確認HFile文件是否過多。

優化建議：hbase.hstore.compactionThreshold設置不能太大，默認是3個;設置須要根據Region大小肯定，一般能夠簡單的認爲hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold。

4. Compaction是否消耗系統資源過多?

優化原理：Compaction是將小文件合併爲大文件，提升後續業務隨機讀性能，可是也會帶來IO放大以及帶寬消耗問題(數據遠程讀取以及三副本寫入都會消耗系統帶寬)。正常配置狀況下Minor Compaction並不會帶來很大的系統資源消耗，除非由於配置不合理致使Minor Compaction太過頻繁，或者Region設置太大狀況下發生Major Compaction。

觀察確認：觀察系統IO資源以及帶寬資源使用狀況，再觀察Compaction隊列長度，確認是否因爲Compaction致使系統資源消耗過多。

優化建議：

(1)Minor Compaction設置：hbase.hstore.compactionThreshold設置不能過小，又不能設置太大，所以建議設置爲5～6;hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold。

(2)Major Compaction設置：大Region讀延遲敏感業務( 100G以上)一般不建議開啓自動Major Compaction，手動低峯期觸發。小Region或者延遲不敏感業務能夠開啓Major Compaction，但建議限制流量;

(3)期待更多的優秀Compaction策略，相似於stripe-compaction儘早提供穩定服務。

HBase列族設計優化

HBase列族設計對讀性能影響也相當重要，其特色是隻影響單個業務，並不會對整個集羣產生太大影響。列族設計主要從兩個方面檢查：

1. Bloomfilter是否設置?是否設置合理?

優化原理：Bloomfilter主要用來過濾不存在待檢索RowKey或者Row-Col的HFile文件，避免無用的IO操做。它會告訴你在這個HFile文件中是否可能存在待檢索的KV，若是不存在，就能夠不用消耗IO打開文件進行seek。很顯然，經過設置Bloomfilter能夠提高隨機讀寫的性能。

Bloomfilter取值有兩個，row以及rowcol，須要根據業務來肯定具體使用哪一種。若是業務大多數隨機查詢僅僅使用row做爲查詢條件，Bloomfilter必定要設置爲row，不然若是大多數隨機查詢使用row+cf做爲查詢條件，Bloomfilter須要設置爲rowcol。若是不肯定業務查詢類型，設置爲row。

優化建議：任何業務都應該設置Bloomfilter，一般設置爲row就能夠，除非確認業務隨機查詢類型爲row+cf，能夠設置爲rowcol。

HDFS相關優化

HDFS做爲HBase最終數據存儲系統，一般會使用三副本策略存儲HBase數據文件以及日誌文件。從HDFS的角度望上層看，HBase便是它的客戶端，HBase經過調用它的客戶端進行數據讀寫操做，所以HDFS的相關優化也會影響HBase的讀寫性能。這裏主要關注以下三個方面：

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

優化原理：當前HDFS讀取數據都須要通過DataNode，客戶端會向DataNode發送讀取數據的請求，DataNode接受到請求以後從硬盤中將文件讀出來，再經過TPC發送給客戶端。Short Circuit策略容許客戶端繞過DataNode直接讀取本地數據。

優化建議：開啓Short Circuit Local Read功能，具體配置戳這裏。

2. Hedged Read功能是否開啓?

優化原理：HBase數據在HDFS中通常都會存儲三份，並且優先會經過Short-Circuit Local Read功能嘗試本地讀。可是在某些特殊狀況下，有可能會出現由於磁盤問題或者網絡問題引發的短期本地讀取失敗，爲了應對這類問題，社區開發者提出了補償重試機制 – Hedged Read。該機制基本工做原理爲：客戶端發起一個本地讀，一旦一段時間以後尚未返回，客戶端將會向其餘DataNode發送相同數據的請求。哪個請求先返回，另外一個就會被丟棄。

優化建議：開啓Hedged Read功能。

3. 數據本地率是否過低?

數據本地率：HDFS數據一般存儲三份，假如當前RegionA處於Node1上，數據a寫入的時候三副本爲(Node1,Node2,Node3)，數據b寫入三副本是(Node1,Node4,Node5)，數據c寫入三副本(Node1,Node3,Node5)，能夠看出來全部數據寫入本地Node1確定會寫一份，數據都在本地能夠讀到，所以數據本地率是100%。如今假設RegionA被遷移到了Node2上，只有數據a在該節點上，其餘數據(b和c)讀取只能遠程跨節點讀，本地率就爲33%(假設a，b和c的數據大小相同)。歡迎加入大數據學習交流分享羣： 658558542   一塊兒吹水交流學習（☛點擊便可加入羣聊）

優化原理：數據本地率過低很顯然會產生大量的跨網絡IO請求，必然會致使讀請求延遲較高，所以提升數據本地率能夠有效優化隨機讀性能。數據本地率低的緣由通常是由於Region遷移(自動balance開啓、RegionServer宕機遷移、手動遷移等),所以一方面能夠經過避免Region無端遷移來保持數據本地率，另外一方面若是數據本地率很低，也能夠經過執行major_compact提高數據本地率到100%。

優化建議：避免Region無端遷移，好比關閉自動balance、RS宕機及時拉起並遷回飄走的Region等;在業務低峯期執行major_compact提高數據本地率。

HBase讀性能優化概括

在本文開始的時候提到讀延遲較大無非三種常見的表象，單個業務慢、集羣隨機讀慢以及某個業務隨機讀以後其餘業務受到影響致使隨機讀延遲很大。瞭解完常見的可能致使讀延遲較大的一些問題以後，咱們將這些問題進行以下歸類，讀者能夠在看到現象以後在對應的問題列表中進行具體定位：

HBase讀性能優化總結

性能優化是任何一個系統都會遇到的話題，每一個系統也都有本身的優化方式。 HBase做爲分佈式KV數據庫，優化點又格外不一樣，更多得融入了分佈式特性以及存儲系統優化特性。文中總結了讀優化的基本突破點，有什麼不對的地方還望指正，有補充的也能夠一塊兒探討交流!

結語

感謝您的觀看，若有不足之處，歡迎批評指正。

若是有對大數據感興趣的小夥伴或者是從事大數據的老司機能夠加羣：

658558542    （☛點擊便可加入羣聊）

裏面整理了一大份學習資料，全都是些乾貨，包括大數據技術入門，海量數據高級分析語言，海量數據存儲分佈式存儲，以及海量數據分析分佈式計算等部分，送給每一位大數據小夥伴，這裏不止是小白彙集地，還有大牛在線解答！歡迎初學和進階中的小夥伴一塊兒進羣學習交流，共同進步！

最後祝福全部遇到瓶頸的大數據程序員們突破本身，祝福你們在日後的工做與面試中一切順利。