Hbase性能测试详细设计文档及用例
Hbase性能测试
一、涉及调优参数
1、表的设计
1.1、Pre-Creating Regions
默认情况下，在创建HBase表的时候会自动创建一个region分区，当导入数据的时候，所有的HBase客户端都向这一个region写数据，直到这个region足够大了才进行切分。
一种可以加快批量写入速度的方法是通过预先创建一些空的regions，这样当数据写入HBase时，会按照region分区情况，在集群内做数据的负载均衡。
1.2、Compact & Split
在HBase中，数据在更新时首先写入WAL 日志(HLog)和内存(MemStore)中，MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。于此同时， 系统会在zookeeper中记录一个redo point，表示这个时刻之前的变更已经持久化了(minor compact)。
StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后，就会进行一次合并(major compact)，将对同一个key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小达到一定阈值后，又会对 StoreFile进行分割(split)，等分为两个StoreFile。
由于对表的更新是不断追加的，处理读请求时，需要访问Store中全部的StoreFile和MemStore，将它们按照row key进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，通常合并过程还是比较快的。
实际应用中，可以考虑必要时手动进行major compact，将同一个row key的修改进行合并形成一个大的StoreFile。同时，可以将StoreFile设置大些，减少split的发生。
1.3、压缩方式
在hadoop和hbase文件传输可以在压缩之后在进行传输，这样就可以在传输的时候减少传输数据，增大I/O和带宽效率。在hadoop中主要提供了三种压缩方式Gzip、LZO、Snappy三种数据压缩。
实际使用中，可以考虑分别尝试两种压缩模式，选出最适合业务场景要求的。
2、写表操作
2.1、Row Key设计
HBase中row key用来检索表中的记录，支持以下三种方式：
- 通过单个row key访问：即按照某个row key键值进行get操作；
- 通过row key的range进行scan：即通过设置startRowKey和endRowKey，在这个范围内进行扫描；
- 全表扫描：即直接扫描整张表中所有行记录。
row key是按照字典序存储，因此，设计row key时，要充分利用这个排序特点，将经常一起读取的数据存储到一块，将最近可能会被访问的数据放在一块。
如果最近写入HBase表中的数据是最可能被访问的，可以考虑将时间戳作为row key的一部分，由于是字典序排序，所以可以使用Long.MAX_VALUE – timestamp作为row key，这样能保证新写入的数据在读取时可以被快速命中。
2.2、多HTable并发写
创建多个HTable客户端用于写操作，提高写数据的吞吐量，
2.3、HTable参数设置
2.3.1 Auto Flush
通过调用HTable.setAutoFlush(false)方法可以将HTable写客户端的自动flush关闭，这样可以批量写入数据到HBase，而不是有一条put就执行一次更新，只有当put填满客户端写缓存时，才实际向HBase服务端发起写请求。默认情况下auto flush是开启的。
2.3.2 Write Buffer
通过调用HTable.setWriteBufferSize(writeBufferSize)方法可以设置HTable客户端的写buffer大小，如果新设置的buffer小于当前写buffer中的数据时，buffer将会被flush到服务端。其中，writeBufferSize的单位是byte字节数，可以根据实际写入数据量的多少来设置该值。
2.3.3 WAL Flag
在HBae中，客户端向集群中的RegionServer提交数据时（Put/Delete操作），首先会先写WAL（Write Ahead Log）日志（即HLog，一个RegionServer上的所有Region共享一个HLog），只有当WAL日志写成功后，再接着写MemStore，然后客户端被通知提交数据成功；如果写WAL日志失败，客户端则被通知提交失败。这样做的好处是可以做到RegionServer宕机后的数据恢复。
因此，对于相对不太重要的数据，可以在Put/Delete操作时，通过调用Put.setWriteToWAL(false)或Delete.setWriteToWAL(false)函数，放弃写WAL日志，从而提高数据写入的性能。
3、读表操作
3.1 多HTable并发读
创建多个HTable客户端用于读操作，提高读数据的吞吐量，
3.3 批量读
通过调用HTable.get(Get)方法可以根据一个指定的row key获取一行记录，同样HBase提供了另一个方法：通过调用HTable.get(List)方法可以根据一个指定的row key列表，批量获取多行记录，这样做的好处是批量执行，只需要一次网络I/O开销，这对于对数据实时性要求高而且网络传输RTT高的情景下可能带来明显的性能提升。
3.4 多线程并发读
在客户端开启多个HTable读线程，每个读线程负责通过HTable对象进行get操作。
3.5 缓存查询结果
对于频繁查询HBase的应用场景，可以考虑在应用程序中做缓存，当有新的查询请求时，首先在缓存中查找，如果存在则直接返回，不再查询HBase；否则对HBase发起读请求查询，然后在应用程序中将查询结果缓存起来。至于缓存的替换策略，可以考虑LRU等常用的策略。
3.6 Blockcache
HBase上Regionserver的内存分为两个部分，一部分作为Memstore，主要用来写；另外一部分作为BlockCache，主要用于读。
写请求会先写入Memstore，Regionserver会给每个region提供一个Memstore，当Memstore满64MB以后，会启动 flush刷新到磁盘。当Memstore的总大小超过限制时（heapsize * hbase.regionserver.global.memstore.upperLimit * 0.9），会强行启动flush进程，从最大的Memstore开始flush直到低于限制。
读请求先到Memstore中查数据，查不到就到BlockCache中查，再查不到就会到磁盘上读，并把读的结果放入BlockCache。由于BlockCache采用的是LRU策略，因此BlockCache达到上限(heapsize * hfile.block.cache.size * 0.85)后，会启动淘汰机制，淘汰掉最老的一批数据。
一个Regionserver上有一个BlockCache和N个Memstore，它们的大小之和不能大于等于heapsize * 0.8，否则HBase不能启动。默认BlockCache为0.2，而Memstore为0.4。对于注重读响应时间的系统，可以将 BlockCache设大些，比如设置BlockCache=0.4，Memstore=0.39，以加大缓存的命中率。
二、测试环境
2.1测试组网
2.2设备配置
软件配置
|
软件名称 |
软件版本 |
数量（套） |
说明 |
|
Hadoop |
2.2.0 |
1 |
|
|
HBase |
HBase-0.96 |
1 |
|
硬件配置
|
序号 |
设备名称 |
数量 |
CPU |
内存 |
硬盘 |
说明 |
|
1 |
主控服务器 |
2 |
I2-2100/双核四线程 |
4G |
500G |
|
|
2 |
处理节点 |
7 |
I5-2320 |
16G |
1T |
|
网络配置
|
序号 |
设备名称 |
设备型号 |
数量 |
|
1 |
千兆交换机 |
SD2008T |
1 |
|
2 |
千兆连接口 |
10/100/1000BASE-T口 |
24 |
2.3测试工具
2.3.1 Ganglia监控工具
Ganglia是设计用于检测数以千计的节点。Ganglia的核心包含gmond、gmetad以及一个Web前端。主要是用来监控系统性能，如：cpu 、mem、硬盘利用率， I/O负载、网络流量情况等，通过曲线很容易见到每个节点的工作状态，对合理调整、分配系统资源，提高系统整体性能起到重要作用。
2.4测试方法
HBase测试是采用YCSB benchmark测试的，HBase入库数据量：5000万条、1亿条、5亿条、10亿条、20亿、40亿、80亿、100亿条；HBase数据查询是采用测试代码实现的，本次HBase查询是以行键+列族+列名进行数据查询的。
数据立方（Datacube）数据入库分别将HBase中的5000万、1亿条、5亿条、10亿条、20亿、40亿、80亿、100亿条数据，以文本格式导入到数据立方hdfs中的。数据立方中的查询条件与HBase中的查询条件相同。
三、用例设计
1、HBase可靠性测试
1.1、Hadoop（NameNode）节点故障
|
项目 |
HBase |
用例名称 |
主namenode宕机 |
|
用例编号 |
HBase-fun-001 |
重要性 |
重要 |
|
测试目的 |
验证主namenode宕机后, 备namenode节点是否能正常转换为主节点，并且系统稳定运行 |
||
|
预置条件 |
1、 HBase运行正常 2、 客户端运行正常 |
||
|
测试步骤 |
1、客户端向HBase写数据 2、写数据过程中，构造主节点服务器故障：重启（reboot）、网络异常、掉电、服务关闭 3、检测写入的数据是否丢失 |
||
|
预期结果 |
1、NameNode2自动切换为active，且系统稳定。切换完成时间少于10s 2、数据写入成功 3、切换后写入的数据无丢失 |
||
|
备注 |
|
||
1.2、Hadoop（DataNode）节点故障
|
项目 |
HBase |
用例名称 |
写数据过程中datanode节点宕机 |
|
用例编号 |
HBase-fun-002 |
重要性 |
重要 |
|
测试目的 |
验证客户端向HBase写入数据过程中，将datanode故障情况下，测试写入的数据是否成功 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 设置副本数为2 |
||
|
测试步骤 |
1、客户端向HBase写数据 2、写数据过程中，构造datanode节点服务器故障：重启（reboot）、网络异常、掉电、服务关闭 3、检测数据写入是否成功 |
||
|
预期结果 |
写数据过程中，在机器宕机的那一瞬间写入的某个文件写失败，之后的数据写入成功 |
||
|
备注 |
|
||
1.3、Hbase（Hmaster）节点故障
|
项目 |
HBase |
用例名称 |
写数据过程中Hmaster节点宕机 |
|
用例编号 |
HBase-fun-002 |
重要性 |
重要 |
|
测试目的 |
验证客户端向HBase写入数据过程中，将Hmaster故障情况下，测试写入的数据是否成功 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 设置副本数为2 |
||
|
测试步骤 |
1、客户端向HBase写数据 2、写数据过程中，构造Hmaster节点服务器故障：重启（reboot）、网络异常、掉电、服务关闭 3、检测数据写入是否成功 |
||
|
预期结果 |
写数据过程中，在机器宕机的那一瞬间写入的某个文件写失败，之后的数据写入成功 |
||
|
备注 |
|
||
1.4、Hbase（RegionServer）节点故障
|
项目 |
HBase |
用例名称 |
写数据过程中RegionServer节点宕机 |
|
用例编号 |
HBase-fun-002 |
重要性 |
重要 |
|
测试目的 |
验证客户端向HBase写入数据过程中，将RegionServer故障情况下，测试写入的数据是否成功 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 设置副本数为2 |
||
|
测试步骤 |
1、客户端向HBase写数据 2、写数据过程中，构造RegionServer节点服务器故障：重启（reboot）、网络异常、掉电、服务关闭 3、检测数据写入是否成功 |
||
|
预期结果 |
写数据过程中，在机器宕机的那一瞬间写入的某个文件写失败，之后的数据写入成功 |
||
|
备注 |
|
||
2、HBase入库性能
2.1、单客户端数据入库
|
项目 |
HBase |
用例名称 |
单个客户端入库性能测试 |
|
用例编号 |
HBase-pre-001 |
重要性 |
重要 |
|
测试目的 |
验证单个客户端向HBase中写数据，通过ganglia监控工具，获知单个客户端数据入库带宽 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 |
||
|
测试步骤 |
1、启用单个客户端向HBase连续写入5亿条数据 2、启用ganglia监控程序 3、记录数据入库速率 |
||
|
预期结果 |
1、数据入库正确无误 2、数据入库速率正常 |
||
|
备注 |
|
||
2.2、多客户端数据入库速率
|
项目 |
HBase |
用例名称 |
多个客户端入库性能测试 |
|
用例编号 |
HBase-pre-002 |
重要性 |
重要 |
|
测试目的 |
验证多个客户端向HBase中写数据，通过ganglia监控工具，获知多个客户端数据入库带宽 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 |
||
|
测试步骤 |
1、启用多个客户（不同服务器）并发向HBase写5亿条数据 2、启用ganglia系统监控程序 3、记录数据库入库速率 |
||
|
预期结果 |
1、数据入库正确无误 2、多个客户端数据入库速率正常 |
||
|
备注 |
|
||
2.3、5000万条记录入库测试
|
项目 |
HBase |
用例名称 |
HBase5000万条记录入库测试 |
|
用例编号 |
HBase-pre-003 |
重要性 |
重要 |
|
测试目的 |
测试统计5000万条记录写到HBase中所用的时长 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 |
||
|
测试步骤 |
1、客户端通过Benchmark向HBase写入5000万记录 2、记录5000万条记录入库时长 |
||
|
预期结果 |
1、记录入库正确 2、5000万条记录入库时长正常 |
||
|
备注 |
|
||
2.4、1亿条记录入库测试
|
项目 |
HBase |
用例名称 |
HBase中1亿条记录入库测试 |
|
用例编号 |
HBase-pre-004 |
重要性 |
重要 |
|
测试目的 |
测试统计1亿条记录写到HBase中所用的时长 |
||
|
预置条件 |
1、 HBase运行正常 2、 客户端运行正常 |
||
|
测试步骤 |
1、客户端通过Benchmark向HBase写入1亿条记录 2、记录1亿条记录入库时长 |
||
|
预期结果 |
1、记录入库正确 2、1亿条记录入库时长正常 |
||
|
备注 |
|
||
2.5、5亿条记录入库测试
|
项目 |
HBase |
用例名称 |
HBase中5亿条记录入库测试 |
|
用例编号 |
HBase-pre-005 |
重要性 |
重要 |
|
测试目的 |
测试统计5亿条记录写到HBase中所用的时长 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 |
||
|
测试步骤 |
1、客户端通过Benchmark向HBase写入5亿条记录 2、记录5亿条记录入库时长 |
||
|
预期结果 |
1、记录入库正确 2、5亿条记录入库时长正常 |
||
|
备注 |
|
||
2.6、10亿条记录入库测试
|
项目 |
HBase |
用例名称 |
HBase中10亿条记录入库测试 |
|
用例编号 |
HBase-pre-006 |
重要性 |
重要 |
|
测试目的 |
测试统计10亿条记录写到HBase中所用的时长 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 |
||
|
测试步骤 |
1、客户端通过Benchmark向HBase写入10亿条记录 2、记录10亿条记录入库时长 |
||
|
预期结果 |
1、记录入库正确 2、10亿条记录入库时长正常 |
||
|
备注 |
|
||
2.7、20亿条记录入库测试
|
项目 |
HBase |
用例名称 |
HBase中20亿条记录入库测试 |
|
用例编号 |
HBase-pre-007 |
重要性 |
重要 |
|
测试目的 |
测试统计20亿条记录写到HBase中所用的时长 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 |
||
|
测试步骤 |
1、客户端通过Benchmark向HBase写入20亿条记录 2、记录20亿条记录入库时长 |
||
|
预期结果 |
1、记录入库正确 2、20亿条记录入库时长正常 |
||
|
备注 |
|
||
2.8、40亿条记录入库测试
|
项目 |
HBase |
用例名称 |
HBase中40亿条记录入库测试 |
|
用例编号 |
HBase-pre-008 |
重要性 |
重要 |
|
测试目的 |
测试统计40亿条记录写到HBase中所用的时长 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 |
||
|
测试步骤 |
1、客户端通过Benchmark向HBase写入40亿条记录 2、记录40亿条记录入库时长 |
||
|
预期结果 |
1、记录入库正确 2、40亿条记录入库时长正常 |
||
|
备注 |
|
||
2.9、80亿条记录入库测试
|
项目 |
HBase |
用例名称 |
HBase中80亿条记录入库测试 |
|
用例编号 |
HBase-pre-009 |
重要性 |
重要 |
|
测试目的 |
测试统计80亿条记录写到HBase中所用的时长 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 |
||
|
测试步骤 |
1、客户端通过Benchmark向HBase写入80亿条记录 2、记录80亿条记录入库时长 |
||
|
预期结果 |
1、数据入库正确 2、80亿条记录入库时长正常 |
||
|
备注 |
|
||
2.10、100亿条记录入库测试
|
项目 |
HBase |
用例名称 |
HBase中100亿条记录入库测试 |
|
用例编号 |
HBase-pre-010 |
重要性 |
重要 |
|
测试目的 |
测试统计100亿条记录写到HBase中所用的时长 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 |
||
|
测试步骤 |
1、客户端通过Benchmark向HBase写入100亿条记录 2、记录100亿条记录入库时长 |
||
|
预期结果 |
1、记录入库正确 2、100亿条记录入库时长正常 |
||
|
备注 |
|
||
3、HBase查询性能测试
3.1、5000万记录中查询10条记录
|
项目 |
HBase |
用例名称 |
从5000万记录中查询10条记录 |
|
用例编号 |
HBase-pre-011 |
重要性 |
重要 |
|
测试目的 |
查询HBase的5000万条记录中的10条记录，查询10条记录正确、时间正常 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 |
||
|
测试步骤 |
1、客户端向HBase写入5000万条记录，其中1条命中 2、通过测试程序发送查询记录请求: 3、记录查询时长 |
||
|
预期结果 |
1、查询结果正确 2、查询时间正常 |
||
|
备注 |
|
||
3.2、1亿条记录中查询1条记录
|
项目 |
HBase |
用例名称 |
1亿条记录中查询1条记录 |
|
用例编号 |
HBase-pre-012 |
重要性 |
重要 |
|
测试目的 |
查询HBase的1亿条记录中的1条记录，查询1条记录正确、时间正常 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 |
||
|
测试步骤 |
1、客户端向HBase写入1亿条记录 2、通过测试程序发送查询记录请求: 3、记录查询时长 |
||
|
预期结果 |
1、查询结果正确 2、查询时间正常 |
||
|
备注 |
|
||
3.3、1亿条记录中查询10条记录
|
项目 |
HBase |
用例名称 |
1亿条记录中查询10条记录 |
|
用例编号 |
HBase-pre-013 |
重要性 |
重要 |
|
测试目的 |
查询HBase的1亿条记录中的10条记录，查询10条记录正确、时间正常 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 |
||
|
测试步骤 |
1、客户端向HBase写入1亿条记录 2、发送数据查询10条记录请求: 3、记录查询10条记录时长 |
||
|
预期结果 |
1、查询结果正确 2、查询时间正常 |
||
|
备注 |
|
||
3.4、5亿条记录中查询1条记录
|
项目 |
HBase |
用例名称 |
1亿条记录中查询1条记录 |
|
用例编号 |
HBase-pre-014 |
重要性 |
重要 |
|
测试目的 |
查询HBase的5亿条记录中的1条记录，查询1条记录正确、时间正常 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 测试程序运行正常 |
||
|
测试步骤 |
1、客户端向HBase写入5亿条记录 2、通过测试程序发送查询1条记录请求: 3、记录查询1条记录时长 |
||
|
预期结果 |
1、查询结果正确 2、查询时间正常 |
||
|
备注 |
|
||
3.5、5亿条记录中查询10条记录
|
项目 |
HBase |
用例名称 |
5亿条记录中查询10条记录 |
|
用例编号 |
HBase-pre-015 |
重要性 |
重要 |
|
测试目的 |
查询HBase的5亿条记录中的10条记录，查询10条记录正确、时间正常 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 测试代码运行正常 |
||
|
测试步骤 |
1、客户端向HBase写入5亿条记录 2、运行测试程序发送查询10条记录请求: 3、记录查询10条记录时长 |
||
|
预期结果 |
1、查询结果正确 2、查询时间正常 |
||
|
备注 |
|
||
3.6、10亿条记录中查询1000条记录
|
项目 |
HBase |
用例名称 |
10亿条记录中查询1000条记录 |
|
用例编号 |
HBase-pre-016 |
重要性 |
重要 |
|
测试目的 |
查询HBase的10亿条记录中的1000条记录，查询1000条记录正确、时间正常 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 测试代码运行正常 |
||
|
测试步骤 |
1、客户端向HBase写入10亿条记录 2、运行测试程序发送查询1000条记录请求: 3、记录查询1000条记录时长 |
||
|
预期结果 |
1、1000条记录查询结果正确 2、1000条记录查询时间正常 |
||
|
备注 |
|
||
3.7、20亿条记录中查询1000条记录
|
项目 |
HBase |
用例名称 |
20亿条记录中查询1000条记录 |
|
用例编号 |
HBase-pre-017 |
重要性 |
重要 |
|
测试目的 |
查询HBase的20亿条记录中的1000条记录，查询1000条记录正确、时间正常 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 测试代码运行正常 |
||
|
测试步骤 |
1、客户端向HBase写入20亿条记录 2、运行测试程序发送查询1000条记录请求: Select (1000个RowKey) 3、记录查询1000条记录时长 |
||
|
预期结果 |
1、1000条记录查询结果正确 2、记下1000条记录查询时间 |
||
|
备注 |
|
||
3.8、40亿条记录中查询1000条记录
|
项目 |
HBase |
用例名称 |
40亿条记录中查询1000条记录 |
|
用例编号 |
HBase-pre-018 |
重要性 |
重要 |
|
测试目的 |
查询HBase的40亿条记录中的1000条记录，查询1000条记录正确、时间正常 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 测试代码运行正常 |
||
|
测试步骤 |
1、客户端向HBase写入40亿条记录 2、运行测试程序发送查询1000条记录请求: Select (1000个RowKey) 3、记录查询1000条记录时长 |
||
|
预期结果 |
1、1000条查询结果正确 2、统计1000条记录查询时间 |
||
|
备注 |
|
||
3.9、80亿条记录中查询1000条记录
|
项目 |
HBase |
用例名称 |
80亿条记录中查询1000条记录 |
|
用例编号 |
HBase-pre-019 |
重要性 |
重要 |
|
测试目的 |
查询HBase的80亿条记录中的1000条记录，查询1000条记录正确、时间正常 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 测试代码运行正常 |
||
|
测试步骤 |
1、客户端向HBase写入80亿条记录 2、运行测试程序发送查询1000条记录请求: Select (1000个RowKey) 3、记录查询1000条记录时长 |
||
|
预期结果 |
1、1000条记录查询结果正确 2、统计1000条记录查询时间 |
||
|
备注 |
|
||
3.10、100亿条记录中查询1000条记录
|
项目 |
HBase |
用例名称 |
100亿条记录中查询1000条记录 |
|
用例编号 |
HBase-pre-020 |
重要性 |
重要 |
|
测试目的 |
查询HBase的100亿条记录中的1000条记录，查询1000条记录正确、时间正常 |
||
|
预置条件 |
HBase运行正常 客户端运行正常 测试代码运行正常 |
||
|
测试步骤 |
1、客户端向HBase写入100亿条记录 2、运行测试程序发送查询1000条记录请求: Select (1000个RowKey) 3、记录查询1000条记录时长 |
||
|
预期结果 |
1、1000条记录查询结果正确 2、统计1000条记录查询时间 |
||
|
备注 |
|
||
