在 BigQuery 中持續整合資料

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

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

簡介

持續整合和持續推送軟體更新 (CI/CD) 已成為軟體開發生命週期中不可或缺的技術。採用 CI/CD 原則可讓團隊以更少的問題，提供更優質的軟體，而非手動整合及部署功能。在資料倉儲現代化時，CI/CD 也能成為資料管理策略的一部分。

不過，如果您使用 BigQuery 等資料倉儲服務，在來源程式碼中實作 CI/CD 的方式，與在 BigQuery 中實作的方式有所不同。這些差異部分是因為資料倉儲是管理基礎資料的固有狀態系統。

本文件提供以下資訊：

  • 在 BigQuery 中實作持續整合 (CI) 策略的技巧。
  • 避免陷阱的指引和方法。
  • 建議使用 BigQuery 功能，以利在 BigQuery 中進行 CI。

本文件著重於 CI，因為整合作業比持續推送軟體更新 (CD) 更需要考量資料倉儲團隊的資料相關考量。

何時應為 BigQuery DWH 使用 CI

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

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

如要執行下列操作，DWHS 的 CI 就非常實用：

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

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

範例情境

範例公司是一家大型零售公司，在 BigQuery 中維護 DWH。在即將到來的一年中，該公司希望將新資料來源整合至 DWH，這些資料來源來自最近由 Example Company 收購的各家公司。要整合的新資料來源有不同的結構定義。不過，DWHS 必須保留現有結構定義，並確保資料一致性和完整性，以免資料的下游使用者受到負面影響。

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

為了更新資料整合程序，以便支援新的資料來源，DWH 團隊必須重新設計資料整合方法，以符合先前提到的要求，例如資料強一致性。團隊必須以隔離的方式導入變更，以便在將資料提供給下游使用者前，先測試及評估資料變更。

DWH 團隊採用新工作流程後，就擁有可重複執行的程序。每位開發人員都可以建立以實際工作環境資料為基礎的隔離開發環境。開發人員可以使用這些隔離環境進行變更、測試、審查，並將必要的變更提交至正式版環境。如果變更導致錯誤或意外問題，您可以輕鬆復原變更。

持續整合對 DWH 的意義

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

當組織必須將資料整合至資料倉儲時，這些原則也適用，但有一些差異。在一般軟體開發作業中，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)。任何對商業邏輯、結構定義或資料完整性的變更，都可能對後續作業造成重大影響。由於現代資料平台的特性是不斷變動，DWHS 團隊可能需要在嚴格遵守服務水準協議的情況下，進行這些變更。為了讓團隊能夠達成這些服務水準協議，並讓 DWH 保持最新狀態，他們需要能夠整合資料的工作流程，同時盡量減少這些變更可能造成的摩擦。

DWH 中用於持續整合的資產

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

  • 資料管道程式碼庫：這些資產通常包含 Python 或 Java 等高階程式設計語言的來源程式碼。針對這類資產，您可以使用 Git 和 Jenkins 等工具，或是使用 Cloud Source Repositories 和 Cloud Build 等Google Cloud 解決方案來建立 CI/CD 程序。

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

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

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

除了與工具和程序相關聯的資產外，DWHS 團隊的主要資產是資料。您無法使用資產追蹤系統 (例如用於追蹤原始碼的 Git) 追蹤資料。本文將說明與追蹤資料相關的問題。

整合資料的問題

由於 DWH 內的資料表關係可能相當複雜 (例如先前提到的其中一個資料表設計模式)，因此要將實際資料的狀態與測試環境隔離，是一項挑戰。軟體開發的標準做法無法套用至資料整合情境。

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

  整合程式碼 整合資料
本機開發 原始碼的大小相對較小，因此很容易複製。一般來說，這段程式碼適用於大多數的使用者機器 (不包括 monorepos，因為後者有其他解決方案)。 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 個資料表。第二個名為「Dev Dataset 1」的資料集包含資料表 2 和 3 的快照，以及資料表 2 和 3 的複本。第三個名為「Dev Dataset 2」的資料集包含資料表 3 和 4 的快照，以及資料表 3 和 4 的複本。

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

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

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

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

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

您可以使用其他方法來達到類似的結果，例如使用資料表複本和資料表快照。這些替代方法的用途通常與複本和快照不同。請務必瞭解這些方法之間的差異，以及您可能偏好某種方法的原因。

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

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

將資料表匯出至 Cloud Storage

另一種方法是透過 Cloud Storage 移動資料。這個方法也類似使用資料表複本和資料表快照。不過，這項方法會額外包含將資料匯出至 Cloud Storage 值區的步驟。這種方法的其中一個優點是，可為您提供額外的資料備份。如果您想要備份災難復原或混合式解決方案，可以選擇這種方法。

使用 BigQuery 共用功能

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

DWH 持續整合選項摘要

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

  費用 復原 風險
資料表快照和資料表本機副本 最低。您只需為快照或克隆資料表與基礎資料表之間的差異付費。 快照可做為備份，必要時可用於回復。 您可以控制風險程度。快照可在所有表格的某個時間點拍攝，即使發生回溯作業，也能減少不一致性。
資料表複製 比使用資料表快照和資料表本機副本的費用高。整個資料都會重複。如要支援回溯作業，您需要相同資料表的多個副本。 可以，但需要兩個資料表副本：一個用於備份，另一個用於作業和變更。 複製某個時間點的資料會比較困難。如果需要回復，則並非所有資料表都會從同一時間點擷取。
匯出及匯入 比使用資料表快照和資料表本機副本的費用高。資料重複。如要支援回溯，您需要相同表格的多個副本。 匯出的資料可做為備份。 匯出的資料並非多個資料表的時間點匯出資料。

後續步驟