在 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 時，資料的下游消費者 (例如應用程式、商業智慧資訊主頁和個別使用者) 可能會因結構定義不符而發生問題。或者，消費者可能會使用不正確的資料，無法反映原始資料來源的資料。

如果您想執行下列操作，DWH 的 CI 就非常實用：

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

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

範例情境

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

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

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

DWH 團隊採用新工作流程後，就能重複使用這個程序。每位開發人員都能建立以實際工作環境資料為基礎的獨立開發環境。開發人員可使用這些獨立環境進行變更、測試、審查，並將必要變更項目交付至正式版環境。如果變更導致錯誤或發生無法預料的問題，可以輕鬆復原。

持續整合對 DWH 的意義

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

如果機構必須將資料整合至 DWH，也適用這些原則，但有幾項差異。在一般軟體開發環境中，CI 會隔離對無狀態原始碼所做的變更。在資料的 CI 脈絡中，CI 會將資料整合至 DWH 系統。不過，資料的定義就是有狀態。如本文所述，這項差異會影響 CI 在 DWH 情境中的適用方式。

本文未涵蓋的其他情境

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

  • 資料測試：您是否能驗證資料符合業務需求？資料是否可靠，可做為事實來源？如要提高對 DWH 放送資料的信心程度，請務必測試資料。如要測試，您可以執行一組查詢，確認資料沒有遺漏值，或確認資料包含「錯誤」值。
  • 資料沿襲：您是否能在資料表的環境中查看資料表？舉例來說，您是否能查看資料的收集來源，以及為了產生資料表而預先運算的資料集？在現代 DWH 架構中，資料會拆分成許多系統，這些系統使用不同的專用資料結構。包括關聯式資料庫、NoSQL 資料庫和外部資料來源。如要充分瞭解您擁有的資料，就必須追蹤這些資料。您也必須瞭解資料的產生方式和來源。

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

將 BigQuery 設為 DWH 的典型設定

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

Google Cloud 以外的三個資料庫是資料來源。資料會移至暫存區的儲存空間。資料接著會移至 BigQuery 資料表，這些資料表是 BigQuery 檢視區塊的來源。Looker、App Engine、Vertex AI Notebooks 和使用者等消費者會使用這些檢視區塊取用資料。

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

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

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

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

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

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

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

資料消費者非常依賴 DWH 提供一致的結構定義，以及 DWH 封裝的業務邏輯。這些結構定義和業務邏輯可視為 DWH 平台的服務水準協議 (SLA)。商業邏輯、結構定義或資料完整性如有任何變更，都可能對下游造成重大影響。現代資料平台不斷演進，因此 DWH 團隊可能需要進行這些變更，但仍須嚴格遵守服務等級協議。為確保團隊能達到這些 SLA，並讓 DWH 維持最新狀態，他們需要工作流程來整合資料，同時盡量減少這些變更可能造成的阻礙。

DWH 中的持續整合資產

與其他開發或 IT 團隊一樣，DWH 團隊必須維護對其職責至關重要的資產。這些資產通常可分為下列類別：

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

  • SQL 指令碼：這些資產說明 DWH 內封裝的結構和業務邏輯。在此類別中，資產可進一步細分為下列子類別：

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

這些資產，以及用於建構元件的 Terraform 指令碼等其他資產，都會保留在程式碼存放區中。Dataform 等工具可協助您建構 CI/CD 管道，驗證 SQL 指令碼，並檢查 DDL 指令碼建立的資料表是否符合預先定義的驗證規則。這些工具可讓您套用 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 的標準方法複製資料。

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

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

使用上一節所述的工作流程時，開發人員可以獨立且平行地工作，不會干擾同事。開發人員可以測試及查看變更，如有問題，則可還原變更。由於您使用的是資料表快照，而非完整資料表，因此與完整資料表相比，可將成本和儲存空間用量降至最低。

本節將詳細說明表格快照和表格副本如何協助開發人員完成這項工作流程。下圖顯示資料表快照和資料表副本與生產資料集資料的關係。

生產資料集包含 9 個資料表。第二個名為「開發資料集 1」的資料集包含資料表 2 和 3 的快照，以及資料表 2 和 3 的副本。名為「開發資料集 2」的第三個資料集包含資料表 3 和 4 的快照，以及資料表 3 和 4 的副本。

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

開發人員建立資料集後，即可建立所用資料表的副本和快照。複製和快照代表特定時間點的資料。此時開發人員可以隨意變更資料表副本，因為變更不會顯示在基本資料表上。

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

開發人員可以將變更合併至基本資料表，同時保留安全快照，以備不時之需。您也可以針對不同環境 (例如開發、測試和實際工作環境) 重複執行這個程序。

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

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

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

另一種替代方法是使用其他資料集，然後將表格複製到該資料集。使用這個方法與使用資料表副本和快照類似，但您會複製整個資料表集。視複製的資料大小而定，儲存空間費用可能很高。在 BigQuery 提供資料表副本功能之前，部分機構會使用這種方法。不過，相較於使用複製和快照，這個方法沒有任何優勢。

將資料表匯出及匯入 Cloud Storage

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

使用 BigQuery 共用功能

BigQuery sharing (舊稱 Analytics Hub) 可讓您在機構內外共用資料集，且共用方式安全無虞。這項服務提供多項功能，可讓您發布資料集，並為訂閱者提供這些資料集的受控唯讀存取權。不過，即使您可以使用 BigQuery sharing 公開資料集來實作變更，開發人員仍須建立資料表副本，才能使用資料表。

DWH 持續整合選項摘要

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

  費用 復原 風險
資料表快照和資料表本機副本 最低。您只需支付快照或複製資料表與基礎資料表之間的差異。 快照可做為備份，必要時可還原。 您可以控管風險程度。您可以針對所有資料表在特定時間點建立快照，即使發生回溯，也能減少不一致的情況。
資料表複製 費用高於使用資料表快照和資料表本機副本。系統會複製所有資料。如要支援回溯，您需要同一資料表的多個副本。 可以，但需要兩個資料表副本，一個做為備份，另一個則用於處理及變更。 複製特定時間點的資料較為困難。如果需要回溯，並非所有資料表都會取自同一時間點。
匯出及匯入 費用高於使用資料表快照和資料表本機副本。資料重複。如要支援復原，您需要同一個資料表的多個副本。 匯出的資料可做為備份。 匯出的資料並非多個資料表的某個時間點資料。

後續步驟