關於多區域沿襲搜尋

本文說明在 Knowledge Catalog (原稱 Dataplex Universal Catalog) 中，跨多個地理區域搜尋資料歷程的概念、方法和用途。

Knowledge Catalog 中的資料歷程是地區化服務，系統會記錄並儲存歷程資料，包括連結、程序和事件，並儲存在基礎資料轉換或資料移動發生的特定地理位置。

不過，企業資料管道經常跨越多個 Google Cloud專案和區域 (例如，us-central1中的 BigQuery 資料表會將資料複製到 europe-west1 中的儲存空間 bucket)。如要全面追蹤這些界線的資料資產，您必須執行多區域沿襲搜尋。

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 端點建構而成，且您想維持結構向後相容性，但不想實作串流回應消費者。

後續步驟