作者：范欣欣
本次測試主要評估線上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，基本和實際情況相符。
本文來自網易雲社區，經作者范欣欣授權發布。
相關文章：
【推薦】 移動端互動直播(入門篇)
【推薦】 常用數據清洗方法大盤點
【推薦】 HashMap在並發場景下踩過的坑