這個架構提供架構和參考部署項目，協助您制定 BigQuery 備份策略。這個建議架構及其自動化功能可協助貴機構執行下列操作：
- 遵守貴機構的災難復原目標。
- 復原因人為錯誤而遺失的資料。
- 遵守法規。
- 提升作業效率。
BigQuery 資料的範圍可以包含 (或排除) 資料夾、專案、資料集和資料表。這個建議架構說明如何大規模自動執行週期性備份作業。您可以為每個資料表使用兩種備份方法：BigQuery 快照和 BigQuery 匯出至 Cloud Storage。
本文適用於雲端架構師、工程師和資料治理主管，協助他們在機構中定義及自動執行資料政策。
架構
下圖顯示自動備份架構：
上圖顯示的工作流程包含下列階段：
- Cloud Scheduler 會透過 Pub/Sub 訊息觸發執行作業，將 BigQuery 資料範圍 (包含和排除的資料) 傳送至調度員服務。系統會使用 Cron 運算式排定執行時間。
- 調度器服務 (以 Cloud Run 為基礎建構) 會使用 BigQuery API，列出 BigQuery 範圍內的資料表。
- 分派器服務會透過 Pub/Sub 訊息，為每個資料表向設定器服務提交一項要求。
Cloud Run 設定器服務會根據下列其中一個定義的選項，計算資料表的備份政策：
- 資料表層級政策，由資料擁有者定義。
- 備援政策，由資料治理主管為沒有定義政策的資料表設定。
如要進一步瞭解備份政策，請參閱備份政策。
設定器服務會根據計算出的備份政策，為每個資料表向下一個服務提交一項要求。
視備份方法而定，下列其中一項自訂 Cloud Run 服務會向 BigQuery API 提交要求，並執行備份程序：
- BigQuery 快照服務會將資料表備份為快照。
- 資料匯出服務會將資料表備份為匯出至 Cloud Storage 的資料。
如果備份方法是匯出表格資料，Cloud Logging 記錄接收器會監聽匯出作業完成事件，以便非同步執行下一個步驟。
備份服務完成作業後，Pub/Sub 會觸發標記器服務。
針對每個資料表，標記服務會記錄備份服務的結果，並更新 Cloud Storage 中繼資料層的備份狀態。
使用的產品
這項參考架構使用下列 Google Cloud 產品：
- BigQuery：企業資料倉儲，內建機器學習、地理空間分析和商業智慧等功能，有助於管理及分析資料。
- Cloud Logging：即時記錄管理系統，提供儲存、搜尋、分析和快訊功能。
- Pub/Sub：可擴充的非同步訊息服務，會分離產生訊息的服務與處理訊息的服務。
- Cloud Run：無伺服器運算平台，可讓您在 Google 可擴充的基礎架構上直接執行容器。
- Cloud Storage：適用於多種資料類型的物件儲存庫，成本低廉且沒有限制。 資料在 Google Cloud 內外都能存取，且會複製到多個位置，以便提供備援機制。 Google Cloud
- Cloud Scheduler：全代管的企業級 Cron 工作排程器，可讓您設定工作的排程單元，以便在設定的時間或以固定的頻率執行特定工作。
- Datastore：具備高度擴充性的 NoSQL 資料庫，適用於網頁和行動應用程式。
用途
本節提供可使用此架構的應用實例範例。
備份自動化
舉例來說，貴公司可能在受監管的產業中營運，並使用 BigQuery 做為主要資料倉儲。即使貴公司遵循軟體開發、程式碼審查和發布工程的最佳做法，仍有因人為錯誤而導致資料遺失或損毀的風險。在受監管的產業中，您必須盡可能降低這項風險。
這類人為錯誤的例子包括：
- 不慎刪除資料表。
- 資料管道邏輯有誤，導致資料損毀。
這類人為錯誤通常可透過時空旅行功能解決，這項功能可讓您復原最多七天前的資料。此外，BigQuery 也提供安全期，在時移視窗過後，刪除的資料會額外保留在安全儲存空間七天。您可以透過 Cloud Customer Care 服務，在緊急情況下復原這些資料。不過，如果貴公司未在上述時間內發現並修正這類錯誤，刪除的資料就無法從最後的穩定狀態復原。
為減輕這類情況的影響，建議您定期備份無法從來源資料重建的 BigQuery 資料表 (例如歷來記錄或業務邏輯不斷演變的 KPI)。
貴公司可以使用基本指令碼備份數十個表格。不過，如果需要定期備份整個機構的數百或數千個資料表，您就需要可擴充的自動化解決方案，以便執行下列操作：
- 處理不同的 Google Cloud API 限制。
- 提供標準化架構，用於定義備份政策。
- 提供備份作業的透明度和監控功能。
備份政策
貴公司也可能要求由下列群組定義備份政策：
- 資料擁有者最瞭解資料表，因此可以設定適當的資料表層級備份政策。
- 資料控管團隊，負責確保已制定備援政策，涵蓋所有沒有資料表層級政策的資料表。備援政策可確保特定資料集、專案和資料夾會備份，以符合貴公司的資料保留法規。
在這個參考架構的部署作業中，定義資料表備份政策的方式有兩種，而且可以同時使用：
資料擁有者設定 (去中心化)：資料表層級的備份政策，手動附加至資料表。
- 資料擁有者會定義儲存在通用值區中的資料表層級 JSON 檔案。
- 解決方案判斷資料表的備份政策時，手動政策的優先順序高於備援政策。
- 如要瞭解部署作業的詳細資料，請參閱「設定資料表層級備份政策」。
機構預設設定 (集中式)：備援政策，僅適用於未手動附加政策的資料表。
- 資料控管團隊會在 Terraform 中定義中央 JSON 檔案，做為解決方案的一部分。
- 備援政策會在資料夾、專案、資料集和資料表層級提供預設備份策略。
- 如需部署作業的詳細資訊，請參閱「定義備用備份政策」。
備份與複製
備份程序會複製特定時間點的資料表資料，以便在資料遺失或毀損時還原。您可以執行一次性備份，也可以透過排定的查詢或工作流程，定期執行備份。在 BigQuery 中，您可以使用快照建立時間點備份。您可以使用快照，在與來源資料相同的儲存位置，保留七天時間旅行期以外的資料副本。BigQuery 快照特別適合在人為錯誤導致資料遺失或損毀時復原資料，而非從區域性故障中復原。BigQuery 根據版本提供99.9% 至 99.99% 的服務等級目標 (SLO)。
相較之下，複製是持續將資料庫變更內容複製到其他位置的次要 (或副本) 資料庫。在 BigQuery 中，跨區域複製功能可透過在次要 Google Cloud 區域建立資料的唯讀副本，提供地理位置備援，這些區域與來源資料區域不同。不過，BigQuery 跨區域複製功能不適用於區域全面中斷情境的災難復原計畫。如要防範區域性災害，請考慮使用 BigQuery 代管的災害復原機制。
BigQuery 跨區域複製功能會在靠近資料消費者的區域中，提供資料的同步唯讀副本。這些資料副本可啟用共置聯結，避免跨區域流量和費用。不過，如果資料因人為錯誤而毀損，單靠複製作業無法復原，因為毀損的資料會自動複製到備用資源。在這種情況下，時間點備份 (快照) 是較好的選擇。
下表摘要比較了備份方法和複製作業：
| 方法 | 頻率 | 儲存空間位置 | 用途 | 費用 |
|---|---|---|---|---|
| 備份 (快照或 Cloud Storage 匯出) |
一次性或週期性 | 與來源資料表資料相同 | 還原時間旅行期間以外的原始資料 | 快照只會針對快照中的資料變更產生儲存空間費用 匯出作業可能會產生標準儲存空間費用 請參閱成本最佳化 |
| 跨區域複製 | 持續 | 遠端 | 在其他區域建立副本 區域間的一次性遷移 |
資料儲存費用 (副本) 資料複製費用 |
設計須知
本節提供指引，說明您使用這個參考架構開發拓撲時，應考量哪些事項，以符合安全性、可靠性、成本最佳化、作業效率和效能方面的特定需求。
安全性、隱私權和法規遵循
部署作業在設計和實作時，會納入下列安全措施：
- Cloud Run 的網路輸入設定只接受內部流量，以限制網際網路存取權。此外，只有經過驗證的使用者和服務帳戶才能呼叫服務。
- 每項 Cloud Run 服務和 Pub/Sub 訂閱項目都會使用個別的服務帳戶，且只會指派必要的權限。這樣做可降低系統使用單一服務帳戶的相關風險，並遵循最低權限原則。
基於隱私權考量，這項解決方案不會收集或處理個人識別資訊 (PII)。不過，如果來源資料表含有外洩的 PII，這些資料表的備份檔也會包含外洩資料。來源資料的擁有者有責任保護來源資料表中的任何 PII (例如套用資料欄層級安全保護措施、資料遮蓋或編輯)。只有在來源資料安全無虞時，備份作業才會安全。另一種做法是確保含有公開 PII 的備份資料所屬專案、資料集或值區，都具備必要的 Identity and Access Management (IAM) 政策，只允許授權使用者存取。
做為通用解決方案，參考部署不一定會遵守特定產業的具體規定。
可靠性
本節說明可靠性的功能和設計考量。
以精細程度降低失敗率
如要備份數千個資料表，您可能會達到基礎 Google Cloud 產品的 API 限制 (例如每個專案的快照和匯出作業限制)。不過，如果某個資料表的備份作業因設定錯誤或其他暫時性問題而失敗，這不應影響整體執行作業，也不會妨礙備份其他資料表。
為減輕潛在的故障問題，參考部署作業會使用細微的 Cloud Run 服務，並透過 Pub/Sub 連接這些服務，藉此將處理步驟分離。如果資料表備份要求在最後的標記器服務步驟失敗，Pub/Sub 只會重試這個步驟，不會重試整個程序。
將流程細分成多項 Cloud Run 服務，而不是在單一 Cloud Run 服務下代管多個端點，有助於精細控管各項服務設定。設定層級取決於服務的功能和通訊的 API。舉例來說，調度員服務會在每次執行時執行一次，但需要相當長的時間才能列出 BigQuery 備份範圍內的所有資料表。因此，調度員服務需要較高的逾時和記憶體設定。不過，BigQuery 快照的 Cloud Run 服務會在單次執行中，為每個資料表執行一次，且完成時間比調度器服務短。因此，Cloud Run 服務需要在服務層級進行不同的設定。
資料一致性
資料表和檢視區塊之間的一致性，對於維持可靠的備份策略至關重要。由於資料會持續更新和修改，不同時間點的備份資料可能擷取到不同的資料集狀態。不同狀態的備份可能會導致還原資料時發生不一致的情況，尤其是屬於相同功能資料集的資料表。舉例來說，如果將銷售資料表還原至與對應的庫存資料表不同的時間點，可能會導致可用庫存不符。同樣地，從多個資料表彙整資料的資料庫檢視畫面，對不一致的情況特別敏感。如果未確保基礎資料表處於一致狀態，就還原這些檢視區塊，可能會導致結果不準確或誤導。因此，設計 BigQuery 備份政策和頻率時，請務必考量這項一致性，確保還原的資料能準確反映資料集在特定時間點的實際狀態。
舉例來說，在此參考架構的部署作業中，資料一致性是透過備份政策中的下列兩項設定控管。這些設定會透過時空旅行計算確切的資料表快照時間，不一定會同時備份所有資料表。
backup_cron：控管資料表的備份頻率。系統會使用執行作業的開始時間戳記做為時間參照點，計算這項作業中備份的所有資料表的時間旅行。backup_time_travel_offset_days：控制要從時間參考點 (執行開始時間) 減去多少天，以計算資料表的確切時間旅行版本。
自動還原備份
雖然這個參考架構的重點在於大規模自動備份，但您也可以考慮以自動方式還原這些備份。這項額外自動化功能可提供與備份自動化功能類似的優點，包括提升復原效率和速度，並減少停機時間。由於這項解決方案會透過標記器服務追蹤所有備份參數和結果，因此您可以開發類似的架構，大規模套用還原作業。
舉例來說，您可以根據隨選觸發程序建立解決方案，將 BigQuery 資料範圍傳送至調度員服務，該服務會為每個資料表向設定器服務調度一項要求。設定器服務可以擷取特定資料表的備份記錄。然後，設定器服務可將其傳遞至 BigQuery 快照還原服務或 Cloud Storage 還原服務，以相應地套用還原作業。最後，標記器服務可能會將這些作業的結果儲存在狀態儲存空間。這麼做可讓自動還原架構享有與本文件詳述備份架構相同的設計目標。
成本最佳化
這個架構的架構提供備份政策，可為整體成本最佳化設定下列參數：
- 備份方法：架構提供下列兩種備份方法：
- 快照到期：為單一資料表快照設定存留時間 (TTL)，以免快照無限期產生儲存空間費用。如果資料表沒有到期時間，儲存空間費用可能會隨著時間增加。
提升作業效率
本節說明作業效率相關功能和注意事項。
精細且可擴充的備份政策
這個架構的目標之一是提高營運效率，也就是在業務投入相對較低且可管理的情況下，擴大業務產出。舉例來說，輸出內容是大量定期備份的資料表，而輸入內容是少數維護的備份政策和設定。
除了允許在資料表層級設定備份政策外，這個架構也允許在資料集、專案、資料夾和全域層級設定政策。也就是說，只要在較高層級 (例如資料夾或專案層級) 進行幾項設定，就能大規模定期備份數百或數千個資料表。
觀測能力
使用自動化架構時，瞭解程序的狀態至關重要。舉例來說，您應該可以找到下列常見查詢的資訊：
- 系統為每個資料表使用的備份政策。
- 每個資料表的備份記錄和備份位置。
- 單次執行的整體狀態 (已處理的資料表數量和失敗的資料表數量)。
- 單次執行時發生的重大錯誤，以及發生錯誤的程序元件或步驟。
為提供這項資訊，部署作業會在每個使用 Cloud Run 服務的執行步驟中，將結構化記錄寫入 Cloud Logging。記錄檔會包含輸入內容、輸出內容和錯誤，以及其他進度檢查點。記錄接收器會將這些記錄檔轉送至 BigQuery 資料表。您可以執行多項查詢，監控執行作業並取得報表，以瞭解常見的可觀測性用途。如要進一步瞭解 BigQuery 中的記錄和查詢，請參閱「查看已路由至 BigQuery 的記錄」。
效能最佳化
為在每次執行時處理數千個資料表，這項解決方案會平行處理備份要求。調度器服務會列出 BigQuery 備份範圍內的所有資料表，並在每次執行時為每個資料表產生一個備份要求。這樣一來，應用程式就能平行處理數千個要求和表格，而非依序處理。
這些要求一開始可能會因暫時性原因而失敗，例如達到基礎 Google Cloud API 的限制，或是發生網路問題。在要求完成前，Pub/Sub 會自動使用指數輪詢重試政策重試要求。如果發生備份目的地無效或缺少權限等重大錯誤，系統會記錄錯誤，並終止該特定資料表要求的執行作業，但不會影響整體執行作業。
限制
這項架構適用下列配額和限制。
如果是資料表快照，您指定的每個備份作業專案都適用下列規定：
- 每個專案最多可同時執行 100 項資料表快照工作。
- 每個專案每天最多可執行 50,000 個資料表快照工作。
- 每個專案每天最多可為每個資料表執行 50 個資料表快照工作。
詳情請參閱「資料表快照」。
如果是匯出工作 (匯出至 Cloud Storage)，則適用下列規定：
- 使用共用運算單元集區，即可免費從專案每日匯出最多 50 TiB 的資料。
- 每個專案每天最多可執行 100,000 次匯出作業。如要延長這項限制，請建立運算單元保留項目。
如要進一步瞭解如何延長這些限制，請參閱匯出工作。
至於並行限制，這個架構會使用 Pub/Sub 自動重試因這些限制而失敗的要求，直到 API 處理要求為止。不過，如果每日每個專案的作業數量達到其他限制，您可以要求增加配額，或是將備份作業 (快照或匯出) 分散到多個專案，藉此減輕影響。如要將作業分散到各個專案，請按照下列部署章節的說明設定備份政策：
部署作業
如要部署這項架構，請參閱「部署可擴充的 BigQuery 自動備份功能」。
後續步驟
- 進一步瞭解 BigQuery：
- 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。
貢獻者
作者：Karim Wadie | 策略雲端工程師
其他貢獻者：
- Chris DeForeest | 網站可靠性工程師
- Eyal Ben Ivri | 雲端解決方案架構師
- Jason Davenport | 開發人員服務代表
- Jaliya Ekanayake | 工程經理
- Muhammad Zain | 策略雲端工程師