資料遷移與驗證

資料遷移簡介

資料遷移通常是雲端轉型中最具挑戰性的部分。對於 Professional Cloud Architect 來說，目標不僅僅是將位元從 A 移動到 B，而是要 安全地、高效地 且以 經過驗證的完整性 來完成。

成功的資料遷移需要根據資料量、可用頻寬、可接受的停機時間，以及來源資料的形態（物件儲存、RDBMS、資料倉儲或 SaaS API）來選擇正確的工具。

白話文解釋

類比 1 — 搬家驗收

資料遷移就像搬新家。搬家公司把箱子載到新房子並不算完工，你還要逐箱清點、檢查家具有沒有刮傷、電器有沒有少零件，最後屋主簽字才算交屋。Database Migration Service (DMS) 把資料庫搬到 Cloud SQL/AlloyDB 只完成「載貨」這一步；你還要做 row count、checksum、schema diff 才能「驗收簽字」。沒有驗收的搬家，等於沒有搬。

類比 2 — 海關 SKU 對帳

跨雲資料搬遷就像進口貨櫃過海關：報關單上寫 10,000 件商品，海關開櫃逐 SKU 對帳，差一件都不放行。Data Validation Tool (DVT) 扮演海關的角色，對來源（Oracle、Teradata、Redshift）與目的（BigQuery、Cloud SQL）執行 COUNT(*)、SUM(col)、MIN/MAX、行級 hash，把不符的 SKU 列成 exception report 給你補件。少了這份報關單，你不知道少了哪些行。

類比 3 — 搬家保險（Backout Plan）

搬家公司都會推銷保險：萬一新家鑰匙打不開、電梯壞掉，你可以退回舊家。雲端遷移的 backout plan 就是這份保險：cutover 後保留舊系統 read-only 至少 7-14 天、保留 DMS replication slot、Cloud SQL 保留 PITR、BigQuery 保留來源 dataset snapshot。沒買保險的搬家，cutover 失敗就只能加班通宵；買了保險，30 分鐘 rollback 回舊系統。

遷移決策矩陣

架構師必須評估以下變數：

• 資料量： 有多少 Terabytes 或 Petabytes？
• 頻寬： 上傳速度是多少（VPN、Interconnect 或公共網際網路）？
• 時間窗口： 可接受多少停機時間？
• 資料類型： 結構化 (SQL)、半結構化 (JSON) 還是非結構化（檔案/圖片）？

Database Migration Service (DMS) for Cloud SQL 與 AlloyDB

Database Migration Service 是將 MySQL、PostgreSQL、SQL Server 遷移到 Cloud SQL 或 AlloyDB for PostgreSQL 的代管管道。當 PCA 考題寫到「以最短停機時間遷移資料庫到 Google Cloud 代管資料庫」時，DMS 通常就是預設答案。

DMS 運作方式

1. Connection profile — 定義來源（地端、GCE、AWS RDS、Azure Database）。連線方式包含 IP allowlist、透過 GCE bastion 的 reverse SSH tunnel，或透過 Interconnect/VPN 的 VPC peering。
2. Migration job — 選擇 one-time（dump + restore）或 continuous（initial dump + 透過 binlog/WAL replay 的 CDC）。
3. Initial load — DMS 在底層使用 mysqldump / pg_dump 的語義，將資料串流到目的端。
4. CDC phase — DMS 追蹤來源的 binlog (MySQL) 或 replication slot (PostgreSQL)，並以接近即時的速度將異動 replay 到目的端。
5. Promotion — 當 replication lag 接近 0 時，你停止來源的寫入、等最後幾筆事件完成、然後在 DMS 中 promote 目的端。Promotion 會讓目的端變成可寫，並切斷 replication 連結。

DMS 常見地雷

• 來源端先決條件： MySQL 需要 binlog_format=ROW；PostgreSQL 需要 wal_level=logical 與 replication slot。這些設定缺一不可，是遷移失敗的第一大原因。
• 異質遷移（例如 Oracle 到 AlloyDB on PostgreSQL）需要 Database Migration Service for Oracle，底層使用 Datastream 加上一個 conversion workspace。
• Sequence 與 AUTO_INCREMENT 在 promotion 後必須在目的端重設，否則第一筆寫入就會撞到 duplicate-key 錯誤。
• DMS 不會 遷移使用者、角色、grants 或 DBA 等級的物件——這些必須由你另寫腳本處理。

Datastream CDC 用於持續複寫

Datastream 是 serverless 的 異動資料擷取 (CDC) 與複寫 服務。DMS 有強烈的方向性（把資料落到代管的 Cloud SQL/AlloyDB 實例），Datastream 則是一條 CDC 管線——從 Oracle、MySQL、PostgreSQL、SQL Server 讀取異動，然後寫到 BigQuery、Cloud Storage（Avro/JSON）或下游的 Dataflow 範本。

典型 Datastream 模式

• Oracle 到 BigQuery 接近即時分析： Datastream 透過 LogMiner 讀取 Oracle redo logs，將異動事件寫到 GCS staging bucket，再由 Dataflow 範本合併到 BigQuery 資料表。Replication lag 通常是 1-15 分鐘。
• MySQL 到 BigQuery 直寫： Datastream 現在支援直接寫入 BigQuery，簡單案例可以省掉 Dataflow merge 這一步。
• 混合 CDC + 批次： Datastream 會先做 backfill（snapshot）載入歷史資料，再切換到 CDC 持續同步異動——一個 stream 定義就可以涵蓋。

Datastream vs DMS

Storage Transfer Service 用於 GCS

Storage Transfer Service (STS) 是把 物件資料搬進 Cloud Storage 的全代管服務，有兩種型態：

STS cloud-to-cloud

• 來源：AWS S3、Azure Blob Storage、HTTP/HTTPS 列表、另一個 GCS bucket。
• 驗證機制：AWS access keys、Azure SAS tokens 或 S3-compatible credentials。對 S3 也支援透過 AWS STS AssumeRole 的 Federated Identity——不需長期金鑰。
• 排程：一次性、每日，或事件驅動（透過 SQS 的 S3 event notifications）。
• 驗證：STS 對每個物件計算 CRC32C 或 MD5 並與目的端比對；不符的物件會重試。

STS for on-premises

• 你在地端機器上安裝 STS agents（Docker 容器），由 agent 從 NFS/POSIX 檔案系統讀取，再透過 STS 控制平面推送到 GCS。
• 每個 agent 與每個 job 都可以限制頻寬，避免塞爆正式環境網路。
• 網路斷線時 agent 會自動續傳——不必再守在 rsync 旁邊。

STS 常見地雷

• STS 會保留 物件名稱，但除非啟用 preserve_metadata，否則不會保留 POSIX metadata（uid/gid/mode）。
• 對 數十億個小檔，STS 會卡在 metadata 處理。考慮改用具備 parallel composite upload 的 gcloud storage cp，或用 Transfer Appliance 做批次 dump。
• STS 不會 做轉碼或轉換——它是位元對位元複製。需要 schema 感知的轉換要交給 Dataflow。

Transfer Appliance 用於離線遷移

Transfer Appliance 是 Google 的「球鞋網路 (sneakernet)」——一台可放進機架、加密的儲存設備，寄送到你的資料中心。你把資料裝進去，寄回 Google，資料就會被匯入 GCS。

何時使用 Transfer Appliance

• 頻寬數學行不通： 一個實用的「T-shirt 法則」是——如果透過你的網路上傳要超過 1 週，就應該考慮用 appliance。例如 100 TB 跑 100 Mbps，線上傳輸要約 100 天；用 appliance 大約 2-3 週可以門對門完成。
• 一次性批次 seed： 常與 Datastream 或 DMS CDC 搭配，appliance 載歷史資料，CDC 處理增量。
• 氣隙或受限網路： 無法大規模從公開網路 egress 的站點。

Appliance 型號

• TA40 — 可用 40 TB，桌面型，可走 FedEx。
• TA300 — 可用 300 TB，機架型，走貨運。

安全模型

• 資料以 AES-256 在 appliance 上加密，金鑰由客戶自帶。Google 不持有 金鑰。
• 抵達 Google 後解密、把資料匯入你的 GCS bucket、然後依 NIST 800-88 安全清除設備。
• 如果 appliance 在運送途中遺失，沒有你的 passphrase 就讀不出資料。

BigQuery Data Transfer Service 用於 SaaS 來源

BigQuery Data Transfer Service (BQ DTS) 是把 SaaS 與外部倉儲來源 載入 BigQuery dataset 的排程式、pull-based 代管載入工具。

支援來源

• Google SaaS： Google Ads、Campaign Manager、Display & Video 360、Search Ads 360、YouTube Channel/Content Owner、Google Merchant Center、Google Play。
• 外部雲端儲存： Amazon S3、Azure Blob Storage（透過 GCS connector）。
• 外部倉儲： Teradata、Amazon Redshift、Snowflake（透過 BigQuery Migration Service 路徑）。

BQ DTS 運作方式

1. 你以 OAuth（SaaS 來源）或 IAM/service-account 憑證（雲端儲存）授權一個 transfer config。
2. DTS 依排程（每日、每小時或自訂 cron）拉取最新資料。
3. 資料落到符合來源 schema 的 分區資料表。大多數 SaaS 來源的 schema 變更會自動處理。
4. 失敗時觸發 Cloud Monitoring alerts；backfill 是一個 CLI flag。

常見架構

BigQuery 上的行銷分析平台通常會用 BQ DTS 處理 Google Ads + YouTube + DV360，搭配 Storage Transfer Service 處理第三方 DSP 從 S3 匯出的 CSV，全部 union 到同一個 BigQuery dataset。

BigQuery Migration Service 用於 SQL 轉譯

BigQuery Migration Service 是把舊有資料倉儲（Teradata、Redshift、Snowflake、Oracle、Hive、Vertica、SQL Server、Netezza）轉譯 schema 與 SQL 到 BigQuery 的傘狀產品。

元件

• Assessment — 分析你的來源倉儲日誌，估算 BigQuery slot 需求、識別不支援的 SQL 模式、報告資料表層級的讀取頻率，方便你排優先順序。
• Schema and Data Transfer — 從來源 DDL 生成 BigQuery DDL，處理型別對應（例如 Teradata DECIMAL(38,18) → BigQuery NUMERIC），並透過 STS 或 appliance 安排一次性資料 dump。
• SQL Translation (Batch and Interactive) — 將來源 SQL 方言轉成 GoogleSQL。Interactive translator 內建於 BigQuery console；batch translator 透過設定檔處理數千個查詢。

它不做的事

• 不會 逐字遷移 stored procedures 或工作流——Teradata BTEQ、Redshift stored procedures 通常需要手動改寫，或交給 Cloud Workflows 或 Dataform。
• 不處理 CDC。要在 parallel run 期間持續同步異動，請搭配 Datastream 或自訂 CDC 管線。

Data Validation Tool (DVT)

Data Validation Tool (DVT) 是 BigQuery Migration Service 的開源夥伴，由 Google Professional Services 在 GitHub 上維護（GoogleCloudPlatform/professional-services-data-validator）。它是 遷移後對帳 的事實標準工具。

DVT 做什麼

DVT 對來源端與目的端執行 相同的驗證查詢 並比較結果。支援的來源/目的組合包含 Teradata、Redshift、Snowflake、Oracle、SQL Server、PostgreSQL、MySQL、BigQuery、Spanner、AlloyDB。

驗證類型

• Column validation — 對數值欄位執行 COUNT、SUM、AVG、MIN、MAX。便宜，幾秒就跑完。
• Row validation — 把每一行（串接所有欄位後 SHA-256）做 hash，兩邊比對。昂貴但能抓出逐行漂移。
• Schema validation — 比對資料表 DDL：欄位名稱、型別、nullability。
• Custom query validation — 自帶 SQL（例如 SELECT customer_id, SUM(amount) FROM orders GROUP BY 1），DVT 在兩邊都跑一次。

DVT 的維運方式

• 可以用 Python CLI 跑、放進 Cloud Run job，或排進 Cloud Composer (Airflow) task。
• 結果寫入 BigQuery results table（pso_data_validator.results），用 Looker Studio 做儀表板輕鬆。
• 支援門檻容忍度：可以設定例如 ±0.01% 的 SUM 容差，吸收方言之間的浮點捨入差異。

Row-Count 與 Checksum 對帳模式

即使沒有 DVT，每份遷移 runbook 都必須包含 對帳查詢，讓稽核員之後也能重新跑一次。

三層對帳

1. Tier 1 — Row count（SELECT COUNT(*) FROM source.t vs SELECT COUNT(*) FROM dest.t）。能抓掉行；秒級執行；一定要做。
2. Tier 2 — Aggregate checksum（SELECT SUM(amount), MIN(created_at), MAX(created_at), COUNT(DISTINCT customer_id) FROM ...）。能抓出靜默的型別強轉（例如 DECIMAL 截斷）與時區位移 bug。
3. Tier 3 — Row-level hash（SELECT MD5(CONCAT(col1, col2, ...)) FROM ...）。能抓逐行漂移；昂貴——通常用抽樣（例如最近 7 天，或 WHERE MOD(id, 1000) = 0）。

真正抓到 bug 的對帳模式

• NULL 處理： COUNT(*) 相同但 COUNT(col) 差 1,200——來源有 NULL，ETL 過程被強轉成空字串。
• 時區漂移： MAX(created_at) 差 8 小時——來源是 Asia/Taipei，目的端誤認為 UTC。
• 浮點精度： 1000 萬行的 SUM(amount) 差 0.03——來源 DOUBLE 到目的端 NUMERIC 的捨入；可接受但要寫進文件。

Cutover Runbook

Cutover 是關鍵時刻——應用程式從舊系統切到新系統。好的 runbook 是 分鐘級的，並在切換前一週由 on-call 團隊複審。

Cutover 階段（以 DMS 到 Cloud SQL 為例）

1. T-7 天： DMS replication 跑起來；lag 儀表板連續 7 天綠燈。
2. T-1 天： 預演——在 staging clone 上跑一次 cutover、計時每一步、量測 rollback 所需時間。
3. T-2 小時： 凍結來源端 schema 變更；通知利害關係人。
4. T-0： 進入 maintenance window；把來源設為 唯讀（MySQL 的 FLUSH TABLES WITH READ LOCK，PostgreSQL 的 ALTER DATABASE ... ALLOW_CONNECTIONS false）。
5. T+2 分： 等待 DMS lag 歸 0；在目的端用 SHOW SLAVE STATUS 確認。
6. T+5 分： 在 DMS promote 目的端；在 canary 資料表跑 smoke-test 查詢（讀 + 寫）。
7. T+10 分： 切換應用程式連線字串（透過 Cloud DNS swap、HAProxy reconfig 或 Secret Manager 版本切換）；重啟 app pods。
8. T+15 分： 跑 Tier 1 對帳（前 20 大資料表的 row count）。
9. T+30 分： 跑 Tier 2 對帳（aggregate checksums）與 DVT。
10. T+60 分： 做簽收或 rollback 決定。

常見 cutover 失敗

• 連線字串快取： App pods 把舊 DNS 快取 5 分鐘；使用者打到唯讀的來源。對策：在 cutover 前 24 小時把 TTL 先壓到 30 秒。
• Sequence 漂移： 目的端的 auto-increment 計數比來源 max 小——第一筆寫入就 duplicate key。對策：promotion 後執行 SELECT setval('orders_id_seq', (SELECT MAX(id) FROM orders))。
• App server 時鐘偏移： 應用主機 NTP 飄了，寫進未來時間戳。對策：在預演時就驗證所有 writer 的時鐘差。

Backout Plan

Backout plan（或稱 rollback plan）是 cutover 失敗時回到來源系統的書面程序。沒有 backout plan = 不准上 production cutover。

真實的 backout plan 應該包含

• 判斷標準 — T+60 分時，只要符合 任何一條：row-count 差異 > 0.01%、P99 latency > 基線的 2 倍、錯誤率 > 0.5%、業務負責人說不行，就 rollback。
• 機制 — DMS 沒有「反向 promotion」按鈕。你必須在驗證期把 來源保持唯讀，然後把連線字串切回去；如果來源已經放回讀寫，你需要事先準備好反向 CDC 管線（Datastream 從 Cloud SQL 回到地端）——這條反向管線必須在 cutover 之前 就建好。
• 時間預算 — 多數 backout plan 的目標是 從決定到流量回到來源 < 30 分鐘。再久業務就會質疑 cutover 窗口本身有沒有設計好。
• 溝通計畫 — Slack 頻道、incident commander、面向客戶的狀態頁、監理機關通報（FSI/healthcare）。

Backout 窗口長度

• Cutover 後讓來源維持唯讀至少 7-14 天。這是為了慢燒 bug 買的保險（例如第 8 天才跑的月度帳單報表發現資料錯了）。
• BigQuery 遷移時，舊倉儲 + DTS 排程要平行跑滿一個完整業務週期（通常 30 天），方便做 A/B 報表對照。

資料驗證策略：確保完整性

如果資料損壞或不完整，遷移就是失敗的。架構師必須實施 驗證框架。

1. 校驗和 (MD5/CRC32C)

確保發送的每個位元都是接收到的位元。GCS 在上傳時會自動執行 MD5/CRC32C 檢查。對於大型遷移，請在傳輸後驗證來源端與目的端的校驗和。

2. 數量驗證 (Count Validation)

最簡單的檢查：對來源與目的端執行 SELECT COUNT(*)。如果數字不匹配，則表示遺失行數。

3. 架構驗證 (Schema Validation)

確保資料類型沒有改變（例如，在 ETL 過程中，「日期」欄位沒有變成「字串」欄位）。

4. 業務邏輯 / 抽查

挑選幾個「關鍵客戶」或「複雜記錄」，並手動驗證兩邊系統中的資料。

遷移模式：原樣搬遷 vs. 重構

• 離線 (Lift & Shift)： 匯出資料 -> 寄送磁碟 -> 匯入。停機時間長，複雜度低。
• 線上 (Replatform)： 設定副本 -> 同步資料 -> 切換。停機時間短，複雜度較高。
• 串流 (Refactor)： 使用 Pub/Sub 和 Dataflow 即時將資料導入新系統。

常見問題 — 資料遷移與驗證

Q1. 我什麼時候該使用 gsutil vs. Storage Transfer Service？

對於來自本機機器的臨時、小型傳輸，請使用 gsutil（或 gcloud storage）。對於大規模、排程或跨雲端傳輸，且希望 Google 管理縮放和重試時，請使用 STS。

Q2. 我該如何處理在漫長遷移過程中發生變化的資料？

使用 異動資料擷取 (Change Data Capture, CDC)。Database Migration Service (DMS) 透過讀取交易日誌並在目的端「重播 (Replaying)」它們，為 SQL 資料庫實現此功能。分析型目的端（BigQuery）則使用 Datastream。

Q3. 什麼是「切換 (Cutover)」，我該如何最小化停機時間？

切換是指將應用程式從舊資料庫指向新資料庫的時刻。為了最小化停機時間，請在最終同步期間在來源端使用「唯讀」模式，或使用代理層 (Proxy layer) 立即切換流量。詳見上方 Cutover Runbook 章節。

Q4. Transfer Appliance 會加密我的資料嗎？

會。資料在進入設備之前就在來源端以 AES-256 加密，金鑰由客戶自帶。Google 沒有金鑰；金鑰由你管理。

Q5. 為什麼即使有 10Gbps 的 Interconnect，我的遷移還是很慢？

常見瓶頸包括：

• 小檔案： 由於 metadata 開銷，移動數百萬個 1KB 的檔案比移動一個 1TB 的檔案慢得多。
• 磁碟 I/O： 你的來源儲存系統可能無法足夠快地讀取資料。
• MTU 不匹配： 網路封包分段會嚴重降低效能。

Q6. 我已經有 STS checksum 了，還需要 DVT 嗎？

需要。STS checksum 證明的是 物件完整性（位元有送到）；DVT 證明的是 語意完整性（行數、總和、schema 都對得上）。兩者回答的是不同問題，都不可省。

最後的架構師建議

在 PCA 考試中，如果你看到 「頻寬受限」 且 「資料量龐大」 的場景，答案幾乎總是 Transfer Appliance。如果資料來自 AWS S3，答案則是 Storage Transfer Service。如果是 營運資料庫遷移到 Cloud SQL/AlloyDB，答案是 DMS。如果是 CDC 進到 BigQuery 做分析，答案是 Datastream。如果是 舊資料倉儲的 SQL 轉換，答案是 BigQuery Migration Service 加上 DVT 做驗證。永遠搭配 cutover runbook 與 經過演練的 backout plan——校驗和是向利害關係人證明遷移成功的最佳工具。