[[420780]]

大家好，我是一哥，曾經那一晚經歷過一次大數據平臺遷移，回想起來歷歷在目!

1.背景

大數據集群遷移這件事，不知道有多少同學做過(反正我是第一次)。我說的不是簡單的把一個集群的數據拷貝到另一個集群上，我指的是整個數據處理平臺與相關的前臺業務的遷移工作，是從一個機房到另一個機房。

剛開始接到遷移通知，想著沒什么問題，一個月應該可以搞定(畢竟無知者無畏)。可是當著手寫遷移方案時，自己卻不知道從何處下手。當第一次操作遷移討論時，面對大家提出的問題，我才明白這是一個艱巨的任務啊，很有可能是一項吃力不討好的工作。但是現有小機房，已經沒有增加機柜的位置了。面對業務不斷的增長，以及來自各個業務方的數據處理需求以及每天收到的幾百條CPU告警和幾十條存儲告警，我們已經別無選擇，就是一個字，干!

此次遷移是異地遷移。并且此次遷移帶寬有限制。按照剛開始提供的帶寬計算，遷移全部數據需要近半年。比較麻煩的事，遷移過程中還存在歷史數據刷新問題，也就是說有部分數據，你遷了也是白遷。

2.方案

要說遷移這件事多么有趣，還得從那個寒冬晚上說起，只記得那天晚上的風特別的冷!一群小伙伴接到遷移平臺的通知后，就開始了準備工作。大家每天晚上都是一通討論，當時我們還提出了，直接下架服務器，搬遷到新機房，上架、上電、啟動、恢復業務。現在想想也是不能這樣做了，畢竟服務器這東西還是很脆弱的。(萬一起不來，根本沒法回退啊)。

還是老老實實的遷移數據吧。

整理思路就是，新集群部署完成后，先遷移歷史近三個月數據進行各系統測試。測試后無問題，開始同步所有歷史數據，待上線前，同步當前時段未遷移的數據。有沒有很簡單，是的，看著很簡單。但是，我司大數據平臺還和外部業務系統存在著千絲萬縷的關系，還有些業務停服的時間窗口在一小時內，這好難了。畢竟不是一人吃飽，全家不餓啊。

先來看一下我司大數據平臺現狀吧，一張圖，如下：

[[420781]]

此次遷移涉及前端和后端，前端門戶、報表、指標等需要在新環境重新部署，并且遷移歷史數據，其中消息隊列，關系型數據庫等數據也需要遷移。后端主要是Hadoop、MPP和ETL工具。此次遷移并不是現有機器完全的遷移，實時處理業務暫不在本次遷移中。所以遷移內容和未遷移之前是否存在耦合，也是遷移工作需要解決的一部分。

在預期的時間內，風險可控的完成大數據平臺遷移工作，單依賴網絡這點帶寬同步數據是不行的，所有我們制定了大致遷移流程如下：

• 先梳理任務運行中所需要的表的最小周期數據。
• 根據梳理出來的任務正常運行所需要的最小周期數據的表，同步對應表的周期數據到新集群。
• 然后每天對比差異數據，增量同步差異數據。
• 使用同步的歷史數據，對新集群進行功能以及性能測試
• 開始對新老平臺進行任務并行運行
• 核對任務并行期間數據質量
• 根據核對質量，選擇時間窗口進行平臺切換

3.問題

在實際遷移過程中，哪部分最難?不是新集群搭建，不是數據同步，是如何保障遷移新集群后數據的準確性。可能你會說，這不是也很簡單，你不是兩個集群并行運行了，頭一天運行，第二天對比結果不就行了。然后現實總是殘酷的，你會發現運行后，新老平臺跑出來的數據差異太大。為什么呢?數據跑出來結果一樣的前提是數據源必須一致，運行程序也一致。然而兩者我們都很難保持一致。

首先是數據源，現有生產系統存在一個問題，就是數據每時每刻基本都在刷新，歷史數據的也在刷新，我們很難實時監控數據是什么時候刷新的，刷新了哪些歷史數據(依靠人工，難免會有疏漏，也需要大量的人力保障)。有些數據源結構甚至都會發生變化。運行的程序同樣也可能隨時發生變化。解決以上問題，我們就必須要對目前生產進行一些限制。數據源，我們每天會定時檢查，同步歷史差異。數據源表結構發生變化，我們通過解析變更的DDL語句在新環境進行同步。運行程序通過定時從老環境中拉取到新環境。

對于抽取生產庫的數據源，由于不同時刻抽取的數據可能不一致，就會導致最終并行跑出來的結果對比不一致，針對該部分數據源，直接采用同步數據方式來保障數據源一致。針對很多文件接口的任務，由于文件接口涉及文件采集后刪除源文件等操作，有人說修改為不刪除，新老并行跑進行驗證就好了。但是我們的文件接口太多了，修改的工作量較大，而且考慮到人工修改可能會影響到現在生產環境，就放棄了(此處提醒下各位在系統設計之初一定要考慮好方案，否則以后遷移一次，哭一次)，該部分數據源也是直接同步了。但是該部分接口涉及到的腳本和網絡策略，我們都要人工梳理出來，一個一個檢查驗證，雖然沒有并行每天跑，但是還是經過驗證的，心里也有底了。

本次遷移的總體目標

遷移期間，大數據平臺的服務不能長時間下線(最多小時級別)，不能對公司小時業務造成影響。

必須確保遷移完成后，影響生產業務的正確性和核心業務指標的正確性。

對于和外部系統重度耦合的業務，需要給業務方足夠的時間，盡量減少業務方改造工作量，必須有模擬割接驗證后才能上線。

本次遷移的原則

• 一切遷移工作和步驟，要以不影響線上業務為標準。
• 凡是可能出錯，不能一步做到位的環節，都必須要有事前驗證測試的手段。
• 能并行運行的業務盡量并行運行，核對數據無誤后，才具備割接條件。
• 遷移工作中，能自動化的自動化，不能自動化的，要給出梳理驗證標準，不能靠人工去猜。
• 要有回退方案，以防萬一。

保障了這么多，大家似乎看出來了最難的部分，就是數據準確性保障！其實遷移所做的一切都是為了讓遷移后，各個業務依然能夠回去準確的指標數據，而不是僅僅使用新環境。但是，還有一樣，我們最容易忽略的，就是操作步驟，我指的是真實割接時候的操作步驟，命令級別的。我們想要的效果就是割接當晚，任何一個人拿著操作步驟都能執行遷移過程。

4.總結 

現在想想這個太難了，雖然現在割接成功了，但是仍然不敢說已經達到這一標準。割接涉及主機、數據庫、后端、前端等操作人員，割接當晚出現有模塊沒有嚴格按照操作步驟執行，有團隊出現多業務操作步驟交叉而沒有提前溝通。所以，割接時一定要安排有經驗的，對系統整體較熟悉的同事在現場支撐，以防萬一啊！

本文轉載自微信公眾號「數據社」，可以通過以下二維碼關注。轉載本文請聯系數據社公眾號。