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

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

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

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

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

陌生的遺留系統(tǒng) DB 設(shè)計(jì)

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

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

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

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

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

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

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

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

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

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

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

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

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

較高的技術(shù)和工具門檻

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

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

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

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

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

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

工具、技術(shù)培訓(xùn)

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

注意留存學(xué)習(xí)和分享的資料，未來有新人加入時(shí)，能夠直接拿來學(xué)習(xí)，加速融入團(tuán)隊(duì)的速度。

程序設(shè)計(jì)

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

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

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

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

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

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

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

成功率及錯(cuò)誤分析報(bào)告

沒有數(shù)據(jù)遷移經(jīng)驗(yàn)的團(tuán)隊(duì)很可能在項(xiàng)目初期遺漏掉這兩部分的開發(fā)工作。數(shù)據(jù)遷移的核心關(guān)注點(diǎn)是遷移沒錯(cuò)，但是業(yè)務(wù)最關(guān)心的是成功率。

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

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

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

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

上線演練

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

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

由于演練的時(shí)間點(diǎn)已經(jīng)比較接近上線時(shí)間，除非發(fā)現(xiàn)嚴(yán)重 bug 才做修改。小問題寧可帶著上線，以后再修數(shù)。此時(shí)千萬不要輕易修改代碼，因?yàn)楹芸赡軙?huì)引起其它 bug 或者性能問題。

上線失敗方案

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

上線

經(jīng)過數(shù)輪測(cè)試和演練，終于迎來了上線，關(guān)于上線我有如下建議：

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

上線后的支持

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

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

總結(jié)

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