桔妹导读：滴滴 HBase 团队日前完成了 0.98 版本 -> 1.4.8 版本滚动升级，用户无感知。新版本为我们带来了丰富的新特性，在性能、稳定性与易用性方便也均有很大提升。我们将整个升级过程中面临的挑战、进行的思考以及解决的问题总结成文，希望对大家有所帮助。

1. 背景

目前 HBase 服务在我司共有国内、海外共计 11 个集群，总吞吐超过 1kw+/s，服务着地图、普惠、车服、引擎、金融等几乎全部部门与业务线。

然而有一个问题持续困扰着我们：版本较社区落后较多——HBase 线上集群使用 0.98 版本，而社区目前最新的 release 版本为 2.3。这为我们的工作带来了很多额外的掣肘与负担，主要包括以下几点：

• 新特性引入成本极高：

0.98 版本可以算是 HBase 第一个稳定版本，但过于老旧，社区已经不再维护。想要 backport 新特性难度越来越大。

• 自研 patch 维护成本较高：

我们基于 0.98 版本有数十个大大小小的自研 patch，涵盖了从 label 分组、ACL 鉴权等大的 feature 到监控体系建设、审计日志优化等 Improvement 以及各种 bug fix。这些 patch 或是新版本中已支持但和我们实现有差异，或是由于版本差异过大无法合入社区，而且随着时间线的拉长，这种问题只会进一步恶化。

• 上层组件对于 HBase 存在一定需求：

得益于活跃的 HBase 生态圈，目前我们的用户使用形态也比较丰富，OLAP（Kylin）、时空索引（GeoMesa）、时序（OpenTSDB）、图（JanusGraph）等等场景不一而足。然而这些上层引擎无一例外，最新版本没有任何一款是依赖 0.98 版本 HBase 的。

因此对于 HBase 团队而言，升级迫在眉睫刻不容缓。

2. 挑战

首先简单介绍一下 HBase 的架构。HBase 是一个典型的主从结构——主备 Master 用于管理集群；RegionServer 用于响应处理用户读写请求；使用 ZooKeeper 保障集群内的一致性；节点间通过 RPC 通信；底层数据文件 HFile 存储于 HDFS 中。

此外 HBase 具有相当丰富的上下游生态，从以 StreamingSQL 为代表的实时任务到 Spark、MR 等批处理任务，通过下图可以得窥一二：

基于以上对集群架构和上下游生态的梳理，可以明确升级过程中我们主要面临的挑战有：

• RPC 接口兼容性问题：

升级不可能一蹴而就，因此我们需要确保所有 RPC 通信接口新旧版本完美兼容。

• HFile 兼容性问题；

不同版本中底层文件的数据格式有差异。1.4.8 版本默认使用 HFile v3，幸运的是 0.98 版本虽然使用 HFile v2，但已经可以兼容 v3。这样我们就不需要再额外 backport 相关 patch 到 0.98 版本。此外也是基于这方面的因素，官方文档中说明 0.98 版本想要升级到 2.x 版本，必须以 1.x 版本作为过渡——这也是我们本次升级选择 1.4.8 版本的原因。

• 自有 patch 兼容性问题：

如上文所述，我们需要全量梳理自研的数十个 patch——高版本是否有替代方案、替代方案是否兼容、是否需要移植到新版本、移植后的功能 / 性能 / 兼容性测试等。

• 上下游兼容性问题：

这一点大家看上图就好不需再赘述，每一种引擎的应用都需确保完全兼容。

• 可能引入的新问题：

HBase 的社区 release 版本迄今仍然非常活跃，但同时这也意味着可能存在很多潜藏的问题（事实上我们在升级过程中也遇到了，解决了并反哺给社区）——这一点其实没有什么太好的办法，只能要求我们随时紧密跟进社区，洞察新进展，即时发现问题修复问题。

基于以上这些挑战点，其实不难得出一个结论：我们需要设计并实施大量的前置准备工作以保证升级过程的可靠性，但这并不是什么坏消息，因为只要我们的准备工作足够细致完善，顺利升级的把握和信心也就越强——这个思路在我们今后的工作中也同样适用。

下面简单列举了我们完成的准备工作：

• Release Note review
• 自研 patch 移植与测试
• 基础功能测试、性能测试
• 高阶功能测试（Bulkload，Snapshot，Replication，Coprocessor 等）
• 社区后续小版本 patch 梳理跟进（截止目前实际合入的有 100 余个）
• 跨版本兼容性测试、RPC 接口兼容性梳理
• 全量测试集制定与实施，涵盖 HBase，Phoenix，GeoMesa，OpenTSDB，Janusgraph 等所有使用场景
• 软件包及配置文件准备

3. 升级方案

升级方案主要有两种：新建集群 + 数据迁移 和 滚动升级。

实际上滚动升级的方案一定是最优选，主要是出于对“release 版本仍然不够稳定”的担忧，我们一度有所犹豫。但最终基于“充分的准备与测试”带给我们的信心，最终我们仍然选择了滚动升级。

简单说明滚动升级的大致步骤：

1. 解决兼容性问题，主要体现在新建 rsgroup 元数据表并重写数据、
2. 挂载新的 coprocessor 等；
3. 升级 master 节点；
4. 升级 meta 分组；
5. 依次升级业务分组；

4. 实操及问题

我们从 19 年下半年启动了这一轮滚动升级的调研与准备，今年 3 月下旬正式开始线上操作，截至 5 月初已完成了国内外共计 9 个集群的升级工作，用户无感知。

在此期间我们也遇到了不少未解问题，这里摘取一个 Critical 问题做简单介绍：

region split 过程中叠加 RS 宕机引发数据丢失：

region split 是一个相当复杂的事务过程，大体可分为以下几步：

• RegionServer 开始执行 split 事务，在 ZK region-in-transition 下创建该 region 的节点，标记为 SPLIT；
• Master 监听到新的 split 节点，开始做一些初始化工作，并修改内存状态，完成后将节点状态改为 SPLITING；
• RS 监听到节点状态变为 SPLITING，开始正式执行 split——关闭父 region、创建子 region 文件夹并添加引用文件、修改 meta 表记录两个子 region 并将父 region 下线；
• 子 region 上线；

当父 region 下线、子 region 还未正式上线时 RegionServer 宕机，master 上的 ServerCrashProcedure 线程开始进行回滚，会将子 region 删除；此外 master 上还有一个 CatalogJanitor 线程做数据清理，正常 split 过程中由于 ZK 上存在对应节点，这个线程会被阻塞；然而由于 RS 宕机，临时节点也随之消失，该线程正常工作，判断 meta 表中父 region 已经下线，从而将父 region 删除——至此父子 region 皆被删除，导致数据丢失。
修复方案已提交社区：HBASE-23693

其它 patch list：

• HBASE-22620 修复 replication znode 积压问题；
• HBASE-21964 支持按 Throttle Type 取消 quota 设置；
• HBASE-24401 修复 hbase.server.keyvalue.maxsize=0 时 append 操作失败的问题；
• HBASE-24184 修复只使用 simple ACL 时 snapshot 相关操作的鉴权问题；
• HBASE-24485 Backport，优化堆外内存初始化时间；
• HBASE-24501 Backport，去除 ByteBufferArray 中非必要的锁；
• HBASE-24453 Backport，修复挪动表分组时缺少校验逻辑的问题；

5. 总结

本次升级工作从立项到完结耗时近一年，能够成功完成非常开心。一方面本次升级极大拉进了内部版本与社区 release 版本的距离，为更加良性的版本迭代及社区互动夯实了基础；另一方面新版本引入了诸多新特性，在稳定性、易用性方面都为我们带来了更为广阔的成长空间；更重要的是在这个过程中我们自身也沉淀出了一套系统的工作思路与方法论，期待后续可以更好的为业务赋能，为公司创造价值。

作者简介

滴滴资深猫奴，专注于 HBase 内核研发，滴滴 HBase 服务及上下游生态的建设与维护。

** 欢迎关注滴滴技术公众号！

滴滴技术 出品