在 BigQuery 中持續整合資料

本文說明實作可重複工作流程的原則和技術，協助您將資料變更整合至以 BigQuery 為基礎的資料倉儲 (DWH)。這些異動可能包括新資料集、新資料來源，或現有資料集的更新和變更。此外，這份文件也說明瞭這項工作的參考架構。

本文件適用於使用 BigQuery 做為 DWH 的軟體和資料架構師，以及資料工程師。本文假設您熟悉 CI/CD 的基本概念，或類似的應用程式生命週期管理做法。

簡介

持續整合和持續推送軟體更新 (CI/CD) 已成為軟體開發生命週期中的重要技術。相較於手動整合及部署功能，採用 CI/CD 原則可讓團隊提供更優質的軟體，並減少問題。在翻新資料倉儲時，CI/CD 也能做為資料管理策略的一部分。

不過，使用 BigQuery 等 DWH 時，實作 CI/CD 的方式與在原始碼中實作 CI/CD 的方式不同。這些差異部分是因為資料倉儲本質上是有狀態的系統，用於管理基礎資料。

本文提供下列資訊：

  • 在 BigQuery 中實作持續整合 (CI) 策略的技術。
  • 協助您避免錯誤的指引和方法。
  • BigQuery 功能建議，有助於在 BigQuery 中執行 CI。

本文著重於 CI，因為對資料倉儲團隊來說，整合比持續推送軟體更新 (CD) 有更多資料相關考量。

何時應為 BigQuery DWH 使用 CI

在本文件中，「資料整合」通常是由 DWH 團隊執行的工作，包括將新資料納入 DWH。這項工作可能涉及將新的資料來源納入 DWH，或變更 DWH 內資料表的結構。

將新資料整合至 DWH 的工作，類似於將新功能整合至現有軟體。這可能會導致錯誤，並對使用者體驗造成負面影響。將資料整合至 BigQuery 時，資料的下游消費者 (例如應用程式、BI 資訊主頁和個別使用者) 可能會因結構定義不符而遇到問題。或者，消費者可能會使用不正確的資料，無法反映原始資料來源的資料。

如要執行下列操作，CI for DWH 相當實用：

  • 說明 DWH 系統 CI 的重點。
  • 為 BigQuery 環境設計及實作 CI 策略。
  • 瞭解如何使用 BigQuery 功能實作 CI。

本指南不會說明如何管理非 DWH 產品的 CI，包括 Dataflow 和 Bigtable 等資料產品。

情境示例

Example Company 是一家大型零售公司，在 BigQuery 中維護資料倉儲。在接下來的一年，該公司希望將新資料來源整合至 DWH，這些資料來源來自 Example Company 最近收購的公司。要整合的新資料來源具有不同的結構定義。不過，DWH 必須保留現有結構定義，並提供強大的資料一致性和資料完整性，以免對下游資料消費者造成負面影響。

目前，Example Company 的 DWH 團隊會執行資料整合。這項整合功能需要現有資料來源採用預先定義的結構定義。這個工作流程涉及舊版資料匯入程序、取得的資料庫和應用程式服務。

為了更新資料整合程序，以容納新的資料來源，DWH 團隊必須重新設計資料整合方法，以符合先前所述的要求，例如強式資料一致性。團隊必須以獨立方式實作變更，以便在資料提供給下游消費者之前，測試及評估資料變更。

DWH 團隊採用新工作流程後，團隊會有一套可重複執行的程序。每位開發人員都能根據實際工作環境資料，建立獨立的開發環境。開發人員可以使用這些獨立環境進行變更、測試、審查，並將所需變更推送至正式環境。如果變更導致錯誤或未預期的問題，可以輕鬆復原。

持續整合對資料倉儲的意義

持續整合 (CI) 是一套做法，可讓開發團隊縮短開發週期，並比手動系統更快找出程式碼中的問題。採用 CI 方法的主要好處是能夠快速開發，降低開發人員之間互相干擾的風險。為達成這個目標，必須確保程序可重複執行，同時讓每位開發人員獨立作業，不受其他開發人員影響。

當組織必須將資料整合至 DWH 時，這些原則也適用，但有一些差異。在一般軟體開發中，CI 會隔離對原始碼的變更，而原始碼是無狀態的。在資料 CI 的情境中，CI 會將資料整合至 DWH 系統。不過，資料在本質上是有狀態的。如本文所述，這項差異會影響 CI 套用至 DWH 情境的方式。

本文未涵蓋的其他情境

雖然本文著重於將開發變更與正式環境隔離，但並未涵蓋下列資料整合層面：

  • 資料測試：您能否驗證現有資料是否符合業務需求？資料是否可靠，可做為可靠資料來源？為提高 DWH 提供的資料可信度，請務必測試資料。如要測試，您可以執行一組查詢，確認資料是否缺少值或包含「不正確」的值。
  • 資料歷程：您是否能查看任何資料表的背景資訊？舉例來說，您是否能看出資料的收集來源，以及哪些資料集經過預先運算，才產生這個資料表？在現代 DWH 架構中，資料會分割到多個系統，並使用不同的專門資料結構。包括關聯式資料庫、NoSQL 資料庫和外部資料來源。如要充分瞭解您擁有的資料，就必須追蹤這些資料。您也必須瞭解資料的生成方式和來源。

這些主題不在本指南的討論範圍內。不過，在為團隊設計工作流程時，如果能針對這些主題進行規劃，將有助於制定資料策略。

將 BigQuery 設為資料倉儲的一般設定

下圖說明 BigQuery 的典型 DWH 設計。說明如何將外部來源的資料擷取至 DWH，以及消費者如何使用 DWH 的資料。

Google Cloud 外部的三個資料庫是資料來源。資料會移至暫存區的儲存空間。接著，資料會移至 BigQuery 資料表，也就是 BigQuery 檢視表的來源。Looker、App Engine、Gemini Enterprise Agent Platform 筆記本和真人使用者等消費者，會使用檢視表來取用資料。

資料會從資料來源開始，其中資料位於傳統交易或低延遲資料庫，例如 OLTP SQL 資料庫和 NoSQL 資料庫。排定的程序會將資料複製到暫存區。

資料會暫時儲存在暫存區。如有需要，資料會先轉換為適合分析系統的格式，再載入 DWH 資料表。(在本圖中，暫存區位於 Google Cloud內，但並非必要)。轉換作業可能包括去正規化、充實特定資料集，或處理格式錯誤的項目 (例如缺少值的項目)。

新資料會從暫存區載入 DWH 資料表。資料表的編排方式可能因 DWH 的設計而異，通常稱為「核心資料表」。資料表設計範例包括星形結構定義、反正規化和多層級匯總。

無論資料表設計為何，這些資料表都會隨著時間儲存資料。資料表必須遵循結構定義，且應保留所有分析用途的可靠資料來源。這代表資料表中的資料必須完整、一致，且符合預先定義的結構定義。

這些資料表不會直接向消費者提供資料，而是透過存取層提供資料，該層旨在封裝必須套用至基礎資料的商業邏輯。這類商業邏輯的例子包括計算每筆記錄的指標，或篩選及分組資料。

資料消費者可以連線至 DWH 存取層並讀取資料。這類資料消費者可能包括下列系統：

  • 商業智慧 (BI) 資訊主頁
  • 資料科學筆記本
  • 依賴 DWH 計算資料的作業系統
  • 執行臨時查詢的人類使用者

資料消費者高度仰賴 DWH 提供一致的結構定義，以及 DWH 封裝的商業邏輯。這些結構定義和商業邏輯可視為 DWH 平台的服務水準協議 (SLA)。商業邏輯、結構定義或資料完整性的任何變更，都可能對下游產生重大影響。現代資料平台瞬息萬變，DWH 團隊可能需要進行這些變更，但仍須嚴格遵守服務水準協議。為了讓團隊符合這些服務水準協議，並保持 DWH 最新狀態，他們需要一個能整合資料的工作流程，同時盡可能減少這些變更可能造成的摩擦。

在資料倉儲中持續整合的資產

與其他開發或 IT 團隊一樣，DWH 團隊必須維護其職責所必需的資產。這些資產通常可分為以下幾類：

  • 資料管道的程式碼集：這些資產通常包含以高階程式設計語言 (例如 Python 或 Java) 編寫的原始碼。對於這類資產，CI/CD 程序是使用 Git 和 Jenkins 等工具，或使用Google Cloud 解決方案 (例如 Cloud Source Repositories 和 Cloud Build) 建構。

  • SQL 指令碼：這些資產描述 DWH 內封裝的結構和商業邏輯。在這個類別中，資產可進一步分為以下子類別：

    • 資料定義語言 (DDL)：這些資產用於定義資料表和檢視表的結構定義。
    • data manipulation language (DML)：這些資產用於操縱資料表中的資料。DML 指令也可用於根據現有資料表建立新資料表。
    • 資料控制語言 (DCL)：這類資產用於控管資料表的權限和存取權。在 BigQuery 中，您可以使用 SQL 和 bq 指令列工具，或使用 BigQuery REST API 來控管存取權。不過，建議您使用 IAM。

這些資產以及用於建構元件的其他資產 (例如 Terraform 指令碼)，都會在程式碼存放區中維護。Dataform 等工具可協助您建構 CI/CD 管道，驗證 SQL 指令碼，並檢查 DDL 指令碼建立的資料表是否符合預先定義的驗證規則。這些工具可讓您對 SQL 套用編譯和測試程序，在大多數情況下，SQL 沒有自然的測試環境。

除了與工具和程序相關聯的資產外，DWH 團隊的主要資產是資料。資料無法使用 Git 等資產追蹤系統追蹤，因為這類系統是專為追蹤原始碼而設計。本文將說明與追蹤資料相關的問題。

整合資料時發生問題

由於 DWH 內資料表關係可能很複雜 (例如，在上述其中一種資料表設計範例中)，因此將正式環境資料的狀態與測試環境隔離是一項挑戰。軟體開發的標準做法不適用於資料整合情境。

下表摘要說明整合程式碼和整合資料的做法差異。

  整合程式碼 整合資料
本機開發 原始碼體積相對較小，因此很容易複製。一般來說，程式碼適用於大多數使用者機器 (不包括單一存放區，這類情況有其他解決方案)。 DWH 中的大多數資料表都因大小而無法放入開發機器。
集中測試 原始碼的不同狀態會複製到中央系統 (CI 伺服器)，以便進行自動化測試。程式碼有不同狀態，可讓您比較穩定版和開發中版本的結果。 在獨立環境中建立不同的資料狀態並不容易。將資料移出 DWH 是一項耗費資源且耗時的操作。因此無法按照測試需求頻繁執行。
過往版本 在發布新版軟體的過程中，您可以追蹤過去的版本。如果在新版本中偵測到問題，可以復原至安全版本。 備份 DWH 中的資料表是標準做法，以防需要復原。不過，您必須確保所有受影響的資料表都復原至相同時間點。這樣一來，相關資料表就會彼此一致。

將資料整合至 BigQuery 資料表

BigQuery 有兩項功能可協助您設計資料整合工作流程：資料表快照和資料表複製。您可以結合這些功能，建立符合成本效益的開發環境工作流程。開發人員可以獨立於正式環境之外，操作資料及其結構，並在必要時復原變更。

BigQuery 資料表快照是資料表 (稱為「基礎資料表」) 在特定時間點的唯讀表示法。同樣地，BigQuery 資料表複製作業是資料表在特定時間點的讀寫表示法。無論是哪種情況，由於只會儲存與基礎資料表的差異，因此儲存費用會降到最低。基礎資料表或資料表本機副本變更時，資料表本機副本就會開始產生費用。資料表快照為唯讀，因此只有在基礎資料表變更時，才會產生費用。

如要進一步瞭解資料表快照和資料表本機副本的定價，請參閱「資料表快照簡介」和「資料表本機副本簡介」。

您可以使用 BigQuery 時光旅行功能 (最多可回溯至過去七天)，建立資料表快照和資料表複製。這項功能可讓您在同一時間點擷取多個資料表的快照和複製項目，確保工作環境和快照彼此一致。這項功能適用於經常更新的資料表。

如何使用資料表複製作業和資料表快照來隔離資料

為說明 DWH 中 CI 的整合工作流程，請想像以下情境。您的任務是將新資料集整合至 DWH。工作可能是建立新的 DWH 資料表、更新現有資料表、變更資料表結構，或上述工作的任何組合。工作流程可能如下所示：

  1. 您找出可能受變更影響的資料表，以及可能需要檢查的其他資料表。
  2. 您建立新的 BigQuery 資料集，用於存放這項變更的資產。這個資料集有助於隔離變更，並將這項工作與其他團隊成員執行的其他工作區隔開來。資料集必須與來源資料集位於相同區域。不過，您可以將該專案與正式環境專案分開，以符合貴組織的安全性與計費需求。

  3. 您可以在新資料集中，為每個資料表建立複製版本和快照，兩者可能屬於同一時間點。此方法具備下列優點：

    • 資料表複製版本可做為工作副本，您可以在其中自由變更，不會影響正式資料表。您可以為同一個基礎資料表建立多個資料表複製項目，同時測試不同的整合路徑，盡可能減少負擔。
    • 快照可做為還原和參考點，也就是在任何變更發生前，資料已知可正常運作的時間點。有了這個快照，您就能在後續程序中偵測到問題時執行復原作業。

  4. 您可以使用資料表複製作業，對資料表進行必要的變更。這項操作會產生更新版的資料表複製，您可以在獨立資料集中測試。

  5. 您也可以在實作階段結束時，提供可用於下列工作的資料集：

    • 使用 Dataform 等驗證工具進行單元測試。單元測試是獨立的，也就是說，素材資源會單獨測試。在本例中，資產是 BigQuery 中的資料表。單元測試可以檢查空值、驗證所有字串是否符合長度要求，並確保特定匯總產生實用結果。單元測試可包含任何信心測試，確保資料表符合組織的業務規則。
    • 與下游消費者進行整合測試。
    • 同儕審查。

    這項工作流程可讓您使用實際工作環境資料進行測試，而不會影響下游消費者。

  6. 將新資料合併至 BigQuery 前，您可以建立另一個快照。如果基礎資料表中的資料有所變更，這個快照可做為另一個復原選項。

    合併變更的程序取決於貴組織要採用的程序，以及需要進行哪些變更。舉例來說，如果 SQL 指令碼有變更，新資料集可能會伴隨對標準程式碼集的提取要求。如果變更僅限於特定資料表中的資料，您可以使用 BigQuery 的標準方法複製資料。

您可以使用預存程序指令碼，封裝及自動執行建立資料集、複製項目和快照的步驟。自動執行這些工作可降低人為錯誤的風險。如需可協助自動化程序的指令碼範例，請參閱 CI for Data in BigQuery CLI 公用程式 GitHub 存放區。

使用資料表本機副本和資料表快照的好處

使用上一節所述的工作流程時，開發人員可以獨立並行工作，不會干擾同事。開發人員可以測試及審查變更，並在發生問題時復原變更。由於您使用的是資料表快照，而非完整資料表，因此與使用完整資料表相比，可以大幅降低成本和儲存空間。

本節將進一步說明資料表快照和資料表複製作業如何協助開發人員完成這項工作流程。下圖顯示資料表快照和資料表複製項目與正式資料集內資料的關係。

某個正式環境資料集含有 9 個資料表。第二個資料集名為「Dev Dataset 1」，包含資料表 2 和 3 的快照，以及資料表 2 和 3 的複製版本。第三個資料集名為「Dev Dataset 2」，包含資料表 3 和 4 的快照，以及資料表 3 和 4 的複製版本。

在圖表中，正式資料集包含正式環境中使用的所有資料表。每位開發人員都可以為自己的開發環境建立資料集。圖表顯示兩個開發人員資料集，分別標示為「Dev Dataset 1」和「Dev Dataset 2」。使用這些開發人員資料集，開發人員就能同時處理相同的資料表，不會互相干擾。

開發人員建立資料集後，可以建立正在處理的資料表複製版本和快照。複製項目和快照代表特定時間點的資料。此時，開發人員可以自由變更資料表本機副本，因為變更不會顯示在基礎資料表上。

開發人員可以查看資料表複製版本、與快照進行比較，並測試與下游消費者的相容性。其他開發人員可以處理其他複製項目和快照，不會受到干擾，也不會建立過多耗用資源的基礎資料表副本。

開發人員可以將變更合併至基礎資料表，同時保留快照，以便在需要時復原。您也可以針對開發、測試和正式環境等不同環境，重複執行這項程序。

資料表本機副本和資料表快照的替代方案

除了使用資料表複製和資料表快照，您也可以透過其他方式達到類似效果。這些替代方法的使用方式通常與複製和快照不同。請務必瞭解這些方法之間的差異，以及您可能偏好其中一種方法的原因。

將整個資料表複製到其他資料集

另一種方法是使用其他資料集，並將資料表複製到該資料集。這個方法與使用資料表複製和快照類似，但您會複製整組資料表。視複製的資料大小而定，儲存費用可能會很高。在 BigQuery 推出資料表複製功能之前，部分組織會使用這種方法。不過，這個方法與使用複製和快照相比，並沒有任何優勢。

將資料表匯出及匯入至 Cloud Storage

另一種替代方法是透過 Cloud Storage 移動資料。這種方法也與使用資料表複製和資料表快照類似。不過，這項做法需要額外執行一個步驟，將資料匯出至 Cloud Storage bucket。這個方法的優點是可為資料提供額外備份。如果您需要備份來進行災難復原或混合式解決方案，可以選擇這個方法。

使用 BigQuery 共用功能

BigQuery sharing (舊稱 Analytics Hub) 可讓您以安全的方式，與組織內外共用資料集。這項服務提供多項功能，可讓您發布資料集，並提供訂閱者對這些資料集的控管、唯讀存取權。不過，即使您可以使用 BigQuery sharing 公開資料集來實作變更，開發人員仍須建立資料表複製版本，才能使用資料表。

DWH 持續整合選項摘要

下表摘要說明 DWH 持續整合選項之間的差異、優點和潛在缺點。(分享功能提供不同的功能組合，因此無法使用表格中列出的參數進行評估)。

  費用 復原 風險
資料表快照和資料表本機副本 極簡。您只需支付快照或複製資料表與基礎資料表之間的差額。 快照可做為備份，以便在必要時復原。 您可以控管風險程度。您可以擷取所有資料表在某個時間點的快照，即使復原，也能減少不一致的情況。
資料表複製 費用高於使用資料表快照和資料表本機副本。所有資料都會複製。如要支援復原功能 您需要同一資料表的多個副本 可以，但需要兩份資料表，一份做為備份，另一份用於處理及變更。 複製時間點資料的難度較高。如果需要復原，並非所有資料表都會從相同時間點擷取。
匯出及匯入 費用高於使用資料表快照和資料表本機副本。資料會重複。如要支援復原，您需要同一資料表的多個副本。 匯出的資料可做為備份。 匯出的資料並非多個資料表的特定時間點匯出作業。

後續步驟