團隊小夥伴前段時間對HBase 2.2.1的随機讀寫性能進行了初步的基準測試，這次測試主要目的是評估社群HBase 2.x版本的整體性能，量化目前HBase的性能名額，對常見KV場景下HBase性能表現進行評估，為業務應用提供參考。
測試環境
測試環境包括測試過程中HBase叢集的拓撲結構、以及需要用到的硬體和軟體資源，硬體資源包括：測試機器配置、網絡狀态等等，軟體資源包括作業系統、HBase相關軟體以及測試工具等。
- 叢集拓撲結構
本次測試中，測試環境總共包含3台實體機作為Hadoop資料存儲，其中2台實體機作為RegionServer部署主控端，每個主控端上起2個RegionServer節點，整個叢集一共4個RegionServer節點。生成資料的YCSB程式與資料庫并不運作在相同的實體叢集。
- 單台機器主機硬體配置
- 軟體版本資訊
- 測試工具
YCSB全稱Yahoo! Cloud Serving Benchmark，是Yahoo公司開發的專門用于NoSQL測試的基準測試工具。Github位址：https://github.com/brianfrankcooper/YCSB
YCSB支援各種不同的資料分布方式：
- Uniform：等概論随機選擇記錄
- Zipfian：随機選擇記錄，存在熱記錄
- Latest：近期寫入的記錄為熱記錄
- 測試場景
YCSB為HBase提供了多種場景下的測試，本次測試中，我們導入15億條資料，并對如下場景進行測試：
因為是基準測試，寫入和查詢的資料具有以下特性：
- 測試核心配置參數
<!-- blockcache -->
<property>
<name>hfile.block.cache.size</name>
<value>0.05</value>
</property>
<property>
<name>hbase.bucketcache.ioengine</name>
<value>offheap</value>
</property>
<property>
<name>hbase.bucketcache.size</name>
<value>61440</value>
</property>
<!-- memstore -->
<property>
<name>hbase.regionserver.offheap.global.memstore.size</name>
<value>30720</value>
</property>
<property>
<name>hbase.hregion.compacting.memstore.type</name>
<value>BASIC</value>
</property>
<property>
<name>hbase.regionserver.global.memstore.lowerLimit</name>
<value>0.30</value>
</property>
<property>
<name>hbase.hregion.memstore.block.multiplier</name>
<value>5</value>
</property>
<property>
<name>hbase.hregion.memstore.flush.size</name>
<value>268435456</value>
</property>
測試結果說明
-
單純查詢場景
- 測試參數
總記錄數為15億，分為300個region，均勻分布在4台region server上；插入操作執行20億次，150用戶端線程；
- 測試結果
- 吞吐量
- 讀延遲
- 資源使用情況
- 結果分析
- 吞吐量曲線說明：單個執行個體節點穩定在3.3W左右，整個叢集2台實體機穩定在11.5W左右，單台實體機穩定在5.8W左右。
- 資源使用情況說明：IO使用率達到80%左右，磁盤單盤TPS達到1.1W次，達到比較高的使用水準。CPU使用率隻有40%左右，遠遠沒有達到瓶頸。
-
讀多寫少場景
總記錄數為15億，分為300個region，均勻分布在4台region server上；查詢操作執行20億次；查詢請求分布遵從zipfian分布；讀寫比例8:2；
- 讀取延遲
- 吞吐量曲線說明：單個執行個體節點穩定在2.7W左右（其中讀TPS穩定在1.9W左右，寫TPS穩定在0.47W左右），整個叢集2台實體機穩定在10W左右，單台實體機穩定在5W左右。
- 讀取延遲說明：讀P999延遲穩定在18ms左右。寫P999延遲穩定在40ms左右。讀寫平均延遲都在1ms左右。
- 資源使用情況說明：IO使用率達到80%左右，磁盤單盤TPS達到0.8W次，達到較高的使用水準。CPU使用率達到50%。
- 異常情況分析
特别說明的是，測試過程中在2點28分~2點32分左右吞吐量有一個比較明顯的突降，對應的P999讀延遲有一個明顯的飙升。直覺上來看，根據資源使用情況，對應時間點測試節點的帶寬有一個非常明顯的突升，IOWait有一個明顯的增大，對應的FsPReadTime_P999也有一個明顯的增大，基本可以确定随機讀P999讀延遲飙升是因為IOWait突變引起的，那什麼情況導緻了這次網絡帶寬、IOWait飙升呢？可以看下面一張圖：
很明顯，在2點28分~2點32分之間減少了十幾個HFile檔案，很容易就猜測到RegionServer執行了compaction操作導緻網絡帶寬和硬碟IO有一個明顯的消耗，導緻了随機讀P999飙升。
不過，HBase可以通過将hbase.regionserver.throughput.controller設定為org.apache.hadoop.hbase.regionserver.compactions.PressureAwareCompactionThroughputController開啟compaction的限流功能，通過參數hbase.hstore.compaction.throughput.higher.bound限制compaction執行過程中的最大使用網絡帶寬。
-
讀寫均衡場景
總記錄數為15億，分為300個region，均勻分布在4台region server上；查詢操作執行20億次；查詢請求分布遵從zipfian分布；讀寫比例 5:5；
- 吞吐量曲線說明：單個執行個體節點穩定在2.5W左右，整個叢集2台實體機穩定在10W左右，單台實體機基本穩定在5W左右。
- 讀取延遲說明：讀P999延遲穩定在20ms左右，讀P99延遲穩定在3ms左右。寫P999延遲穩定在25ms左右。讀平均延遲在1ms以内，寫平均延遲在1ms以内。
-
寫多讀少場景
總記錄數為15億，分為300個region，均勻分布在4台region server上；查詢操作執行20億次；查詢請求分布遵從zipfian分布；讀寫比例2:8；
- 吞吐量曲線說明：單個執行個體節點穩定在3.5W左右，整個叢集2台實體機穩定在14W左右，單台實體機穩定在7W左右。
- 讀取延遲說明：讀P999延遲穩定在30ms左右，讀P99延遲穩定在10ms左右。寫P999延遲穩定在27ms左右。讀平均延遲在1ms左右，寫平均延遲在1ms以内。
測試結果分析
這次測試主要針對HBase 2.2.1這個版本進行了基準性能測試，測試結果顯示無論是吞吐量還是随機讀寫延遲都達到了較高的水準，可以滿足線上的應用場景。在我們另一個針對于真實線上資料場景（非基準資料，是以測試結果中的絕對值沒有實際意義）的性能測試中對HBase
2.2.1和HBase 1.4.1這兩個版本進行了對比測試，詳細的測試結果就不在這裡展開介紹，在讀寫均衡場景下，HBase
2.2.1相比HBase
1.4.1在吞吐量方面有60%的性能提升，同時随機讀P999延遲從50ms降低到30ms，随機讀P99從20ms降低到7ms，而且來說抖動大大減少。
HBase 官方社群推薦必讀好文
HBase 原理|HBase 記憶體管理之 MemStore 進化論
HBase 抗戰總結|阿裡巴巴 HBase 高可用8年抗戰回憶錄