使用YCSB進行HBase效能測試

語言: CN / TW / HK

在叢集上執行任何效能基準測試工具時,關鍵的決定始終是應該使用什麼資料集大小進行效能測試,並且在這裡我們演示了為什麼在執行HBase效能時選擇“合適的”資料集大小非常重要在您的叢集上進行測試。

HBase叢集配置和資料集的大小可能會改變同一叢集上工作負載的效能和測試結果。您應該根據要了解的有關叢集效能的資訊來選擇此資料集大小。為了表明在可用記憶體快取和一個有配合從底層儲存我們跑讀取工作組之間的差異2 YCSB工作負載與同CDP私有云基礎7.2.2運營資料庫叢集上選擇適當的資料集大小的測試。我們使用的資料集大小為40GB與1TB,下面比較了不同YCSB工作負載的吞吐量,在圖表中,柱形越高,吞吐量越好。

注意:吞吐量=每秒操作

當應用程式嘗試從HBase叢集中讀取資料時,處理請求的區域伺服器會首先檢查所需的結果是否在其塊快取中已經存在於其程序本地的資料塊中。如果存在資料塊,則可以直接從快取中服務客戶請求,這算作快取命中。但是,如果該塊當前不在區域伺服器程序本地,則將其計為快取未命中,必須從HDFS儲存中的HFile中讀取該塊。然後,根據快取利用率,該塊將被儲存在快取中以供將來請求。 

如預期並在摘要圖中所示,與從hdfs儲存中的HFiles訪問資料的工作負載執行相比,大多數資料集適合快取記憶體的工作負載的延遲較低,吞吐量更高。 

為了選擇工作負載資料集大小來很好地滿足我們的測試目標,重要的是檢查RegionServer堆,L1和L2快取,OS緩衝區快取的大小,然後設定適當的資料集大小。在YCSB工作負載執行完成之後,可以檢查一個很好的引數,作為驗證事情是否按預期執行的一種方式,即從快取中提供了多少資料(快取命中)以及從hdfs儲存中訪問了多少資料。區域伺服器快取命中次數與總讀取請求的比率就是快取命中率。

您可以從L1快取命中率“ l1CacheHitRatio”配置中找到此資訊。如果在叢集中同時設定了L1和L2快取,則L1快取服務於索引塊,L2快取服務於資料塊,並且您可以記錄L1“ l1CacheHitRatio”和L2“ l2CacheHitRatio”配置以供參考。

本博文的其餘部分將詳細介紹測試設定,選擇資料集大小,然後使用這些資料集大小執行YCSB。

用於此測試的HBase叢集配置

  • 使用的叢集:6個節點叢集(1個主節點+ 5個區域伺服器)

  • 說明:Dell PowerEdge R430、20c / 40t Xenon e5-2630 v4 @ 2.2Ghz,128GB Ram,4-2TB磁碟

  • 安全性:未配置(無Kerberos)

  • CDP版本:CDP私有云Base 7.2.2具有1個主伺服器+ 5個區域伺服器的6節點HBase叢集

  • JDK使用jdk1.8_232

  • HBase Region伺服器配置了32GB堆 

  • HBase主站已配置有4GB堆

  • 具有LruBlockCache的L1快取記憶體用於12.3 GB快取記憶體大小

  • 叢集中的L1快取總數為61 GB(12.3 * 5 = 61GB)

  • 叢集上未配置L2堆外快取

大小調整案例1:資料完全適合叢集上的可用快取

在我們的HBase叢集中,我們在分配給L1塊快取的5個區域伺服器中總共配置了61GB(12.3GB * 5)。對於完全適合快取的資料集,我們選擇了大小為40GB資料集。 

大小調整案例2:資料集大於叢集上的可用快取

對於第二種情況,我們希望資料比可用快取大得多。為了選擇合適的資料集大小,我們查看了叢集中已配置的HBase塊快取和OS緩衝區快取。在給定的HBase叢集中,跨RegionServer聚合時,配置的L1塊快取為61G。伺服器節點每個伺服器總共有128G RAM,OS可以使用非專用於伺服器程序的任何記憶體來有效地快取基礎HDFS塊並提高整體吞吐量。在我們的測試配置中,每個區域伺服器節點上都有大約96G OS快取可用於此目的(忽略DataNode或OS程序使用的記憶體來簡化操作)。在5個區域伺服器上進行彙總,我們有大約500G的緩衝區(96G * 5個區域伺服器)潛力。因此,我們選擇了1TB的資料集大小,

將目標資料大小轉換為YCSB引數在YCSB中,預設情況下一行為1KB,因此,根據載入到YCSB“使用者表”中的行數,您可以輕鬆估算YCSB“使用者表”表資料大小。因此,如果您上載100萬行,則已將1,000,000 * 1KB = 1GB的資料上載到YCSB“使用者表”中。

我們兩個測試使用的資料集大小為:

  • 40 GB資料和4000萬行

  • 1 TB資料和10億行 

測試方法

在6節點叢集上安裝了CDP私有云基礎7.2.2,並生成了4000萬行的工作負載資料(總資料集大小=> 40 GB),並運行了YCSB工作負載。載入後,在開始工作負載測試之前,我們等待所有壓縮操作完成。在HBase上執行的YCSB工作負載是

  1. 工作負載A:50%讀取和50%更新

  2. 工作負載C:100%讀取 

  3. 工作負載F:50%讀取和50%更新/讀取-修改-寫入比率:50/50

  4. 僅自定義更新工作負載:100%更新

每個YCSB工作負載(A,C,F和UpdateOnly)各自執行15分鐘,並且重複完整的執行5次,兩次執行之間沒有重新啟動,以測量YCSB吞吐量*。顯示的結果是5次執行中最後3次執行的平均值。為了避免第一輪和第二輪的損失,忽略了前兩次測試。

一旦完成40GB的執行,我們就丟棄了可使用的使用者,並重新生成了10億行,以建立1TB的資料集大小,並在同一叢集上以相同的方法重新運行了測試。 

試驗結果

YCSB結果為40GB

在40GB的情況下,資料可以完全容納在叢集上的61GB L1快取中。在測試期間,在叢集中觀察到的L1快取命中率接近99%。 

提示: 對於較小的資料集,資料可以放入快取中,我們還可以使用“載入時快取”選項,並使用表選項PREFETCH_BLOCKS_ON_OPEN預熱快取以獲取100%的快取命中率

每個YCSB工作負載每5次執行15分鐘,並取最後3次執行的平均值,以避免第一次執行損失。

下表顯示了在區域伺服器上40G L1快取命中率達到99%時看到的結果: 

運作方式

數字行動

通量

平均延遲

95延遲

99等待時間



(每秒運算元)

(多發性硬化症)

(多發性硬化症)

(多發性硬化症)

工作負載C

148558364

165063

0.24

0.30

0.48

僅更新

56727908

63030

0.63

0.78

1.57

工作負載A

35745710

79439

0.40

0.54

0.66

工作負載F

24823285

55157

0.58

0.70

0.96

具有1TB資料集的YCSB結果

在1TB的情況下,資料無法放入叢集上的61GB L1快取記憶體或500GB OS緩衝區快取記憶體中。在測試期間觀察到的叢集中L1快取命中率為82-84%。 

我們每5次將每個工作負載執行15分鐘,並取最近3次執行的平均值,以避免第一次執行損失。

下表顯示了在區域伺服器上1TB L1快取命中率達到82-84%時看到的結果: 

運作方式

數字行動

通量

平均延遲

95延遲

99等待時間



(每秒運算元)

(多發性硬化症)

(多發性硬化症)

(多發性硬化症)

工作負載C

2727037

3030

13.19

55.50

110.85

僅更新

56345498

62605

0.64

0.78

1.58

工作負載A

3085135

6855

10.88

48.34

97.70

工作負載F

3333982

3704

10.45

47.78

98.62

*吞吐率(ops / sec)=每秒運算元

分析

比較上面兩個不同資料集大小的測試結果,我們可以看到當從具有預熱快取的40G資料集中更快地訪問資料而不是從hdfs快速訪問資料時,相同的工作負載吞吐量如何從每秒3K操作變化到每秒165K操作。儲存。

下面的圖表顯示了吞吐量,並比較了使用2個不同大小的資料集執行時不同工作負載的吞吐量如何變化。在圖表中,條形越高,吞吐量越好。

注意:吞吐量=每秒操作

如圖所示,在40G情況下,讀取資料如Workload A,Workload C和Workload F的YCSB工作負載具有更好的吞吐量,在40G情況下,資料容易放入快取,而在1TB資料大小的情況下,必須使用HFile資料。從HDFS訪問

從快取命中率來看,40G資料集的快取命中率接近99%,而1TB資料集的快取命中率約為85%,因此在1TB情況下,有15%的資料是從hdfs儲存中訪問的。

在這兩種情況下,我們執行的YCSB自定義僅更新工作負載都具有相同的吞吐量,因為它僅進行更新而沒有讀取。

在HBase效能期間,我們密切關注第95和第99個百分位延遲。平均延遲只是總吞吐量除以總時間,但是第95個百分位數和第99個百分位數顯示了影響總工作負載吞吐量的實際異常值。在1TB的情況下,第95和第99個百分位的高延遲異常值會導致吞吐量下降,而在40GB的情況下,第99個百分位的低延遲快取命中會導致總吞吐量增加。

下圖顯示了平均延遲,第95個百分位延遲和第99個百分位延遲的延遲比較,以及在使用不同大小的資料集執行時,不同工作負載的延遲差異。

在上面的圖表中,很難看到代表40GB資料集延遲的條形圖,因為它們與從HDFS訪問資料的1TB資料集所觀察到的延遲相比非常低。

我們使用等待時間值的對數繪製了等待時間圖,以顯示下表中的差異

如上所示,在40GB的情況下,快取命中率接近99%,並且大多數工作負載資料在快取中可用,因此延遲要低得多。與1TB資料集相比,由於必須從HDFS儲存訪問HFile資料,因此快取命中率約為85%。

在40G情況下,從預熱的快取返回99%資料的Workload C的平均延遲和99延遲約為2 – 4 ms。在1TB情況下,相同Workload C的第99個百分位數延遲對於Workload C(只讀工作負載)約為100ms。 

這表明從堆上塊快取記憶體命中的快取記憶體在大約2 ms內返回讀取,並且快取記憶體未命中以及從HDFS獲取記錄可能需要大約100 ms的時間。 

建議

在執行YCSB基準測試時,資料集的大小會對效能結果產生重大影響,因此適當調整測試的大小非常重要。同時,檢視快取命中率以及最小延遲與第99個延遲之間的延遲差異,將有助於您找到與從叢集中的基礎儲存訪問資料相比的快取命中的延遲。 

注意

要檢查區域伺服器上工作負載的快取命中率,可以使用以下命令

curl http://<region-server-host>:22102/jmx | grep -e l1CacheHitRatio -e l2CacheHitRatio

您還可以按照以下步驟從HBase Web UI中檢視快取命中率:

  1. 在HBase Web UI中,單擊區域伺服器 

  2. 在“塊快取記憶體”部分下,選擇L1(如果配置了L2,則選擇L2)以檢視快取記憶體命中率。 

螢幕快照顯示了來自L1塊快取的快取命中率,如下所示:

這是指向上面顯示的HBase螢幕快照和塊快取的更多資訊的連結https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html

關於YCSB

YCSB是一個開源規範和程式套件,用於評估計算機程式的檢索和維護功能。這是一個非常流行的工具,用於比較NoSQL資料庫管理系統的相對效能。 

要使用YCSB來測試運營資料庫的效能,請檢視部落格如何為HBase執行YCSB 

原文作者:Surbhi Kochhar

原文連結:https://blog.cloudera.com/hbase-performance-testing-using-ycsb/



本文分享自微信公眾號 - 大資料雜貨鋪(bigdataGrocery)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。