HBase2.0中的Benchmark工具-PerformanceEvaluation

简介

在项目开发过程中，我们经常需要一些benchmark工具来对系统进行压测，以获得系统的性能参数，极限吞吐等等指标。而在HBase中，就自带了一个benchmark工具—PerformanceEvaluation，可以非常方便地对HBase的Put、Get、Scan等API进行性能测试，并提供了非常丰富的参数来模拟各种场景。这篇文章，就以HBbase2.0中的PerformanceEvaluation工具为例，给大家讲解一下这款HBase benchmark工具的使用和注意事项

参数介绍

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的写性能。使用的命令如下：

在这个测试中，我把PE模式设为了非MapReduuce(--nomapred)，即采用起线程的形式。跑的命令是randomWrite，即随机写入、后面跟的64代表起了64个线程来做写入。--rows=150000 代表每个线程会写入150000行数据。其他的参数含义可以参见之前的章节。PE工具的所有的输出都会直接写到LOG文件，LOG的位置需要参照HBase的设置。运行结束后，PE会分别打出每个线程的延迟状况。如下面是其中一个线程的结果：

PE统计了这个线程一共跑了多少行，和相应的延迟统计，包括min，max，999th延迟等等。

并在最后统计了所有线程的最大持续时间，平均持续时间等等。

比较坑的是，PE竟然不会统计所有线程的平均延迟和总的吞吐。。。

随机读测试 RandomReadTest

在进行RandomReadTest之前，需要准备数据。准备数据建议使用SequentialWriteTest。如下面的语句

为啥要用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的命令如下：

注意在读测试时不要加表的任何参数，如presplit这些，如果加了会使PE重新建表，之前写入的数据就拜拜了。valueSize和size的值要与准备数据命令中保持一致，PE靠这两个值来算数据的范围和行数。Read测试的输出与Write测试的输出类似。

PE工具存在的问题

PE工具虽然功能已经比较完备，但是使用下来发现还是存在一定的问题的，主要有以下几点：

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倍以上。

没有multiPut的支持，PE写时使用的BufferedMutator需要靠调整size来决定buffer多少个put再上发。如果我想明确测试batch 5个put请求，batch10个put请求，都比较难实现。

没有统计总体的RT和TPS/QPS,只有按单个thread统计，如果我用100个thread去压服务器，这要我怎么去评估服务器的吞吐……

针对以上的问题，我对PerformanceEvaluation工具做了一些改进，回馈给了社区，具体大家可以看HBASE-20601这个issue。主要的改进有：

加入multiPut参数，支持设置batch的数量

加入connCount参数，支持设置connection的多少，比如connCount=2，不管多少个thread都会共用这2个connection

支持统计所有线程的平均TPS，平均延迟

一些代码的优化和去重

大家工作学习遇到HBase技术问题，把问题发布到HBase技术社区论坛http://hbase.group，欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup)，非常欢迎大家积极投稿。