如何使用YCSB進行HBase性能測試

這篇文章給大家分享的是有關如何使用YCSB進行HBase性能測試的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

在集群上運行任何性能基準測試工具時，關鍵的決定始終是應該使用什么數(shù)據(jù)集大小進行性能測試，并且在這里我們演示了為什么在運行HBase性能時選擇“合適的”數(shù)據(jù)集大小非常重要在您的集群上進行測試。

HBase集群配置和數(shù)據(jù)集的大小可能會改變同一集群上工作負載的性能和測試結果。您應該根據(jù)要了解的有關集群性能的信息來選擇此數(shù)據(jù)集大小。為了表明在可用內(nèi)存緩存和一個有配合從底層存儲我們跑讀取工作組之間的差異2 YCSB工作負載與同CDP私有云基礎7.2.2運營數(shù)據(jù)庫集群上選擇適當?shù)臄?shù)據(jù)集大小的測試。我們使用的數(shù)據(jù)集大小為40GB與1TB，下面比較了不同YCSB工作負載的吞吐量，在圖表中，柱形越高，吞吐量越好。

注意：吞吐量=每秒操作

當應用程序嘗試從HBase集群中讀取數(shù)據(jù)時，處理請求的區(qū)域服務器會首先檢查所需的結果是否在其塊緩存中已經(jīng)存在于其進程本地的數(shù)據(jù)塊中。如果存在數(shù)據(jù)塊，則可以直接從緩存中服務客戶請求，這算作緩存命中。但是，如果該塊當前不在區(qū)域服務器進程本地，則將其計為緩存未命中，必須從HDFS存儲中的HFile中讀取該塊。然后，根據(jù)緩存利用率，該塊將被保存在緩存中以供將來請求。 

如預期并在摘要圖中所示，與從hdfs存儲中的HFiles訪問數(shù)據(jù)的工作負載運行相比，大多數(shù)數(shù)據(jù)集適合高速緩存的工作負載的延遲較低，吞吐量更高。 

為了選擇工作負載數(shù)據(jù)集大小來很好地滿足我們的測試目標，重要的是檢查RegionServer堆，L1和L2緩存，OS緩沖區(qū)緩存的大小，然后設置適當?shù)臄?shù)據(jù)集大小。在YCSB工作負載運行完成之后，可以檢查一個很好的參數(shù)，作為驗證事情是否按預期運行的一種方式，即從緩存中提供了多少數(shù)據(jù)（緩存命中）以及從hdfs存儲中訪問了多少數(shù)據(jù)。區(qū)域服務器緩存命中次數(shù)與總讀取請求的比率就是緩存命中率。

您可以從L1緩存命中率“ l1CacheHitRatio”配置中找到此信息。如果在集群中同時設置了L1和L2緩存，則L1緩存服務于索引塊，L2緩存服務于數(shù)據(jù)塊，并且您可以記錄L1“ l1CacheHitRatio”和L2“ l2CacheHitRatio”配置以供參考。

本博文的其余部分將詳細介紹測試設置，選擇數(shù)據(jù)集大小，然后使用這些數(shù)據(jù)集大小運行YCSB。

• 使用的集群：6個節(jié)點集群（1個主節(jié)點+ 5個區(qū)域服務器）

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

• 安全性：未配置（無Kerberos）

• CDP版本：CDP私有云Base 7.2.2具有1個主服務器+ 5個區(qū)域服務器的6節(jié)點HBase集群

• JDK使用jdk1.8_232

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

• HBase主站已配置有4GB堆

• 具有LruBlockCache的L1高速緩存用于12.3 GB高速緩存大小

• 集群中的L1緩存總數(shù)為61 GB（12.3 * 5 = 61GB）

• 集群上未配置L2堆外緩存

大小調(diào)整案例1：數(shù)據(jù)完全適合集群上的可用緩存

在我們的HBase集群中，我們在分配給L1塊緩存的5個區(qū)域服務器中總共配置了61GB（12.3GB * 5）。對于完全適合緩存的數(shù)據(jù)集，我們選擇了大小為40GB的數(shù)據(jù)集。 

大小調(diào)整案例2：數(shù)據(jù)集大于集群上的可用緩存

對于第二種情況，我們希望數(shù)據(jù)比可用緩存大得多。為了選擇合適的數(shù)據(jù)集大小，我們查看了集群中已配置的HBase塊緩存和OS緩沖區(qū)緩存。在給定的HBase集群中，跨RegionServer聚合時，配置的L1塊緩存為61G。服務器節(jié)點每個服務器總共有128G RAM，OS可以使用非專用于服務器進程的任何內(nèi)存來有效地緩存基礎HDFS塊并提高整體吞吐量。在我們的測試配置中，每個區(qū)域服務器節(jié)點上都有大約96G OS緩存可用于此目的（忽略DataNode或OS進程使用的內(nèi)存來簡化操作）。在5個區(qū)域服務器上進行匯總，我們有大約500G的緩沖區(qū)（96G * 5個區(qū)域服務器）潛力。因此，我們選擇了1TB的數(shù)據(jù)集大小，

將目標數(shù)據(jù)大小轉(zhuǎn)換為YCSB參數(shù)在YCSB中，默認情況下一行為1KB，因此，根據(jù)加載到YCSB“用戶表”中的行數(shù)，您可以輕松估算YCSB“用戶表”表數(shù)據(jù)大小。因此，如果您上載100萬行，則已將1,000,000 * 1KB = 1GB的數(shù)據(jù)上載到YCSB“用戶表”中。

我們兩個測試使用的數(shù)據(jù)集大小為：

• 40 GB數(shù)據(jù)和4000萬行

• 1 TB數(shù)據(jù)和10億行 

在6節(jié)點集群上安裝了CDP私有云基礎7.2.2，并生成了4000萬行的工作負載數(shù)據(jù)（總數(shù)據(jù)集大小=> 40 GB），并運行了YCSB工作負載。加載后，在開始工作負載測試之前，我們等待所有壓縮操作完成。在HBase上運行的YCSB工作負載是

1. 工作負載A：50％讀取和50％更新

2. 工作負載C：100％讀取 

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

4. 僅自定義更新工作負載：100％更新
   

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

一旦完成40GB的運行，我們就丟棄了可使用的用戶，并重新生成了10億行，以創(chuàng)建1TB的數(shù)據(jù)集大小，并在同一集群上以相同的方法重新運行了測試。 

YCSB結果為40GB

在40GB的情況下，數(shù)據(jù)可以完全容納在集群上的61GB L1緩存中。在測試期間，在集群中觀察到的L1緩存命中率接近99％。 

提示： 對于較小的數(shù)據(jù)集，數(shù)據(jù)可以放入緩存中，我們還可以使用“加載時緩存”選項，并使用表選項PREFETCH_BLOCKS_ON_OPEN預熱緩存以獲取100％的緩存命中率

每個YCSB工作負載每5次運行15分鐘，并取最后3次運行的平均值，以避免第一次運行損失。

下表顯示了在區(qū)域服務器上40G L1緩存命中率達到99％時看到的結果： 

具有1TB數(shù)據(jù)集的YCSB結果

在1TB的情況下，數(shù)據(jù)無法放入集群上的61GB L1高速緩存或500GB OS緩沖區(qū)高速緩存中。在測試期間觀察到的集群中L1緩存命中率為82-84％。 

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

下表顯示了在區(qū)域服務器上1TB L1緩存命中率達到82-84％時看到的結果： 

*吞吐率（ops / sec）=每秒操作數(shù)

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

下面的圖表顯示了吞吐量，并比較了使用2個不同大小的數(shù)據(jù)集運行時不同工作負載的吞吐量如何變化。在圖表中，條形越高，吞吐量越好。

注意：吞吐量=每秒操作

如圖所示，在40G情況下，讀取數(shù)據(jù)如Workload A，Workload C和Workload F的YCSB工作負載具有更好的吞吐量，在40G情況下，數(shù)據(jù)容易放入緩存，而在1TB數(shù)據(jù)大小的情況下，必須使用HFile數(shù)據(jù)。從HDFS訪問

從緩存命中率來看，40G數(shù)據(jù)集的緩存命中率接近99％，而1TB數(shù)據(jù)集的緩存命中率約為85％，因此在1TB情況下，有15％的數(shù)據(jù)是從hdfs存儲中訪問的。

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

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

下圖顯示了平均延遲，第95個百分位延遲和第99個百分位延遲的延遲比較，以及在使用不同大小的數(shù)據(jù)集運行時，不同工作負載的延遲差異。

在上面的圖表中，很難看到代表40GB數(shù)據(jù)集延遲的條形圖，因為它們與從HDFS訪問數(shù)據(jù)的1TB數(shù)據(jù)集所觀察到的延遲相比非常低。

我們使用等待時間值的對數(shù)繪制了等待時間圖，以顯示下表中的差異

如上所示，在40GB的情況下，緩存命中率接近99％，并且大多數(shù)工作負載數(shù)據(jù)在緩存中可用，因此延遲要低得多。與1TB數(shù)據(jù)集相比，由于必須從HDFS存儲訪問HFile數(shù)據(jù)，因此緩存命中率約為85％。

在40G情況下，從預熱的緩存返回99％數(shù)據(jù)的Workload C的平均延遲和99延遲約為2 – 4 ms。在1TB情況下，相同Workload C的第99個百分位數(shù)延遲對于Workload C（只讀工作負載）約為100ms。 

這表明從堆上塊高速緩存命中的高速緩存在大約2 ms內(nèi)返回讀取，并且高速緩存未命中以及從HDFS獲取記錄可能需要大約100 ms的時間。 

在運行YCSB基準測試時，數(shù)據(jù)集的大小會對性能結果產(chǎn)生重大影響，因此適當調(diào)整測試的大小非常重要。同時，查看緩存命中率以及最小延遲與第99個延遲之間的延遲差異，將有助于您找到與從集群中的基礎存儲訪問數(shù)據(jù)相比的緩存命中的延遲。 

注意

要檢查區(qū)域服務器上工作負載的緩存命中率，可以使用以下命令

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

您還可以按照以下步驟從HBase Web UI中查看緩存命中率：

1. 在HBase Web UI中，單擊區(qū)域服務器 

2. 在“塊高速緩存”部分下，選擇L1（如果配置了L2，則選擇L2）以查看高速緩存命中率。 

屏幕快照顯示了來自L1塊緩存的緩存命中率，如下所示：

這是指向上面顯示的HBase屏幕快照和塊緩存的更多信息的鏈接https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html

感謝各位的閱讀！關于“如何使用YCSB進行HBase性能測試”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！