從 Meta 的 PB 級資料遷移實務，解析如何實現零停機的數據導入架構升級

在處理海量數據的企業環境中，將舊有的數據導入系統遷移到新架構，其困難程度並不亞於在運行中的飛機上更換引擎。Meta 最近分享了他們如何將每天處理數個 Petabyte（PB，即 1024 Terabytes）規模的 MySQL 社交圖譜數據，從碎片化的舊管線遷移到集中式管理服務的過程。對於工程師來說，這次遷移的核心挑戰不在於數據搬移本身，而是在於如何確保數據的一致性（Consistency）與系統的零停機（Zero Downtime）。

理解 CDC 與數據導入背景

在進入遷移流程前，必須先理解 Meta 使用的 CDC 技術。CDC 全稱為 Change Data Capture（變更數據擷取），這是一種監控資料庫變更並即時將這些變更同步到目標系統的技術。它解決了傳統全量備份過於緩慢且對資料庫壓力過大的問題。

在 Meta 的設計中，每個導入任務包含三個關鍵部分：首先是全量快照（Full Dump），用於初始化數據；其次是增量表（Delta），用於記錄快照之後的所有變更；最後是目標表（Target Table），這是提供給分析、機器學習等下游團隊使用的最終數據。

從碎片化到集中化的轉型

過去 Meta 的數據管線是由各個客戶端自行擁有與維護的，這導致基礎設施碎片化，維運效率低且難以統一管理。因此，他們決定將其重構為一個集中式的自管理倉庫服務（Centralized Managed Warehouse Service）。這意味著成千上萬個導入任務必須在不影響下游分析與 ML 模型的狀況下，集體搬家。

確保正確性的三階段遷移策略

為了降低風險，Meta 並非直接切換系統，而是採取了極為謹慎的三階段滾動更新：

第一階段是影子測試（Shadow Phase）。在新系統中建立一套與生產環境平行運行的影子任務，讓新舊系統同時處理相同的生產數據。此時，新系統的輸出僅用於驗證，不會影響任何業務。

第二階段是反向影子測試（Reverse Shadow Phase）。在驗證新系統穩定後，將生產環境的擁有權切換給新系統，但舊系統依然在背景運行。這樣做是為了在發現問題時，能夠迅速將權限切回舊系統，實現快速回滾（Rollback）。

第三階段是清理階段（Cleanup Phase）。當數據一致性與效能指標全部達標後，正式關閉並移除舊有的管線。

驗證數據一致性的技術手段

在 PB 級的規模下，人工檢查是不可能的，Meta 採用了自動化的監控機制來確保數據正確性：

首先是行數比對（Row Count），確保新舊系統處理的紀錄總數一致。

其次是校驗和監控（Checksum Monitoring）。Checksum 是一種將數據內容轉換為短碼的算法，只要數據內容有任何微小變動，校驗和就會完全不同。透過對比新舊系統的 Checksum，工程師能精準發現數據不一致的時刻。

一旦發現不匹配，團隊會立即在預生產環境（Pre-production）修復問題並驗證，直到差異消失才推進到下一個階段。

優化資源成本與效能

在大規模遷移中，最昂貴的操作是全量快照（Full Dump），因為它會消耗大量的計算資源與儲存空間。為了避免重複執行昂貴的快照，Meta 採取了兩個優化措施：第一，在解決數據質量問題前，盡量減少創建不必要的影子任務；第二，在遷移初期直接複用舊系統的快照分區（Snapshot Partitions），大幅降低了對基礎設施的壓力。

總結

Meta 的這次經驗告訴我們，處理超大規模系統遷移時，技術細節（如 CDC）固然重要，但更重要的是建立一套完整的生命週期管理機制。透過影子測試、嚴格的校驗和比對以及分階段的切換策略，才能在不中斷業務的前提下，完成核心基礎設施的升級。

來源：infoq.com (How Meta Rebuilt Data Ingestion for Petabyte-Scale Reliability)

本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。