滴滴HBase大版本滚动升级之旅

桔妹导读：滴滴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服务及上下游生态的建设与维护。

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

滴滴技术 出品