浅析华为云基于 HBase MTTR 上的优化实践

本文分享自华为云社区《华为云在HBase MTTR上的优化实践》，作者： 搬砖小能手。

随着 HBase 在华为云的广泛应用，HBase 的数据节点规模也越来越大。最新版本的 MRS 可支持的单集群 HBase 数据节点规模可达到 1024 节点，可支持的 region 数量可达到 200w+。面对如此大规模的节点数量，集群的 MTTR 也面临着巨大的挑战。

首先介绍一下 HBase 故障恢复涉及的几个主要 Procedure：

• ServerCrashProcedure：处理单个 RegionServer 的恢复的 Procedure 任务，是所有其他相关任务的 Root Procedure；

• SplitWALProcedure：处理单个 WAL 文件数据恢复的 Procedure 任务；

• TransitRegionStateProcedure：处理单个 RegionServer 上下线的 Procedure 任务。

RegionServer 节点故障恢复流程(基于 2.x 内核）

当 HMaster 检测到 RegionServer 故障后，会创建一个 ServerCrashProcedure 任务处理 RegionServer 的故障恢复。

该 Procedure 任务主要处理的事务包括 WAL Split 和 Region Assign：

• 其中 WAL Split 由 Sub Procedure：SplitWALProcedure 负责。每个 WAL 文件对应一个 Procedure，所以一个 ServerCrashProcedure 可能存在多个 SplitWALProcedure；

• Region Assign 则由 Sub Procedure：TransitRegionStateProcedure 负责。每个 region 对应一个 Procedure，因此一个 ServerCrashProcedure 也会存在多个 TransitRegionStateProcedure。

由此可以看出，一个 RegionServer 节点的恢复，中间会涉及到大量的 Procedure 任务，下面我们介绍一下华为云的 HBase 这对这部分所做的一些优化实践。

优化一，异步 ServerCrashProcedure

前面提到 ServerCrashProcedure 会包含多个 SplitWALProcedure 和 TransitRegionStateProcedure，这两种 Procedure 在 ServerCrashProcedure 里面是串行执行的，也就是说 TransitRegionStateProcedure 只有在所有 SplitWALProcedure 任务执行完成之后才会开始执行，在 WAL Split 流程结束之前，整个 ServerCrashProcedure 会一直占用 Procedure 的线程资源并等待。

在大集群的场景下，由于 HMaster 的 Procedure 线程池资源有限，这样会导致有大量的 ServerCrashProcedure 任务在队列中等待。

针对这种情况，我们讲 ServerCrashProcedure 任务改为异步执行，在执行 WAL Split 过程中，将 ServerCrashProcedure 重新放回队列并释放资源给其他待执行的任务。当 WAL Split 执行完成后，再重新唤醒该任务并继续提交执行 TransitRegionStateProcedure。

优化前：MTTR = (Avg SCP * RS Count) / (hbase.master.procedure.threads)

优化后：MTTR = (Avg Split time) + (RS Count * Avg Assign time)/ (hbase.master.procedure.threads)

优化二，Split WAL to HAR

通过测试，我们发现在 WAL Split 阶段会产生大量的文件 IO，主要是因为 WAL Split 阶段会生成大量的 recovered.edits 文件。因此，在大集群下，这部分的开销会导致 HDFS 的 NameNode 成为瓶颈。

对此，我们利用 Hadoop 提供的 HAR file 对生成的小文件进行优化，大大减少文件 IO 的开支，达到 MTTR 优化的目的。

我们以单个 RegionServer 20 个 WAL+2000 个 region 来举例：

通过 HAR 优化，单个 RS 的 IO 次数将由 2000 次读+2000 次写减少为 3 次读+3 次写。单个 RS 生成的文件数据也由 40000 个减少为 20 个。

最终在测试环境通过对 100 个 RS，每个 RS 20 个 WAL+2000 个 region 的规模进行对比测试，HDFS 的的 IO 负载下降了 70%(RPC 请求数从 640 万下降到 150 万左右)，MTTR 的时间则从 103 分钟下降到 26 分钟。

优化三，Batch TRSP

由于 TransitRegionStateProcedure 只负责处理一个 Region，大集群下的 region 往往都在几十万甚至更多，这样的话，HBase 恢复过程中会产生大量的 TransitRegionStateProcedure 任务。为了减少大量 Procedure 所带来的任务开销，我们优化了 TransitRegionStateProcedure，允许一个 Procedure 任务处理一个 RegionServer 上所有的 region assign。这样不仅减少了 Procedure 任务的数量，还大大减少了 HMaster 跟 RegionServer 的 RPC 开销。

点击关注，第一时间了解华为云新鲜技术~