如何進(jìn)行大規(guī)模在線數(shù)據(jù)遷移

工程團(tuán)隊(duì)常面臨一項(xiàng)共同挑戰(zhàn)：重新設(shè)計(jì)數(shù)據(jù)模型以支持清晰準(zhǔn)確的抽象和更復(fù)雜的功能。這意味著，在生產(chǎn)環(huán)境中，需要遷移數(shù)以百萬計(jì)的活躍數(shù)據(jù)對象，并且重構(gòu)上千行代碼。

用戶期望 Stripe API 保障可用性和一致性。所以在進(jìn)行遷移時(shí)，需要格外謹(jǐn)慎，必須保證數(shù)據(jù)的數(shù)值正確無誤，并且 Stripe 的服務(wù)始終保持可用。

本文將展示國外移動支付服務(wù)商 Stripe 如何安全地對數(shù)以億計(jì)的 Subscriptions（訂閱服務(wù)）對象進(jìn)行大規(guī)模遷移。

為什么遷移困難？

1.數(shù)據(jù)規(guī)模

數(shù)以億計(jì)的 Subscriptions 對象。在生產(chǎn)環(huán)境數(shù)據(jù)庫上進(jìn)行涉及到所有這些對象的大規(guī)模遷移會有巨大的工作量。

想象一下，遷移一個(gè) Subscription 對象需要花費(fèi)一秒鐘，若以順序方式遷移一億個(gè)對象將花費(fèi)超過三年的時(shí)間。

2.服務(wù)運(yùn)行時(shí)間

商業(yè)機(jī)構(gòu)持續(xù)通過 Stripe 的服務(wù)進(jìn)行交易。所有的基礎(chǔ)設(shè)施升級都是在線進(jìn)行，而不依賴于有計(jì)劃的維護(hù)時(shí)段。因?yàn)椴荒茉谶w移過程中中斷 Subscriptions 服務(wù)，在這個(gè)遷移過程中必須要保證所有服務(wù) 100% 處于可用狀態(tài)。

3.數(shù)據(jù)正確性

代碼庫中的很多代碼都在使用 Subscriptions 數(shù)據(jù)庫表。如果試圖一次性修改整個(gè) Subscriptions 服務(wù)中數(shù)以千計(jì)的代碼行，那幾乎肯定會忽視一些邊界情況 。工程團(tuán)隊(duì)必須確保每項(xiàng)服務(wù)都能夠持續(xù)獲取正確無誤的數(shù)據(jù)。

在線遷移的模式

將數(shù)百萬個(gè)對象從舊數(shù)據(jù)庫表遷移到新表是很有難度的，但許多公司需要去做這樣的事情。

以下是在進(jìn)行大型在線遷移中常用的 4 步”雙寫模式“，具體步驟是：

1. 向舊表和新表雙寫數(shù)據(jù)以保證它們之間的數(shù)據(jù)是同步的。
2. 修改代碼庫中所有的數(shù)據(jù)讀取路徑以從新表讀取數(shù)據(jù)。
3. 修改代碼庫中所有的數(shù)據(jù)寫入路徑以將數(shù)據(jù)只寫入新表。
4. 刪除依賴過時(shí)數(shù)據(jù)模型的舊數(shù)據(jù)。

遷移示例：Subscriptions

什么是Subscriptions？為什么需要進(jìn)行數(shù)據(jù)遷移？

Stripe 的 Subscriptions 用于幫助 DigitalOcean 和 Squarespace 這類用戶構(gòu)建并管理他們客戶的循環(huán)計(jì)費(fèi)。在過去幾年中，我們穩(wěn)步增加了一些功能來支持更復(fù)雜的計(jì)費(fèi)模式，例如多訂閱、試用、優(yōu)惠券和發(fā)票。

在早期，每個(gè) Customer 對象最多只有一個(gè) subscription 。 customers 信息存儲為單獨(dú)的記錄。因?yàn)?customers 到 subscriptions 之間的映射關(guān)系非常簡單，所以subscriptions 信息與 customers 信息存儲在一起。

class Customer 
 
  Subscription subscription 
 
end 

最終，我們的用戶想要具有多個(gè) subscriptions 的 customers 。我們決定將單一的 subscription 字段轉(zhuǎn)換為 subscriptions 字段，以便存儲具有多個(gè) subscription 的數(shù)組。

class Customer 
 
  array: Subscription subscriptions 
 
end

當(dāng)添加新功能時(shí)，這個(gè)數(shù)據(jù)模型便出現(xiàn)問題了。任何對 subscriptions 的修改都會引發(fā)整條 Customer 記錄的更新，以及 subscriptions 相關(guān)的查詢都要通過掃描 customer 對象實(shí)現(xiàn)。所以我們決定將 subscriptions 獨(dú)立存儲。

（重新設(shè)計(jì)的數(shù)據(jù)模型將 subscriptions 轉(zhuǎn)移到獨(dú)立的數(shù)據(jù)表中）

提醒一下，四步遷移方案如下：

1. 向舊表和新表雙寫數(shù)據(jù)以保證它們之間的數(shù)據(jù)是同步的。
2. 修改代碼庫中所有的數(shù)據(jù)讀取路徑以從新表讀取數(shù)據(jù)。
3. 修改代碼庫中所有的數(shù)據(jù)寫入路徑以將數(shù)據(jù)只寫入新表。
4. 刪除依賴過時(shí)數(shù)據(jù)模型的舊數(shù)據(jù)。

下面介紹這四個(gè)步驟的具體實(shí)踐。

***步：雙寫

創(chuàng)建一張新的數(shù)據(jù)庫表，作為遷移的開始。***步是開始復(fù)制新數(shù)據(jù)，同時(shí)寫入新舊兩處存儲中。之后，再將缺失的數(shù)據(jù)回填至新存儲，已使兩處存儲具有相同的數(shù)據(jù)

（所有新寫入的數(shù)據(jù)都應(yīng)更新新舊兩處存儲）

在 Stripe 的案例中，我們將所有新創(chuàng)建的 subscriptions 同時(shí)寫入 Customers 表和 Subscriptions 表。在開始雙寫兩張表之前，需要評估額外的寫入操作對生產(chǎn)環(huán)境數(shù)據(jù)庫性能的潛在影響?？梢酝ㄟ^緩慢提高重復(fù)對象的百分比來緩解性能問題，同時(shí)持續(xù)關(guān)注系統(tǒng)運(yùn)行指標(biāo)。

進(jìn)行到此時(shí)，新創(chuàng)建的對象已同時(shí)存在于兩張表中，而舊對象只能在舊表中找到。接下來將以懶惰方式（ lazy fashion ）開始復(fù)制已存在的舊對象：每當(dāng)對象更新時(shí)，將它們自動復(fù)制到新表中。這種方式可逐步轉(zhuǎn)移已存在的數(shù)據(jù)。

***，將剩余的 subscriptions 數(shù)據(jù)回填至新表。

（回填已存在 subscriptions 數(shù)據(jù)至新表）

在正在對外提供服務(wù)的數(shù)據(jù)庫上找到所有需要遷移的數(shù)據(jù)是回填操作中代價(jià)***的部分。通過查詢數(shù)據(jù)庫查找所有對象的方式將需要在生產(chǎn)環(huán)境數(shù)據(jù)庫上執(zhí)行相當(dāng)多的查詢操作，這將耗費(fèi)很多時(shí)間。幸運(yùn)的是，可以將數(shù)據(jù)從線上導(dǎo)入對生產(chǎn)環(huán)境數(shù)據(jù)庫完全無影響的離線流程中。我們創(chuàng)建適用于我們 Hadoop 集群的數(shù)據(jù)庫快照，這讓我們可以使用 MapReduce 以離線、分布式的方式快速處理數(shù)據(jù)。

我們使用 Scalding 來管理 MapReduce 作業(yè)。 Scalding 是用 Scala 編寫的非常實(shí)用的庫，可以很容易地編寫MapReduce作業(yè)（10行代碼即可實(shí)現(xiàn)一個(gè)簡單的作業(yè)）。 在這種情況下，使用 Scalding 幫助工程團(tuán)隊(duì)找出所有subscriptions 數(shù)據(jù)。具體步驟如下：

• 編寫一份 Scalding 作業(yè)，提供所有需要復(fù)制的 subscription ID 的列表。
• 通過一組進(jìn)程并行執(zhí)行來大規(guī)模的復(fù)制 subscriptions 數(shù)據(jù)。
• 遷移完成后，需再次運(yùn)行 Scalding 作業(yè)，以確保所有 subscriptions 數(shù)據(jù)都已存在于 Subscriptions 表中。

第二步：改變所有讀操作路徑

到目前為止，新舊數(shù)據(jù)表已是同步狀態(tài)。下一步要做的是在新表上進(jìn)行所有的讀操作。

（目前，所有的讀操作在 Customers 表上進(jìn)行，需要將這些操作轉(zhuǎn)移到 Subscriptions 表上）

需要確保從新表讀數(shù)據(jù)是安全的，subscription 在新舊表中的數(shù)據(jù)應(yīng)該是一致的。可以使用 GitHub 出品的 Scientist 來輔助驗(yàn)證讀操作。Scientist 是一個(gè) Ruby 庫， 它可以讓我們在生產(chǎn)環(huán)境運(yùn)行實(shí)驗(yàn)，比對不同代碼的運(yùn)行結(jié)果并對不一致的結(jié)果發(fā)出警告 。通過 Scientist ，可實(shí)時(shí)生成針對不一致結(jié)果的警告和指標(biāo)。當(dāng)實(shí)驗(yàn)代碼中發(fā)生錯(cuò)誤，其余的應(yīng)用程序是不會受到任何影響的。

實(shí)驗(yàn)按如下進(jìn)行：

• 使用 Scientist 從 Subscriptions 表和 Customers 表同時(shí)讀取數(shù)據(jù)。
• 如果讀取到的數(shù)據(jù)不一致，則向工程團(tuán)隊(duì)發(fā)出警告。

GitHub 的 Scientist 可運(yùn)行讀取兩張表并對數(shù)據(jù)做對比的實(shí)驗(yàn)。

在確認(rèn)所有數(shù)據(jù)是一致的后，就可以開始從新表讀取數(shù)據(jù)了。

（實(shí)驗(yàn)成功，現(xiàn)在所有的讀操作都在 Subscriptions 表上進(jìn)行）

第三步：改變所有寫操作路徑

接下來，需要更新寫操作路徑，將數(shù)據(jù)寫入新的 Subscriptions 表。 實(shí)施的目標(biāo)是逐步推進(jìn)這些改變，所以需要采取謹(jǐn)慎的策略。

直到現(xiàn)在，數(shù)據(jù)一直寫入舊表，然后被復(fù)制到新表：

現(xiàn)在要顛倒這個(gè)順序：先將數(shù)據(jù)寫入新表，然后將其寫入舊表中。 通過保持這兩張表的一致性，我們可以進(jìn)行增量更新并仔細(xì)觀察每個(gè)更改。

重構(gòu) subscriptions 的所有寫操作代碼可以說是遷移中***挑戰(zhàn)性的部分。 Stripe 服務(wù)中處理 subscriptions 操作的邏輯（例如更新，分期付款、續(xù)費(fèi)）涉及多個(gè)服務(wù)的數(shù)千行代碼。

成功重構(gòu)的關(guān)鍵是增量處理：將盡可能多的代碼路徑分隔成可能的最小單元，以便可以仔細(xì)應(yīng)用每個(gè)更改。 新舊兩張表的數(shù)據(jù)在重構(gòu)的任何一個(gè)階段都需要保持一致。

對于每個(gè)代碼路徑，我們需要使用整體方法來確保我們的更改是安全的。 我們不能僅僅只使用新數(shù)據(jù)替代舊數(shù)據(jù)：每一個(gè)邏輯塊都需要仔細(xì)斟酌。 如果錯(cuò)過了任何情況，可能就會造成數(shù)據(jù)不一致。 值得慶幸的是，可以運(yùn)行更多的 Scientist 實(shí)驗(yàn)來提醒工程團(tuán)隊(duì)可能存在的任何不一致。

新的，簡化的寫數(shù)據(jù)路徑如下所示：

可通過在調(diào)用 subscriptions 數(shù)組時(shí)觸發(fā)報(bào)錯(cuò)的方法，確保沒有代碼繼續(xù)使用過時(shí)的subscriptions 數(shù)組：

class Customer 
 
  def subscriptions 
 
    hard_assertion_failed("Accessing subscriptions array on customer") 
 
  end 
 
end 

第四步：刪除舊數(shù)據(jù)

***的（也是最令人滿意的）步驟是移除舊的寫操作代碼，并最終刪除。

一旦確定沒有任何代碼依賴過時(shí)數(shù)據(jù)模型的 subscriptions 字段，就不再需要將數(shù)據(jù)寫入舊表：

隨著這一變化，代碼不再使用舊數(shù)據(jù)源，新數(shù)據(jù)源成為唯一數(shù)據(jù)源。

現(xiàn)在，可以刪除所有 Customer 對象上的 subscriptions 數(shù)組，并且逐漸以懶惰的方式處理“刪除”操作。 每次 subscription 被加載后，都會自動清空這個(gè) subscriptions 數(shù)組，然后運(yùn)行 Scalding 作業(yè)并遷移，以查找任何剩余的要?jiǎng)h除的對象。 最終的數(shù)據(jù)模型如下：

結(jié)論

在保證 Stripe API 數(shù)據(jù)一致性的同時(shí)進(jìn)行遷移是非常復(fù)雜的工作。安全進(jìn)行這項(xiàng)遷移的幾個(gè)要點(diǎn)是：

• 我們制定了一個(gè)四階段遷移策略，可以讓我們在生產(chǎn)環(huán)境中不停服進(jìn)行數(shù)據(jù)切換。
• 使用Hadoop離線處理數(shù)據(jù)，使用MapReduce以并行方式處理大量數(shù)據(jù)，而不是依賴在生產(chǎn)環(huán)境數(shù)據(jù)庫上執(zhí)行的代價(jià)高昂的查詢。
• 所做的所有更改都是漸進(jìn)式的。 我們從未試圖一次更改幾百行代碼。
• 所有的變化都是高度透明和可觀察的。 Scientist 的實(shí)驗(yàn)只要有一條數(shù)據(jù)在生產(chǎn)環(huán)境中是不一致的，就立即提醒工程團(tuán)隊(duì)。 在整個(gè)遷移過程中，我們都對安全的遷移懷有信心。

我們發(fā)現(xiàn)這種方法在我們執(zhí)行過的許多在線數(shù)據(jù)遷移中都很有效。我們希望這些實(shí)踐做法對于其他團(tuán)隊(duì)進(jìn)行大規(guī)模遷移也是有幫助的。