大数据集群迁移的那一夜是怎么过的|回忆录
背景
大数据集群迁移这件事，不知道有多少同学做过(反正我是第一次)。我说的不是简单的把一个集群的数据拷贝到另一个集群上，我指的是整个数据处理平台与相关的前台业务的迁移工作，是从一个机房到另一个机房。
刚开始接到迁移通知，想着没什么问题，一个月应该可以搞定(毕竟无知者无畏)。可是当着手写迁移方案时，自己却不知道从何处下手。当第一次操作迁移讨论时，面对大家提出的问题，我才明白这是一个艰巨的任务啊，很有可能是一项吃力不讨好的工作。但是现有小机房，已经没有增加机柜的位置了。面对业务不断的增长，以及来自各个业务方的数据处理需求以及每天收到的几百条CPU告警和几十条存储告警，我们已经别无选择，就是一个字，干！
此次迁移是异地迁移。并且此次迁移带宽有限制。按照刚开始提供的带宽计算，迁移全部数据需要近半年。比较麻烦的事，迁移过程中还存在历史数据刷新问题，也就是说有部分数据，你迁了也是白迁。
方案
要说迁移这件事多么有趣，还得从那个寒冬晚上说起，只记得那天晚上的风特别的冷！一群小伙伴接到迁移平台的通知后，就开始了准备工作。大家每天晚上都是一通讨论，当时我们还提出了，直接下架服务器，搬迁到新机房，上架、上电、启动、恢复业务。现在想想也是不能这样做了，毕竟服务器这东西还是很脆弱的。（万一起不来，根本没法回退啊）。
还是老老实实的迁移数据吧。
整理思路就是，新集群部署完成后，先迁移历史近三个月数据进行各系统测试。测试后无问题，开始同步所有历史数据，待上线前，同步当前时段未迁移的数据。有没有很简单，是的，看着很简单。但是，我司大数据平台还和外部业务系统存在着千丝万缕的关系，还有些业务停服的时间窗口在一小时内，这好难了。毕竟不是一人吃饱，全家不饿啊。
先来看一下我司大数据平台现状吧，一张图，如下：
此次迁移涉及前端和后端，前端门户、报表、指标等需要在新环境重新部署，并且迁移历史数据，其中消息队列，关系型数据库等数据也需要迁移。后端主要是Hadoop、MPP和ETL工具。此次迁移并不是现有机器完全的迁移，实时处理业务暂不在本次迁移中。所以迁移内容和未迁移之前是否存在耦合，也是迁移工作需要解决的一部分。
在预期的时间内，风险可控的完成大数据平台迁移工作，单依赖网络这点带宽同步数据是不行的，所有我们制定了大致迁移流程如下：
先梳理任务运行中所需要的表的最小周期数据。
根据梳理出来的任务正常运行所需要的最小周期数据的表，同步对应表的周期数据到新集群。
然后每天对比差异数据，增量同步差异数据。
使用同步的历史数据，对新集群进行功能以及性能测试
开始对新老平台进行任务并行运行
核对任务并行期间数据质量
根据核对质量，选择时间窗口进行平台切换
问题
在实际迁移过程中，哪部分最难？不是新集群搭建，不是数据同步，是如何保障迁移新集群后数据的准确性。可能你会说，这不是也很简单，你不是两个集群并行运行了，头一天运行，第二天对比结果不就行了。然后现实总是残酷的，你会发现运行后，新老平台跑出来的数据差异太大。为什么呢？数据跑出来结果一样的前提是数据源必须一致，运行程序也一致。然而两者我们都很难保持一致。
首先是数据源，现有生产系统存在一个问题，就是数据每时每刻基本都在刷新，历史数据的也在刷新，我们很难实时监控数据是什么时候刷新的，刷新了哪些历史数据（依靠人工，难免会有疏漏，也需要大量的人力保障）。有些数据源结构甚至都会发生变化。运行的程序同样也可能随时发生变化。解决以上问题，我们就必须要对目前生产进行一些限制。数据源，我们每天会定时检查，同步历史差异。数据源表结构发生变化，我们通过解析变更的DDL语句在新环境进行同步。运行程序通过定时从老环境中拉取到新环境。
对于抽取生产库的数据源，由于不同时刻抽取的数据可能不一致，就会导致最终并行跑出来的结果对比不一致，针对该部分数据源，直接采用同步数据方式来保障数据源一致。针对很对文件接口的任务，由于文件接口涉及文件采集后删除源文件等操作，有人说修改为不删除，新老并行跑进行验证就好了。但是我们的文件接口太多了，修改的工作量较大，而且考虑到人工修改可能会影响到现在生产环境，就放弃了（此处提醒下各位在系统设计之初一定要考虑好方案，否则以后迁移一次，哭一次），该部分数据源也是直接同步了。但是该部分接口涉及到的脚本和网络策略，我们都要人工梳理出来，一个一个检查验证，虽然没有并行每天跑，但是还是经过验证的，心里也有底了。
本次迁移的总体目标
迁移期间，大数据平台的服务不能长时间下线（最多小时级别），不能对公司小时业务造成影响。
必须确保迁移完成后，影响生产业务的正确性和核心业务指标的正确性。
对于和外部系统重度耦合的业务，需要给业务方足够的时间，尽量减少业务方改造工作量，必须有模拟割接验证后才能上线。
本次迁移的原则
一切迁移工作和步骤，要以不影响线上业务为标准。
凡是可能出错，不能一步做到位的环节，都必须要有事前验证测试的手段。
能并行运行的业务尽量并行运行，核对数据无误后，才具备割接条件。
迁移工作中，能自动化的自动化，不能自动化的，要给出梳理验证标准，不能靠人工去猜。
要有回退方案，以防万一。
保障了这么多，大家似乎看出来了最难的部分，就是数据准确性保障！其实迁移所做的一切都是为了让迁移后，各个业务依然能够回去准确的指标数据，而不是仅仅使用新环境。但是，还有一样，我们最容易忽略的，就是操作步骤，我指的事真实割接时候的操作步骤，命令级别的。我们想要的效果就是割接当晚，任何一个人拿着操作步骤都能执行迁移过程。
现在想想这个太难了，虽然现在割接成功了，但是仍然不敢说已经达到这一标准。割接涉及主机、数据库、后端、前端等操作人员，割接当晚出现有模块没有严格按照操作步骤执行，有团队出现多业务操作步骤交叉而没有提前沟通。所以，割接时一定要安排有经验的，对系统整体较熟悉的同事在现场支撑，以防万一啊。