您好,登錄后才能下訂單哦!
這篇文章給大家分享的是有關如何使用YCSB進行HBase性能測試的內容。小編覺得挺實用的,因此分享給大家做個參考,一起跟隨小編過來看看吧。
在集群上運行任何性能基準測試工具時,關鍵的決定始終是應該使用什么數據集大小進行性能測試,并且在這里我們演示了為什么在運行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堆外緩存
在我們的HBase集群中,我們在分配給L1塊緩存的5個區域服務器中總共配置了61GB(12.3GB * 5)。對于完全適合緩存的數據集,我們選擇了大小為40GB的數據集。
對于第二種情況,我們希望數據比可用緩存大得多。為了選擇合適的數據集大小,我們查看了集群中已配置的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工作負載是
工作負載A:50%讀取和50%更新
工作負載C:100%讀取
工作負載F:50%讀取和50%更新/讀取-修改-寫入比率:50/50
僅自定義更新工作負載: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的情況下,數據無法放入集群上的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中查看緩存命中率:
在HBase Web UI中,單擊區域服務器
在“塊高速緩存”部分下,選擇L1(如果配置了L2,則選擇L2)以查看高速緩存命中率。
屏幕快照顯示了來自L1塊緩存的緩存命中率,如下所示:
這是指向上面顯示的HBase屏幕快照和塊緩存的更多信息的鏈接https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html
感謝各位的閱讀!關于“如何使用YCSB進行HBase性能測試”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。