史上第二全面的HBase讀寫效能優化總結

語言: CN / TW / HK

HBase 讀取效能優化

1. HBase服務端優化

1.1 讀請求是否均衡

如果資料吞吐量較大,且一次查詢返回的資料量較大,則Rowkey 必須進行雜湊化處理,同時建表必須進行預分割槽處理。對於以get為主的查詢場景,則將表進行hash預分割槽,均勻分佈;如果以scan為主,則需要兼顧業務場景設計rowkey,在滿足查詢需求的前提下儘量對資料打散並進行負載均衡。

1.2 BlockCache 設定是否合理

一個通用的規則就是:如果 JVM 記憶體配置量小於 20G,BlockCache 策略選擇 LRUBlockCache;否則選擇 BucketCache 策略的 offheap 模式。如果是heap模式,也可以根據業務場景的讀寫比例來配置堆中讀寫heap的比例,預設堆中讀寫快取均佔heap的40%,即讀寫均衡。

1.3 HFile 檔案是否太多

一個 Store 中包含多個 HFile 檔案,檔案越多,檢索所需的 IO 次數越多,讀取延遲也越高。檔案數量通常取決於 Compaction 的執行策略,一般和兩個配置引數有關:hbase.hstore.compactionThreshold 和 hbase.hstore.compaction.max.size ,前者表示一個 store 中的檔案數超過閾值就應該進行合併,後者表示參與合併的檔案大小最大是多少,超過此大小的檔案不能參與合併。

可以檢視 RegionServer 級別以及 Region 級別的HFile數量,確認 HFile 檔案是否過多。

hbase.hstore.compactionThreshold 設定不能太大,預設為3個。

1.4 Compaction 是否消費系統資源過多

由於配置檔案中預設的major compact是定時按表執行,且消耗資源很大,對系統性能影響同樣很大,所以對於大 Region 讀延遲敏感的業務(100G以上)通常不建議開啟自動 Major Compaction,手動低峰期觸發;小 Region 或者延遲不敏感的業務可以開啟 Major Compaction,但建議限制流量。

1.5 資料本地率是不是很低

儘量避免 Region 無故遷移。對於本地化率較低的節點,可以在業務低峰期執行 major_compact。

2. HBase客戶端優化

2.1 scan 快取是否設定合理

在HBase總RPC次數調整到比較合理的前提下,可以考慮將大 scan 場景下將 scan 快取從 100 增大到 500 或者 1000,用以減少 RPC 次數。

2.2 get 是否使用批量請求

HBase 分別提供了單條 get 以及批量 get 的 API 介面,使用批量 get 介面可以減少客戶端到 RegionServer 之間的 RPC 連線數,提高讀取吞吐量。

2.3 請求是否可以顯式指定列簇或者列

儘量指定列簇或者列進行精確查詢。

2.4 離線批量讀取請求是否設定禁止快取

離線批量讀取請求設定禁用快取,scan.setCacheBlocks(false),此種場景適用於離線的全表掃秒,如mapreduce。此時使用快取不僅無法提升效能,可能還會適得其反。

3. HBase列簇設計優化

建議在任何業務都應該設定布隆過濾器,通常設定為 row,除非確定業務隨機查詢型別為 row + column,則設定為 rowcol(適合大量指定column的場景,這種場景下佔用的快取記憶體以及磁碟的量會增加)。

HBase 寫入效能調優

1. HBase 伺服器端優化

1.1 Region 是否太少

在表的 Region 數量小於 RegionServer 節點數的場景下,需要將切分部分請求負載高的Region,並遷移到其他 RegionServer 節點上,已達到充分利用伺服器資源,負載均衡。

1.2 寫入請求是否均衡

檢查 RowKey 設計以及預分割槽策略,保證寫入請求均衡。針對get查詢為主的表,可以使用hash預分割槽策略;針對scan為主的表,建議使用分段預分割槽的策略。

1.3 使用 SSD 儲存 WAL

將 WAL 檔案寫到SSD上,對於寫效能會有非常大的提升。

使用該特性配置步驟:

使用 HDFS Archival Storage 機制,配置 HDFS 的部分檔案目錄為 SSD 介質

hbase-site.xml 新增配置

<property>
<name>hbase.wal.storage.policy</name>
<value>ONE_SSD</value>
</property>

hbase.wal.storage.policy 預設為 none,使用者可以指定 ONESSD(WAL 一個副本寫入 SSD 介質)或者 ALLSSD(WAL的三個副本全部寫入 SSD 介質)。

2. HBase客戶端優化

2.1 是否可以使用 Bulkload 方案寫入

Bulkload 是一個 MapReduce 程式,輸出 HFile 檔案。這種方式的業務場景是離線匯入資料,有點事吞吐量大 ,效率高;缺點是實時性差。

2.2 是否需要寫WAL?WAL是否需要同步寫入

此處劃重點:如果業務上能夠忍受小分部資料丟失,且需要極限提高寫入速度,可以考慮禁用WAL,這樣做的缺點就是系統crash的時候會丟一部分資料,且無法做跨叢集的replication。

資料寫入流程可以理解為 一次順序寫WAL+一次寫快取。

WAL 的持久化分為四個等級:

SKIP_WAL
ASYNC_WAL
SYNC_WAL
FSYNC_WAL

預設為 SYNC_WAL 等級持久化資料。

根據業務關注點在 WAL 機制和寫入吞吐量之間作出選擇,使用者可以通過客戶端設定 WAL 持久化策略。

2.3 Put 是否可以同步批量提交

類似 Get 介面。

2.4 Put 是否可以非同步批量提交

開啟非同步批量提交,使用者可以設定 setAutoFlush(false),客戶端快取達到閾值(預設2M)後批量提交給 RegionServer。這樣做的好處是能夠減少RPC呼叫的次數,提高吞吐量;缺點是如果客戶端異常,快取資料可能丟失。

2.5 寫入 KeyValue 資料是否太大

KeyValue 大小對寫入效能影響巨大。如果太大,會對效能產生很大的影響。

RowKey的最大長度限制為64KB,但在實際應用中最多不會超過100B。這是由於HBase的rowkey會被多次冗餘儲存,RowKey越大,浪費的記憶體和硬碟資源也會越多。

Value過大也會對效能產生很大的影響,也會影響到HBase的響應速度。如果Value過大,建議拆成多列儲存,每次返回需要的值,或者將Value儲存到HDFS上,在HBase中儲存url

原文連結:

https://blog.csdn.net/microGP/article/details/116946418