447
ApsaraDB for HBase性能/延時全麵領先社區版本
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 分布原則？
此外，YCSB還有很多和HBase相關的參數配置，比如：寫的時候的writeBufferSize，讀的時候是否有setBlockCache， 這些都是有的。
2.2.2.HBase PerformanceEvaluation工具原理以及使用方法介紹
HBase PerformanceEvaluation 這個工具是HBase 自帶的，測試的case 以及提供給外界的接口比YCSB 更豐富，比如提供了：RandomWrite，SequenceWrite，scan，randomSeekScan，scanRange10 ，scanRange100 等等。這個測試的場景比上述YCSB 豐富的多，YCSB的scan的case 就沒有上述豐富。我們本文中的測試的工具主要使用的是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條 |
2.3.測試方法
對於寫操作：通過設置writeWAL可以設置寫時候是如何操作write-ahead-logging的，對於如何操作是否是batch100還是2條還是一條數據，這裏我主要是通過設置寫的時候本地client的緩存的大小，writebuffersize的大小。因為我們這裏的key的對應value是一定的，1000B；100條的話，我們設置size是他的100倍，2倍以及1倍去操作。隨機與順序寫，隻是對於key的操作順序是什麼樣的進行了相應的設置；
對於讀操作：是否有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操作做一個注釋；
3.1.1隨機寫
3.1.2順序寫
3.1.3.讀/scan操作
上麵幾個圖分布展示了我們對阿裏雲HBase 以及HBase1.1.12的測試數據，通過數據我們可以看出，阿裏雲HBase在讀、寫、scan場景下的性能比社區HBase（1.1.12）的性能都要高很多，大部分場景下的性能超過30%的提高，某些場景下甚至超過100%。此外，從測試性能上麵看，阿裏雲HBase的性能還是很不錯的。此外，上述測試是單rs下的讀寫scan，整體性能具有線性擴展能力。
最後更新：2017-09-07 12:32:39