滴滴在 HBase 性能与可用性上的探索与实践

桔妹导读：HBase 作为 Hadoop 生态中表现较为突出的分布式在线数据存储产品，在滴滴有着非常广泛的应用，但同样存在比较突出的短板问题——例如可用性较弱、毛刺严重等，一定程度上限制了它的业务边界。本文主要介绍在此背景下，HBase 团队近期进行的一些探索工作。

1. 背景

HBase 是一个基于 HDFS 的低成本、分布式 LSM 结构数据库，可以支持毫秒级别查询；支持海量的 PB 级的大数据存储，适用于高 QPS 的随机读写和前缀范围查询等场景。此外，优秀的开源环境使得 HBase 还可以支持丰富的上下游生态与离线任务。

目前在滴滴内部，HBase 基本覆盖了全部业务线，数据量 PB 规模，吞吐超千万级别；业务包含司乘轨迹、订单、特征工程、推荐引擎、IOT、APM 等各种场景，基于 HBase 的多模生态诸如 OLAP（Kylin）、时序（OpenTSDB）、时空（GeoMesa）、图（JanusGraph）亦均有应用。

2020 年下半年，HBase 团队逐渐将视野投向端上/类端上业务，希望能够承载更加重要的流量。然而对于 HBase 自身架构和实现而言，主要存在两方面痛点：

▍1.可用性问题

架构层面看，HBase 在 CAP 定理中选择了 C，以较弱的可用性为代价换取强一致性，数据层面依赖 HDFS 保证数据安全，计算层面 region 无副本。

这样当 region 迁移、分裂、合并、RS 宕机等情况发生时，对应 region 都会有短时不可用；而作为高吞吐的数据服务，客户端往往都会大量使用线程池，少量 region 不可用会迅速形成木桶短板，进而放大为整体 TPS 掉底。

而这种“预期内的”抖动、掉底，是无法满足互联网行业端上场景的可用性要求的。

社区提供的 region replica 功能一定程度上可以缓解这一问题，但一方面目前这个 feature 可靠性还不算高，社区仍在推进各种加固和改善，目测稳定的目标 release 版本可能要放到未发布的 3.0 了；另一方面端上服务需要双机房，保证容灾和降级，而 replica 是集群内的 region 副本，显然也不能支持。

▍2.毛刺问题

HBase 主要受 Java GC 和底层 HDFS 共用影响，HBase 的毛刺相对突出，是进一步提升性能的瓶颈点。

基于以上两个痛点问题，HBase 团队近半年进行了一些尝试与探索，主要是基于 replication 的客户端多路读功能 与 HBase-ZGC 应用实践，预期能够优化 HBase 的可用性与毛刺问题，简单分享给大家。

2. 基于 replication 的客户端多路读功

2020 年来，为提升 HBase 可用性，我们大体经历了两个阶段：

1. replication 主备

replication 是 HBase 的异步数据同步机制，和 MySQL 利用 Binlog 实现主从库类似，HBase 利用 WAL 实现主备集群的数据同步。大致流程为主集群记录写入的 WAL，并将数据异步发送给备集群，备集群接收数据并将其转换为 put/delete 操作，批量写入备集群。提供最终一致性保证。

图片来源：HBase 官方文档

detailed_information_about_cluster_replication

这一阶段存在的问题：

• 故障时用户有感知，需用户侧切读；
• 备集群利用率较低，资源闲置存在浪费；

2. replication + failover

failover 是滴滴 HBase 团队基于 replication 自研的增强 feature，架构如下图：

• 相比第一阶段，failover 可以基于 zk 实现服务切换，不需用户操作。但仍然存在用户有感知、备集群无法充分利用的问题；
• 基于以上背景，我们又开发了基于 replication 的客户端多路读功能，预期解决以下问题：
  • 故障时用户无感知；
  • 提升备集群利用率；
  • 打磨 HBase 毛刺；

▍1. 设计

整体设计参考 HDFS 的 hedgedRead 功能，客户端首先向主集群发起读请求，一定时间没有返回结果则并发向备集群发起请求，两者取先完成者返回。

实际上 HBase 的 regionReplica 也是类似的实现。

▍2.新增配置

▍3.性能测试

3.1 用例设计

1. 两个集群分别创建主备测试表，构建 replication
2. ycsb 打入 100w 测试数据
3. 测试组打开多路读，对照组关闭多路读，各发起 10w 次 scan
4. 客户端统计 max、P999、P99

3.2 测试结论

max 对比

P999 对比

P99 对比

多路读对于 max 和 P999 有较佳优化效果，可以有效打磨毛刺。

• 本文地址：滴滴在 HBase 性能与可用性上的探索与实践
• 本文版权归作者和AIQ共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出

▍4.未尽事项和思考

1. 多路读功能基于 replication 实现，因此只能实现最终一致性，备集群读到的数据有可能和主集群存在差异；
2. 目前此功能仅作用于查询，主集群宕机时，最新数据无法同步，因此备集群查询最新数据可能查询不到；
3. HBase 的 scan 操作可能分解为多次 RPC，由于相关 session 信息在不同集群间没有同步，数据也不能保证完全一致，因此多路读只在第一次 RPC 时生效，之后的请求会固定访问第一次 RPC 时最终使用的集群。

多路读本质上是多活建设，但 CAP 较难跨越，多活可以提供高可用能力，但强一致性很难得到保障。

但我们可以通过“让用户选择”的方式来解决这一问题：

• 方案一：多活 + 最终一致性
• 方案二：主备 + 强一致性

对于方案一，当前的多路读实现了读链路的多活，写链路仍有优化空间，例如提升 replication 效率、降低两集群间数据 lag 等；

对于方案二，可以基于社区的同步 replication 实现，此外 failover 的功能仍需我们做更多工作，实现更加智能的自动切换，降低用户感知。

***3. *** HBase-ZGC 应用实践

▍1.为什么要更换 GC 算法？

随着滴滴内部越来越多的端上和类端上业务使用 HBase 作为存储引擎，用户对 HBase 读写延迟稳定性的要求也越来越高，HBase 的 GC 毛刺问题尤为突出，G1 无法满足性能需求。

好消息是 JDK15 在 9 月 15 号正式发布，划时代的 ZGC 正式转正，我们决定尝试用 ZGC 来解决 GC 毛刺问题。

ZGC（The Z Garbage Collector）：ZGC 是 JDK11 之后发布的一款可伸缩的低延迟 JVM 垃圾收集器。

ZGC 官方的设计目标如下：

• Max pause times of a few milliseconds(*)
• Pause times do not increase with the heap or live-set size (*)
• Handle heaps ranging from a 8MB to 16TB in size

ZGC 是一个并发的、单代的、基于区域的、NUMA 感知的压缩收集器，Stop-the-world 阶段仅限于根扫描，因此 GC 暂停时间不会随堆或活动集（live set）的变大而增加。

ZGC 的核心设计原则是将 Load barriers 与染色对象指针结合使用，这使得 ZGC 能够在 Java 应用程序线程运行时执行并发操作，例如对象重定向。从 Java 线程的角度来看，在 Java 对象中加载引用字段的行为受到加载屏障的影响。除了对象地址之外，colored oops 还包含加载屏障使用的信息，以确定在允许 Java 线程使用指针之前是否需要采取某些操作。********

ZGC 相比 G1

• 更低延迟：GC 停顿时间更短，不超过 10ms
• 更大内存：堆内存支持范围更大（8MB-16TB）

SPECjbb 2015 基准测试，128G 堆，ZGC 的暂停时间远低于 G1

相较于 G1 只有写屏障没有读屏障，复制移动的过程需要 Stop the world，ZGC 通过读屏障、Remark 标记和重定向表来并发拷贝非 GC Roots 对象，尽可能的减少了 Stop the world。

官方的性能测试对比可以参考 JEP333。本文主要介绍 HBase 场景的 ZGC 应用实践，对 ZGC 的原理不展开介绍。

▍2.HBase 应用 ZGC 实践

2.1 选择 JDK 版本

由于需要在生产环境使用，而 Orace JDK 商业使用开始收费，所以我们需要一个免费版的 JDK。经过对比，我们最终选取了 AdoptOpenJDK 的 JDK15 版本。

1. AdoptOpenJDK 是社区（伦敦 JUG）维护版的 OpenJDK，提供预构建的二进制文件，主要维护 LTS 及最新版本；和 OpenJDK 一样，AdoptOpenJDK 也支持 GPL 协议且免费，不同的是 OpenJDK 只会由 Oracle 提供 6 个月的安全更新，而 AdoptOpenJDK 则由社区提供至少 4 年的免费长期支持（LTS）。
2. 选择 JDK15 的原因：

• JDK11 存在小概率 crash 的问题
• ZGC 在 JDK15 版本正式生产环境可用

2.2 编译 HBase（基于 AdoptOpenJDK15）

滴滴内部使用的 HBase 版本是基于社区 1.4.8 基础上开发的版本，不支持 JDK11 及以上版本的编译，所以需要解决一些编译问题。

社区 3.x 及 2.3.x 版本开始支持 JDK11，参考 HBASE-22972。在 1.4.8 版本的编译过程中，主要遇到了以下几类编译问题：

• 1. 部分类找不到或被删除，比如 javax.xml.ws.http.HTTPException。解决办法：找到替换类或依赖包；
• 2. 一些类不可读，比如 sun.nio.ch.DirectBuffer。解决办法：运行时添加--add-exports=java.base/sun.nio.ch=ALL-UNNAMED；
• 3. 依赖的组件包不支持 JDK15，如 Jetty、Jruby 等。解决办法：升级对应的组件到高版本；
• 4. 编译插件不支持 JDK15，如 maven-shade-plugin、extra-enforcer-rules 等。解决办法：升级对应的插件到高版本。

2.3 应用 ZGC 的效果：

1. 顺序读场景 ZGC 和 G1 性能表现对比

Scan 场景下，ZGC 的 P99 延迟降低 20%，P999 降低 40%。

2. 压力测试场景对比 ZGC 和 G1 的性能表现

构造写压力测试场景，RegionServer 的全局 Memstore 写满，触发 Upper Limit，G1GC 回收不过来，触发 Full GC，耗时超过 40s（ZK 会话的超时时间），RS 服务会宕机。

对比同等写入压力下，ZGC 99.93% 的回收时间都在 10ms 以内，只有 2 次在 10~20ms 之间，RS 服务未宕机。

备注：如果内存分配过快，ZGC 也可能会出现回收不过来的问题，这种情况下可以通过增大堆内存的方式缓解。

HBase 使用 ZGC 可以有效的降低了服务端 P99 及 P999 的延时，非常适合对延迟较敏感的业务场景。

3. 总结

HBase 在真正海量数据的离线应用场景下具备毋庸置疑的竞争力，但受其自身实现短板的限制，距离端上应用的标准还是存在一定距离的。滴滴 HBase 希望通过一系列优化手段，服务好离线业务的同时，未来可以接入更多的不涉及核心流程的线上/类线上业务，欢迎感兴趣的同学一起交流。

团队招聘

滴滴大数据架构离线引擎&HBase 团队主要负责滴滴集团大数据离线存储、离线计算、NoSQL 等引擎的开发与运维工作，通过持续应用和研发新一代大数据技术，构建稳定可靠、低成本、高性能的大数据基础设施，更多赋能业务，创造更多价值。

团队持续招聘 HDFS、YARN，Spark，HBase 等领域专家，参与滴滴大数据架构的建设工作，欢迎加入。

可投递简历到 diditech@didiglobal.com，邮件主题请命名为「姓名-应聘部门-应聘方向」。