HBase測試報告
本文將介紹我們對阿里雲HBase以及HBase1.1.12進行的測試的細節，大概會介紹測試的環境，測試工具分析以及我們對工具的選擇，測試的case，以及測試的結果分析。
1.測試環境
1.1.物理環境：
服務端：單臺regionserver：8core，32G，4X250G ssd
Client：16core 64G，雙client壓；
1.2.軟件環境：
client：hbase-1.1.2
server：ApsaraDB for HBase, HBase1.1.12
JDK: Ali-JDK-1.8
1.3.測試條件：
2個client壓server端，打滿server的性能，server端是單Regionserver。寫操作500w數據，共1000萬數據，scan，讀分別單線程操作5k，5w數據。操作的單條value大小1000B（1KB）
2.測試步驟
2.1.測試工具分析：
測試工具之前一直在YCSB和HBase 自帶工具PerformanceEvaluation二者之間進行選擇，這裏大概介紹下二者之間的區別；
2.2.1.YCSB工具原理和使用方法介紹
YCSB是雅虎開發的測試平臺，主要的優點是可以做對比各個平臺的性能，他擁有主流數據庫的測試接口，包括Mongodb，HBase，Cassandra等；使用YCSB測試HBase的話，在測試的基本環境準備好以後，我們YCSB的client裏面的文件夾下面大概有下面幾個文件：
[ycsb-hbase10-binding-0.12.0-SNAPSHOT]# ll -l
總用量 52
drwxr-xr-x 2 root root 4096 9月 5 11:38 bin
drwxr-xr-x 2 root root 4096 9月 5 09:54 conf
drwxr-xr-x 2 root root 4096 9月 4 22:26 lib
-rw-r--r-- 1 501 games 8082 11月 9 2016 LICENSE.txt
-rw-r--r-- 1 root root 15489 9月 5 09:56 longtimetest
-rw-r--r-- 1 501 games 615 11月 9 2016 NOTICE.txt
-rw-r--r-- 1 501 games 5484 11月 9 2016 README.md
drwxr-xr-x 2 501 games 4096 9月 5 11:40 workloads
上面的conf文件夾本來是沒有的，但是這裏是需要人爲的加入相應的conf文件夾，這裏的話，在conf文件夾下面是需要放入hbase-site.xml的配置文件，或者這個配置文件最好和服務端的配置文件一樣，如果不一樣至少也要保證zk的地址是一樣的。
在workloads裏面有需要的各個相關的測試參數，下面以2個實際的case 解釋下測試的各個參數的意思：
1.bin/ycsb load hbase10 -P workloads/workloads -p table=usertable -p columnfamily=cf -p -p fieldlength=50 -p fieldcount=1 -s threads 50
2.bin/ycsb run hbase10 -P workloads/workloada -p table=usertable -p columnfamily=cf -p fieldlength=1000 -p fieldcount=1 -s -threads 50
[root@ ycsb-hbase10-binding-0.12.0-SNAPSHOT]# cat workloads/workloada
recordcount=1000
operationcount=1000
workload=com.yahoo.ycsb.workloads.CoreWorkload
readallfields=true
readproportion=0.5
updateproportion=0.5
scanproportion=0
insertproportion=0
requestdistribution=zipfian
上面case中，（1）表示的是使用ycsb load相關信息數據到hbase的數據庫裏面，實際上也就是寫入部分數據到hbase中，-p 後面一般跟的是屬性信息，包括table是usertable，columnfamily是cf ，寫入的文件的長度是50B，寫入1個文件，也就是一列。啓動線程是50個線程做這麼些事情；一共要寫多少數據呢？在workloads/workloads這個文件裏面會有一個recordcount ，這個表示的是寫入的總共條數，當然這個參數也可以在命令行傳輸；
（2）表示的是開始執行run操作，run操作的類型主要是看workload/workloada裏面的“readproportion”，“updateproportion”，“scanproportion”，“insertproportion”佔用的比例，比如insertproportion=1，那就是寫，如果insertproportion=0.5，readproportion=0.5 那麼就是讀寫各50%，同理這個時候配置文件裏面會有一個operationcount，表示需要操作的次數，這些操作次數裏面讀寫各佔50%。
requestdistribution 表示的是請求的分佈類型，可以是類似正太分佈，還是2/8請求分佈，或者是別的分佈。上面的zipfian表示2/8分佈。
此外，YCSB還有很多和HBase相關的參數配置，比如：寫的時候的writeBufferSize，讀的時候是否有setBlockCache等。
2.2.2.HBase PerformanceEvaluation工具原理以及使用方法介紹
HBase PerformanceEvaluation 這個工具是HBase 自帶的，測試的case 以及提供給外界的接口比YCSB 更豐富，比如提供了：RandomWrite，SequenceWrite，scan，randomSeekScan，scanRange10 ，scanRange100 等等。最直觀的case，YCSB的直觀的scan的case 就沒有上述PE的豐富。我們本文中的測試的工具主要使用的是HBase Performance工具。我們以幾個測試的實際case 來說明用法和相應的原理：
1.sh hbase org.apache.hadoop.hbase.PerformanceEvaluation --nomapred --writeToWAL=false --table=xxx --rows=50000 randomWrite 100
2.sh hbase org.apache.hadoop.hbase.PerformanceEvaluation --nomapred --writeToWAL=false --table=xxx --rows=50000 sequentialWrite 100
3.sh hbase org.apache.hadoop.hbase.PerformanceEvaluation --nomapred --writeToWAL=true --table=xxx --rows=50000 randomWrite 100
4.sh hbase org.apache.hadoop.hbase.PerformanceEvaluation --nomapred --writeToWAL=true --table=xxx --rows=50000 sequentialWrite
5.sh hbase org.apache.hadoop.hbase.PerformanceEvaluation --nomapred --table=xxx --rows=50000 randomRead 100
6.sh hbase org.apache.hadoop.hbase.PerformanceEvaluation --nomapred --table=xxx --rows=5000 --caching=100 scanRange100 100
先來介紹用法，上述1-6個case 我們看到相關的參數，nomapred，writeToWAL, table, rows 以及各個randomWrite，sequentialWrite，scanRange100，等；下面列一個表大概介紹用法：
| 參數 | 意義 |
|---|---|
| nommapred | 默認使用本地啓動mapreduce方式測試，如果有此參數，表示使用本地啓動線程方式，非mr方式測試 |
| table | 測試的表名 |
| rows | 因爲pe本地啓動多線程的模式是，每一個線程需要操作一定的數量的key，這裏後面跟操作的key的數量，默認是1024*1024 |
| startRow | 每個線程操作key的起始key，默認是0；當然，這裏的key，實際到最終操作的row key 有點小區別，下面會說 |
| compression | 表對數據的壓縮策略（lzo，gz，snappy，lz4，zstd，none幾種策略），是在服務端的表沒有的時候，這個參數是有意義的，默認是沒有壓縮 |
| blockEncoding | 表的data block的encoding策略： NONE; PREFIX; DIFF; FAST_DIFF; PREFIX_TREE,默認none |
| writeToWAL | 寫的時候Hlog的策略，有： SYNC_WAL 和 SKIP_WAL 2種，但是這裏我們在測試的時候添加了一種新的ASYNC_WAL的方式，標誌異步的flush wal ；這裏原來的true標誌sync_wal,false標誌skip，我們改爲false 標誌位async_wal方式； |
| multiGet | 標誌get多條，在server端get多條需要的數據，然後返回；默認是0；單條get不受影響 |
| columns | 表示有多少個列，默認是1，我們這裏使用默認的case |
| caching | 表示在在服務端cache多少數據，然後一次拉回來；主要是scan的時候用到 |
| randomWrite | 上面說了每個線程發送對應的數據量的數據，從startRow開始到最終條數終止，每次的row key 以總共操作的rows隨機出一個數字，row的總數是線程數*rows；row key 26byte |
| sequentialWrite | 這裏的row key 是以star row 開始，和這個數據是有相關性的，順序key |
| randomRead | 讀的key是randowrite 一樣，具有隨機性 |
| scan | 給定指定的start row，開始scan，但是這裏好像代碼是隻讀到第一條key就返回，應該是個bug，我們已經改了 ，而且start row 每次應該讀完需要變化 |
| randomSeekScan | 和上述的scan做對比，每一次讀的star row是隨機的，這裏是讀到最終的數據爲止； |
| scanRange10 | 隨機的指定範圍的scan，scan的key的起止之間是10個；scanrang100是100個，依次類推 |
pe的大概的原理是：client啓動線程池，線程池的上限線程是我們傳遞多少線程的參數，也就是各個case最後的100。然後會啓動多個線程，每個線程併發的去執行rows次的讀/寫/scan操作；當然各個操作的類型是不一樣的。
pe只是統計了整個流程下來消耗的平均時間以及各個線程的延時等信息，沒有統計單位時間內這個server所處理的rps（request per second），我們這邊修改了代碼，統計該數據，大概的思路很簡單，就是以所有線程並行操作的所有操作記錄數count除以平均時間ts，得到的就是每秒這個sever處理的請求；
2.2.測試case：
| 寫操作標誌 | 寫操作類型 |
|---|---|
| sw1 | 順序Batch100，ASYNC_WAL |
| sw2 | 順序Batch100，SYNC_WAL |
| sw3 | 順序Batch2 ，ASYNC_WAL |
| sw4 | 順序Batch 2，SYNC_WAL |
| sw5 | 順序寫一條，ASYNC_WAL |
| sw6 | 順序寫一條，SYNC_WAL |
| rw1 | 隨機Batch100，ASYNC_WAL |
| rw2 | 隨機Batch 100，SYNC_WAL |
| rw3 | 隨機Batch 2，ASYNC_WAL |
| rw4 | 隨機Batch2，SYNC_WAL |
| rw5 | 隨機寫一條，ASYNC_WAL |
| rw6 | 隨機寫一條，SYNC_WAL |
| 讀操作標誌 | 讀操作 |
|---|---|
| nr1 | 無cache命中，隨機讀一條 |
| nr2 | 無cache命中，scan100條 |
| yr1 | cache命中近100%，隨機讀一條 |
| yr2 | cache命中近100%，scan100條 |
這裏解釋下上述測試case的意思：順序/隨機的意思是指：寫入的row key的規律是隨機性產生還是具有順序特性；batch 100、2條等是指每次提交給服務端的key的條數。ASYNC_WAL/SYNC_WAL是指每次寫操作下，服務端對於WAL 日誌的處理是異步flush到文件系統，或者是同步flush到文件系統。無命中cache和命中cache主要是指這次讀/scan的請求是否有命中cahce。
爲了更好的對比數據，我們的兩個版本的大部分參數都是用默認參數，比如這裏的blockcache使用lrucache，size是默認大小。我們的表沒有開啓壓縮，我們的minor compaction閾值沒有做變化，等等。當然，這些詳細的參數設置我們後面會有一篇單獨的文章進行介紹，調優相關。
2.3.測試方法
對於寫操作：通過設置writeWAL可以設置寫時候是如何操作write-ahead-logging的。對於隨機還是順序的設置key，主要是pe自己有這個接口。
對於讀操作：是否有cache的命中，無cahce的話，通過設置單表的blockcache選項是否是true，false，測試單表需要通過修改表的屬性裏面cache與否設置是否開啓cache； cache的命中率的提高是通過預讀多次，在監控中觀測cache的命中率來做判斷。 當觀察到監控中的現象是cahce free size夠大，且cache的hint percent是0/近100%的場景下，取到需要的測試結果。
此外我們使用2個client進行測試，2個client是同一個az，爲啥使用2client，因爲單client的時候發現cpu容易打滿，這個時候線程越多對client而言以及壓力測試並不是好事，我們使用2個client分別測試，發現各100線程的時候，sever的性能表現比較不錯，在某些場景下是可以把server的cpu/磁盤壓榨的比較不錯；此外個人認爲單client 多線程和多client在分佈式場景下效果相差不是很大。
3.測試結果
3.1.測試結果柱狀圖
下面給出了隨機寫，順序寫以及隨機讀，scan 100條數據在各個背景下的性能情況，主要的輸出數據有3個維度：rps（單秒的request請求），所有請求的平均延時，99延時；其中PE是多線程的請求，輸出的數據給出各個線程的99延時，我們大概隨機抽樣了幾條線程的99延時數據，這裏主要輸出的信息集中在rps和平均延時，這裏的平均延時是多條線程併發請求sever以後處理完數據的各個線程的平均延時。此外這裏還有一個地方需要注意下，對於scan的話，一次scan100條左右，所有我們最終統計的rps是在統計次數上乘以100作爲大概的rps；但是scan下面的延時是每次的請求時延，對於get/write請求這個延時沒有什麼影響，單純對scan操作做一個註釋；此外cache的命中也不能保證100%，只是通過多次讀取，達到cache命中的的可能性，所以上面寫的是命中率近100%。
3.1.1隨機寫
從數據結果來看，隨機寫情況下，BATCH 2條的性能和社區對比的話是比較不錯的，性能有30%多的提升，這種情況下，網絡消耗不會佔很多，此外也不會像單條寫那樣消耗磁盤性能。
3.1.2順序寫
3.1.3.讀/scan操作
scan的時候的命中率受到cache的大小影響以及scan的條數的影響，這裏使用默認的blockcachesize，scan100條數據，這裏存在部分數據會請求文件系統的可能性，這裏需要說明下。
上面幾個圖分佈展示了我們對阿里雲HBase 以及HBase1.1.12的測試數據，通過數據我們可以看出，阿里雲HBase在讀、寫、scan場景下的性能比社區HBase（1.1.12）的性能都要高很多，大部分場景下的性能超過30%的提高，某些場景下甚至超過100%；就讀、寫、scan的延時數據來看阿里雲HBase的讀寫/scan延時普遍比社區HBase快，某些場景下近1倍的速度。從測試性能上面看，阿里雲HBase的性能還是很不錯的。此外，上述測試是單rs下的讀寫scan，整體性能具有線性擴展能力。
此外，我們也在測試ApsaraDB for HBase 和 HBase1.2.6的性能，後續會給出二者的測試報告和詳細數據。
