0.2

1. 文档名称：HBase benchmark
HBase benchmark
-1-

2. 文档名称：HBase benchmark
1. 测试目的
本测试的目的是确定 hbase 各项性能指标，包括随机读写，顺序读写的性能。
由于本版本 hdfs（cdh3b2）引入了 sync 的功能，并且默认情况下会对 meta/root
region 每条记录 sync 一次，以保证 meta/root region 在其所在机器 down 机情况下的数
据安全，其带来的开销就是写入性能的下降，因此在测试中我们还会对比 hbase 的顺
序导入性能。
2. 环境
2.1 软硬件
Hbase 集群规模为 12 台机器，其中 1 台 HMaster，11 台 region server，物理内存 48G，
处在同一机房
测试用 client 为 5 台机器 ，物理内存为 16G
Hbase：hbase 0.20.6，hadoop：cdh3b2 （对比测试中老基线指 hbase 0.20.4 + hadoop
0.20.2, 新基线指 hbase 0.20.6， hadoop： cdh3b2）
功能上包括多线程 compaction，sync 功能的支持
日志级别：regionserver 为 INFO
2.3 表结构
5 个 column family，每个 column family 有 5 个 qualifier
2.4 写入的数据
KeyLen : 50 B ， ValueLen: 100 B
2.5 配置参数的修改
dfs.replication = 2
hbase.regions.nobalancing.count = 10
hbase.client.scanner.caching = 100
hbase.regionserver.hlog.splitlog.reader.threads = 10
hbase.regionserver.hlog.splitlog.writer.threads = 20
3. 测试方法
3.1 顺序写
本测试分别在每台 client 机分别启动 2 个，4 个，6 个，8 个 client，每个 client 写入的
-2-

3. 文档名称：HBase benchmark
key 长度为 50B， 格式为 <随机整数><index>, 每个 client 有一个唯一的随机整数前缀，而
且对于每一个 client， index 连续。
其 Value 长度为 100B。 下图为测试中所获得的测试数据。
横坐标分别为每台机器 2 个，4 个，6 个，8 个 client 的 case。纵坐标分别为对应各 case 的
吞吐量，单位为每秒记录数（rec/s）
3.2 随机写
本测试分别在每台 client 机分别启动 2 个，4 个，6 个，8 个 client，每个 client 写入的
key 长度为 50B， 格式为 <随机整数>，而且对于每一条记录随机生成一个行 key。Value
长度为 100B。 下图为测试中所获得的测试数据。横坐标分别为每台机器 2 个，4 个，6 个，
8 个 client 的 case。纵坐标分别为对应各 case 的吞吐量，单位为每秒记录数（rec/s）
3.3 顺序读（scan）
本测试分别在每台 client 机分别启动 2 个，4 个，6 个，8 个 client，每个 client scan 一
个 row key 区间。 下图为测试中所获得的测试数据。横坐标分别为每台机器 2 个，4 个，6
-3-

4. 文档名称：HBase benchmark
个，8 个 client 的 case。纵坐标分别为对应各 case 的吞吐量，单位为每秒记录数（rec/s）
3.4 顺序读(get)
本测试分别在每台 client 机分别启动 2 个，4 个，6 个，8 个 client，每个 client scan 一个
row key 区间，获取一个 row key 样本，然后顺序的 get 每一个 key 并统计性能。 下图为测
试中所获得的测试数据。横坐标分别为每台机器 2 个，4 个，6 个，8 个 client 的 case。纵坐
标分别为对应各 case 的吞吐量，单位为每秒记录数（rec/s）
3.5 随机读
本测试分别在每台 client 机分别启动 2 个，4 个，6 个，8 个 client，每个 client scan 一个
row key 区间，获取一个 row key 样本，然后随机的 get 每一个 key 并统计性能。 下图为测
试中所获得的测试数据。横坐标分别为每台机器 2 个，4 个，6 个，8 个 client 的 case。纵坐
标分别为对应各 case 的吞吐量，单位为每秒记录数（rec/s）
-4-

5. 文档名称：HBase benchmark
3.6 导入性能对比测试
hbase0.20.4 和 hbase 0.20.6 的性能对比测试，在 12 台机器的 hbase 的集群测试，client
也部署在这 12 台机器。每台机器分别起 2、4、6、8、10 个客户端。
hbase 0.20.6 + hdfs cdh3b2
客户端数/台 原始数据平均 原始数据平均 平均每台 平均每台
速度 Mb/s 速度 rec/s client 的平均 client 的平均
速度 MB/s 速度 rec/s
2 58.42 16334.21 2.65 742.46
4 45.22 12643.2 1.03 287.35
6 38.16 10670.17 0.58 161.67
8 30.25 8458.59 0.34 96.12
hbase 0.20.4 + hdfs 0.20.2
客户端数/台 原始数据平均 原始数据平均 平均每台 平均每台
速度 Mb/s 速度 rec/s client 的平均 client 的平均
速度 MB/s 速度 rec/s
2 93.31 26091.82 4.24 1185.99
4 69.13 19333.11 1.57 439.39
6 42.68 11934.21 0.65 180.82
8 34.54 9659.01 0.39 109.76
对比 hbase 0.20.4 和 hbase 0.20.6 顺序写入性能
由于 hadoop0.20.2 不支持 sync 功能，日志文件只有当日志滚动时，才保证日
志数据被持久化。 hadoop cdh3b2 支持 sync 功能，
而 meta/root region 每条都 sync，
user region 不 sync。
对比 2 个版本性能， 在开启 sync 功能后，对于 2 个 client 性能损失 37.4%, 4
-5-

6. 文档名称：HBase benchmark
个 client 性能损失 34.6%， 6 个 client 性能损失 10.59 %， 8 个 client 性能损失
12.43%。
使用 hbase0.20.6 + hadoop cdh3b2 最高时可以保证 58.42 MB/s 的原始数据导
入。据推算，每小时能够导入原始数据 205.38 G。
对比 2 个版本，以上几项分别为每台机器 2 client，4 client， 6 client，8 client 的性
能。纵坐标为整个集群的吞吐量（rec/s）
此外， 当前 HBase 中对于 user region 提供不同安全级别， wal 打开的情况下， region
当 user
每 hbase.regionserver.flushlogentries （ 默 认 为 100 ） 条 记 录 sync 一 次 ， 每
hbase.regionserver.optionallogflushinterval （默认 10 s），将未 sync 的记录 sync 到 hdfs。
因此，我们针对 hbase.regionserver.flushlogentries 的条目进行了对比测试。我们选择了
12 台 client 机，每台机器 6 个 client 进行顺序导入测试。hbase.regionserver.flushlogentries 分
别选择 100，1000， 10000 以及关闭 user region sync 功能。性能指标如下：
测试 sync 的性能，以上几项分别为 user region 每 100 条，每 1000 条，每 10000 条，以及
user region 不写日志的性能。纵坐标为整个集群的吞吐量（rec/s）
3.7 不同 column family 和 qualifier 的情况下对比测试
-6-

7. 文档名称：HBase benchmark
本测试分别在每台 client 机分别启动 5 column family + 5 qualifier, 1 column family + 25
qualifier 2 client, 1 column family + 25 qualifier 6 client, 1 column family + 25 qualifier 8 client,。
下图为测试中所获得的测试数据。纵坐标分别为对应各 case 的吞吐量，单位为每秒记录数
（rec/s） 。
当使用 1 column family + 25 qualifier 8 client 的情况下， 经过 2 天测试， 网卡峰值可以达
到 100 MB/s，均值可以达到 80 MB/s 左右。
4.结论
下表为以上测试数据，根据测试结果我们对比当前版本 hbase 更擅长于顺序读写。我们
对比了写入性能，顺序写入性能基本上可以达到随机写入性能的 2 倍。据观察，从每台机器
2 个 client 到每台机器 8 个 client（5 台 client 机器）的 case 中，网卡均未打满，系统吞吐量
并未能随 client 数线性增长，性能瓶颈还需要进一步定位。
对比 scan 和顺序，随机 get 的性能，不难看出，当前 hbase scan 的性能还是比较优的，
系统吞吐量基本可以随 client 数线性增长。 而随机， 顺序 get 的性能比较差基本上载 3000 rec/s
上下浮动，client 数目对其性能影响不大。
client 2 client 4 client 6 client 8
顺序写 10219.13 8074.55 6292.89 5971.43
随机写 4542.74 3677.05 3426.33 4417.01
顺序读（get） 3263.23 2682.9 2340.22 1923.48
顺序读 （scan） 17851.15 28062.29 29680.82 44210.63
随机 get 2758.64 2827.29 2437.03 1944.71
写性能对比图：
-7-

8. 文档名称：HBase benchmark
读性能对比图：
此外，根据不同 column family 和 qualifier 的情况下对比测试，我们发现在相同数据量
情况下，1 column family + 25 qualifier 吞吐量是 5 colomn family + 5 qualifier 的 6 倍左右，
所以在应用方面，推荐使用更少的 column family，能够获得更好的导入性能。在 1 column
family + 25 qualifier 8 client case 中网卡基本上可以打满，吞吐量瓶颈在网卡硬件限制。
-8-