hbase讀寫優化
一、hbase讀優化
客戶端優化
1、scan緩存是否設置合理？
優化原理：一次scan請求，實際並不會一次就將所有數據加載到本地，而是多次RPC請求進行加載。默認100條數據大小。
優化建議：大scan場景下將scan緩存從100增大到500或者1000，以減少RPC次數
2、get請求是否可以使用批量請求？
優化原理：Hbase分別提供了單條get以及批量get的API接口，使用批量get接口可以減少客戶端到RegionServer之間的PRC連接數，提高讀取性能。
3、請求是否可以顯示指定列族或者列？
優化原理：同一列族的數據存儲在一起，不同列族的數據分開存儲在不同的目錄下。如果一個表有多個列族，只是根據Rowkey而不指定列族進行檢索的話不同列族的數需要獨立進行檢索，很多情況下甚至會有2倍~3倍的性能損失。
優化建議：可以指定列族或者列進行精確查找的盡量指定查找
4、離線批量讀取請求是否設置禁止緩存？
優化原理：大量數據進入緩存必將其他實時業務熱點數據擠出，其他業務不得不從HDFS加載，進而會造成明細的讀延遲毛刺。
優化建議：離線批量讀取請求設置禁用緩存，scan.setBlockCache(false)
服務端優化
1、讀請求是否均衡？
優化原理：讀請求不均衡不僅會造成本身業務性能很差，還會嚴重影響其他業務
觀察確認：觀察所有RegionServer的讀請求QPS曲線,確認是否存在讀請求不均衡現象
優化建議：RowKey必須進行散列話處理（比如MD5散列），同時建表時必須進行預分區處理
2、BlockCache是否設置合理？
優化原理：默認情況下BlockCache和Memstore的配置相對比較均衡（各占40%），可以根據集群業務進行修正，比如讀多寫少可以將BlockCache占比調大。
優化建議：JVM內存配置量<20G,BlockCache策略選擇LRUBlockCache;否則選擇BucketCache策略的offheap模式
3、HFile文件是否太多？
優化原理：文件越多，檢索所需的IO次數必然越多，讀取延遲也就越高。文件數量通常取決於Compaction的執行策略，一般和兩個參數有關：
hbase.hstore.compactionThreshold和hbase.hstore.compaction.max.size，前者表示一個store中的文件數超過多少就應該進行合並，後者表示參數合並的文件大小最大是多少，超過此大小的文件不能參與合並。
觀察確認：觀察RegionServer級別以及Region級別的storefile數，確認HFile文件是否過多
優化建議：hbase.store.compactionThreshold設置不能太大，默認是3個；設置需要根據Region大小確定，通常可以簡單的認為：
hbase.hstore.compaction.max.size=RegionSize / hbase.hstore.compactionThreshold
4、Compaction是否消耗系統資源過多？
優化原理：Compaction是將小文件合並為大文件，提高後續業務隨機讀性能，但是也會帶來IO放大以及帶寬消耗問題，問題主要產生於配置不合理導致Minor Compaction太過頻繁，或者Region設置太大情況下發生Major Compaction。
觀察確認：觀察系統IO資源以及帶寬資源使用情況，再觀察Compaction隊列長度，確認是否由於Compaction導致系統資源消耗過多。
優化建議：
a、Minor Compaction設置：hbase.hstore.compactionThreshold設置不能太小，又不能設置太大，因此建議設置為5~6；hbase.hstore.compaction.max.size=RegionSize / hbase.hstore.compactionThreshold
b、Major Compaction設置：大Region讀延遲敏感業務（100G以上）通常不建議開啟自動Major Compaction,手動低峰期觸發。小Region或者延遲不敏感業務可以開啟Major Compaction，但建議限制流量
Hbase列族設計優化
1、Bloomfilter是否設置？是否設置合理？
優化原理：過濾不存在待檢索Rowkey或者Row-Col的HFile文件，避免無用的IO操作。它會告訴你在這個HFile文件中是否存在待檢索的key-value，如果不存在，就可以不用消耗IO打開文件進行seek，可以提升隨機讀寫的性能。
Bloomfiler取值有兩個，Row以及RowCol ；如果業務大多數隨機查詢僅僅使用Row作為查詢條件，Bloomfiler一定要設置為Row;如果大多數隨機查詢使用Row+cf作為查詢條件，Bloomfilter要設置為RowCol。
優化建議：任何業務都應該設置Bloomfilter，通常設置為Row就可以，除非確認業務隨機查詢類型為Row+cf，可以設置為RowCol
HDFS相關優化
1、Short-Circuit Local Read功能是否開啟？
優化原理：當前HDFS讀取數據都需要經過DataNode，客戶端會向DataNode發送讀取數據的請求，DataNode接受請求之後從硬盤中將文件讀出來發送給客戶端。Short Circuit策略允許客戶端繞過DataNode直接讀取本地數據。
優化建議：開啟Short Circuit Local Read功能
2、Hedged Read功能是否開啟？
優化原理：優先會通過Short-Circuit Local Read功能嘗試本地讀。某些特殊情況下，有可能會出現因為磁盤問題或者網絡問題引起的短時間本地讀取失敗。補償重試機制-Hedged Read的基本工作原理為：客戶端發起一個本地讀，一旦一段時間之後還沒有返回，客戶端將會向其他DataNode發送相同數據的請求。哪一個請求先返回，另一個就會被丟棄。
優化建議：開啟Hedged Read功能
3、數據本地率是否太低？
優化原理：本地化率低會產生大量的跨網絡IO請求，必然會導致讀請求延遲較高，原因一般是因為Region遷移（自動balance開啟、RegionServer宕機遷移、手動遷移等），因此一方面可以通過避免Region無故遷移來保持數據本地率，另一方面如果數據本地率很低，也可以通過執行major_compact提升數據本地率。
優化建議：避免Region無故遷移，比如關閉自動balance、RegionServer宕機及時拉起並遷回飄走的Region等；在業務低峰期執行major_compact提升數據本地率
二、Hbase寫優化
1、是否需要寫WAL?WAL是否需要同步寫入？
優化原理：
a、WAL機制一方面是為了確保數據即使寫入緩存丟失也可以恢復，另一方面是為了集群之間異步復制
b、默認開啟
c、對於部分業務可能並不特別關心異常情況下部分數據的丟失，而更關心數據寫入吞吐量，比如某些推薦業務，這類業務即使丟失一部分用戶行為數據可能對推薦結果並不構成很大影響，但是對於寫入吞吐量要求很高，不能造成數據隊列阻塞。這種場景下可以考慮關閉WAL寫入，寫入吞吐量可以提升2x~3x，然而有些業務不能接受不寫WAL，但是可以接受WAL異步寫入，也是可以考慮優化的，通常也會帶來1x~2x的性能提升。
優化建議：根據業務關註點在WAL機制與寫入吞吐量直接作出選擇
2、Put是否可以同步批量提交
優化原理：Hbase分別提供了單條put以及批量put的API接口，使用批量put接口可以減少客戶端到RegionServer之間的RPC連接數，提高寫入性能。另外需要註意的是批量put請求要麽全部成功返回，要麽拋出異常。
優化建議：使用批量put進行寫入請求
3、Put是否可以一步批量提交?
優化原理：業務如果可以接受異常情況下少了數據丟失的話，還可以使用異步批量提交的方式提交請求。提交分為兩個階段執行：用戶提交寫請求之後，數據會寫入客戶端緩存，並返回用戶寫入成功；當客戶端緩存達到閾值（默認2M）之後批量提交給RegionServer。需要註意的是，在某些情況下客戶端異常的情況下緩存數據有可能丟失。
優化建議:在業務可以接受的情況下開啟異步批量提交
使用方式：setAutoFlush(false)
4、Region是否太少？
優化原理：當前集群中表的Region個數如果小於RegionServer個數，即Num（Region of Table ）< Num(RegionServer),可以考慮切分Region並盡可能分布到不同RegionServer來提高系統請求並發度
優化建議：在Num(Region of Tale)<Num(RegionServer)的場景下切分部分請求負載高的Region並遷移到其他RegionServer;
5、寫入請求是否不均衡？
優化原理：如果不均衡，一方面會導致系統並發度較低，另一方面也有可能造成部分節點負載很高，進而影響其他業務。
優化建議：檢查Rowkey設計以及預分區策略，保證寫入請求均衡。
三、Hbase優化總結
hbase讀寫優化