關於多區域沿襲搜尋

管理複雜機構的資料時，瞭解資料沿襲對於良好的資料治理和有效的雲端資料管理至關重要。本指南說明如何在 Knowledge Catalog (原稱 Dataplex Universal Catalog) 中使用多區域搜尋功能，追蹤跨越地理界線的資料。

根據預設，Knowledge Catalog 中的資料歷程是區域服務。每當資料移動或轉換時，系統會將產生的歷程資料 (例如連結、程序和事件) 儲存在執行該動作的特定區域。

不過，實際的資料管道經常會跨越多個 Google Cloud 專案 和區域。舉例來說，您可能在 us-central1 中有一個 BigQuery 資料表，可將資料複製到 europe-west1 中的儲存空間值區。如要追蹤這些界線的資料資產，並建構完整的歷程圖，您需要執行多區域搜尋。

您可以透過兩種方式，在 Knowledge Catalog 中探索及連結這些跨區域歷程圖：

如要瞭解多區域歷程探索功能，請先瞭解系統如何處理圖表遍歷：

  • 根層級條件：血統搜尋的起點，由一或多個資產名稱 (例如 BigQuery 資料表或 Pub/Sub 主題) 或細微的資料欄欄位定義。

  • 方向：圖表遍歷相對於根條件的方向。您可以搜尋上游 (查看資料來源) 或下游 (查看資料去向)。

  • 廣度優先搜尋：用於尋找連結節點的架構機制。搜尋作業會逐層遍歷歷程圖，準確計算跨區域界線的每個已連結資產執行深度。

多區域搜尋方法比較

這兩種方法都能協助您拼湊出跨區域的資料檢視畫面，但處理繁重作業的方式不同：

功能 伺服器端自動化
searchLineageStreaming API		 用戶端擴散傳遞功能
searchLinks API
執行模型 伺服器端自動化： Google Cloud 路由引擎會以原生方式遍歷多個區域。 用戶端協調：應用程式指令碼必須手動迴圈並管理要求。
要求額外負荷 單一 API 要求：單一 HTTP POST 呼叫會啟動多區域搜尋。 多個 API 要求：每個區域和每個圖層都需要個別的 HTTP 呼叫。
處理回應 即時串流：系統會在找到結果時推送至用戶端，避免逾時。 靜態酬載：必須手動接收、收集及合併個別的 JSON 陣列。
深層圖表 (超過 2 個圖層) 自動處理深層巢狀血統圖，最多可達 100 個層級。 會遇到 N+1 查詢問題；需要從用戶端進行緩慢的往返迭代。

選擇合適的多區域搜尋方法

請參閱下列情境，判斷哪種多區域搜尋方法適合您的工作負載。

請針對下列用途選擇串流 API 方法：

  • 追蹤深層或複雜的圖表：您的資料會經過不同區域的多個中繼資料表、值區或管道，因此需要多層遍歷 (maxDepth 大於 2)。

  • 追蹤資料欄層級的歷程：您想追蹤跨區域的欄位，或利用萬用字元 (*) 搜尋，一次提取所有資料欄的依附元件。

  • 維持輕量型程式碼：您偏好發出單一 API 呼叫，並讓Google Cloud 處理路徑、重複資料刪除和圖形組裝作業。

  • 要求管道中繼資料：您想在同一個要求酬載中，選擇性地擷取管道執行程序的結構詳細資料。

在下列情境中，選擇用戶端擴散傳遞功能方法：

  • 您只追蹤淺層的單一躍點歷程：歷程圖表不複雜，您只需要在少數固定數量的已知區域中，查閱直接父項或子項連結 (maxDepth 等於 1)。

  • 您使用嚴格的舊版系統：您現有的資料控管應用程式是根據標準 SearchLinks 端點建構而成，且想維持結構向後相容性，但不想實作串流回應消費者。

後續步驟