HBase 是Hadoop生态里重要一员。对HBase的调优,对节约成本,提升用户体验有重要意义。
然而,对一个复杂系统而言,参数调整是否有效,是否符合预期,需要时间来验证,这个过程可能漫长。为了快速验证参数调整是否符合预期,我们可以通过压测集群的方法,模拟上层业务对集群的访问,从而加快验证参数调整是否符合预期。
因此,本文首先给出HBase参数调优原则,接着给出压测方法,检验参数调优是否合理。
在EMR实例中的HBase集群默认参数,并没有调为最优。我们强烈推荐用户在使用前,根据自己使用场景,调整参数。
客户端优化通常考虑如下方面:
HBase是基于LSM-Tree模型实现的。在Server端处理写请求路径上,依次需要写WAL日志、写MemTable。 除了基础优化步骤外,还可以从如下方面着手:
在HBase集群Server端处理读请求的路径上,BlockCache 内存容量、HFile文件数量对读请有影响。除了基本的优化操作外,还可以从如下方面着手:
在HBase设计中,提供了读写分离的机制。所谓读写分离,即读写请求分别有不同线程池处理,从而避免相互影响。这样将资源合理分配给不同类型操作,从而满足复杂的业务需求。
具体而言,HBase 提供了Read\Write\Scan三种类型的操作,这三种类型操作可以委托给不同类型的线程池,通过参数来控制每个线程池中线程数量,从而起到分配资源的目的。参数说明如下:
例如,hbase.ipc.server.callqueue.handler.factor = 1 hbase.ipc.server.callqueue.read.ratio = 0.6 hbase.ipc.server.callqueue.scan.ratio = 0.5
配置下,表示有60%的线程处理Read\Scan操作(其中30%处理Read操作,30%处理Scan操作),40%线程处理Write操作。
HBase 进程运行在JVM中,JVM 内存回收机制对Java进程有着重要影响。由于GC优化和具体业务场景息息相关,并没有一种“合理的”参数,满足一切使用场景。在这里,推荐一些基本的参数
在正式压测HBase集群前,需要完成一些准备工作,包括压测节点,压测集群,压测工具。
YCSB(Yahoo! Cloud Serving Benchmark)是雅虎开源的用于测试新式数据库(主要为 NoSQL)性能的框架。
所谓压测节点,就是运行压测工具,向HBase集群发起请求的节点。通常,根据HBase集群规模,选择适当的压测节点数量。强烈建议,不要在部署有HBase 集群进程的节点充当压测节点,因为压测节点本身将占用部分资源,影响最终压测结果。
根据您业务需求,购买合适规格的EMR实例,并选择HBase组件。我们推荐使用高IO机型,配本地磁盘。
ycsb-0.13.0
ycsb-0.13.0/hbase12-binding
。EMR实例的HBase集群配置在master节点的/usr/local/server/hbase/conf
压测过程重要分两步,加载数据阶段,和压测阶段。
首先,要创建数据表,需要预先分配region到每一个RegionServer节点上。具体执行如下命令:
create 't', 'c', {SPLITS => (1..n_splits).map {|i| "user#{1000+i*(9999-1000)/n_splits}"}} ```
### 3.1 加载数据
在ycsb工作目录运行命令加载数据到HBase集群。进入ycsb工作目录,执行如下命令:
```bin/ycsb load hbase12 -P workloads/workloada -threads 32 -p table=t -p columnfamily=c -s```
YCSB提供了6中不同类型的Workload. 这些Workload通过参数化不同请求类型,以及读写比,模拟HBase 常见的使用场景。例如,有读写比为1:1的Workload, 有只读不写的Workload, 有read-update-wrie 的Workload等。
可以更加自己需求,调整workload文件中参数取值。
YCSB提供了丰富的参数配置接口。诸如压测节点工作线程数量,是否在控制台打印压测日志等。
执行压测命令和加载数据命令很相似:
bin/ycsb run hbase12 -P workloads/workloada -threads 32 -p table=t -p columnfamily=c -s
3.5 分析结果在压测任务结束后,ycsb工具会输出如下数据:
OVERALL, RunTime(ms), 2097940
OVERALL, Throughput(ops/sec), 4766.580550444722
TOTAL_GCS_PS_Scavenge, Count, 3108
TOTAL_GC_TIME_PS_Scavenge, Time(ms), 9733
TOTALGC_TIME%_PS_Scavenge, Time(%), 0.4639312849747848
TOTAL_GCS_PS_MarkSweep, Count, 0
TOTAL_GC_TIME_PS_MarkSweep, Time(ms), 0
TOTALGC_TIME%_PS_MarkSweep, Time(%), 0.0
TOTAL_GCs, Count, 3108
TOTAL_GC_TIME, Time(ms), 9733
TOTALGC_TIME%, Time(%), 0.4639312849747848
READ, Operations, 4466688
READ, AverageLatency(us), 6131.758938614024
READ, MinLatency(us), 137
READ, MaxLatency(us), 781823
READ, 95thPercentileLatency(us), 8695
READ, 99thPercentileLatency(us), 18527
READ, Return=OK, 4466688
READ, Return=NOT_FOUND, 534718
CLEANUP, Operations, 64
CLEANUP, AverageLatency(us), 552.96875
CLEANUP, MinLatency(us), 3
CLEANUP, MaxLatency(us), 34687
CLEANUP, 95thPercentileLatency(us), 17
CLEANUP, 99thPercentileLatency(us), 187
READ-FAILED, Operations, 534718
READ-FAILED, AverageLatency(us), 5304.548231030188
READ-FAILED, MinLatency(us), 233
READ-FAILED, MaxLatency(us), 767999
READ-FAILED, 95thPercentileLatency(us), 7539
READ-FAILED, 99thPercentileLatency(us), 16247
UPDATE, Operations, 4998594
UPDATE, AverageLatency(us), 7364.818844259005
UPDATE, MinLatency(us), 660
UPDATE, MaxLatency(us), 799231
UPDATE, 95thPercentileLatency(us), 10583
UPDATE, 99thPercentileLatency(us), 26927
UPDATE, Return=OK, 4998594
通过输出信息,可以看到此次压测情况。
参考文献
1(https://cloud.tencent.com/developer/article/1005560)
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。