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