[[420780]]

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

1.背景

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

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

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

2.方案

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

還是老老實實的遷移數(shù)據(jù)吧。

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

先來看一下我司大數(shù)據(jù)平臺現(xiàn)狀吧，一張圖，如下：

[[420781]]

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

在預(yù)期的時間內(nèi)，風(fēng)險可控的完成大數(shù)據(jù)平臺遷移工作，單依賴網(wǎng)絡(luò)這點帶寬同步數(shù)據(jù)是不行的，所有我們制定了大致遷移流程如下：

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

3.問題

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

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

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

本次遷移的總體目標(biāo)

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

必須確保遷移完成后，影響生產(chǎn)業(yè)務(wù)的正確性和核心業(yè)務(wù)指標(biāo)的正確性。

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

本次遷移的原則

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

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

4.總結(jié) 

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

本文轉(zhuǎn)載自微信公眾號「數(shù)據(jù)社」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系數(shù)據(jù)社公眾號。