专栏首页数据社大数据集群迁移的那一夜是怎么过的|回忆录

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

背景

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

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

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

方案

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

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

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

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

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

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

  • 先梳理任务运行中所需要的表的最小周期数据。
  • 根据梳理出来的任务正常运行所需要的最小周期数据的表,同步对应表的周期数据到新集群。
  • 然后每天对比差异数据,增量同步差异数据。
  • 使用同步的历史数据,对新集群进行功能以及性能测试
  • 开始对新老平台进行任务并行运行
  • 核对任务并行期间数据质量
  • 根据核对质量,选择时间窗口进行平台切换

问题

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

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

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

本次迁移的总体目标

  1. 迁移期间,大数据平台的服务不能长时间下线(最多小时级别),不能对公司小时业务造成影响。
  2. 必须确保迁移完成后,影响生产业务的正确性和核心业务指标的正确性。
  3. 对于和外部系统重度耦合的业务,需要给业务方足够的时间,尽量减少业务方改造工作量,必须有模拟割接验证后才能上线。

本次迁移的原则

  • 一切迁移工作和步骤,要以不影响线上业务为标准。
  • 凡是可能出错,不能一步做到位的环节,都必须要有事前验证测试的手段。
  • 能并行运行的业务尽量并行运行,核对数据无误后,才具备割接条件。
  • 迁移工作中,能自动化的自动化,不能自动化的,要给出梳理验证标准,不能靠人工去猜。
  • 要有回退方案,以防万一。

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

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

历史好文推荐

  1. 从0到1搭建大数据平台之计算存储系统
  2. 从0到1搭建大数据平台之调度系统
  3. 从0到1搭建大数据平台之数据采集系统
  4. 如何从0到1搭建大数据平台

本文分享自微信公众号 - 数据社(DataClub),作者:数据社

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-09-19

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 一文了解数据湖引擎

    数据湖引擎是一种开源软件解决方案或云服务,它通过一组统一的api和数据模型为分析工作负载的各种数据源提供关键功能。数据湖引擎解决了快捷访问、加速分析处理、保护和...

    数据社
  • 数据中台设计方法论

    横向规划即在数据中台规划初期,需要打通企业各个业务系,打破数据孤岛现象。其实就是我们建设数据仓库的阶段。比如电信业务,我们要把客户、账务、客服、营销等业务板块打...

    数据社
  • 数据挖掘从入门到放弃(二):决策树

    “ 上篇内容介绍的是线性回归和逻辑回归模型,输入输出是连续值,分类模型的输出是一个有限集合,本篇介绍决策分类树算法”

    数据社
  • 深度长文:中国产业大迁移全景图

    中国产业大迁移并没有发生在传统产业,而是发生在新兴产业。传统制造在出清过程中向低成本、高效率地区集聚。新兴制造向地理纵深发展的过程中,中部核心二线城市群逐渐崛起...

    钱塘数据
  • 现代操作系统部分章节笔记二、进程与线程三、存储管理

    二、进程与线程 1.进程 1.进程模型: 1.有自己的程序地址空间,程序计数器、寄存器和变量当前值。 2.切换进程的时候程序计数器、寄存器会装载到真正的相应物...

    何时夕
  • PHP中用Trait封装单例模式的实现

    确保某一个类只有一个实例,不能重复实例,只能它自己实例化,而且向整个系统提供这个实例。

    砸漏
  • 【案例】重庆市金融工作办公室:大数据监测预警非法集资平台

    近年来,随着国家对金融市场管控政策的不断调整以及互联网金融的快速发展,非法集资的犯罪手段和形势发生了很大变化。仅在2016年,全国检察机关公诉部门受理非法集资案...

    数据猿
  • Apache IoTDB 随笔 - IoTDB核心技术剖析

    【摘要】Gartner指出赋能边缘是2020年十大战略技术趋势之一,5G加速IoT领域的发展,物联网设备数据的收集,存储和计算需求与日俱增。Apache IoT...

    Apache IoTDB
  • 在CEPH管理节点查看 ceph pool 中一个镜像的信息

    查看镜像 [root@node1 ~]# rbd ls images a56330e7-79d7-4639-a68f-366ac344bfe2 eccfee07...

    院长技术
  • 搭建一个Hexo博客

    0x00 背景 一直想搭建一个自己的博客,之前在Aliyun虚拟主机上搭了一个WordPress+MySQL的个人博客。后来维护成本太大,主机和域名都没有续费被...

    WeaponX

扫码关注云+社区

领取腾讯云代金券