史上第二全面的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