QCon北京「鸿蒙专场」火热来袭!即刻报名,与创新同行~ 了解详情
写点什么

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

  • 2020-06-18
  • 本文字数:2951 字

    阅读完需:约 10 分钟

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

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 元数据表并重写数据、挂载新的 coprocessor 等;

  2. 升级 master 节点;

  3. 升级 meta 分组;

  4. 依次升级业务分组;


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 服务及上下游生态的建设与维护。


本文转载自公众号滴滴技术(ID:didi_tech)。


原文链接


https://mp.weixin.qq.com/s?__biz=MzU1ODEzNjI2NA==&mid=2247492131&idx=1&sn=7dd0ea079f5290fe042da1d7b3a6597d&chksm=fc298c84cb5e0592390098c6746113e47794389c22b294d1b99575ebeec83a9733b3c525af1b&scene=27#wechat_redirect


2020-06-18 10:072156

评论 1 条评论

发布
用户头像
难度好大。
2020-06-22 10:31
回复
没有更多了
发现更多内容

SNZ资本的首席信息官Gavin确认出席Hack .Summit() 2024香港开发者大会!

TechubNews

聊聊Java 类属性与类方法的应用

伤感汤姆布利柏

Java 前端

亚马逊云科技为派拓网络打造数字安全平台产品组合

财见

教你如何用Keepalived和HAproxy配置高可用 Kubernetes 集群

华为云开发者联盟

开发 华为云 华为云开发者联盟

商品评价聚合:利用API从多个来源获取数据的详细指南

Noah

Web3.0区块链技术全流程方案:DApp项目开发、推广以及运营

区块链软件开发推广运营

dapp开发 区块链开发 链游开发 NFT开发 公链开发

云桌面跟远程桌面有什么区别?

青椒云云电脑

云桌面 云桌面方案 云桌面系统

云桌面系统厂家-青椒云

青椒云云电脑

云桌面 云桌面厂家 云桌面方案 云桌面系统

火山引擎弹性容器实例:从节点中心转型 Serverless 化架构的利器

极客天地

Supermicro 通过新基础设施解决方案,加速 5G 和电信云工作负载性能

财见

陆海×微帧,在海洋卫星传输环境下的极限视频压缩

微帧Visionular

视频编码 视频压缩

作为程序员,沟通能力是否重要?

小齐写代码

聚道云助力时尚巨头打通数据孤岛,实现全渠道管理升级!

聚道云软件连接器

案例分享

开班在即 | 测试开发名企定向培养训练营,手把手带你提升核心竞争力!

测吧(北京)科技有限公司

测试

SD-WAN对金融行业的重要性

Ogcloud

SD-WAN 企业网络 SD-WAN组网 SD-WAN服务商 SDWAN

PTS 3.0:开启智能化的压测瓶颈分析

阿里巴巴云原生

阿里云 云原生 压测

EMQX Enterprise 5.5 发布:新增 Elasticsearch 数据集成

EMQ映云科技

mqtt mqtt broker

破防了,谁懂啊家人们:记一次mysql问题排查

阿里技术

MySQL 索引 问题排查 表结构

超越传统:人工智能赋能的自动化测试新前景

测吧(北京)科技有限公司

测试

KaiwuDB 拿下 “物联之星” 双项殊荣

KaiwuDB

数据库 物联网

SD-WAN网络搭建技术:企业降本增效的首选

Ogcloud

SD-WAN 企业网络 SD-WAN组网 SD-WAN服务商 SDWAN

追踪Jira中项目成本与工时,更符合国人使用习惯——TimeWise工时管理

龙智—DevSecOps解决方案

DevOps DevSecOps Atlassian

前端:Vue2.0和Vue3.0的一些入门对比

秃头小帅oi

前端 低代码 js Vue 3 vue2

云桌面哪家好用?

青椒云云电脑

云桌面 云桌面厂家 云桌面解决方案

蒋安祥:巴拿马奖项评选指南与规程赢得企业界广泛认可

极客天地

Udemy 上最受欢迎的免费编程课程

秃头小帅oi

php 学习 React 课程 java

蜗牛游戏宣布利用AI技术提升其开发流程

财见

舞台LED显示屏与传统LED显示屏的区别

Dylan

LED显示屏 全彩LED显示屏 led显示屏厂家 户内led显示屏 舞台表演

滴滴HBase大版本滚动升级之旅_架构_唐天航_InfoQ精选文章