Hbase性能测试详细设计文档及用例Word格式文档下载.docx
《Hbase性能测试详细设计文档及用例Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《Hbase性能测试详细设计文档及用例Word格式文档下载.docx（19页珍藏版）》请在冰豆网上搜索。
即直接扫描整张表中所有行记录。
rowkey是按照字典序存储，因此，设计rowkey时，要充分利用这个排序特点，将经常一起读取的数据存储到一块，将最近可能会被访问的数据放在一块。
如果最近写入HBase表中的数据是最可能被访问的，可以考虑将时间戳作为rowkey的一部分，由于是字典序排序，所以可以使用Long.MAX_VALUE–timestamp作为rowkey，这样能保证新写入的数据在读取时可以被快速命中。
2.2、多HTable并发写
创建多个HTable客户端用于写操作，提高写数据的吞吐量，
2.3、HTable参数设置
2.3.1AutoFlush
通过调用HTable.setAutoFlush（false）方法可以将HTable写客户端的自动flush关闭，这样可以批量写入数据到HBase，而不是有一条put就执行一次更新，只有当put填满客户端写缓存时，才实际向HBase服务端发起写请求。
默认情况下autoflush是开启的。
2.3.2WriteBuffer
通过调用HTable.setWriteBufferSize（writeBufferSize）方法可以设置HTable客户端的写buffer大小，如果新设置的buffer小于当前写buffer中的数据时，buffer将会被flush到服务端。
其中，writeBufferSize的单位是byte字节数，可以根据实际写入数据量的多少来设置该值。
2.3.3WALFlag
在HBae中，客户端向集群中的RegionServer提交数据时（Put/Delete操作），首先会先写WAL（WriteAheadLog）日志（即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）方法可以根据一个指定的rowkey获取一行记录，同样HBase提供了另一个方法：
通过调用HTable.get（List）方法可以根据一个指定的rowkey列表，批量获取多行记录，这样做的好处是批量执行，只需要一次网络I/O开销，这对于对数据实时性要求高而且网络传输RTT高的情景下可能带来明显的性能提升。
3.4多线程并发读
在客户端开启多个HTable读线程，每个读线程负责通过HTable对象进行get操作。
3.5缓存查询结果
对于频繁查询HBase的应用场景，可以考虑在应用程序中做缓存，当有新的查询请求时，首先在缓存中查找，如果存在则直接返回，不再查询HBase；
否则对HBase发起读请求查询，然后在应用程序中将查询结果缓存起来。
至于缓存的替换策略，可以考虑LRU等常用的策略。
3.6Blockcache
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
硬件配置
序号
设备名称
数量
CPU
内存
硬盘
主控服务器
2
I2-2100/双核四线程
4G
500G
处理节点
7
I5-2320
16G
1T
网络配置
序号
设备型号
数量
千兆交换机
SD2008T
千兆连接口
10/100/1000BASE-T口
24
2.3测试工具
2.3.1Ganglia监控工具
Ganglia是设计用于检测数以千计的节点。
Ganglia的核心包含gmond、gmetad以及一个Web前端。
主要是用来监控系统性能，如：
cpu、mem、硬盘利用率，I/O负载、网络流量情况等，通过曲线很容易见到每个节点的工作状态，对合理调整、分配系统资源，提高系统整体性能起到重要作用。
2.4测试方法
HBase测试是采用YCSBbenchmark测试的，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）节点故障
项目
用例名称
主namenode宕机
用例编号
HBase-fun-001
重要性
重要
测试目的
验证主namenode宕机后,备namenode节点是否能正常转换为主节点，并且系统稳定运行
预置条件
1、HBase运行正常
2、客户端运行正常
测试步骤
1、客户端向HBase写数据
2、写数据过程中，构造主节点服务器故障：
重启（reboot）、网络异常、掉电、服务关闭
3、检测写入的数据是否丢失
预期结果
1、NameNode2自动切换为active，且系统稳定。
切换完成时间少于10s
2、数据写入成功
3、切换后写入的数据无丢失
备注
1.2、Hadoop（DataNode）节点故障
写数据过程中datanode节点宕机
HBase-fun-002
验证客户端向HBase写入数据过程中，将datanode故障情况下，测试写入的数据是否成功
HBase运行正常
客户端运行正常
设置副本数为2
2、写数据过程中，构造datanode节点服务器故障：
3、检测数据写入是否成功
写数据过程中，在机器宕机的那一瞬间写入的某个文件写失败，之后的数据写入成功
1.3、Hbase（Hmaster）节点故障
写数据过程中Hmaster节点宕机
验证客户端向HBase写入数据过程中，将Hmaster故障情况下，测试写入的数据是否成功
2、写数据过程中，构造Hmaster节点服务器故障：
1.4、Hbase（RegionServer）节点故障
写数据过程中RegionServer节点宕机
验证客户端向HBase写入数据过程中，将RegionServer故障情况下，测试写入的数据是否成功
2、写数据过程中，构造RegionServer节点服务器故障：
2、HBase入库性能
2.1、单客户端数据入库
单个客户端入库性能测试
HBase-pre-001
验证单个客户端向HBase中写数据，通过ganglia监控工具，获知单个客户端数据入库带宽
1、启用单个客户端向HBase连续写入5亿条数据
2、启用ganglia监控程序
3、记录数据入库速率
1、数据入库正确无误
2、数据入库速率正常
2.2、多客户端数据入库速率
多个客户端入库性能测试
HBase-pre-002
验证多个客户端向HBase中写数据，通过ganglia监控工具，获知多个客户端数据入库带宽
1、启用多个客户（不同服务器）并发向HBase写5亿条数据
2、启用ganglia系统监控程序
3、记录数据库入库速率
2、多个客户端数据入库速率正常
2.3、5000万条记录入库测试
HBase5000万条记录入库测试
HBase-pre-003
测试统计5000万条记录写到HBase中所用的时长
1、客户端通过Benchmark向HBase写入5000万记录
2、记录5000万条记录入库时长
1、记录入库正确
2、5000万条记录入库时长正常
2.4、1亿条记录入库测试
HBase中1亿条记录入库测试
HBase-pre-004
测试统计1亿条记录写到HBase中所用的时长
1、客户端通过Benchmark向HBase写入1亿条记录
2、记录1亿条记录入库时长
2、1亿条记录入库时长正常
2.5、5亿条记录入库测试
HBase中5亿条记录入库测试
HBase-pre-005
测试统计5亿条记录写到HBase中所用的时长
1、客户端通过Benchmark向HBase写入5亿条记录
2、记录5亿条记录入库时长
2、5亿条记录入库时长正常
2.6、10亿条记录入库测试
HBase中10亿条记录入库测试
HBase-pre-006
测试统计10亿条记录写到HBase中所用的时长
1、客户端通过Benchmark向HBase写入10亿条记录
2、记录10亿条记录入库时长
2、10亿条记录入库时长正常
2.7、20亿条记录入库测试
HBase中20亿条记录入库测试
HBase-pre-007
测试统计20亿条记录写到HBase中所用的时长
1、客户端通过Benchmark向HBase写入20亿条记录
2、记录20亿条记录入库时长
2、20亿条记录入库时长正常
2.8、40亿条记录入库测试
HBase中40亿条记录入库测试
HBase-pre-008
测试统计40亿条记录写到HBase中所用的时长
1、客户端通过Benchmark向HBase写入40亿条记录
2、记录40亿条记录入库时长
2、40亿条记录入库时长正常
2.9、80亿条记录入库测试
HBase中80亿条记录入库测试
HBase-pre-009
测试统计80亿条记录写到HBase中所用的时长
1、客户端通过Benchmark向HBase写入80亿条记录
2、记录80亿条记录入库时长
1、数据入库正确
2、80亿条记录入库时长正常
2.10、100亿条记录入库测试
HBase中100亿条记录入库测试
HBase-pre-010
测试统计100亿条记录写到HBase中所用的时长
1、客户端通过Benchmark向HBase写入100亿条记录
2、记录100亿条记录入库时长
2、100亿条记录入库时长正常
3、HBase查询性能测试
3.1、5000万记录中查询10条记录
从5000万记录中查询10条记录
HBase-pre-011
查询HBase的5000万条记录中的10条记录，查询10条记录正确、时间正常
1、客户端向HBase写入5000万条记录，其中1条命中
2、通过测试程序发送查询记录请求:
3、记录查询时长
1、查询结果正确
2、查询时间正常
3.2、1亿条记录中查询1条记录
1亿条记录中查询1条记录
HBase-pre-012
查询HBase的1亿条记录中的1条记录，查询1条记录正确、时间正常
1、客户端向HBase写入1亿条记录
3.3、1亿条记录中查询10条记录
1亿条记录中查询10条记录
HBase-pre-013
查询HBase的1亿条记录中的10条记录，查询10条记录正确、时间正常
2、发送数据查询10条记录请求:
3、记录查询10条记录时长
3.4、5亿条记录中查询1条记录
HBase-pre-014
查询HBase的5亿条记录中的1条记录，查询1条记录正确、时间正常
测试程序运行正常
1、客户端向HBase写入5亿条记录
2、通过测试程序发送查询1条记录请求:
3、记录查询1条记录时长
3.5、5亿条记录中查询10条记录
5亿条记录中查询10条记录
HBase-pre-015
查询HBase的5亿条记录中的10条记录，查询10条记录正确、时间正常
测试代码运行正常
2、运行测试程序发送查询10条记录请求:
3.6、10亿条记录中查询1000条记录
10亿条记录中查询1000条记录
HBase-pre-016
查询HBase的10亿条记录中的1000条记录，查询1000条记录正确、时间正常
1、客户端向HBase写入10亿条记录
2、运行测试程序发送查询1000条记录请求:
3、记录查询1000条记录时长
1、1000条记录查询结果正确
2、1000条记录查询时间正常
3.7、20亿条记录中查询1000条记录
20亿条记录中查询1000条记录
HBase-pre-017
查询HBase的20亿条记录中的1000条记录，查询1000条记录正确、时间正常
1、客户端向HBase写入20亿条记录
Select（1000个RowKey）
2、记下1000条记录查询时间
3.8、40亿条记录中查询1000条记录
40亿条记录中查询1000条记录
HBase-pre-018
查询HBase的40亿条记录中的1000条记录，查询1000条记录正确、时间正常
1、客户端向HBase写入40亿条记录
Select（1000个Row
升级会员 