HBase 2.2.1随机读写性能测试

团队小伙伴前段时间对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，而且来说抖动大大减少。