HBase2.0中的Benchmark工具 — PerformanceEvaluation

　　摘要：在項目開發過程當中，咱們常常須要一些benchmark工具來對系統進行壓測，以得到系統的性能參數，極限吞吐等等指標。而在HBase中，就自帶了一個benchmark工具—PerformanceEvaluation，能夠很是方便地對HBase的Put、Get、Scan等API進行性能測試，並提供了很是豐富的參數來模擬各類場景。

　　簡介

　　在項目開發過程當中，咱們常常須要一些benchmark工具來對系統進行壓測，以得到系統的性能參數，極限吞吐等等指標。而在HBase中，就自帶了一個benchmark工具—PerformanceEvaluation，能夠很是方便地對HBase的Put、Get、Scan等API進行性能測試，並提供了很是豐富的參數來模擬各類場景。這篇文章，就以HBbase2.0中的PerformanceEvaluation工具爲例，給你們講解一下這款HBase benchmark工具的使用和注意事項

　　參數介紹

　　PerformanceEvaluation的全名是org.apache.hadoop.hbase.PerformanceEvaluation. 已經集成在了bin/hbase工具集中。在安裝好HBase的機器上，在HBase的安裝路徑的bin目錄下執行hbase pe，加上相應參數，便可運行PE工具（如下簡稱PerformanceEvaluation爲PE）。若是不加任何參數，則會輸出PE的幫助信息。

　　

　　PE工具的參數很是多，不少參數只是用於某項專門的測試。這裏我只介紹一下比較重要的幾個全局參數。

　　nomapred採用MapReduce的方式啓動多線程測試仍是經過多線程的方式，若是沒有安裝MapReduce，或者不想用MapReduce，一般咱們採用多線程的方式，所以通常在命令中加上--nomapred來表示不使用MapReduce。

　　oneCon多線程運行測試時，底層使用一個仍是多個參數。這個參數默認值爲false，每一個thread都會啓一個Connection，建議把這個參數設爲True，至於緣由，後面的章節會講。

　　valueSize寫入HBase的value的size，單位是Byte，你們能夠根據本身實際的場景設置這個Value的大小。

　　blockEncodingPE工具會自動建表，這個參數用來指定表的block encoding。關於encoding後面會有專門的文章介紹，這裏再也不講。

　　table測試表的名字，若是不設，默認爲TestTable。

　　rows總共測試的行數。注意這裏的行數是指單線程的行數，若是rows=100， 線程數爲10，那麼在寫測試中，寫入HBase的將是 100 x 10 行。

　　size總測試的數據大小，單位爲GB，這個參數與上面的size是互斥的，不要兩個參數一塊兒設。在使用randomReads和randomSeekScans測試時，這個size能夠用來指定讀取的數據範圍。這個值在Read時很是重要，若是設的很差，會產生不少返回值爲空的讀，影響測試結果，下面會詳細介紹。

　　compress設置表的compress算法，根據本身選擇，默認是None,即不作壓縮。

　　presplit表的預分裂region個數，在作性能測試時必定要設置region個數，否則全部的讀寫會落在一個region上，嚴重影響性能

　　autoFlush默認爲false，即PE默認用的是BufferedMutator，BufferedMutator會把數據攢在內存裏，達到必定的大小再向服務器發送，若是想明確測單行Put的寫入性能，建議設置爲true。我的以爲PE中引入autoFlush會影響統計的準確性，由於在沒有攢夠足夠的數據時，put操做會立馬返回，根本沒產生RPC，可是相應的時間和次數也會被統計在最終結果裏。

　　比較重要的參數就這麼多，其餘的參數要麼使用默認就好，要麼就是和具體的測試命令相關，用戶能夠根據測試的內容具體設置。

　　使用示例

　　下面我用測試讀和寫兩個示例來說解下PE工具的使用

　　隨機寫測試 RandomWriteTest

　　RandomWriteTest經常使用來評估HBase的寫性能。使用的命令以下：

　　hbase pe --nomapred --oneCon=true --valueSize=100 --compress=SNAPPY --rows=150000 --autoFlush=true --presplit=64 randomWrite 64

　　在這個測試中，我把PE模式設爲了非MapReduuce(--nomapred)，即採用起線程的形式。跑的命令是randomWrite，即隨機寫入、後面跟的64表明起了64個線程來作寫入。--rows=150000 表明每一個線程會寫入150000行數據。其餘的參數含義能夠參見以前的章節。PE工具的全部的輸出都會直接寫到LOG文件，LOG的位置須要參照HBase的設置。運行結束後，PE會分別打出每一個線程的延遲情況。以下面是其中一個線程的結果：

　　

　　PE統計了這個線程一共跑了多少行，和相應的延遲統計，包括min，max，999th延遲等等。
並在最後統計了全部線程的最大持續時間，平均持續時間等等。

　　2018-05-18 12:07:25,564 INFO [main] hbase.PerformanceEvaluation(507): [RandomWriteTest duration ] Min: 36969ms Max: 40160ms Avg: 38203ms

　　比較坑的是，PE居然不會統計全部線程的平均延遲和總的吞吐。。。

　　隨機讀測試 RandomReadTest

　　在進行RandomReadTest以前，須要準備數據。準備數據建議使用SequentialWriteTest。以下面的語句

　　hbase pe --nomapred --oneCon=true --valueSize=100 --compress=SNAPPY --size=2 --presplit=64 sequentialWrite 64

　　爲啥要用SequentialWriteTest？
這是由於PE寫入的行是有規律的。若是傳入的是--row=1000，thread數是10，則寫入的行總數是1000 x 10 = 10000。在SequentialWrite中，PE會給每一個線程設置偏移量，保證0~9999這10000個行（會把全部數字擴展成26位等長的byte數組）一行不差地寫入HBase。若是是RandomWriteTest，在每一個線程中會隨機生成一個0~9999以前的數字寫入（--row=1000表明每一個線程會寫1000次）。因爲是隨機，會形成中間有些行沒有寫入，那麼在讀取測試時，讀到的就是空行，影響測試結果。
爲啥要用--size而不是--row？
--size=2，表明寫入2GB數據，具體是多少行PE內部會本身去算。假設我這裏填的是--row=1000，線程數是10，那麼寫入的數據範圍是0~9999。當我在作RandomReadTest時，若是須要修改線程數，好比我想測20個線程並行讀，那麼數據讀取的範圍將是0~ （1000 * 20 - 1）， 很大一部分讀是空讀！你固然能夠根據線程數來調整讀測試時row變量的值，使讀的總體範圍不超過寫入的數據範圍，可是row的大小影響了總體測試的時間，而統一用size你就啥都不用管了。
RandomReadTest的命令以下：

　　hbase pe --nomapred --oneCon=true --valueSize=100 --size=2 randomRead 100

　　注意在讀測試時不要加表的任何參數，如presplit這些，若是加了會使PE從新建表，以前寫入的數據就拜拜了。valueSize和size的值要與準備數據命令中保持一致，PE靠這兩個值來算數據的範圍和行數。Read測試的輸出與Write測試的輸出相似。

　　PE工具存在的問題

　　PE工具雖然功能已經比較完備，可是使用下來發現仍是存在必定的問題的，主要有如下幾點：

　　1. Connection的數目設置只能由oneCon這個參數指定，要麼就是一個connection，要麼就是每一個thread一個connection。當測試的線程數比較多時，就比較尷尬了，若是隻用一個connection，connection內部的metaCache等實現都是有鎖的，在拿metacache時，線程較多會產生爭搶，影響對服務器性能的評估。若是每一個thread一個connection更加不可取，每一個connection中都會有一個netty的客戶端，若是我沒記錯的話，每一個客戶端中將會有 2*CPU個worker threads。這在PE運行過程當中產生大量的context switch，更加影響性能測試。根據個人測試發現，在開100個thread測試時，若是每一個thread開一個connection，測試結果比只用一個connection的要慢10%。Context switch的頻率更是10倍以上。

　　2. 沒有multiPut的支持，PE寫時使用的BufferedMutator須要靠調整size來決定buffer多少個put再上發。若是我想明確測試batch 5個put請求，batch10個put請求，都比較難實現。

　　3. 沒有統計整體的RT和TPS/QPS,只有按單個thread統計，若是我用100個thread去壓服務器，這要我怎麼去評估服務器的吞吐……

　　針對以上的問題，我對PerformanceEvaluation工具作了一些改進，回饋給了社區，具體你們能夠看HBASE-20601這個issue。主要的改進有：

　　1. 加入multiPut參數，支持設置batch的數量

　　2. 加入connCount參數，支持設置connection的多少，好比connCount=2，無論多少個thread都會共用這2個connection

　　3. 支持統計全部線程的平均TPS，平均延遲

　　4. 一些代碼的優化和去重

　　你們在PE工具的使用過程當中還遇到了什麼問題，或者有什麼不懂的地方，歡迎與我聯繫。

　　雲端使用

　　阿里HBase目前已經在阿里雲提供商業化服務，任何有需求的用戶均可以在阿里雲端使用深刻改進的、一站式的HBase服務。雲HBase版本與自建HBase相比在運維、可靠性、性能、穩定性、安全、成本等方面均有不少的改進，

原文連接