在資料網格中建立資料產品

Last reviewed 2024-09-03 UTC

為確保滿足資料消費者的用途，資料網格中的資料產品必須經過精心設計和建構。資料產品的設計從定義資料消費者如何使用該產品，以及該產品如何向消費者公開開始。資料網格中的資料產品是建構在資料儲存庫 (例如網域資料倉儲或資料湖泊) 之上。在資料網格中建立資料產品時，建議您在整個過程中考量以下重要因素。本文將說明這些考量事項。

本文是系列文章之一，說明如何在 Google Cloud上實作資料網格。本文假設您已閱讀並熟悉「資料網格中的架構和函式」和「使用 Google Cloud建構現代化分散式資料網格」中說明的概念。

本系列包含以下部分：

從網域資料倉儲建立資料產品時，建議資料生產者為這些產品仔細設計分析 (消耗) 介面。這些介面提供一系列資料品質和作業參數的保證，以及產品支援模式和產品文件。變更取用介面的成本通常很高，因為資料生產者和多個資料取用者可能都需要變更取用程序和應用程式。由於資料取用者最有可能位於與資料產生者不同的機構單位，因此協調變更可能很困難。

以下各節提供背景資訊，說明建立網域資料倉儲、定義消耗介面，以及向資料消費者公開這些介面時，必須考量的事項。

建立網域資料倉儲

建立獨立資料倉儲，以及建立資料生產團隊用來建立資料產品的網域資料倉儲，兩者之間沒有基本差異。兩者唯一的真正差異在於，後者會透過取用介面公開部分資料。

在許多資料倉儲中，從營運資料來源擷取的原始資料會經過豐富化和資料品質驗證 (管理) 程序。在 Dataplex Universal Catalog 管理的 data lake 中，經過整理的資料通常會儲存在指定的整理區。完成策展後，資料子集應可透過多種介面供網域外部使用。如要定義這些消費介面，機構應為剛開始採用資料網格方法的網域團隊提供一組工具。資料生產者可透過這些工具，以自助式方式建立新的資料產品。如需建議做法，請參閱「設計自助式資料平台」。

此外，資料產品必須符合集中定義的資料治理規定。這些需求會影響資料品質、資料可用性和生命週期管理。因為這些規定可建立資料消費者對資料產品的信任感，並鼓勵使用資料產品，因此實作這些規定所帶來的效益，絕對值得您投入心力支援。

定義使用介面

建議資料產生者使用多種介面，而非只定義一或兩種介面。資料分析中的每種介面類型都有優缺點，沒有任何一種介面類型能面面俱到。資料產生者評估各介面類型是否合適時，必須考量下列事項：

  • 能夠執行所需的資料處理作業。
  • 擴充性，可支援目前和未來的資料消費者用途。
  • 資料消費者要求的效能。
  • 開發和維護成本。
  • 執行介面的費用。
  • 支援貴機構使用的語言和工具。
  • 支援儲存空間和運算能力分隔。

舉例來說，如果業務需求是能夠對 PB 級資料集執行分析查詢，那麼唯一實用的介面就是 BigQuery 檢視畫面。但如果需要提供近乎即時的串流資料，則更適合使用 Pub/Sub 型介面。

許多介面不需要您複製或複製現有資料。其中大多數也支援儲存空間與運算功能分離，這是Google Cloud 分析工具的重要功能。透過這些介面公開的資料消費者會使用可用的運算資源處理資料。資料生產者不需要佈建任何額外的基礎架構。

消費介面種類繁多，以下介面是資料網格中最常用的介面，我們將在後續章節中討論：

本文件中的介面清單僅列出部分示例。您也可以考慮使用其他選項做為取用介面，例如 BigQuery sharing (舊稱 Analytics Hub)。不過，這些其他介面不在本文的討論範圍內。

授權檢視區塊和函式

資料產品應盡可能透過授權檢視畫面和授權函式公開，包括資料表值函式。已授權資料集可自動授權多個檢視區塊，十分方便。使用授權檢視區塊可防止直接存取基礎資料表，並讓您最佳化基礎資料表和針對這些資料表執行的查詢，而不影響消費者使用這些檢視區塊。這個介面的消費者會使用 SQL 查詢資料。下圖說明如何使用授權資料集做為取用介面。

用量介面。

授權資料集和檢視畫面可協助輕鬆建立介面版本。如下圖所示，資料產生者可以採取兩種主要版本控管方法：

資料集和檢視區塊版本控管。

這些方法可歸納如下：

  • 資料集版本控管：這個方法會控管資料集名稱的版本。 您不會為資料集內的檢視區塊和函式建立版本。無論版本為何，您都保留檢視區塊和函式的相同名稱。舉例來說，銷售資料集的第一個版本定義在名為 sales_v1 的資料集中，並包含 catalog 和 orders 這兩個檢視區塊。在第二個版本中，銷售資料集已重新命名為 sales_v2，資料集中所有先前的檢視畫面都會保留先前的名稱，但會採用新的結構定義。第二個版本的資料集也可能新增檢視畫面，或移除任何先前的檢視畫面。
  • 檢視版本控管：採用這種做法時，系統會控管資料集內檢視區塊的版本，而不是資料集本身。舉例來說，銷售資料集不論版本為何，都會保留 sales 的名稱。不過，資料集內的檢視區塊名稱會變更，以反映每個新版本的檢視區塊 (例如 catalog_v1、catalog_v2、orders_v1、orders_v2 和 orders_v3)。

最適合貴機構的版本控管方法，取決於貴機構的政策，以及更新基礎資料後會過時的檢視畫面數量。如果需要進行重大產品更新，且大部分檢視區塊都必須變更，建議使用資料集版本控管。檢視區塊版本控管可減少不同資料集中名稱相同的檢視區塊，但可能會導致模稜兩可的情況，例如如何判斷資料集之間的聯結是否正常運作。混合式做法是不錯的折衷方案。在混合式方法中，單一資料集內允許相容的結構定義變更，不相容的變更則需要新的資料集。

BigLake 資料表注意事項

授權檢視表不僅可建立在 BigQuery 資料表上，也可建立在 BigLake 資料表上。消費者可透過 BigQuery SQL 介面，查詢儲存在 Cloud Storage 中的資料。BigLake 資料表支援精細的存取權控管，資料消費者不必具備基礎 Cloud Storage 值區的讀取權限。

資料生產者必須考量 BigLake 資料表的下列事項：

  • 檔案格式和資料版面配置的設計會影響查詢效能。一般來說，與 JSON 或 CSV 格式相比，以資料欄為基礎的格式 (例如 Parquet 或 ORC) 更適合用於分析查詢。
  • Hive 分區版面配置可讓您修剪分區，並加快使用分區資料欄的查詢速度。
  • 在設計階段，也必須考量檔案數量和檔案大小的偏好查詢效能。

如果使用 BigLake 資料表的查詢不符合介面的服務等級協議 (SLA) 規定，且無法調整，建議採取下列行動：

  • 如要向資料消費者公開資料，請將資料轉換為 BigQuery 儲存空間。
  • 重新定義授權檢視畫面，以使用 BigQuery 資料表。

一般來說，這種做法不會對資料消費者造成任何干擾，也不需要變更查詢。BigQuery 儲存空間中的查詢可使用 BigLake 資料表無法採用的技術進行最佳化。舉例來說，使用 BigQuery 儲存空間時，消費者可以查詢具體化檢視區塊，這些檢視區塊與基本資料表有不同的分割和叢集，且消費者可以使用 BigQuery BI Engine。

直接讀取 API

雖然我們通常不建議資料產生者直接授予資料消費者基礎資料表的讀取權，但有時基於效能和成本等因素，允許這類存取權可能很實用。在這種情況下，請務必確保資料表結構定義穩定。

一般來說，您可以透過兩種方式直接存取資料倉儲中的資料。資料產生者可以使用 BigQuery Storage Read API，或 Cloud Storage JSON 或 XML API。下圖說明消費者使用這些 API 的兩個範例。 一個是機器學習 (ML) 使用案例，另一個是資料處理工作。

機器學習和資料處理用途，詳見下文。

直接讀取介面的版本管理十分複雜。通常資料產生者必須建立具有不同結構定義的另一個資料表。此外，在已淘汰版本的資料消費者全數遷移至新版本前，他們也必須維護兩個版本的資料表。如果消費者可以接受重建資料表和切換至新結構定義的過程會中斷服務，則可避免資料重複。如果結構定義變更可回溯相容，就能避免遷移基礎資料表。舉例來說，如果只新增資料欄，且所有資料列都已回填這些資料欄中的資料，您就不必遷移基礎資料表。

以下摘要說明 Storage Read API 與 Cloud Storage API 之間的差異。一般來說，我們建議資料產生者盡可能使用 BigQuery API 進行分析應用程式。

  • Storage Read API： Storage Read API 可用於讀取 BigQuery 資料表中的資料，以及讀取 BigLake 資料表。這項 API 支援篩選功能和精細的存取權控管，對於穩定的資料分析或機器學習消費者來說，是不錯的選擇。

  • Cloud Storage API： 資料生產者可能需要直接與資料消費者共用特定 Cloud Storage bucket。舉例來說，如果資料消費者因故無法使用 SQL 介面，或是 bucket 含有Storage Read API 不支援的資料格式，資料生產者可以共用 bucket。

一般來說，我們不建議資料產生者透過儲存空間 API 允許直接存取，因為直接存取無法進行篩選，也無法提供精細的存取控管。不過，如果資料集穩定且大小適中 (GB 級)，直接存取法或許是可行的選擇。

允許 Pub/Sub 存取 bucket，資料消費者就能輕鬆將資料複製到自己的專案並進行處理。一般而言，如果可以避免，我們不建議複製資料。多個資料副本會增加儲存費用，並增加維護和沿襲追蹤的負擔。

以串流形式傳送資料

網域可以將串流資料發布至 Pub/Sub 主題，藉此公開資料。如要使用資料，訂閱者可以建立訂閱項目，以便使用發布至該主題的訊息。每個訂閱者都會獨立接收及使用資料。下圖顯示這類資料串流的範例。

接收及使用資料的資料串流。

在圖表中，擷取管道會讀取原始事件、擴充 (管理) 這些事件，並將管理後的資料儲存至分析資料存放區 (BigQuery 基本資料表)。同時，管道會將經過擴充的事件發布至專屬主題。這個主題會由多個訂閱者取用，每個訂閱者可能會篩選這些事件，只取得與自己相關的事件。此外，管道也會匯總事件統計資料並發布至自己的主題，供其他資料消費者處理。

以下是 Pub/Sub 訂閱的用途範例：

  • 經過強化處理的事件，例如提供完整的顧客個人資料資訊，以及特定顧客訂單的資料。
  • 近乎即時的匯總通知，例如過去 15 分鐘的訂單統計資料總計。
  • 商家層級快訊，例如：如果訂單量較前一天同期減少 20%，系統就會產生快訊。
  • 資料變更通知 (概念類似於變更資料擷取通知)，例如特定訂單的狀態變更。

資料生產者用於 Pub/Sub 訊息的資料格式，會影響費用和這些訊息的處理方式。如果是資料網格架構中的大量串流，建議使用 Avro 或 Protobuf 格式。如果資料生產者使用這些格式，可以將結構定義指派給 Pub/Sub 主題。這些結構定義可確保消費者收到格式正確的訊息。

由於串流資料結構可能會不斷變更，因此這個介面的版本控管需要資料產生者和資料取用者協調。資料產生者可以採取幾種常見做法，如下所示：

  • 每次訊息結構變更時，系統都會建立新主題。這個主題通常有明確的 Pub/Sub 結構定義。需要新介面的資料消費者可以開始使用新資料。主題名稱會隱含訊息版本，例如 click_events_v1。訊息格式是強型別。同一主題中的訊息格式不會有所不同。這個方法的缺點是，部分資料消費者可能無法改用新訂閱方案。在這種情況下，資料生產者必須持續將事件發布至所有有效主題一段時間，而訂閱主題的資料消費者則必須處理訊息流中的間隙，或重複刪除訊息。
  • 資料一律會發布至相同主題。不過，訊息的結構可能會改變。Pub/Sub「訊息屬性」(與酬載不同) 會定義訊息版本。例如：v=1.0。這種做法可免除處理間隙或重複項目的需求，但所有資料消費者都必須準備好接收新類型的訊息。資料生產者也無法使用 Pub/Sub 主題結構定義。
  • 混合式做法。訊息結構定義可包含任意資料區段，可用於新欄位。這種做法可在強型別資料與頻繁且複雜的版本變更之間，取得合理的平衡。

資料存取 API

資料產生者可以建構自訂 API，直接存取資料倉儲中的基本資料表。通常，這些生產者會將自訂 API 公開為 REST 或 gRPC API，並部署在 Cloud Run 或 Kubernetes 叢集上。Apigee 等 API 閘道可提供其他額外功能，例如流量節流或快取層。向 Google Cloud 機構外部的消費者公開資料存取 API 時，這些功能就派得上用場。資料存取 API 的潛在候選項目是延遲時間敏感型和高並行查詢，這兩者都會在單一 API 中傳回相對較小的結果，且可有效快取。

這類資料存取自訂 API 的範例如下：

  • 表格或產品的 SLA 指標綜合檢視畫面。
  • 特定資料表的前 10 筆記錄 (可能已快取)。
  • 資料表統計資料集 (資料列總數，或主要資料欄中的資料分布)。

機構針對建構應用程式 API 制定的任何規範和管理措施，也適用於資料產生者建立的自訂 API。機構的指南和管理機制應涵蓋主機代管、監控、存取權控管和版本管理等問題。

自訂 API 的缺點是，資料生產者必須負責代管這個介面所需的任何額外基礎架構，以及自訂 API 編碼和維護作業。建議資料產生者先研究其他選項，再決定是否要建立自訂資料存取 API。舉例來說，資料產生者可以使用 BigQuery BI Engine 縮短回應延遲時間，並提高並行性。

Looker Blocks

對於 Looker 等大量用於商業智慧 (BI) 工具的產品，維護一組 BI 工具專用的小工具可能很有幫助。由於資料產生者團隊瞭解網域中使用的基礎資料模型，因此最適合建立及維護預先建構的視覺化項目。

以 Looker 來說，這類視覺化內容可能是一組 Looker Blocks (預建的 LookML 資料模型)。消費者可輕鬆將 Looker Blocks 併入代管的資訊主頁。

機器學習模型

由於資料領域團隊對資料瞭若指掌，因此通常最適合建構及維護以領域資料訓練的機器學習模型。這些機器學習模型可透過多種不同的介面公開，包括：

  • BigQuery ML 模型可部署在專屬資料集中，並與資料消費者共用，以進行 BigQuery 批次預測。
  • 您可以將 BigQuery ML 模型匯出至 Vertex AI，以進行線上預測。

使用介面的資料位置考量事項

資料生產者為資料產品定義取用介面時，資料位置是一項重要考量。一般來說，為盡量降低成本，資料應在儲存資料的區域中處理。這種做法有助於避免產生跨區域資料輸出費用。這種做法的資料耗用延遲時間也最短。基於上述原因，儲存在多區域 BigQuery 位置的資料，通常最適合做為資料產品公開。

不過，基於效能考量，透過 BigLake 資料表或直接讀取 API 公開的 Cloud Storage 資料，應儲存在區域值區中。

如果某項產品公開的資料位於某個區域，且需要與另一個區域中另一個網域的資料聯結，資料消費者就必須考量下列限制：

  • 系統不支援使用 BigQuery SQL 的跨區域查詢。如果資料的主要使用方法是 BigQuery SQL，查詢中的所有資料表都必須位於相同位置。
  • BigQuery 固定費率使用承諾是區域性資源。如果專案只在一個區域使用固定費率承諾，但查詢另一個區域的資料產品，則適用以量計價模式。
  • 資料消費者可以使用直接讀取 API，從其他區域讀取資料。不過，您仍須支付跨區域網路輸出費用，且資料消費者在移轉大型資料時，很可能會遇到延遲問題。

如果經常跨區域存取資料，可以將資料複製到這些區域，減少產品消費者查詢時產生的費用和延遲時間。舉例來說，您可以將 BigQuery 資料集複製到其他區域。不過，只有在必要時才應複製資料。建議資料產生者複製資料時，只將可用產品資料的子集提供給多個區域。這項做法有助於盡量減少複製延遲和成本。這種做法可能會導致需要提供多個版本的消費介面，並明確指出資料位置區域。舉例來說，BigQuery 授權檢視區塊可透過 sales_eu_v1 和 sales_us_v1 等命名方式公開。

使用 Pub/Sub 主題的資料串流介面不需要任何額外的複製邏輯，即可在與訊息儲存區域不同的區域中取用訊息。不過，在這種情況下，您必須支付額外的跨區域輸出費用。

向資料消費者公開使用介面

本節將說明如何讓潛在消費者發現消費介面。Data Catalog 是全代管服務，機構可使用這項服務提供資料探索和中繼資料管理服務。資料生產者必須讓資料產品的取用介面可供搜尋，並使用適當的中繼資料加以註解，讓產品消費者以自助方式存取。三

下列各節將討論如何將每個介面類型定義為資料目錄項目。

以 BigQuery 為基礎的 SQL 介面

系統會自動為授權檢視區塊、BigLake 檢視區塊，以及透過 Storage Read API 提供的 BigQuery 資料表，註冊技術中繼資料，例如完整格式的資料表名稱或資料表結構定義。建議資料生產者也在資料產品文件中提供額外資訊，協助資料消費者。舉例來說，為了協助使用者尋找項目的產品說明文件，資料製作人可以在套用至項目的其中一個標記中新增網址。製作人也可以提供下列資訊：

  • 叢集資料欄集，應在查詢篩選器中使用。
  • 如果類型未在欄位說明中提供，則具有邏輯列舉類型的欄位列舉值。
  • 支援與其他資料表彙整。

資料串流

Pub/Sub 主題會自動向資料目錄註冊。不過，資料生產者必須在資料產品說明文件中描述結構定義。

Cloud Storage API

資料目錄支援定義 Cloud Storage 檔案項目及其結構定義。如果資料湖泊檔案集是由 Dataplex Universal Catalog 管理，系統會自動在 Data Catalog 中註冊該檔案集。如要新增未與 Dataplex Universal Catalog 建立關聯的檔案集，請採用其他方法。

其他介面

您可以建立自訂項目，新增 Data Catalog 內建不支援的其他介面。

後續步驟