EMR之HBASE集群参数调优与压测

0. 概述

HBase 是Hadoop生态里重要一员。对HBase的调优，对节约成本，提升用户体验有重要意义。

然而，对一个复杂系统而言，参数调整是否有效，是否符合预期，需要时间来验证，这个过程可能漫长。为了快速验证参数调整是否符合预期，我们可以通过压测集群的方法，模拟上层业务对集群的访问，从而加快验证参数调整是否符合预期。

因此，本文首先给出HBase参数调优原则，接着给出压测方法，检验参数调优是否合理。

1. HBase 参数调优

在EMR实例中的HBase集群默认参数，并没有调为最优。我们强烈推荐用户在使用前，根据自己使用场景，调整参数。

1.0 基础优化

• 1) 确保负载均衡，主要有如下手段：
• a) 创建表时候预先分配Region，使得Region均匀分布在不同的RegionServer上。
• b) 合理设计RowKey, 避免数据倾斜。
• c) 适当重新调整分裂热点Region, 将子Region调整到不同数据节点上，保持集群负载均衡。
• 2) 数据压缩：数据压缩是一种节约存储空间可行方案，我们推荐使用Snappy 数据压缩算法；
• 3) 评估集群负载，适时扩容集群；

1.1 客户端优化

客户端优化通常考虑如下方面：

• 1) 批量读写，节约网络带宽，提高吞吐量；
• 2) 增大Scan缓存，使得一次RPC返回更多数据量，道理同1)。
• 3) 避免全表扫描，这是非常耗时的动作；
• 4) 离线任务，关闭BlockCache, 节约内存；

1.2 服务端写操作优化

HBase是基于LSM-Tree模型实现的。在Server端处理写请求路径上，依次需要写WAL日志、写MemTable。 除了基础优化步骤外，还可以从如下方面着手：

• 1) 调整WAL：写WAL日志，涉及IO操作，关闭WAL日志，将提升集群写性能；
• 2) 增大MemTable内存: 增大MemTable的内存，避免频繁刷盘阻塞写操作。

1.3 服务端读操作优化

在HBase集群Server端处理读请求的路径上，BlockCache 内存容量、HFile文件数量对读请有影响。除了基本的优化操作外，还可以从如下方面着手：

• 1) 集群请求低峰期，执行Majar Compaction，降低HFile数量，消除脏数据；
• 2) 增大BlockCache 内存，增大热点数据命中率，避免不必要的IO操作；

1.4 服务端读写分离优化

在HBase设计中，提供了读写分离的机制。所谓读写分离，即读写请求分别有不同线程池处理，从而避免相互影响。这样将资源合理分配给不同类型操作，从而满足复杂的业务需求。

具体而言，HBase 提供了Read\Write\Scan三种类型的操作，这三种类型操作可以委托给不同类型的线程池，通过参数来控制每个线程池中线程数量，从而起到分配资源的目的。参数说明如下：

• 1) hbase.ipc.server.callqueue.handler.factor: 设置为1，HBase将Read\Write\Scan分别由单独线程池处理；
• 2) hbase.ipc.server.callqueue.read.ratio: 取值介于0与1直接。表示Read\Scan操作占用线程数量与Write操作线程数量比值；
• 3) hbase.ipc.server.callqueue.scan.ratio： 表示在Read\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操作。

1.5 服务端GC优化

HBase 进程运行在JVM中，JVM 内存回收机制对Java进程有着重要影响。由于GC优化和具体业务场景息息相关，并没有一种“合理的”参数，满足一切使用场景。在这里，推荐一些基本的参数

• -XX:+UseG1GC： 使用G1GC垃圾回收器，适合服务端大内存java进程；
• -Xms，-Xmx: 为Hbase进程分配合理的内存量。注意要为系统、其他进程预留一定物理内存；
• -XX:MaxDirectMemorySize：启用堆外内存。
• -XX:G1HeapRegionSize=32m: 默认值1m, 推荐32m

2. 压测准备工作

在正式压测HBase集群前，需要完成一些准备工作，包括压测节点，压测集群，压测工具。

YCSB（Yahoo! Cloud Serving Benchmark）是雅虎开源的用于测试新式数据库（主要为 NoSQL）性能的框架。

2.0 准备压测节点

所谓压测节点，就是运行压测工具，向HBase集群发起请求的节点。通常，根据HBase集群规模，选择适当的压测节点数量。强烈建议，不要在部署有HBase 集群进程的节点充当压测节点，因为压测节点本身将占用部分资源，影响最终压测结果。

2.1 准备压测HBase集群

根据您业务需求，购买合适规格的EMR实例，并选择HBase组件。我们推荐使用高IO机型，配本地磁盘。

2.2 压测工具

• 1) YCSB官网下载可执行程序包，选择0.13.0版本；
• 2) 解压可执行程序包，假设解压后目录名称为ycsb-0.13.0
• 3) 复制腾讯云EMR实例中的HBase集群配置到ycsb-0.13.0/hbase12-binding。EMR实例的HBase集群配置在master节点的/usr/local/server/hbase/conf

3. 压测与结果分析

压测过程重要分两步，加载数据阶段，和压测阶段。

3.0 创建数据表

首先，要创建数据表，需要预先分配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```

3.2 选择Workload

YCSB提供了6中不同类型的Workload. 这些Workload通过参数化不同请求类型，以及读写比，模拟HBase 常见的使用场景。例如，有读写比为1:1的Workload, 有只读不写的Workload, 有read-update-wrie 的Workload等。

可以更加自己需求，调整workload文件中参数取值。

3.3 配置其他参数

YCSB提供了丰富的参数配置接口。诸如压测节点工作线程数量，是否在控制台打印压测日志等。

3.4 执行压测

执行压测命令和加载数据命令很相似：

bin/ycsb run hbase12 -P workloads/workloada -threads 32 -p table=t -p columnfamily=c -s3.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)

2(https://hbase.apache.org/book.html)

3(https://github.com/brianfrankcooper/YCSB/wiki)