作者：範欣欣

本次測試主要評估線上HBase的整體效能，量化當前HBase的效能指標，對各種場景下HBase效能表現進行評估，為業務應用提供參考。本篇文章主要介紹此次測試的基本條件，HBase在各種測試場景下的效能指標（主要包括單次請求平均延遲和系統吞吐量）以及對應的資源利用情況，並對各種測試結果進行分析。

測試環境

測試環境包括測試過程中HBase叢集的拓撲結構、以及需要用到的硬體和軟體資源，硬體資源包括：測試機器配置、網路狀態等等，軟體資源包括作業系統、HBase相關軟體以及測試工具等。

叢集拓撲結構

本次測試中，測試環境總共包含4臺SA5212H2物理機作為資料儲存。生成資料的YCSB程式與資料庫並不執行在相同的物理叢集。

單臺機器主機硬體配置

軟體版本資訊

測試工具

YCSB全稱Yahoo! Cloud Serving Benchmark，是Yahoo公司開發的專門用於NoSQL測試的基準測試工具。github地址：https://github.com/brianfrankcooper/YCSB YCSB支援各種不同的資料分佈方式

1. Uniform：等概論隨機選擇記錄 

2. Zipfian：隨機選擇記錄，存在熱記錄 

3. Latest：近期寫入的記錄為熱記錄

測試場景

YCSB為HBase提供了多種場景下的測試，本次測試中，我們匯入10億條資料，並對如下場景進行測試:

YCSB並沒有提供Increment相關的測試功能，但是部分業務有這方面的需求，因此對YCBS進行了改造，加入了Increment模組。需要注意的是，在測試Increment效能前需要匯入1億條數字進行測試。寫入和查詢的資料模擬目前線上記錄的長度，具有以下特性：

HBase相關重要配置

hfile.block.cache.size：0.2hbase.regionserver.global.memstore.upperLimit：0.45jvm：-Xms48g -Xmx48g -Xmn4g -Xss256k -XX:PermSize=256m -XX:MaxPermSize=256m

jvm引數表示每臺機器會分配48G記憶體作為Java的堆記憶體使用，hfile.block.cache.size引數表示HBase會為每臺Region Server分配大小為9.6G（48 * 0.2）的記憶體作為讀快取使用。hbase.regionserver.global.memstore.upperLimit引數表示HBase會為每臺Region Server最多分配大小為21.6G（48 * 0.45）的記憶體作為寫快取使用。

測試方法

上述測試場景中部分測試（插入測試、scan掃描查詢等）對客戶端頻寬資源要求很高，單個客戶端測試會因為客戶端頻寬耗盡而導致無法測出實際伺服器叢集讀寫效能，因此我們開啟6個YCBS客戶端併發進行測試，最終Throughput是6個客戶端的總和，AverageLatency取6個客戶端延遲的平均值。

單個YCSB測試都遵守標準測試流程，基本流程如下：

1. 在6個客戶端伺服器部署YCSB程式，向叢集中load 10億條資料

2. 按照預先定義的場景修改負載檔案workload

3. 使用ycsb run方法執行測試，向叢集寫入讀取資料

4. 進行資料操作時通過YCSB記錄產生的統計資料，主要是吞吐量和平均延遲兩個指標

5. 根據結果生成對應的圖示

6. 針對不同場景，重複上述測試步驟

測試結果

單條記錄插入

測試引數

總記錄數為10億，分為128個region，均勻分佈在4臺region server上；插入操作執行2千萬次；插入請求分佈遵從zipfian分佈；

測試結果

資源使用情況

上圖為單臺RegionServer的頻寬使用曲線圖（資源使用情況中只列出和本次測試相關的資源曲線圖，後面相關資源使用情況類似），本次測試執行緒為1000的情況下頻寬基本維持在100M左右，對於百兆網絡卡來說基本上已經打滿。

結果分析

1.     吞吐量曲線分析：執行緒數在10~500的情況下，隨著執行緒數的增加，系統吞吐量會不斷升高；之後執行緒數再增加，系統吞吐量基本上不再變化。結合圖3頻寬資源使用曲線圖可以看出，當執行緒數增加到一定程度，系統頻寬資源基本耗盡，系統吞吐量就不再會增加。可見，HBase寫操作是一個頻寬敏感型操作，當頻寬資源bound後，寫入吞吐量基本就會穩定。

2.     寫入延遲曲線分析：隨著執行緒數的不斷增加，寫入延遲也會不斷增大。這是因為寫入執行緒過多，導致CPU資源排程頻繁，單個執行緒分配到的CPU資源會不斷降低；另一方面由於執行緒之間可能會存在互斥操作導致執行緒阻塞；這些因素都會導致寫入延遲不斷增大。

建議

根據曲線顯示，500執行緒以內的寫入延遲並不大於10ms，而此時吞吐量基本最大，因此如果是單純寫入的話500執行緒寫入會是一個比較合適的選擇。

單純查詢

測試引數

總記錄數為10億，分為128個region，均勻分佈在4臺region server上；查詢操作執行2千萬次；查詢請求分佈遵從zipfian分佈；

測試結果

資源使用情況

圖5為執行緒數在1000時IO利用率曲線圖，圖中IO利用率基本保持在100%，說明IO資源已經達到使用上限。圖6為執行緒數在1000時系統負載曲線圖，圖中load1曲線表示在最近一分鐘內的平均負載，load5表示最近五分鐘內的平均負載。最近5分鐘的負責達到了50左右，對於32核系統來說，表示此時系統負載很高，已經遠遠超負荷執行。

結果分析

1.     吞吐量曲線分析：執行緒數在10~500的情況下，隨著執行緒數的增加，系統吞吐量會不斷升高；之後執行緒數再增加，系統吞吐量基本上不再變化。結合圖5、圖6系統資源使用曲線圖可以看出，當執行緒數增加到一定程度，系統IO資源基本達到上限，系統負載也特別高。IO利用率達到100%是因為大量的讀操作都需要從磁碟查詢資料，系統負載很高是因為HBase需要對查詢的資料進行解壓縮操作，解壓縮操作需要耗費大量CPU資源。這兩個因素結合導致系統吞吐量就不再隨著執行緒數增肌而增加。可見，HBase讀操作是一個IO/CPU敏感型操作，當IO或者CPU資源bound後，讀取吞吐量基本就會穩定不變。

2.     延遲曲線分析：隨著執行緒數的不斷增加，讀取延遲也會不斷增大。這是因為讀取執行緒過多，導致CPU資源排程頻繁，單個執行緒分配到的CPU資源會不斷降低；另一方面由於執行緒之間可能會存在互斥操作導致執行緒阻塞；這些因素都會導致寫入延遲不斷增大。和寫入延遲相比，讀取延遲會更大，是因為讀取涉及IO操作，IO本身就是一個耗時操作，導致延遲更高。

建議

根據曲線顯示，500執行緒以內的讀取延遲並不大於20ms，而此時吞吐量基本最大，因此如果是單純讀取的話500執行緒讀取會是一個比較合適的選擇。

Range掃描查詢

測試引數

總記錄數為10億，分為128個region，均勻分佈在4臺region server上；scan操作執行一千兩百萬次，請求分佈遵從zipfian分佈； scan最大長度為100條記錄， scan長度隨機分佈且遵從uniform分佈；

測試結果

資源使用情況

圖8為執行緒數在1000時IO利用率曲線圖，圖中IO利用率基本保持在100%，說明IO資源已經達到使用上限。圖9為執行緒數在1000時頻寬資源使用曲線圖，圖中頻寬資源基本也已經達到上限。

結果分析

1.     吞吐量曲線分析：執行緒數在10~500的情況下，隨著執行緒數的增加，系統吞吐量會不斷升高；之後執行緒數再增加，系統吞吐量基本上不再變化。結合圖8 、圖9資源使用曲線圖可以看出，當執行緒數增加到一定程度，系統IO資源基本達到上限，頻寬也基本達到上限。IO利用率達到100%是因為大量的讀操作都需要從磁碟查詢資料，而頻寬負載很高是因為每次scan操作最多可以獲取50Kbyte資料，TPS太高會導致資料量很大，因而頻寬負載很高。兩者結合導致系統吞吐量就不再隨著執行緒數增大會增大。可見，scan操作是一個IO/頻寬敏感型操作，當IO或者頻寬資源bound後，scan吞吐量基本就會穩定不變。

2.     延遲曲線分析：隨著執行緒數的不斷增加，讀取延遲也會不斷增大。這是因為讀取執行緒過多，導致CPU資源排程頻繁，單個執行緒分配到的CPU資源會不斷降低；另一方面由於執行緒之間可能會存在互斥操作導致執行緒阻塞；這些因素都會導致寫入延遲不斷增大。和寫入延遲以及單次隨機查詢相比，讀取延遲會更大，是因為scan操作會涉及多次IO操作，IO本身就是一個耗時操作，因此會導致延遲更高。

建議

根據圖表顯示，使用者可以根據業務實際情況選擇100~500之間的執行緒數來執行scan操作。

查詢插入平衡

測試引數

總記錄數為10億，分為128個region，均勻分佈在4臺region server上；查詢插入操作共執行8千萬次；查詢請求分佈遵從zipfian分佈；

測試結果

資源使用情況

圖11為執行緒數在1000時系統IO利用率曲線圖，圖中IO利用率基本保持在100%，說明IO資源已經達到使用上限。圖12為執行緒數在1000時系統負載曲線圖，圖中顯示CPU負載資源達到了40+，對於只有32核的系統來說，已經遠遠超負荷工作了。

結果分析

1.    吞吐量曲線分析：執行緒數在10~500的情況下，隨著執行緒數的增加，系統吞吐量會不斷升高；之後執行緒數再增加，系統吞吐量變化就比較緩慢。結合圖11、圖12系統資源使用曲線圖可以看出，當執行緒數增加到一定程度，系統IO資源基本達到上限，頻寬也基本達到上限。IO利用率達到100%是因為大量的讀操作都需要從磁碟查詢資料，而系統負載很高是因為大量讀取操作需要進行解壓縮操作，而且執行緒數很大本身就需要更多CPU資源。因此導致系統吞吐量就不再會增加。可見，查詢插入平衡場景下，當IO或者CPU資源bound後，系統吞吐量基本就會穩定不變。

2.     延遲曲線分析：隨著執行緒數的不斷增加，讀取延遲也會不斷增大。這是因為讀取執行緒過多，導致CPU資源排程頻繁，單個執行緒分配到的CPU資源會不斷降低；另一方面由於執行緒之間可能會存在互斥操作導致執行緒阻塞；這些因素都會導致寫入延遲不斷增大。圖中讀延遲大於寫延遲是因為讀取操作涉及到IO操作，比較耗時。

建議

根據圖表顯示，在查詢插入平衡場景下使用者可以根據業務實際情況選擇100~500之間的執行緒數。

插入為主

測試引數

總記錄數為10億，分為128個region，均勻分佈在4臺region server上；查詢插入操作共執行4千萬次；查詢請求分佈遵從latest分佈；

測試結果

資源使用情況

圖15為執行緒數在1000時系統頻寬使用曲線圖，圖中系統頻寬資源基本到達上限，而總體IO利用率還比較低。

結果分析

1.    曲線分析：執行緒數在10~500的情況下，隨著執行緒數的增加，系統吞吐量會不斷升高；之後執行緒數再增加，系統吞吐量基本上不再變化。結合圖14頻寬資源使用曲線圖可以看出，當執行緒數增加到一定程度，系統頻寬資源基本耗盡，系統吞吐量就不再會增加。基本同單條記錄插入場景相同。

2.    寫入延遲曲線分析： 基本同單條記錄插入場景。

建議

根據圖表顯示，插入為主的場景下使用者可以根據業務實際情況選擇500左右的執行緒數來執行。

查詢為主

測試引數

總記錄數為10億，分為128個region，均勻分佈在4臺region server上；查詢插入操作共執行4千萬次；查詢請求分佈遵從zipfian分佈；

測試結果

資源使用情況

圖17為執行緒數在1000時IO利用率曲線圖，圖中IO利用率基本保持在100%，說明IO資源已經達到使用上限。

結果分析

基本分析見單純查詢一節，原理類似。

建議

根據圖表顯示，查詢為主的場景下使用者可以根據業務實際情況選擇100~500之間的執行緒數來執行。

Increment自增

測試引數

1億條資料，分成16個Region，分佈在4臺RegionServer上；操作次數為100萬次；

測試結果

結果分析

1.    執行緒數增加，Increment操作的吞吐量會不斷增加，執行緒數到達100個左右時，吞吐量會達到頂峰（23785 ops/sec），之後再增加執行緒數，吞吐量基本維持不變;

2.    隨著執行緒數增加，Increment操作的平均延遲會不斷增加。執行緒數在100以下，平均延時都在4ms以內；

建議

根據圖表顯示，查詢為主的場景下使用者可以根據業務實際情況選擇100~500之間的執行緒數來執行。

測試結果總結

根據以上測試結果和資源利用情況可以得出如下幾點：

1. 寫效能：叢集吞吐量最大可以達到70000+ ops/sec，延遲在幾個毫秒左右。網路頻寬是主要瓶頸，如果將千兆網絡卡換成萬兆網絡卡，吞吐量還可以繼續增加，甚至達到目前吞吐量的兩倍。

2. 讀效能：很多人對HBase的印象可能都是寫效能很好、讀效能很差，但實際上HBase的讀效能遠遠超過大家的預期。叢集吞吐量最大可以達到26000+，單臺吞吐量可以達到8000+左右，延遲在幾毫秒～20毫秒左右。IO和CPU是主要瓶頸。

3. Range 掃描效能：叢集吞吐量最大可以達到14000左右，系統平均延遲在幾毫秒～60毫秒之間（執行緒數越多，延遲越大）；其中IO和網路頻寬是主要瓶頸。

測試注意事項

1. 需要關注是否是全記憶體測試，全記憶體測試和非全記憶體測試結果相差會比較大。參考線上實際資料情況，本次測試採用非全記憶體讀測試。是否是全記憶體讀取決於總資料量大小、叢集Jvm記憶體大小、Block Cache佔比、訪問分佈是否是熱點訪問這四者，在JVM記憶體大小以及Block Cache佔比不變的情況下，可以增大總資料量大小或者修改訪問分佈；

2. 測試客戶端是否存在瓶頸。HBase測試某些場景特別耗費頻寬資源，如果單個客戶端進行測試很可能會因為客戶端頻寬被耗盡導致無法測出實際伺服器叢集效能。本次測試使用6個客戶端併發進行測試。

3. 單條記錄大小對測試的影響。單條記錄設定太大，會導致併發插入操作佔用大量頻寬資源進而效能產生瓶頸。而設定太小，測試出來的TPS峰值會比較大，和線上實際資料不符。本次測試單條資料大小設定為50M，基本和實際情況相符。

本文來自網易雲社群，經作者範欣欣授權釋出。