大数据集群迁移的那一夜是怎么过的|回忆录

原创
09/19 07:00
阅读数 1.8K

背景

大数据集群迁移这件事,不知道有多少同学做过(反正我是第一次)。我说的不是简单的把一个集群的数据拷贝到另一个集群上,我指的是整个数据处理平台与相关的前台业务的迁移工作,是从一个机房到另一个机房。

刚开始接到迁移通知,想着没什么问题,一个月应该可以搞定(毕竟无知者无畏)。可是当着手写迁移方案时,自己却不知道从何处下手。当第一次操作迁移讨论时,面对大家提出的问题,我才明白这是一个艰巨的任务啊,很有可能是一项吃力不讨好的工作。但是现有小机房,已经没有增加机柜的位置了。面对业务不断的增长,以及来自各个业务方的数据处理需求以及每天收到的几百条CPU告警和几十条存储告警,我们已经别无选择,就是一个字,干!

此次迁移是异地迁移。并且此次迁移带宽有限制。按照刚开始提供的带宽计算,迁移全部数据需要近半年。比较麻烦的事,迁移过程中还存在历史数据刷新问题,也就是说有部分数据,你迁了也是白迁。

方案

要说迁移这件事多么有趣,还得从那个寒冬晚上说起,只记得那天晚上的风特别的冷!一群小伙伴接到迁移平台的通知后,就开始了准备工作。大家每天晚上都是一通讨论,当时我们还提出了,直接下架服务器,搬迁到新机房,上架、上电、启动、恢复业务。现在想想也是不能这样做了,毕竟服务器这东西还是很脆弱的。(万一起不来,根本没法回退啊)。

还是老老实实的迁移数据吧。 

整理思路就是,新集群部署完成后,先迁移历史近三个月数据进行各系统测试。测试后无问题,开始同步所有历史数据,待上线前,同步当前时段未迁移的数据。有没有很简单,是的,看着很简单。但是,我司大数据平台还和外部业务系统存在着千丝万缕的关系,还有些业务停服的时间窗口在一小时内,这好难了。毕竟不是一人吃饱,全家不饿啊。

先来看一下我司大数据平台现状吧,一张图,如下: 

此次迁移涉及前端和后端,前端门户、报表、指标等需要在新环境重新部署,并且迁移历史数据,其中消息队列,关系型数据库等数据也需要迁移。后端主要是Hadoop、MPP和ETL工具。此次迁移并不是现有机器完全的迁移,实时处理业务暂不在本次迁移中。所以迁移内容和未迁移之前是否存在耦合,也是迁移工作需要解决的一部分。

在预期的时间内,风险可控的完成大数据平台迁移工作,单依赖网络这点带宽同步数据是不行的,所有我们制定了大致迁移流程如下:

  • 先梳理任务运行中所需要的表的最小周期数据。

  • 根据梳理出来的任务正常运行所需要的最小周期数据的表,同步对应表的周期数据到新集群。

  • 然后每天对比差异数据,增量同步差异数据。

  • 使用同步的历史数据,对新集群进行功能以及性能测试

  • 开始对新老平台进行任务并行运行

  • 核对任务并行期间数据质量

  • 根据核对质量,选择时间窗口进行平台切换

问题

在实际迁移过程中,哪部分最难?不是新集群搭建,不是数据同步,是如何保障迁移新集群后数据的准确性。可能你会说,这不是也很简单,你不是两个集群并行运行了,头一天运行,第二天对比结果不就行了。然后现实总是残酷的,你会发现运行后,新老平台跑出来的数据差异太大。为什么呢?数据跑出来结果一样的前提是数据源必须一致,运行程序也一致。然而两者我们都很难保持一致。

首先是数据源,现有生产系统存在一个问题,就是数据每时每刻基本都在刷新,历史数据的也在刷新,我们很难实时监控数据是什么时候刷新的,刷新了哪些历史数据(依靠人工,难免会有疏漏,也需要大量的人力保障)。有些数据源结构甚至都会发生变化。运行的程序同样也可能随时发生变化。解决以上问题,我们就必须要对目前生产进行一些限制。数据源,我们每天会定时检查,同步历史差异。数据源表结构发生变化,我们通过解析变更的DDL语句在新环境进行同步。运行程序通过定时从老环境中拉取到新环境。 

对于抽取生产库的数据源,由于不同时刻抽取的数据可能不一致,就会导致最终并行跑出来的结果对比不一致,针对该部分数据源,直接采用同步数据方式来保障数据源一致。针对很对文件接口的任务,由于文件接口涉及文件采集后删除源文件等操作,有人说修改为不删除,新老并行跑进行验证就好了。但是我们的文件接口太多了,修改的工作量较大,而且考虑到人工修改可能会影响到现在生产环境,就放弃了(此处提醒下各位在系统设计之初一定要考虑好方案,否则以后迁移一次,哭一次),该部分数据源也是直接同步了。但是该部分接口涉及到的脚本和网络策略,我们都要人工梳理出来,一个一个检查验证,虽然没有并行每天跑,但是还是经过验证的,心里也有底了。

本次迁移的总体目标

  1. 迁移期间,大数据平台的服务不能长时间下线(最多小时级别),不能对公司小时业务造成影响。

  2. 必须确保迁移完成后,影响生产业务的正确性和核心业务指标的正确性。

  3. 对于和外部系统重度耦合的业务,需要给业务方足够的时间,尽量减少业务方改造工作量,必须有模拟割接验证后才能上线。

本次迁移的原则

  • 一切迁移工作和步骤,要以不影响线上业务为标准。

  • 凡是可能出错,不能一步做到位的环节,都必须要有事前验证测试的手段。

  • 能并行运行的业务尽量并行运行,核对数据无误后,才具备割接条件。

  • 迁移工作中,能自动化的自动化,不能自动化的,要给出梳理验证标准,不能靠人工去猜。

  • 要有回退方案,以防万一。

保障了这么多,大家似乎看出来了最难的部分,就是数据准确性保障!其实迁移所做的一切都是为了让迁移后,各个业务依然能够回去准确的指标数据,而不是仅仅使用新环境。但是,还有一样,我们最容易忽略的,就是操作步骤,我指的事真实割接时候的操作步骤,命令级别的。我们想要的效果就是割接当晚,任何一个人拿着操作步骤都能执行迁移过程。

现在想想这个太难了,虽然现在割接成功了,但是仍然不敢说已经达到这一标准。割接涉及主机、数据库、后端、前端等操作人员,割接当晚出现有模块没有严格按照操作步骤执行,有团队出现多业务操作步骤交叉而没有提前沟通。所以,割接时一定要安排有经验的,对系统整体较熟悉的同事在现场支撑,以防万一啊。

历史好文推荐
  1. 从0到1搭建大数据平台之计算存储系统

  2. 从0到1搭建大数据平台之调度系统

  3. 从0到1搭建大数据平台之数据采集系统

  4. 如何从0到1搭建大数据平台


你点的每个 在看 ,我都认真当成了喜欢

本文分享自微信公众号 - 数据社(DataClub)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
1 收藏
分享
加载中
更多评论
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部