大數據集群遷移這件事，不知道有多少同學做過。我說的不是把一個集群的數據備份到另一個集群上。我指的是整個數據平臺與大數據相關的所有集群及業(yè)務的遷移工作，從一個機房到另一個機房。

具體范圍可能包括：從離線計算集群到實時計算集群；從存儲，計算組件，到作業(yè)調度，開發(fā)平臺服務；從底層數據同步到上層業(yè)務遷移。要求：不能影響業(yè)務，幾乎沒有停服預算。。。

這事，這要求，但凡玩過大數據平臺的同學，應該都不難想象，一定是個吃力不討好，還要背故障的苦差事。不幸的是，這樣的苦差事，出于各種各樣的原因，最近兩年來，我們一共干了三次。。。

所以，這篇文章，我打算和大家一起討論分享一下那些不堪回首的歲月里，我們遷移過的集群。以備哪一天，萬一，你也攤上事了，也好有所準備，看看有那些工作需要做的，盡量不要死得太過悲慘。

都有哪些麻煩事

要說這事有多苦，那得從解放前的那個晚上。。。哦，不，底層的環(huán)境開始向上說起。

集群和機房外部環(huán)境問題

歷數三次搬遷工作，一次是同城機房搬遷，另外兩次是異地機房搬遷。其中一次同城和一次異地，機房間有10-20Gb不等的專線帶寬可供使用；另外一次異地搬遷，機房間只有大概1Gb的公網帶寬。。。

需要搬遷的集群的整體規(guī)模，大概在200到400個節(jié)點之間，所涉及到的集群類型，包括，HDFS／HBase等存儲集群，以及Yarn／Storm／Spark等計算集群

數據量呢，具備專線環(huán)境的這兩次搬遷，基本上集群上的歷史全量數據按單拷貝來算大概2-3個PB，占用HDFS集群容量6-7個P左右，而集群每日的數據增量規(guī)模大概在十幾到幾十個TB的樣子。

可以粗略估算一下，如果全部歷史數據走網絡傳輸，純粹的拷貝傳輸動作，平均跑滿10Gb帶寬的話，大概要花費二十幾天的時間才能拷貝完成2P的數據，如果這期間數據拷貝出了問題。。。而做一次單日的增量拷貝動作，根據數據量變化大小的不同，大概也要花費3-8個小時的時間。

那么如何在可接受的時間和空間資源內，及時，正確的完成數據的同步工作呢？

平臺自身組件和服務依賴問題

講完集群外部環(huán)境問題，接下來看看開發(fā)平臺自身的組件和服務依賴。

我司的大數據開發(fā)平臺，自身組件眾多，和外部系統(tǒng)也有著千絲萬縷的關聯(lián)。

以離線批處理業(yè)務流程為例：

• 首先，會有數據采集系統(tǒng)負責從各種外部數據源比如，日志，DB，消息隊列中以全量或增量的方式將數據采集到集群中來，
• 其次會有調度系統(tǒng)將各種不同類型的作業(yè)分發(fā)到不同的Worker和集群上去執(zhí)行，而作業(yè)的來源，包括周期性調度的作業(yè)，也包括從開發(fā)平臺上發(fā)起的臨時作業(yè)，還包括通過我們對外提供的服務接口，由外部業(yè)務系統(tǒng)通過程序自動觸發(fā)的周期或一次性作業(yè)
• 然后，會有數據交換系統(tǒng)將數據導出到其它各個目標數據源中，比如報表DB，各種業(yè)務DB，HBase集群，ES集群等等。
• 此外，平臺的報警監(jiān)控服務，消息通知服務，元數據管理服務，權限管控服務，數據可視化服務，數據質量監(jiān)控服務等等，往往也是互相依賴的。

實時業(yè)務流程和離線業(yè)務流程相比，整體鏈路長度可能會更短，但是和外部系統(tǒng)的關聯(lián)倒并不見得更簡單，而服務的容錯性和對網絡帶寬延遲等方面的要求往往也會更高一些。

所以，如何保證遷移期間，服務的穩(wěn)定可靠，盡可能減少服務下線或不可用的時間，如何保證各種依賴服務的平滑過渡銜接呢？

業(yè)務模式和溝通配合問題

說完服務，接下來說說業(yè)務方使用我們服務的模式，又會給遷移工作帶來哪些麻煩。

如果所有的業(yè)務都由平臺完全掌控，事情會好辦一些，但作為數據平臺基礎架構團隊，我們的定位是提供平臺服務，所以，絕大多數的業(yè)務都是由業(yè)務方透過我們的服務來自主運行和管理的。那就會存在服務用多用少，用好用壞的問題

比如，可能某個業(yè)務方的一個完整業(yè)務鏈路，一半的流程是和他們自身的業(yè)務系統(tǒng)緊耦合的，在它們自己的平臺和機器上運行，另一半的流程則零散的透過我們的服務來運行，甚至由于各種各樣的原因跳過我們的平臺調度體系和服務，直接使用底層的應用接口和集群進行交互（比如，具體的業(yè)務邏輯和數據處理邏輯強關聯(lián)，代碼邏輯無法拆分，不能模塊化或著不想重構改造成通過我們的服務接口來處理數據，直接讀寫HDFS，直接提交MR任務等等）

如果整個流程鏈路是自封閉的，自產自銷也就罷了，壞就壞在這些業(yè)務保不定還有些上下游依賴，需要和其它業(yè)務方的作業(yè)相串聯(lián)。更糟糕的是，有時候，這些上下游依賴方并沒有意識到對方的存在，再加上互聯(lián)網公司難免出現的業(yè)務變更，組織架構調整，工作交接，遇上這種情況，事情就更加嚴重了。

這種情況，往往很多業(yè)務就需要具體的業(yè)務方配合梳理或者改造才能順利完成遷移，可是業(yè)務方對這類工作一般都是拒絕的，很容易理解，大家都忙，都希望麻煩越少越好不是，你們遷移，別拖我們下水啊 ；）好吧，這怎么辦？也只能動之以情，曉之以公司大義了唄 ；）

總之，這種情況下，如何降低風險，確保業(yè)務在遷移過程中不會出現大的差錯，的確是個大問題。

業(yè)務邏輯和數據正確性問題

最后，是業(yè)務邏輯和由此帶來的數據正確性問題。遷移，不光遷，遷完以后，你得保證業(yè)務結果的正確性吧？

在海量數據的情況下，如何驗證數據，這本身已經是個很棘手的問題了，更糟糕的是，如果業(yè)務方自己都搞不清楚數據是否正確怎么辦？ 甚至同一個作業(yè)，在同樣的數據集上跑兩次，結果都不一樣，重跑作業(yè)也不冪等又怎么辦？再糟糕一點，連數據集自身的狀態(tài)，可能也和時間相關，隨時可能變化怎么辦？

所以，你如何驗證遷移的結果是正確的，或者有哪些業(yè)務是正確的？有多大的概率是正確的？誰能替結果負責？ 萬一某個業(yè)務真的有問題，能不能發(fā)現，怎么發(fā)現，具體又會是數據，腳本，集群哪個環(huán)節(jié)的問題？

那該怎么辦

總之，大數據平臺搬遷工作并不是光“集群” 搬遷 這么簡單，它是一個你享受過一次以后，就絕對不想再來一次的苦差事。然而，說這么多，并沒有什么用。日子再苦，也得過不是。接下來，讓我來針對上述具體問題，和大家一起探討一下應對的方式和幾次搬遷過程中的我們的經驗教訓。

總體目標和原則

日子怎么過，上述問題如何應對，取決于你的目標是什么。一旦決定了目標，為了順利達到，也就會有一些原則是不能輕易打破，要時時刻刻留心遵守的。

所以，我們的目標是：

• 整體遷移工作，一到兩個月的周期內完成
• 遷移期間，大數據平臺的各種服務不能長時間下線（最多小時級別），不能對公司業(yè)務造成影響。
• 必須確保遷移完成后，核心業(yè)務的正確性，不能靠運氣，要有足夠可靠的驗證手段和數據
• 對于和外部系統(tǒng)重度耦合的業(yè)務，需要給業(yè)務方足夠的時間，正確的環(huán)境和過渡手段分批逐步遷移
• 遷移過程，盡可能做到對多數業(yè)務方透明，減少需要業(yè)務方需要配合的工作

那么，原則有哪些呢：

• 一切遷移工作和步驟，不以難易為標準，以不對線上業(yè)務造成影響為標準
• 凡是可能出錯，不能一步做到位的環(huán)節(jié)，都必須要有事前驗證測試的手段
• 只要能夠雙跑的環(huán)節(jié)那就雙跑，寧可花費更多的精力準備并行方案，也不能寄希望于一切順利
• 具體的雙跑方案，要確保與最終完成遷移，停止雙跑后的流程最大限度的保持一致，減少切換帶來的變數。
• 不做一錘子買賣，直到完成集群切換，數據和業(yè)務正確性驗證完畢，正式開始對用戶提供服務之前，都要給自己留下后路，堅決不做任何不可逆的操作
• 過程和步驟，能自動化的自動化，不能自動化的，也要明確的文檔化和標準化，不能依靠臨場的隨機應變。

好吧，你可能會說，這些，不是廢話么，必需做到呀。。。是的，如果只是光站著說說的話，那的確如此。

但是當你真正面對這項棘手的工作的時候，你就隨時都有可能就把這些目標原則拋在腦后。畢竟，沒有人想要主動給自己找麻煩，所以，這個時候，你只有時刻告誡自己，如果不這么做，一旦出了問題，只會更加的麻煩 ；）

大致流程方案

要在預期的時間范圍內，風險和代價可控的完成遷移的工作，光靠跨機房網絡這點帶寬進行同步肯定是不現實的。所以，我們的整體遷移流程大致如下

• 分離歷史數據，在源機房內部搭建中轉集群，先做一次歷史大全量數據的拷貝工作，受數據量規(guī)模限制，只同步那些確定不經常變更的數據，然后下線中轉集群，物理搬遷到目標機房，再次上線同步到目標集群中
• 在歷史數據同步過程中，在目標機房搭建數據平臺的全套集群和服務，逐個驗證各個服務功能的正確性
• 完成初始的大全量數據拷貝工作后，開始通過網絡實施若干輪階段性小全量數據拷貝工作，目標是將數據同步時間逐步縮短到當天能同步完成截止前一天為止的數據（因為第一輪全量拷貝的同步周期會比較長，期間集群新增的數據無法在一天內透過網絡完成拷貝）
• 使用實際的歷史數據，驗證集群服務和性能
• 開始集群每日增量數據同步工作，同時，同步各種數據平臺服務自身的元數據信息和作業(yè)腳本信息，開啟作業(yè)雙跑流程
• 每日核心作業(yè)雙跑完畢后，對比兩邊平臺的產出結果，排查問題，存在問題，修復，并繼續(xù)下一輪雙跑工作，如此循環(huán)，直到結果驗證滿意為止。
• 正式切換各種對外服務的域名，接口，數據庫等到新機房，完成主要鏈路的遷移工作。
• 切換完畢后，保留原平臺整體業(yè)務按既有邏輯運轉一段時間，給部分因為各種原因無法雙跑或立刻切換的業(yè)務留下分批遷移的時間窗口。

上述方案，主要描述的是偏離線批處理業(yè)務的遷移流程，實時類業(yè)務，由于從業(yè)務邏輯的角度來看，往往無法在統(tǒng)一的時間點上整體切換，所以更加強調分批雙跑的流程。具體的遷移工作，也往往需要業(yè)務方根據自己的業(yè)務情況參與配合，因此流程上有些環(huán)節(jié)需要具體業(yè)務具體討論，這里就不再詳細闡述。

一些具體問題的分析和實踐

如何保證正確性？

你要問遷移工作中，哪部分工作最難？ 我可以很負責任的告訴你，不是海量數據的同步，也不是服務的搭建，甚至也不是與各種關聯(lián)業(yè)務方無止境的溝通工作。

實際上，上述工作，盡管工作量很大，但只要花時間，總是能做好的。而最難，也最容易被輕視的，是你如何確保遷移完畢后，作業(yè)運行結果的正確性？

你可能會想，這還不簡單，前面不都說了兩邊機房同步進行作業(yè)的雙跑么？那第二天比較作業(yè)運行的結果數據就好了啊，不對，查問題，查到對為止。。。然而，事情并沒有那么美好，暫且放下怎么比較結果不提，先讓我們來看看結果真的可以用來比較么？

具體難在哪里

首先，雙跑結果可以比較驗證的前提，是數據源是一致的，但數據源往往做不到一致。。。

先來看看數據平臺是如何采集外部數據的？數據平臺的上游數據源有很多，但主要的來源是DB和日志，這兩種數據源根據業(yè)務場景不同，會有不同的采集方式

比如日志可能通過客戶端Agent采集后，寫入Kafka消息隊列，然后再消費解析寫入Hive。

而DB一方面可以通過Binlog采集進入消息隊列，走日志類似的流程消費，另一方面也可以直接連接DB，定時按一定的業(yè)務邏輯掃描源表后寫入數據平臺。采用哪種方式取決于數據量的大小，業(yè)務的更新模式等等。

那么問題來了，這些數據源是會隨著時間變化的，什么時候執(zhí)行這些數據采集任務的作業(yè)邏輯呢？任務執(zhí)行的時間不同，采集到的結果就不一樣啊，而兩邊集群具體某個任務的實際運行時間，受集群資源，前序任務運行時間等隨機因素的干擾，是無法精確控制的。

你會說，判斷數據源里信息的時間不就好了？ 這里面有三個問題：

• 有些數據源的采集邏輯里沒有可以用來做精確更新判斷時間的依據信息（不要問我為什么，DB設計，業(yè)務邏輯，歷史遺留問題等等都有可能）
• 自定義的清洗腳本邏輯，或者自認為對具體時間信息不敏感，或者沒有意識到會有問題，沒有做時間篩選。
• 流程中做了數據的時間篩選判斷，但客戶端會有晚到的數據，會有時間錯誤的數據，前置鏈路會有延遲的情況等等。

其次，同樣的數據源，雙跑的結果一致，還有一個要求是，作業(yè)運行邏輯是冪等的。 所謂冪等，這里包含了兩層意思：一是只要輸入源一致，作業(yè)每次運行的結果都因該是一樣的，二是重跑等情況對結果沒有影響。

但實際情況也不是這樣，不少作業(yè)邏輯并非冪等，運行兩次，結果并不能保證一致，一個集群上跑如此，在兩邊集群分別運行，那就更加無法保證了。

為什么會出現非冪等作業(yè)的情況？比如有些作業(yè)邏輯對數據進行排序，然后Limit取部分值，而排序用的字段組合，并非唯一標識一行數據的，也就是說在分布式計算的場景下，排序的結果順序可能是隨機的。再有，比如腳本運行的邏輯是把上游的增量數據寫入下游的全量表中，如果因為各種原因執(zhí)行了兩次，那就會寫入兩份數據等等。

雖然實際上這些差異可能對作業(yè)的業(yè)務邏輯結果的正確性不一定有很大影響（否則早就被發(fā)現并解決了），比如客戶端晚到的PV數據算昨天的還是今天的？每天都有部分移位的數據的話，量級上還補償上了呢。。。

但是這對雙跑結果的驗證，卻帶來了不小的麻煩，我們平臺上每天跑上萬個任務，產出幾千張結果表，雖然對應存在冪等或隨機問題的作業(yè)比例不會很高，但是經過作業(yè)依賴傳導以后，可能會對下游的大批作業(yè)都造成影響。那么如果幾千張結果表的數據全都不一樣（雖然差異有大有?。阌秩绾闻袛嗥脚_遷移結果的正確性？ 你顯然不可能去挨個人工分析每張表數據不一致的原因。

這時候，你可以對自己有信仰，相信只要集群服務是正確的，就OK了，管它結果如何呢，一定都是上述原因造成的，無傷大雅。

說實話，這的確是一種解決方案。前提是，你的業(yè)務方認可，領導也認可。問題在于你如何說服他們相信集群服務是正確的呢？請拿數據說話啊，可是數據都不一樣啊！你說差異是正常的，是由業(yè)務邏輯造成的，可是有差異的部分，業(yè)務方會替你背書么？我看懸，而你自己，說實話，也未必真的心里踏實。。。

可以采取的措施

所以，要降低風險，就必須盡可能的減少這兩者的干擾。實際上，我們前期做的大量準備工作都是圍繞著這個目標來的，具體方案上在幾次遷移過程中，也采用過不同的措施。詳細的細節(jié)不說，大致包括：

• 數據源部分不雙跑，單邊跑完，同步，再開始雙跑（然而，一來違反了雙跑和正式切換流程盡可能一致的原則，二來雙跑流程會變得冗長，影響正常業(yè)務和實施驗證的時間點，最近一次遷移，放棄了這種方案）
• 提前梳理非冪等腳本，邏輯上能夠修復的進行修復
• 日志采集鏈路，采用雙跑但是由源端單邊判斷和控制offset進度，確保兩邊數據的讀取范圍完全一致
• DB鏈路上，適當調整運行時間，盡量規(guī)避由于鏈路延遲，業(yè)務更新等造成的數據晚到／變更的情況

通過這些手段，減少源頭數據的差異和計算過程的隨機性，最終我們能夠做到主要鏈路三千五百多張表格，90%左右的表，驗證結果我們認為完全一致，無需人工判斷。99%的表，差異比例在0.1%以下，只需要重點人工檢查極少量差異較大的表的結果邏輯，和部分核心關鍵表格的具體數值，加快了結果驗證的效率和可靠性。

驗證比較方式

最后再來說一下如何比較結果數據。

首先，結果數據分為兩類，一類是在集群上的數據，主要以hive表為主。另一類是導出到外部數據源的數據，以DB為主，也有ES／HBASE等。

理論上你會說，那就一條一條的對比啊。但問題是，你如何確定用哪一條數據和哪一條數據進行對比？排序么？怎么排序？一方面，你不可能為每張表單獨構建比較邏輯，另一方面，海量的數據你是否有足夠的計算和存儲資源進行比較？你是否可能承擔相應的代價？

要確定哪條數據對比哪條數據，針對DB中的數據，我們的做法是拼合所有我們認為可能區(qū)別一行數據的字段，對兩邊的表進行Join，然后根據Join后的結果進行值的比對。這種做法并不完全精確，因為無法保證拼合用的字段就一定構成Unqiue key，能夠唯一標識每一行數據，還是可能造成錯位比較數據，將實際結果正確的表格誤判為結果不匹配。

而對于集群上的海量hive數據來說，這種操作，無論計算和存儲代價都是無法接受的。所以，集群上的hive表，我們只統(tǒng)計數據的條數和尺寸大小，你說這樣做會不會風險太大？其實還好，理論上，只要比較最終導出到DB的業(yè)務數據就OK了，畢竟下游數據如果一致，上游數據也應該是一致的，所以Count Hive表中的數據量大小，主要是為了方便溯源查找問題，同時快速判斷整體的差異情況。

最后，這些工作要執(zhí)行的順利，還需要盡可能的自動化，還要讓比較結果便于人工解讀，所以在實際操作中，我們還會自動將比較的結果格式化的導入到可視化平臺的報表中，這樣，業(yè)務方可以通過各種條件，過濾和篩選比較結果，便于快速定位問題。 總之，一切都是為了提高驗證效率，加快驗證速度。給問題修復，雙跑迭代和正式切換工作留出更充裕的時間。

集群數據同步拷貝

平臺搬遷，需要同步的數據源頭很多，包括 HDFS／HBase／DB 這里面有業(yè)務數據，也有各種服務和系統(tǒng)自身需要的配置，任務，元數據，歷史記錄等信息。

這里主要討論一下HDFS集群數據的拷貝同步，畢竟這是同步工作中，占比最大，也最麻煩的部分。

如何在兩個集群間同步HDFS集群數據，顯然，你不會去做硬盤拷貝的動作。因為集群上的數據是在持續(xù)變化的，而且，還有元數據映射關系要處理呢。

玩過一點HDFS集群的同學應該都了解，HDFS集群自身提供了一個distcp工具來做集群間的數據拷貝工作。但是，真正用這個工具實踐過整個集群規(guī)模的數據拷貝工作的同學，估計就是鳳毛麟角了。為什么這么說，因為這個工具有很大的局限性。無論谷歌，stackoverflow，還是郵件列表，你幾乎看不到大規(guī)模搬遷的實際案例。

所以，distcp工具最大的問題是什么？ 它最大的問題是慢！ 不是拷貝文件速度慢，而是拷貝任務的啟動速度和收尾速度慢！

至于為什么慢，就要來看看distcp的工作原理和流程了。

Distcp在執(zhí)行拷貝工作前，會先根據指定的目錄路徑比較兩邊集群的文件狀態(tài)，生成需要新增／修改／刪除的文件列表內容，這個過程包括遍歷目錄樹，比較文件元數據信息（比如時間戳，尺寸，CRC校驗值等等）。生成的結果提交執(zhí)行MR任務執(zhí)行，然后，當數據全部拷貝完成以后，還要執(zhí)行結果校驗，元數據信息同步之類的工作。同步哪些元數據信息取決于你的執(zhí)行distcp時指定的參數，比如文件owner，權限，時間戳，拷貝數等等。通常情況下，做集群遷移工作，這些信息都是要同步的。

在Distcp的執(zhí)行流程中，開始和收尾的很多步驟，都是單機執(zhí)行的。。。所以當集群的規(guī)模大到一定程度的時候（比如我們集群PB級別的容量，億級別的文件對象），這兩步動作就會變得異常緩慢。在我們的集群中，往往需要2-3個小時的啟動和收尾時間。（這還是在一些步驟社區(qū)已經打過多線程補丁，配置過參數以后，否則會需要4-8小時的啟動時間）

所以，用Distcp來做歷史全量數據的同步，問題不大，但是要在數據增量同步階段，進行快速同步迭代，就比較困難了。而我們的目標是做到最大限度不影響線上業(yè)務，那么同步流程就會希望做到盡可能快速的迭代，最后一輪增量同步動作加上各種DB元數據同步和準備工作，必須在一個小時內完成。

為了達到這個目標，我們參考distcp的代碼，自己開發(fā)了數據同步拷貝的工具，主要針對distcp的問題，將一些單機執(zhí)行的流程進行了調整，分散到Map任務中并行的執(zhí)行，同時調整和簡化了同步過程中的一些工作步驟（比如拷貝完成后的CRC校驗，出錯的概率非常非常低，萬一拷貝出錯了，下一輪同步的時候覆蓋掉或者再同步一次就好了），這樣準備和收尾時間可以做到只需要半小時就能完成。整體一輪增量同步所需時間，在最后一輪增量數據很少的情況下，可以滿足一小時內完成的目標。

實際的同步工作，我們前期通過distcp完成了歷史數據的同步，后續(xù)集群范圍的增量數據同步通過自己開發(fā)的這個工具定時自動循環(huán)執(zhí)行來完成。而如果有臨時的小范圍的數據拷貝動作，則還是通過distcp工具來完成（因為我們的同步工具，業(yè)務邏輯設計得比較固定）

當然，除了上面說的迭代速度的問題，數據同步工作中還有很多其它的問題要考慮，比如：

• 有些數據是不需要／不能同步的，那么需要過濾掉
• 數據拷貝過程中源頭數據發(fā)生了變化怎么辦？（實際上Distcp后期的版本還提供了基于集群Snapshot來拷貝和驗證的機制，我們其中一次遷移使用過這個機制，也有很多具體問題需要解決）
• 出于各種原因，在一些場景下，我們需要獲取集群文件比較的差異信息（匯總和明細），來做同步任務的決策。

總結來說，數據同步工作的難點在于及時，準確和文件狀態(tài)的可控可比較。這三點做得好不好，對整體遷移流程的順利進行和結果的驗證，影響還是很大的。

各種無法雙跑的業(yè)務場景梳理

要想處理無法雙跑的業(yè)務，首先，你得找到哪些業(yè)務不能雙跑不是。問業(yè)務方是不行的，因為業(yè)務方自己可能也未必清楚，多數情況下，要靠你的經驗判斷以及反復的溝通去推動梳理

舉幾個在我們的場景下無法／不宜 雙跑的例子：

• 大量不受我們自己管轄的數據源，具體管轄的業(yè)務方沒有時間精力或資源搭建雙跑用數據源的（比如，沒那么多機器，還有其它數據源寫入，相關業(yè)務需要修改代碼等等）
• 一些服務或作業(yè)雙跑會干擾線上業(yè)務的。比如監(jiān)控報警相關業(yè)務，如果按流程跑，雙跑過程中無效的報警或雙份的報警都不是業(yè)務方希望看到的。可以hack一些流程，但是代價就比較高了。
• 雙跑會對一些系統(tǒng)會造成壓力的，比如網絡帶寬，服務負載
• 業(yè)務整體流程，只有部分鏈路在我們的系統(tǒng)中，雙跑這部分業(yè)務鏈路會造成整體業(yè)務邏輯錯誤的

此外還有一些業(yè)務場景可能需要修改以后才能支持雙跑的，比如從消息隊列讀取數據，如果不修改消費組ID信息，雙跑的業(yè)務就會在同一份數據中各自讀取部分數據，造成兩邊結果都是錯誤的。

類似會出問題的地方可能還有很多，都是坑啊。。。

至于無法雙跑的業(yè)務場景，如果發(fā)現了，那么具體如何處理，反倒可能沒有那么難，總能找到臨時解決方案，最最不濟，在目標集群禁掉部分業(yè)務，不要雙跑，依靠其它手段提前驗證確保流程的正確性，集群切換完再把這部分業(yè)務單獨切換過去就好了。

總結

總結一下：大數據平臺／集群的搬遷工作，絕對不是集群數據拷貝這么簡單（實際上，數據拷貝也不簡單），作為一個開放的服務平臺，擁有海量的數據，系統(tǒng)組件眾多，上下游依賴關系錯綜復雜，業(yè)務邏輯不完全受你控制，外部系統(tǒng)的方案和決策也往往不受你左右，而你的業(yè)務環(huán)境又是在持續(xù)變化中，可能出錯的環(huán)節(jié)太多太多了。

在這種情況下，請務必堅守文中我們所提到的原則：堅決不做任何不可逆轉的操作；凡事另可麻煩一些，也要給自己留下退路；盡可能讓所有的步驟，流程自動化，標準化；讓系統(tǒng)狀態(tài)透明化；同時做好犯錯的準備，提前想好補救的手段。

生活總是如此艱辛，還是只有搬遷時是這樣？總是如此！

祝好運，搬遷順利。

常按掃描下面的二維碼，關注“大數據務虛雜談”，務虛，我是認真的 ；）