背景
大數據集群遷移這件事，不知道有多少同學做過(反正我是第一次)。我說的不是簡單的把一個集群的數據拷貝到另一個集群上，我指的是整個數據處理平台與相關的前台業務的遷移工作，是從一個機房到另一個機房。
剛開始接到遷移通知，想着沒什么問題，一個月應該可以搞定(畢竟無知者無畏)。可是當着手寫遷移方案時，自己卻不知道從何處下手。當第一次操作遷移討論時，面對大家提出的問題，我才明白這是一個艱巨的任務啊，很有可能是一項吃力不討好的工作。但是現有小機房，已經沒有增加機櫃的位置了。面對業務不斷的增長，以及來自各個業務方的數據處理需求以及每天收到的幾百條CPU告警和幾十條存儲告警，我們已經別無選擇，就是一個字，干！
此次遷移是異地遷移。並且此次遷移帶寬有限制。按照剛開始提供的帶寬計算，遷移全部數據需要近半年。比較麻煩的事，遷移過程中還存在歷史數據刷新問題，也就是說有部分數據，你遷了也是白遷。
方案
要說遷移這件事多么有趣，還得從那個寒冬晚上說起，只記得那天晚上的風特別的冷！一群小伙伴接到遷移平台的通知后，就開始了准備工作。大家每天晚上都是一通討論，當時我們還提出了，直接下架服務器，搬遷到新機房，上架、上電、啟動、恢復業務。現在想想也是不能這樣做了，畢竟服務器這東西還是很脆弱的。（萬一起不來，根本沒法回退啊）。
還是老老實實的遷移數據吧。 
整理思路就是，新集群部署完成后，先遷移歷史近三個月數據進行各系統測試。測試后無問題，開始同步所有歷史數據，待上線前，同步當前時段未遷移的數據。有沒有很簡單，是的，看着很簡單。但是，我司大數據平台還和外部業務系統存在着千絲萬縷的關系，還有些業務停服的時間窗口在一小時內，這好難了。畢竟不是一人吃飽，全家不餓啊。
先來看一下我司大數據平台現狀吧，一張圖，如下：
此次遷移涉及前端和后端，前端門戶、報表、指標等需要在新環境重新部署，並且遷移歷史數據，其中消息隊列，關系型數據庫等數據也需要遷移。后端主要是Hadoop、MPP和ETL工具。此次遷移並不是現有機器完全的遷移，實時處理業務暫不在本次遷移中。所以遷移內容和未遷移之前是否存在耦合，也是遷移工作需要解決的一部分。
在預期的時間內，風險可控的完成大數據平台遷移工作，單依賴網絡這點帶寬同步數據是不行的，所有我們制定了大致遷移流程如下：
-
先梳理任務運行中所需要的表的最小周期數據。
-
根據梳理出來的任務正常運行所需要的最小周期數據的表，同步對應表的周期數據到新集群。
-
然后每天對比差異數據，增量同步差異數據。
-
使用同步的歷史數據，對新集群進行功能以及性能測試
-
開始對新老平台進行任務並行運行
-
核對任務並行期間數據質量
-
根據核對質量，選擇時間窗口進行平台切換
問題
在實際遷移過程中，哪部分最難？不是新集群搭建，不是數據同步，是如何保障遷移新集群后數據的准確性。可能你會說，這不是也很簡單，你不是兩個集群並行運行了，頭一天運行，第二天對比結果不就行了。然后現實總是殘酷的，你會發現運行后，新老平台跑出來的數據差異太大。為什么呢？數據跑出來結果一樣的前提是數據源必須一致，運行程序也一致。然而兩者我們都很難保持一致。
首先是數據源，現有生產系統存在一個問題，就是數據每時每刻基本都在刷新，歷史數據的也在刷新，我們很難實時監控數據是什么時候刷新的，刷新了哪些歷史數據（依靠人工，難免會有疏漏，也需要大量的人力保障）。有些數據源結構甚至都會發生變化。運行的程序同樣也可能隨時發生變化。解決以上問題，我們就必須要對目前生產進行一些限制。數據源，我們每天會定時檢查，同步歷史差異。數據源表結構發生變化，我們通過解析變更的DDL語句在新環境進行同步。運行程序通過定時從老環境中拉取到新環境。
對於抽取生產庫的數據源，由於不同時刻抽取的數據可能不一致，就會導致最終並行跑出來的結果對比不一致，針對該部分數據源，直接采用同步數據方式來保障數據源一致。針對很對文件接口的任務，由於文件接口涉及文件采集后刪除源文件等操作，有人說修改為不刪除，新老並行跑進行驗證就好了。但是我們的文件接口太多了，修改的工作量較大，而且考慮到人工修改可能會影響到現在生產環境，就放棄了（此處提醒下各位在系統設計之初一定要考慮好方案，否則以后遷移一次，哭一次），該部分數據源也是直接同步了。但是該部分接口涉及到的腳本和網絡策略，我們都要人工梳理出來，一個一個檢查驗證，雖然沒有並行每天跑，但是還是經過驗證的，心里也有底了。
本次遷移的總體目標
-
遷移期間，大數據平台的服務不能長時間下線（最多小時級別），不能對公司小時業務造成影響。
-
必須確保遷移完成后，影響生產業務的正確性和核心業務指標的正確性。
-
對於和外部系統重度耦合的業務，需要給業務方足夠的時間，盡量減少業務方改造工作量，必須有模擬割接驗證后才能上線。
本次遷移的原則
-
一切遷移工作和步驟，要以不影響線上業務為標准。
-
凡是可能出錯，不能一步做到位的環節，都必須要有事前驗證測試的手段。
-
能並行運行的業務盡量並行運行，核對數據無誤后，才具備割接條件。
-
遷移工作中，能自動化的自動化，不能自動化的，要給出梳理驗證標准，不能靠人工去猜。
-
要有回退方案，以防萬一。
保障了這么多，大家似乎看出來了最難的部分，就是數據准確性保障！其實遷移所做的一切都是為了讓遷移后，各個業務依然能夠回去准確的指標數據，而不是僅僅使用新環境。但是，還有一樣，我們最容易忽略的，就是操作步驟，我指的事真實割接時候的操作步驟，命令級別的。我們想要的效果就是割接當晚，任何一個人拿着操作步驟都能執行遷移過程。
現在想想這個太難了，雖然現在割接成功了，但是仍然不敢說已經達到這一標准。割接涉及主機、數據庫、后端、前端等操作人員，割接當晚出現有模塊沒有嚴格按照操作步驟執行，有團隊出現多業務操作步驟交叉而沒有提前溝通。所以，割接時一定要安排有經驗的，對系統整體較熟悉的同事在現場支撐，以防萬一啊。
歷史好文推薦