歷史悠久的大型企業，都會存在遺留系統。這些系統運轉著重要的業務，但使用到的技術已經跟不上時代潮流。因此有著維護成本高、難以擴展、用戶體驗差等缺陷。最終，企業一定會下決心開發一套全新的系統來替代遺留系統。除了完成新系統的開發，還有一項重要的工作，是將老系統中存留的數據遷移進新系統，也就是我們常說的數據遷移。

如果你沒有數據遷移的經驗，很容易低估其難度。數據遷移看起來只是把數據從一個 DB 轉移到另外一個 DB，select + insert + 轉換邏輯就可以輕松搞定。如果帶著這個想法開始數據遷移項目，你的團隊很快就會墜入深淵，舉步維艱。

數據遷移是一項看似簡單，實而復雜且繁瑣的工作，想要做好并不容易。

為什么數據遷移項目難做

不久前，我剛剛完成一次數據遷移項目。雖然項目結果很成功，但過程中遇到很多開始之初沒有想到的問題，導致項目過程非常痛苦。如果在項目開始時就把這些問題考慮進來，過程會輕松很多，風險也會小很多。下面我們來看看數據遷移項目所面臨的挑戰有哪些。

陌生的遺留系統 DB 設計

作為新系統的開發方，你一定熟知新系統的 DB 設計。但是遺留系統的 DB 設計想必你一定不甚了解。作為要被替換的遺留系統，其開發方肯定也不會提供技術支持。在這個情況下，如何寫好遷移規則就成為了一個難題。

古老的遺留系統數據庫

新系統一般都會采用當前主流的數據庫，例如 MySQL、Oracle 等。但遺留系統可能采用的是幾十年前古老的技術，數據庫的名字你可能聽都沒聽過。這時候不會有任何 ETL 工具可以使用，甚至于沒有主流語言的客戶端類庫可以使用。如何連接老系統的 DB，查詢出里面的數據都會是一個難題。

遷移海量數據量

遺留系統經過幾年甚至幾十年的使用，累積了海量的數據。業務一般不會輕易放棄這些數據。同時，在上線的窗口期內，留給數據遷移的時間也就短短幾個小時。如何在短時間內導入海量的數據，將會是很大的挑戰！

錯誤數據如何處理

新老系統在業務處理上肯定會有差異，此外老系統的數據也會有質量問題。這會導致有一部分數據無法進入新系統。業務人員總是希望能夠導入更多的數據到新系統。一個選擇是放松校驗，但低質量的數據進入新系統會造成很多問題。另外一個選擇是讓業務人員在老系統中修復數據。但很多問題數據無法通過界面修改。如何權衡數據的遷移準入標準也將是一個挑戰。否則遷移成功率上來了，但上線后會陷入無止境的修數據工作中。

業務部門過高的預期

業務部門往往對數據遷移抱有不切實際的幻想，例如非常高的導入成功率及導入速度。如何采用有效的策略讓業務部門降低預期，是數據遷移項目組要認真思考的問題。否則團隊的辛苦付出不被認可，對團隊傷害極大。

數據遷移程序如何兼容業務系統的改動

迫于上線時間點的壓力，往往數據遷移程序開發的同時，業務系統也還在開發中。如何做到兼容業務系統的變化，是一個難題。處理不好這個問題，會導致數據按照錯誤的邏輯導入，甚至可能遺漏新的字段。

要開發的遠不止數據遷移程序

數據遷移項目中除了開發遷移的主程序，還需要開發很多輔助的工具。比如成功率報表工具、錯誤日志分析工具、數據刪除工具、環境檢查工具等。這些工具都是數據遷移過程中必不可少的。如果項目估算時忽略了這些工作量，會造成嚴重的資源緊張。

較高的技術和工具門檻

數據遷移使用的技術和工具不同于業務開發，均有一定門檻。如果項目中期遇到進度吃緊，需要增加資源，往往很難短時間找到合適的資源。最終可能妥協讓沒有經驗的工程師上項目。這些工程師如何快速掌握所需技能，加速融入團隊是項目組需要提前考慮的事情。如果處理不好，會造成新人沒有產出，只能依賴項目已有人員加班趕工，使得整個團隊陷入疲憊不堪的狀態。

做好數據遷移，就這些事

看完上面數據遷移過程中的各種問題，是不是覺得很頭疼？沒關系，辦法總比困難多。根據經驗，我提煉出如下幾件數據遷移要關注的事情。

Mapping rule（映射規則） 管理

Mapping rule是數據遷移的需求。寫好 mapping rule 需要既熟悉新系統，又熟悉老系統。并且還要熟悉數據庫設計。一個人能同時做到新老系統都熟悉幾乎不可能。一般來說需要新老系統各出一位熟悉系統的成員，一起討論 mapping rule。
建議參與 mapping rule 討論和制定的是開發成員。因為此人不僅需要熟悉業務，還需要熟悉數據如何存儲。
Mapping rule 還需要明確遷移的數據范圍。哪些業務數據需要遷移，遷移多久的數據都需要明確。
Mapping rule 制定完成后，要和業務部門澄清確認。并且告知成功率不可能100%，盡量降低業務的預期。
對 Mapping rule 的變更要格外小心，尤其在開發的收尾階段，原因如下：

1. 為了讓幾條報錯數據進入系統而改了 mapping rule，有可能導致更多數據進不來。
2. Mapping rule的修改很可能影響系統的性能。
   如果 mapping rule 是錯誤的，必須要改，那么一定注意上面的兩個問題。千萬不要僅僅關注 mapping rule 變更的工作量。

工具、技術培訓

數據遷移一般會使用 ETL 工具，當然也可能自開發程序。遷移程序的關注點在如何高效快速的處理數據，這和業務開發關注點完全不同。因此采用的技術棧也區別很大。由于數據遷移所使用的技術在業務開發中較少使用，所以需要提前投入時間學習。并且需要制定長期的學習計劃，項目開始后也要保持團隊的學習和技術交流。

注意留存學習和分享的資料，未來有新人加入時，能夠直接拿來學習，加速融入團隊的速度。

程序設計

架構師需要先行設計好代碼框架，定義好開發規范和流程，并寫好樣例代碼。這樣可以確保開發集中進項目時快速產出。程序設計要考慮如下事項：

1. 遷移任務的記錄、解耦以及依賴管理。
2. log 設計。需要包含任務名稱，錯誤數據業務主鍵子段等關鍵信息。總之需要方便統計和定位錯誤。
3. 通過程序設計，讓開發只關注業務邏輯的實現。不需要過多關注任務記錄、異常處理等非功能性需求。
4. 能夠方便調節并發數等性能相關參數。
5. 成功率統計程序設計。
6. 錯誤日志分析程序設計。
7. 其他輔助工具。
8. 如何兼容業務系統的新變更。

重點說一下最后一點，很多時候在遷移程序開發階段，業務系統還未開發結束。如果解決業務邏輯的改動和表變更改動對數據遷移的影響是個難題。首先業務邏輯的改動我們可以通過調業務API完成數據遷移的方式來屏蔽掉。由于不是表對表轉換后直接sql寫入，而是通過業務的API寫入。那么當API輸入有變化時，遷移程序就會報錯。此外如果邏輯有調整，數據自然也會按照最新的邏輯進入的數據庫。

對于新的字段和新的表，我們可以通過工具對比現有 mapping rule 的表和字段，識別出變化點，再分析是否需要增加 mapping rule 來遷移這些數據。

一定要在開發高峰到來前做好程序設計和框架代碼開發。否則會讓開發團隊陷入泥沼，有力氣使不上。
性能調優

大數量級的數據遷移，肯定會有性能的問題。數據遷移時，新老系統都不可用。因此，業務部門肯定希望數據遷移時間越短越好。這對性能是極大的挑戰。關于性能優化，我有如下建議：

1. 一定要有 APM 工具。還要有虛機、DB 等資源的監控工具。有了工具才能將性能狀況透明出來。性能瓶頸在哪里一目了然，否則就是胡亂抓藥。
2. 性能要全局考慮，不要只考慮某個運算單點的性能。很多時候，性能是相互制約的。
3. 減少網絡IO的次數，讓單次請求傳輸更多數據。但并不是越多越好，需要找到性能的平衡點。
4. 數據量太大的話，可以分幾個批次遷移，分批上線。
5. 變化不大的非交易數據可以提前上線。甚至交易數據也可以考慮提前上線，真正上線時再做增量遷移。這種方式需要額外開發增量遷移程序。
6. 在高并發的遷移過程中，任何關于性能的參數調整都可能有想不到的影響。要不斷試驗，不能想當然。

成功率及錯誤分析報告

沒有數據遷移經驗的團隊很可能在項目初期遺漏掉這兩部分的開發工作。數據遷移的核心關注點是遷移沒錯，但是業務最關心的是成功率。

這兩種報告要提前設計好。遷移程序的設計和開發要考慮報表的需求來記錄任務成功率和日志。否則等到程序開發完再去思考報告程序的開發，很可能會對原有遷移程序的造成比較大的返工。

這兩份報告要和業務部門澄清，確定錯誤數據如何處理。錯誤數據處理一般分為如下三類：

1. 數據問題，業務可以改數據。讓業務自行修改。
2. 數據問題，業務不能直接修改。通知業務數據無法導入，自行備份。
3. Mapping rule 未考慮的場景。修改 Mapping rule 來適配這些數據。

除了這兩個報告，遷移過程中需要開發很多小工具，比如數據清理、環境狀態檢查工具等等。對這些工具的開發工作量要有預期。

上線演練

上線前如果有條件，一定要使用真實環境和數據進行演練。演練的時間和執行步驟也盡量和上線計劃一致。

上線演練的不能過早進行，否則會造成演練的數據和上線時差異過大，減弱了演練的效果。但演練的時間也不能過晚，否則發現問題沒有時間解決。我的經驗是上線前兩周進行演練。

由于演練的時間點已經比較接近上線時間，除非發現嚴重 bug 才做修改。小問題寧可帶著上線，以后再修數。此時千萬不要輕易修改代碼，因為很可能會引起其它 bug 或者性能問題。

上線失敗方案

雖然你經歷的上線可能從來沒有失敗過，但不要以為這一次也一定會成功。如果出現問題，全部回滾還是部分回滾，都要提前計劃好。先上線后面再補歷史數據是一種方案。直接終止上線，再次開啟老系統也是一種方案。不管什么方案，都需要提前和業務溝通好。因為上線期間的時間十分寶貴。一定避免臨時定方案，這會造成決策困難，甚至無人拍板。

上線

經過數輪測試和演練，終于迎來了上線，關于上線我有如下建議：

1. 分配好資源。如果晚上通宵上線，不要全部開發都來支持上線。一定留有人手第二天線上支持。
2. 根據上線計劃，一步步小心執行，確保每個操作至少兩個同事 pair 完成。
3. 每一步操作完成都要做相應的檢查。
4. 上線前預測可能出現的異常，準備好處理方案。如果出現預料之外的錯誤也不要驚慌，冷靜思考解決方案。

上線后的支持

我向你保證，遷移進來的數據一定會有各種各樣的問題。一般來說修復數據有如下幾種方式：

1. SQL 腳本修復。適用于修復問題數據涉及的表，在同一個 DB 中，邏輯也不復雜的情況。
2. 存儲過程修復。適用于修復問題數據涉及的表，在同一個 DB 中，邏輯比較復雜的情況。存儲過程的優點是不需要發布程序。缺點是不好調試和維護。
3. 程序修復。修復問題數據需要跨 DB 時，只能通過開發程序來修復。這種場景也是最復雜的。
   無論采用哪種方式，都需要經過充分的測試。數據修復是很危險的操作，一旦程序有問題，可能會把沒問題的數據修壞。此外還要測試修復程序的性能，對執行時長要有預估。最后切記修復前一定要好做數據備份。

總結

美國管理學家 哈羅德·孔茨 曾經說過：雖然計劃不能完全準確地預測將來，但如果沒有計劃，組織地工作往往陷入盲目，或者碰運氣。千萬不要低估數據遷移項目的難度，參考本文內容提前做好規劃，會讓你的數據遷移項目有一個好的開始。