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

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

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

為什么數(shù)據(jù)遷移項目難做

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

陌生的遺留系統(tǒng) DB 設計

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

古老的遺留系統(tǒng)數(shù)據(jù)庫

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

遷移海量數(shù)據(jù)量

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

錯誤數(shù)據(jù)如何處理

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

業(yè)務部門過高的預期

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

數(shù)據(jù)遷移程序如何兼容業(yè)務系統(tǒng)的改動

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

要開發(fā)的遠不止數(shù)據(jù)遷移程序

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

較高的技術和工具門檻

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

做好數(shù)據(jù)遷移，就這些事

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

Mapping rule（映射規(guī)則） 管理

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

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

工具、技術培訓

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

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

程序設計

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

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

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

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

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

大數(shù)量級的數(shù)據(jù)遷移，肯定會有性能的問題。數(shù)據(jù)遷移時，新老系統(tǒng)都不可用。因此，業(yè)務部門肯定希望數(shù)據(jù)遷移時間越短越好。這對性能是極大的挑戰(zhàn)。關于性能優(yōu)化，我有如下建議：

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

成功率及錯誤分析報告

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

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

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

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

除了這兩個報告，遷移過程中需要開發(fā)很多小工具，比如數(shù)據(jù)清理、環(huán)境狀態(tài)檢查工具等等。對這些工具的開發(fā)工作量要有預期。

上線演練

上線前如果有條件，一定要使用真實環(huán)境和數(shù)據(jù)進行演練。演練的時間和執(zhí)行步驟也盡量和上線計劃一致。

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

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

上線失敗方案

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

上線

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

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

上線后的支持

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

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

總結

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