在資料網格中，自助式資料平台可讓使用者自主建構、分享及使用資料產品，從資料中產生價值。為充分發揮這些優勢，建議您的自助式資料平台提供本文件所述功能。
本文是系列文章之一，說明如何在 Google Cloud上實作資料網格。本文假設您已閱讀並熟悉使用 Google Cloud建構現代分散式資料網格和資料網格中的架構和功能所述的概念。
本系列包含以下部分：
- 資料網格的架構和功能
- 為資料網格設計自助式資料平台 (本文件)
- 在資料網格中建構資料產品
- 在資料網格中探索及使用資料產品
資料平台團隊通常會建立中央自助式資料平台，如本文所述。這個團隊會建構解決方案和元件，供網域團隊 (資料產生者和資料消費者) 用於建立及使用資料產品。網域團隊代表資料網格的功能部分。資料平台團隊建構這些元件後，就能提供流暢的開發體驗，並降低建構、部署及維護安全且可互通資料產品的複雜度。
最終，資料平台團隊應允許網域團隊加快速度。這些工具可滿足網域團隊的需求，因此有助於提升團隊效率。資料平台團隊提供這些工具，可減輕網域團隊自行建構及取得這些工具的負擔。工具選擇應可自訂，以滿足不同需求，且不應強迫資料領域團隊採用不靈活的工作方式。
資料平台團隊不應專注於為資料管道協調器或持續整合和持續部署 (CI/CD) 系統建構自訂解決方案。持續整合/持續推送軟體更新系統等解決方案，可做為代管雲端服務使用，例如 Cloud Build。使用代管雲端服務可減少資料平台團隊的作業負擔，讓他們專注於資料網域團隊的特定需求 (這些團隊是平台的使用者)。減少營運負擔後，資料平台團隊就能將更多時間用於滿足資料領域團隊的特定需求。
架構
下圖說明自助式資料平台的架構元件。圖中也顯示這些元件如何支援團隊，在資料網格中開發及使用資料產品。
如上圖所示，自助式資料平台提供下列功能：
平台解決方案：這些解決方案包含可組合的元件，用於佈建專案和資源，使用者可選取並以不同組合組裝這些元件，以滿足特定需求。 Google Cloud 平台使用者不必直接與元件互動，而是與平台解決方案互動，以達成特定目標。資料網域團隊應設計平台解決方案，解決常見的痛點和摩擦區域，這些問題會導致資料產品開發和使用速度變慢。舉例來說，加入資料網格的資料網域團隊可以使用基礎架構即程式碼 (IaC) 範本。使用 IaC 範本，他們可以快速建立一組專案，並為資料產品開發啟用標準身分與存取權管理 (IAM) 權限、網路、安全性政策和相關 API。Google Cloud Google Cloud建議您為每項解決方案附上說明文件，例如「如何開始使用」指南和程式碼範例。資料平台解決方案及其元件預設必須安全無虞且符合規定。
常見服務：這些服務提供資料產品探索、管理、共用及可觀測性。這些服務可協助資料消費者信任資料產品，並讓資料生產者有效提醒資料消費者資料產品的問題。
資料平台解決方案和常見服務可能包括：
- IaC 範本，用於設定基礎資料產品開發工作區環境，包括：
- IAM
- 記錄和監控
- 網路
- 安全性與法規遵循防護措施
- 資源標記，用於帳單歸因
- 資料產品儲存、轉換及發布
- 資料產品註冊、分類和中繼資料標記
- 遵循組織安全防護措施和最佳做法的 IaC 範本，可用於將 Google Cloud 資源部署到現有的資料產品開發工作區。
- 應用程式和資料 pipeline 範本，可用於啟動新專案，或做為現有專案的參考資料。這類範本的例子包括：
- 使用常見的程式庫和架構
- 與平台記錄、監控和觀測工具整合
- 建構及測試工具
- 設定管理
- 封裝和 CI/CD 管道，用於部署
- 驗證、部署及管理憑證
- 提供資料產品可觀測性和控管的常見服務，包括：
- 運作時間檢查，可顯示資料產品的整體狀態。
- 自訂指標，提供資料產品的實用指標。
- 由中央團隊提供營運支援，確保資料消費者團隊收到所用資料產品的變更通知。
- 產品評量表，顯示資料產品的成效。
- 用於探索資料產品的中繼資料目錄。
- 集中定義的一組運算政策，可全域套用至資料網格。
- 資料市集，方便網域團隊共用資料。
使用 IaC 範本建立平台元件和解決方案：說明 IaC 範本的優點，可公開及部署資料產品。提供通用服務：說明為何為網域團隊提供由資料平台團隊建構及管理的通用基礎架構元件，會有所幫助。
使用 IaC 範本建立平台元件和解決方案
資料平台團隊的目標是設定自助式資料平台，從資料中發掘更多價值。為建構這些平台，他們會建立並提供經過審查、安全且可自助式使用的基礎架構範本給網域團隊。網域團隊會使用這些範本部署資料開發和資料耗用環境。基礎架構即程式碼範本可協助資料平台團隊達成目標，並實現擴充。使用經過審查且值得信賴的 IaC 範本，可讓網域團隊重複使用現有的 CI/CD pipeline，簡化資源部署程序。網域團隊可透過這種方法快速上手，並在資料網格中提高生產力。
您可以使用 IaC 工具建立 IaC 範本。雖然有許多 IaC 工具，包括 Cloud Config Connector、Pulumi、Chef 和 Ansible，但本文提供以 Terraform 為基礎的 IaC 工具範例。Terraform 是開放原始碼的 IaC 工具，可讓資料平台團隊有效率地為Google Cloud 資源建立可組合的平台元件和解決方案。資料平台團隊使用 Terraform 編寫程式碼，指定所選的最終狀態，並讓工具找出達成該狀態的方法。資料平台團隊可透過這種陳述式方法，將基礎架構資源視為不可變更的構件，以便跨環境部署。這也有助於降低已部署資源與來源控管中宣告的程式碼之間發生不一致的風險 (稱為「設定偏移」)。對基礎架構進行臨時和手動變更所造成的設定漂移，會阻礙 IaC 元件安全且可重複地部署至生產環境。
可組合平台元件的常見 IaC 範本包括使用 Terraform 模組，部署 BigQuery 資料集、Cloud Storage 值區或 Cloud SQL 資料庫等資源。您可以將 Terraform 模組合併為端對端解決方案，部署完整的 Google Cloud 專案，包括使用可組合的模組部署相關資源。您可以在 Terraform 藍圖 Google Cloud中找到範例 Terraform 模組。
根據預設，每個 Terraform 模組都應符合貴機構使用的安全防護措施和法規遵循政策。這些防護措施和政策也可以表示為程式碼，並使用自動化法規遵循驗證工具 (例如 Google Cloud 政策驗證工具) 自動執行。
貴機構應持續測試平台提供的 Terraform 模組，並使用與將變更升級至實際工作環境時相同的自動化法規遵循防護措施。
如要讓網域團隊探索及使用 IaC 元件和解決方案，但這些團隊的 Terraform 經驗有限，建議您使用 Service Catalog 等服務。如果使用者有大量自訂需求，應允許他們使用現有解決方案採用的相同可組合式 Terraform 範本，建立自己的部署解決方案。
使用 Terraform 時，建議您遵循「使用 Terraform 的最佳做法」一文所述的最佳做法。 Google Cloud
為說明如何使用 Terraform 建立平台元件，以下各節將討論如何使用 Terraform 公開使用介面，以及如何使用資料產品的範例。
公開使用介面
資料產品的取用介面是資料領域團隊提供的一組資料品質和作業參數保證，可讓其他團隊探索及使用資料產品。每個使用介面也包含產品支援模型和產品說明文件。資料產品可能有多種取用介面，例如 API 或串流，如「在資料網格中建構資料產品」一文所述。最常見的取用介面可能是 BigQuery 已授權資料集、已授權檢視區塊或已授權函式。這個介面會公開唯讀虛擬資料表，以查詢的形式表示資料網格。介面不會授予讀取者權限，直接存取基礎資料。
Google 提供Terraform 模組範例，用於建立授權檢視表，而不必授予團隊基礎授權資料集的權限。這個 Terraform 模組的下列程式碼會將這些 IAM 權限授予dataset_id授權檢視畫面：
module "add_authorization" {
source = "terraform-google-modules/bigquery/google//modules/authorization"
version = "~> 4.1"
dataset_id = module.dataset.bigquery_dataset.dataset_id
project_id = module.dataset.bigquery_dataset.project
roles = [
{
role = "roles/bigquery.dataEditor"
group_by_email = "ops@mycompany.com"
}
]
authorized_views = [
{
project_id = "view_project"
dataset_id = "view_dataset"
table_id = "view_id"
}
]
authorized_datasets = [
{
project_id = "auth_dataset_project"
dataset_id = "auth_dataset"
}
]
}
如要授予使用者多個資料檢視的存取權，逐一授予每個授權資料檢視的存取權，不僅耗時，也較難維護。您不必建立多個授權檢視表，只要使用授權資料集，即可自動授權在授權資料集中建立的任何檢視表。
使用資料產品
在大多數的數據分析用途中，耗用模式取決於使用資料的應用程式。集中式提供的消耗環境主要用於資料探索，之後資料才會在消耗應用程式中使用。如「在資料網格中探索及使用產品」一文所述，SQL 是查詢資料產品最常用的方法。因此，資料平台應為資料消費者提供 SQL 應用程式，以探索資料。
視數據分析用途而定，您或許可以使用 Terraform 為資料消費者部署耗用環境。舉例來說，資料科學是資料消費者常見的用途。您可以使用 Terraform 部署 Vertex AI 使用者自行管理的筆記本，做為資料科學開發環境。資料消費者可透過資料科學筆記本，使用自己的憑證登入資料網格，探索有權存取的資料，並根據這些資料開發機器學習模型。
如要瞭解如何使用 Terraform 部署及保護 Google Cloud上的筆記本環境，請參閱「在企業中建構及部署生成式 AI 和機器學習模型」。
提供常見服務
除了自助式 IaC 元件和解決方案，資料平台團隊也可能負責建構及運作多個資料網域團隊使用的通用共用平台服務。共用平台服務的常見範例包括自行代管的第三方軟體，例如商業智慧視覺化工具或 Kafka 叢集。在 Google Cloud，資料平台團隊可能會選擇代表資料網域團隊管理資源，例如 Dataplex Universal Catalog 和 Cloud Logging 接收器。管理資料網域團隊的資源，可讓資料平台團隊在整個機構中，集中管理政策和稽核。
以下各節說明如何使用 Dataplex Universal Catalog，在資料網格中集中管理及治理資料，以及如何在資料網格中導入資料可觀測性功能。 Google Cloud
Dataplex Universal Catalog 適用於資料治理
Dataplex Universal Catalog 提供資料管理平台，協助您在涵蓋整個機構的資料網格中，建構獨立的資料網域。Dataplex Universal Catalog 可讓您維持集中控管機制，以管理及監控各網域的資料。
有了 Dataplex Universal Catalog，機構就能按照邏輯，將資料 (支援的資料來源) 和相關構件 (例如程式碼、筆記本和記錄) 彙整至代表資料網域的 Dataplex Universal Catalog 湖泊。在下圖中，銷售網域使用 Dataplex Universal Catalog，將資產 (包括資料品質指標和記錄) 整理到 Dataplex Universal Catalog 區域。
如上圖所示，Dataplex Universal Catalog 可用於管理下列資產的網域資料：
- Dataplex Universal Catalog 可讓資料網域團隊在稱為 Dataplex Universal Catalog lake 的邏輯群組中，一致地管理資料資產。資料網域團隊可以在同一個 Dataplex Universal Catalog lake 中整理 Dataplex Universal Catalog 資產，不必實際移動資料或將資料儲存在單一儲存系統中。Dataplex Universal Catalog 資產可以參照儲存在多個 Google Cloud 專案中的 Cloud Storage bucket 和 BigQuery 資料集，這些專案不一定包含 Dataplex Universal Catalog lake。Google Cloud Dataplex Universal Catalog 資產可以是結構化或非結構化，也可以儲存在分析資料湖泊或資料倉儲中。在圖表中，銷售領域、供應鏈領域和產品領域都有資料湖。
- 資料網域團隊可透過 Dataplex Universal Catalog 區域，在同一個 Dataplex Universal Catalog lake 中，將資料資產進一步劃分為較小的子群組，並新增結構來擷取子群組的重要層面。舉例來說，Dataplex Universal Catalog 專區可用於將資料產品中的相關聯資料資產分組。將資料資產歸入單一 Dataplex Universal Catalog 可用區，資料網域團隊就能以單一資料產品的形式，在整個可用區中一致地管理存取政策和資料治理政策。在圖表中，離線銷售、線上銷售、供應鏈倉庫和產品都有各自的資料區域。
Dataplex Universal Catalog 的 lake 和 zone 可協助機構統整分散各處的資料，並根據業務背景資訊整理資料。這項安排是管理中繼資料、設定管理政策和監控資料品質等活動的基礎。這類活動可讓機構大規模管理分散式資料，例如在資料網格中。
資料觀測
每個資料網域都應實作自己的監控和警報機制，最好是採用標準化方法。每個網域都可以套用「服務監控的概念」一文所述的監控做法，並視需要調整資料網域。可觀測性是個大主題，不在本文討論範圍內。本節只會說明有助於實作資料網格的模式。
如果產品有多個資料消費者，及時向每位消費者提供產品狀態資訊可能會造成營運負擔。手動管理電子郵件發布作業等基本解決方案通常容易出錯。這類通知有助於向消費者告知預計中斷服務的時間、即將推出的產品和淘汰的產品，但無法提供即時的營運資訊。
中央服務在監控資料網格中產品的健康狀態和品質方面，扮演重要角色。雖然實作資料網格並非必要條件，但導入可觀測性功能可提高資料生產者和消費者的滿意度，並降低整體營運和支援成本。下圖顯示以 Cloud Monitoring 為基礎的資料網格可觀測性架構。
以下各節說明圖中顯示的元件，包括：
- 正常運作時間檢查：顯示資料產品的整體狀態。
- 自訂指標： 提供資料產品的實用指標。
- 由中央資料平台團隊提供作業支援，在資料產品發生變更時，通知資料消費者。
- 產品評分表和資訊主頁，可顯示資料產品的成效。
運作時間檢查
資料產品可建立實作運作時間檢查的簡單自訂應用程式。這些檢查可做為產品整體狀態的高層級指標。 舉例來說，如果資料產品團隊發現產品的資料品質突然下降，團隊可以將該產品標示為不正常。對於衍生產品的資料消費者而言，接近即時的正常運作時間檢查特別重要，因為這些產品依賴上游資料產品中資料的持續可用性。資料生產者應建立正常運作時間檢查，包括檢查上游依附元件，藉此向資料消費者提供產品健康狀態的準確資訊。
資料消費者可以在處理程序中加入產品正常運作時間檢查。舉例來說，如果編寫器工作會根據資料產品提供的資料產生報表，則第一步是驗證產品是否處於「執行中」狀態。建議正常運作時間檢查應用程式在 HTTP 回應的訊息主體中，傳回結構化酬載。這個結構化酬載應指出是否有問題、問題的根本原因 (以人類可解讀的形式)，以及服務的預估還原時間 (如有可能)。這個結構化酬載也能提供產品狀態的更精細資訊。舉例來說，這項資訊可能包含授權資料集中每個檢視區塊的健康資訊，並以產品形式公開。
自訂指標
資料產品可以有各種自訂指標，用來評估實用性。資料產生者團隊可將這些自訂指標發布至指定的網域專屬 Google Cloud 專案。如要為所有資料產品建立統一的監控體驗，可以授權中央資料網格監控專案存取這些特定網域的專案。
每種資料產品使用介面都有不同的指標，可衡量其效用。指標也可以是特定於業務領域。舉例來說，透過檢視區塊或 Storage Read API 公開的 BigQuery 資料表指標可能如下所示：
- 列數。
- 資料更新間隔 (以測量時間前幾秒表示)。
- 資料品質分數。
- 可用的資料。這項指標可指出資料是否可供查詢。或者，您也可以使用本文稍早提及的正常運作時間檢查。
這些指標可視為特定產品的服務水準指標 (SLI)。
如果是資料串流 (以 Pub/Sub 主題的形式實作)，這份清單可以是標準 Pub/Sub 指標，可透過主題取得。
中央資料平台團隊提供的營運支援
中央資料平台團隊可以公開自訂資訊主頁，向資料消費者顯示不同層級的詳細資料。簡單的狀態資訊主頁會列出資料網格中的產品，以及這些產品的正常運作時間狀態，有助於回應多項使用者要求。
中央團隊也可以做為通知發布中心，在資料消費者使用的資料產品中發生各種事件時，通知他們。通常，這個中樞是透過建立快訊政策來製作。集中管理這項功能可減少每個資料產生者團隊必須完成的工作。建立這些政策時，不需要具備資料網域的相關知識，有助於避免資料使用瓶頸。
資料網格監控的理想最終狀態是，資料產品標記範本在產品推出時，會公開產品支援的服務水準指標 (SLI) 和服務水準目標 (SLO)。中央團隊隨後可使用 Monitoring API 搭配服務監控功能，自動部署相應的警報。
產品評量表
根據中央控管協議，資料網格中的四項功能可以定義建立資料產品評量表的條件。這些評量表可做為資料產品成效的客觀衡量標準。
計算評量表時，許多變數都是資料產品達到 SLO 的時間百分比。實用條件包括正常運作時間百分比、平均資料品質分數，以及資料即時性未低於門檻的產品百分比。如要使用監控查詢語言 (MQL) 自動計算這些指標，自訂指標和中央監控專案的正常運作時間檢查結果就已足夠。
後續步驟
- 進一步瞭解 BigQuery。
- 請參閱 Dataplex 相關說明。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。