本次測試主要評(píng)估線上HBase的整體性能，量化當(dāng)前HBase的性能指標(biāo)，對(duì)各種場景下HBase性能表現(xiàn)進(jìn)行評(píng)估，為業(yè)務(wù)應(yīng)用提供參考。本篇文章主要介紹此次測試的基本條件，HBase在各種測試場景下的性能指標(biāo)(主要包括單次請(qǐng)求平均延遲和系統(tǒng)吞吐量)以及對(duì)應(yīng)的資源利用情況，并對(duì)各種測試結(jié)果進(jìn)行分析。

　　測試環(huán)境

　　測試環(huán)境包括測試過程中HBase集群的拓?fù)浣Y(jié)構(gòu)、以及需要用到的硬件和軟件資源，硬件資源包括：測試機(jī)器配置、網(wǎng)絡(luò)狀態(tài)等等，軟件資源包括操作系統(tǒng)、HBase相關(guān)軟件以及測試工具等。

　　集群拓?fù)浣Y(jié)構(gòu)

　　本次測試中，測試環(huán)境總共包含4臺(tái)SA5212H2物理機(jī)作為數(shù)據(jù)存儲(chǔ)。生成數(shù)據(jù)的YCSB程序與數(shù)據(jù)庫并不運(yùn)行在相同的物理集群。

　　單臺(tái)機(jī)器主機(jī)硬件配置

　　軟件版本信息

　　測試工具

　　YCSB全稱Yahoo! Cloud Serving Benchmark，是Yahoo公司開發(fā)的專門用于NoSQL測試的基準(zhǔn)測試工具。github地址：https://github.com/brianfrankcooper/YCSB YCSB支持各種不同的數(shù)據(jù)分布方式

　　1. Uniform：等概論隨機(jī)選擇記錄

　　2. Zipfian：隨機(jī)選擇記錄，存在熱記錄

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

　　測試場景

　　YCSB為HBase提供了多種場景下的測試，本次測試中，我們導(dǎo)入10億條數(shù)據(jù)，并對(duì)如下場景進(jìn)行測試:

　　YCSB并沒有提供Increment相關(guān)的測試功能，但是部分業(yè)務(wù)有這方面的需求，因此對(duì)YCBS進(jìn)行了改造，加入了Increment模塊。需要注意的是，在測試Increment性能前需要導(dǎo)入1億條數(shù)字進(jìn)行測試。寫入和查詢的數(shù)據(jù)模擬目前線上記錄的長度，具有以下特性：

　　HBase相關(guān)重要配置

　　hfile.block.cache.size：0.2

　　hbase.regionserver.global.memstore.upperLimit：0.45

　　jvm：-Xms48g -Xmx48g -Xmn4g -Xss256k -XX:PermSize=256m -XX:MaxPermSize=256m

　　jvm參數(shù)表示每臺(tái)機(jī)器會(huì)分配48G內(nèi)存作為Java的堆內(nèi)存使用，hfile.block.cache.size參數(shù)表示HBase會(huì)為每臺(tái)Region Server分配大小為9.6G(48 * 0.2)的內(nèi)存作為讀緩存使用。hbase.regionserver.global.memstore.upperLimit參數(shù)表示HBase會(huì)為每臺(tái)Region Server最多分配大小為21.6G(48 * 0.45)的內(nèi)存作為寫緩存使用。

　　測試方法

　　上述測試場景中部分測試(插入測試、scan掃描查詢等)對(duì)客戶端帶寬資源要求很高，單個(gè)客戶端測試會(huì)因?yàn)榭蛻舳藥捄谋M而導(dǎo)致無法測出實(shí)際服務(wù)器集群讀寫性能，因此我們開啟6個(gè)YCBS客戶端并發(fā)進(jìn)行測試，最終Throughput是6個(gè)客戶端的總和，AverageLatency取6個(gè)客戶端延遲的平均值。

　　單個(gè)YCSB測試都遵守標(biāo)準(zhǔn)測試流程，基本流程如下：

　　1. 在6個(gè)客戶端服務(wù)器部署YCSB程序，向集群中l(wèi)oad 10億條數(shù)據(jù)

　　2. 按照預(yù)先定義的場景修改負(fù)載文件workload

　　3. 使用ycsb run方法執(zhí)行測試，向集群寫入讀取數(shù)據(jù)

　　4. 進(jìn)行數(shù)據(jù)操作時(shí)通過YCSB記錄產(chǎn)生的統(tǒng)計(jì)數(shù)據(jù)，主要是吞吐量和平均延遲兩個(gè)指標(biāo)

　　5. 根據(jù)結(jié)果生成對(duì)應(yīng)的圖標(biāo)

　　6. 針對(duì)不同場景，重復(fù)上述測試步驟

　　測試結(jié)果

　　單條記錄插入

　　測試參數(shù)

　　總記錄數(shù)為10億，分為128個(gè)region，均勻分布在4臺(tái)region server上;插入操作執(zhí)行2千萬次;插入請(qǐng)求分布遵從zipfian分布;

　　測試結(jié)果

　　資源使用情況

　　上圖為單臺(tái)RegionServer的帶寬使用曲線圖(資源使用情況中只列出和本次測試相關(guān)的資源曲線圖，后面相關(guān)資源使用情況類似)，本次測試線程為1000的情況下帶寬基本維持在100M左右，對(duì)于百兆網(wǎng)卡來說基本上已經(jīng)打滿。

　　結(jié)果分析

　　1. 吞吐量曲線分析：線程數(shù)在10~500的情況下，隨著線程數(shù)的增加，系統(tǒng)吞吐量會(huì)不斷升高;之后線程數(shù)再增加，系統(tǒng)吞吐量基本上不再變化。結(jié)合圖3帶寬資源使用曲線圖可以看出，當(dāng)線程數(shù)增加到一定程度，系統(tǒng)帶寬資源基本耗盡，系統(tǒng)吞吐量就不再會(huì)增加。 可見， HBase寫操作是一個(gè)帶寬敏感型操作，當(dāng)帶寬資源bound后，寫入吞吐量基本就會(huì)穩(wěn)定。

　　2. 寫入延遲曲線分析：隨著線程數(shù)的不斷增加，寫入延遲也會(huì)不斷增大。這是因?yàn)閷懭刖€程過多，導(dǎo)致CPU資源調(diào)度頻繁，單個(gè)線程分配到的CPU資源會(huì)不斷降低;另一方面由于線程之間可能會(huì)存在互斥操作導(dǎo)致線程阻塞;這些因素都會(huì)導(dǎo)致寫入延遲不斷增大。

　　建議

　　根據(jù)曲線顯示，500線程以內(nèi)的寫入延遲并不大于10ms，而此時(shí)吞吐量基本最大，因此如果是單純寫入的話500線程寫入會(huì)是一個(gè)比較合適的選擇。

　　單純查詢

　　測試參數(shù)

　　總記錄數(shù)為10億，分為128個(gè)region，均勻分布在4臺(tái)region server上;查詢操作執(zhí)行2千萬次;查詢請(qǐng)求分布遵從zipfian分布;

　　測試結(jié)果

　　資源使用情況

　　圖5為線程數(shù)在1000時(shí)IO利用率曲線圖，圖中IO利用率基本保持在100%，說明IO資源已經(jīng)達(dá)到使用上限。圖6為線程數(shù)在1000時(shí)系統(tǒng)負(fù)載曲線圖，圖中l(wèi)oad1曲線表示在最近一分鐘內(nèi)的平均負(fù)載，load5表示最近五分鐘內(nèi)的平均負(fù)載。最近5分鐘的負(fù)責(zé)達(dá)到了50左右，對(duì)于32核系統(tǒng)來說，表示此時(shí)系統(tǒng)負(fù)載很高，已經(jīng)遠(yuǎn)遠(yuǎn)超負(fù)荷運(yùn)行。

　　結(jié)果分析

　　1. 吞吐量曲線分析：線程數(shù)在10~500的情況下，隨著線程數(shù)的增加，系統(tǒng)吞吐量會(huì)不斷升高;之后線程數(shù)再增加，系統(tǒng)吞吐量基本上不再變化。結(jié)合圖5、圖6系統(tǒng)資源使用曲線圖可以看出，當(dāng)線程數(shù)增加到一定程度，系統(tǒng)IO資源基本達(dá)到上限，系統(tǒng)負(fù)載也特別高。IO利用率達(dá)到100%是因?yàn)榇罅康淖x操作都需要從磁盤查找數(shù)據(jù)，系統(tǒng)負(fù)載很高是因?yàn)镠Base需要對(duì)查找的數(shù)據(jù)進(jìn)行解壓縮操作，解壓縮操作需要耗費(fèi)大量CPU資源。這兩個(gè)因素結(jié)合導(dǎo)致系統(tǒng)吞吐量就不再隨著線程數(shù)增肌而增加。可見，HBase讀操作是一個(gè)IO/CPU敏感型操作，當(dāng)IO或者CPU資源bound后，讀取吞吐量基本就會(huì)穩(wěn)定不變。

　　2. 延遲曲線分析：隨著線程數(shù)的不斷增加，讀取延遲也會(huì)不斷增大。這是因?yàn)樽x取線程過多，導(dǎo)致CPU資源調(diào)度頻繁，單個(gè)線程分配到的CPU資源會(huì)不斷降低;另一方面由于線程之間可能會(huì)存在互斥操作導(dǎo)致線程阻塞;這些因素都會(huì)導(dǎo)致寫入延遲不斷增大。和寫入延遲相比，讀取延遲會(huì)更大，是因?yàn)樽x取涉及IO操作，IO本身就是一個(gè)耗時(shí)操作，導(dǎo)致延遲更高。

　　建議

　　根據(jù)曲線顯示，500線程以內(nèi)的讀取延遲并不大于20ms，而此時(shí)吞吐量基本最大，因此如果是單純讀取的話500線程讀取會(huì)是一個(gè)比較合適的選擇。

　　Range 掃描查詢

　　測試參數(shù)

　　總記錄數(shù)為10億，分為128個(gè)region，均勻分布在4臺(tái)region server上;scan操作執(zhí)行一千兩百萬次，請(qǐng)求分布遵從zipfian分布; scan最大長度為100條記錄， scan長度隨機(jī)分布且遵從uniform分布;

　　測試結(jié)果

　　資源使用情況

　　圖8為線程數(shù)在1000時(shí)IO利用率曲線圖，圖中IO利用率基本保持在100%，說明IO資源已經(jīng)達(dá)到使用上限。圖9為線程數(shù)在1000時(shí)帶寬資源使用曲線圖，圖中帶寬資源基本也已經(jīng)達(dá)到上限。

　　結(jié)果分析

　　1. 吞吐量曲線分析：線程數(shù)在10~500的情況下，隨著線程數(shù)的增加，系統(tǒng)吞吐量會(huì)不斷升高;之后線程數(shù)再增加，系統(tǒng)吞吐量基本上不再變化。結(jié)合圖8 、圖9資源使用曲線圖可以看出，當(dāng)線程數(shù)增加到一定程度，系統(tǒng)IO資源基本達(dá)到上限，帶寬也基本達(dá)到上限。IO利用率達(dá)到100%是因?yàn)榇罅康淖x操作都需要從磁盤查找數(shù)據(jù)，而帶寬負(fù)載很高是因?yàn)槊看蝧can操作最多可以獲取50Kbyte數(shù)據(jù)，TPS太高會(huì)導(dǎo)致數(shù)據(jù)量很大，因而帶寬負(fù)載很高。兩者結(jié)合導(dǎo)致系統(tǒng)吞吐量就不再隨著線程數(shù)增大會(huì)增大。可見，scan操作是一個(gè)IO/帶寬敏感型操作，當(dāng)IO或者帶寬資源bound后，scan吞吐量基本就會(huì)穩(wěn)定不變。

　　2. 延遲曲線分析：隨著線程數(shù)的不斷增加，讀取延遲也會(huì)不斷增大。這是因?yàn)樽x取線程過多，導(dǎo)致CPU資源調(diào)度頻繁，單個(gè)線程分配到的CPU資源會(huì)不斷降低;另一方面由于線程之間可能會(huì)存在互斥操作導(dǎo)致線程阻塞;這些因素都會(huì)導(dǎo)致寫入延遲不斷增大。和寫入延遲以及單次隨機(jī)查找相比，讀取延遲會(huì)更大，是因?yàn)閟can操作會(huì)涉及多次IO操作，IO本身就是一個(gè)耗時(shí)操作，因此會(huì)導(dǎo)致延遲更高。

　　建議

　　根據(jù)圖表顯示，用戶可以根據(jù)業(yè)務(wù)實(shí)際情況選擇100~500之間的線程數(shù)來執(zhí)行scan操作。

　　查詢插入平衡

　　測試參數(shù)

　　總記錄數(shù)為10億，分為128個(gè)region，均勻分布在4臺(tái)region server上;查詢插入操作共執(zhí)行8千萬次;查詢請(qǐng)求分布遵從zipfian分布;

　　測試結(jié)果

　　資源使用情況

　　圖11為線程數(shù)在1000時(shí)系統(tǒng)IO利用率曲線圖，圖中IO利用率基本保持在100%，說明IO資源已經(jīng)達(dá)到使用上限。圖12為線程數(shù)在1000時(shí)系統(tǒng)負(fù)載曲線圖，圖中顯示CPU負(fù)載資源達(dá)到了40+，對(duì)于只有32核的系統(tǒng)來說，已經(jīng)遠(yuǎn)遠(yuǎn)超負(fù)荷工作了。

　　結(jié)果分析

　　1. 吞吐量曲線分析：線程數(shù)在10~500的情況下，隨著線程數(shù)的增加，系統(tǒng)吞吐量會(huì)不斷升高;之后線程數(shù)再增加，系統(tǒng)吞吐量變化就比較緩慢。結(jié)合圖11、圖12系統(tǒng)資源使用曲線圖可以看出，當(dāng)線程數(shù)增加到一定程度，系統(tǒng)IO資源基本達(dá)到上限，帶寬也基本達(dá)到上限。IO利用率達(dá)到100%是因?yàn)榇罅康淖x操作都需要從磁盤查找數(shù)據(jù)，而系統(tǒng)負(fù)載很高是因?yàn)榇罅孔x取操作需要進(jìn)行解壓縮操作，而且線程數(shù)很大本身就需要更多CPU資源。因此導(dǎo)致系統(tǒng)吞吐量就不再會(huì)增加。可見，查詢插入平衡場景下，當(dāng)IO或者CPU資源bound后，系統(tǒng)吞吐量基本就會(huì)穩(wěn)定不變。

　　2. 延遲曲線分析：隨著線程數(shù)的不斷增加，讀取延遲也會(huì)不斷增大。這是因?yàn)樽x取線程過多，導(dǎo)致CPU資源調(diào)度頻繁，單個(gè)線程分配到的CPU資源會(huì)不斷降低;另一方面由于線程之間可能會(huì)存在互斥操作導(dǎo)致線程阻塞;這些因素都會(huì)導(dǎo)致寫入延遲不斷增大。圖中讀延遲大于寫延遲是因?yàn)樽x取操作涉及到IO操作，比較耗時(shí)。

　　建議

　　根據(jù)圖表顯示，在查詢插入平衡場景下用戶可以根據(jù)業(yè)務(wù)實(shí)際情況選擇100~500之間的線程數(shù)。

　　插入為主

　　測試參數(shù)

　　總記錄數(shù)為10億，分為128個(gè)region，均勻分布在4臺(tái)region server上;查詢插入操作共執(zhí)行4千萬次;查詢請(qǐng)求分布遵從latest分布;

　　測試結(jié)果

　　資源使用情況

　　圖15為線程數(shù)在1000時(shí)系統(tǒng)帶寬使用曲線圖，圖中系統(tǒng)帶寬資源基本到達(dá)上限，而總體IO利用率還比較低。

　　結(jié)果分析

　　1. 曲線分析：線程數(shù)在10~500的情況下，隨著線程數(shù)的增加，系統(tǒng)吞吐量會(huì)不斷升高;之后線程數(shù)再增加，系統(tǒng)吞吐量基本上不再變化。結(jié)合圖14帶寬資源使用曲線圖可以看出，當(dāng)線程數(shù)增加到一定程度，系統(tǒng)帶寬資源基本耗盡，系統(tǒng)吞吐量就不再會(huì)增加。基本同單條記錄插入場景相同。

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

　　建議

　　根據(jù)圖表顯示，插入為主的場景下用戶可以根據(jù)業(yè)務(wù)實(shí)際情況選擇500左右的線程數(shù)來執(zhí)行。

　　查詢?yōu)橹?/p>

　　測試參數(shù)

　　總記錄數(shù)為10億，分為128個(gè)region，均勻分布在4臺(tái)region server上;查詢插入操作共執(zhí)行4千萬次;查詢請(qǐng)求分布遵從zipfian分布;

　　測試結(jié)果

　　資源使用情況

　　圖17為線程數(shù)在1000時(shí)IO利用率曲線圖，圖中IO利用率基本保持在100%，說明IO資源已經(jīng)達(dá)到使用上限。

　　結(jié)果分析

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

　　建議

　　根據(jù)圖表顯示，查詢?yōu)橹鞯膱鼍跋掠脩艨梢愿鶕?jù)業(yè)務(wù)實(shí)際情況選擇100~500之間的線程數(shù)來執(zhí)行。

　　Increment 自增

　　測試參數(shù)

　　1億條數(shù)據(jù)，分成16個(gè)Region，分布在4臺(tái)RegionServer上;操作次數(shù)為100萬次;

　　測試結(jié)果

　　結(jié)果分析

　　1. 線程數(shù)增加，Increment操作的吞吐量會(huì)不斷增加，線程數(shù)到達(dá)100個(gè)左右時(shí)，吞吐量會(huì)達(dá)到頂峰(23785 ops/sec)，之后再增加線程數(shù)，吞吐量基本維持不變;

　　2. 隨著線程數(shù)增加，Increment操作的平均延遲會(huì)不斷增加。線程數(shù)在100以下，平均延時(shí)都在4ms以內(nèi);

　　建議

　　根據(jù)圖表顯示，查詢?yōu)橹鞯膱鼍跋掠脩艨梢愿鶕?jù)業(yè)務(wù)實(shí)際情況選擇100~500之間的線程數(shù)來執(zhí)行。

　　測試結(jié)果總結(jié)

　　根據(jù)以上測試結(jié)果和資源利用情況可以得出如下幾點(diǎn)：

　　1. 寫性能：集群吞吐量最大可以達(dá)到70000+ ops/sec，延遲在幾個(gè)毫秒左右。網(wǎng)絡(luò)帶寬是主要瓶頸，如果將千兆網(wǎng)卡換成萬兆網(wǎng)卡，吞吐量還可以繼續(xù)增加，甚至達(dá)到目前吞吐量的兩倍。

　　2. 讀性能：很多人對(duì)HBase的印象可能都是寫性能很好、讀性能很差，但實(shí)際上HBase的讀性能遠(yuǎn)遠(yuǎn)超過大家的預(yù)期。集群吞吐量最大可以達(dá)到26000+，單臺(tái)吞吐量可以達(dá)到8000+左右，延遲在幾毫秒～20毫秒左右。IO和CPU是主要瓶頸。

　　3. Range 掃描性能：集群吞吐量最大可以達(dá)到14000左右，系統(tǒng)平均延遲在幾毫秒～60毫秒之間(線程數(shù)越多，延遲越大);其中IO和網(wǎng)絡(luò)帶寬是主要瓶頸。

　　測試注意事項(xiàng)

　　1. 需要關(guān)注是否是全內(nèi)存測試，全內(nèi)存測試和非全內(nèi)存測試結(jié)果相差會(huì)比較大。參考線上實(shí)際數(shù)據(jù)情況，本次測試采用非全內(nèi)存讀測試。是否是全內(nèi)存讀取決于總數(shù)據(jù)量大小、集群Jvm內(nèi)存大小、Block Cache占比、訪問分布是否是熱點(diǎn)訪問這四者，在JVM內(nèi)存大小以及Block Cache占比不變的情況下，可以增大總數(shù)據(jù)量大小或者修改訪問分布;

　　2. 測試客戶端是否存在瓶頸。HBase測試某些場景特別耗費(fèi)帶寬資源，如果單個(gè)客戶端進(jìn)行測試很可能會(huì)因?yàn)榭蛻舳藥挶缓谋M導(dǎo)致無法測出實(shí)際服務(wù)器集群性能。本次測試使用6個(gè)客戶端并發(fā)進(jìn)行測試。

　　3. 單條記錄大小對(duì)測試的影響。單條記錄設(shè)置太大，會(huì)導(dǎo)致并發(fā)插入操作占用大量帶寬資源進(jìn)而性能產(chǎn)生瓶頸。而設(shè)置太小，測試出來的TPS峰值會(huì)比較大，和線上實(shí)際數(shù)據(jù)不符。本次測試單條數(shù)據(jù)大小設(shè)置為50M，基本和實(shí)際情況相符。