Knowledge Catalog (舊稱 Dataplex Universal Catalog) 的多區域歷程搜尋功能，可讓您追蹤 Google Cloud 專案和區域中的資料資產，建立完整的歷程圖。當管道跨越地理界線時，這個整合式資料檢視可協助您維護資料治理，並分析整個組織的依附元件。您可以使用建議的伺服器端自動化功能搭配 searchLineageStreaming API (預先發布版)，或使用用戶端扇出功能搭配 searchLinks API，探索及連結跨區域圖表。如需使用串流 API 的操作說明，請參閱「使用伺服器端自動化功能搜尋多區域歷程」。
多區域歷程搜尋的核心概念
根據預設，Knowledge Catalog 的資料歷程是區域性服務。每當資料移動或轉換時，產生的歷程資料 (例如連結、程序和事件) 都會儲存在執行該動作的特定區域。不過，實際的資料管道通常會跨越多個Google Cloud 專案和區域。舉例來說，您可能在 us-central1 有一個 BigQuery 資料表，會將資料複製到 europe-west1 的 Storage bucket，因此需要多區域搜尋，才能跨越這些界線追蹤資料資產。
如要瞭解多區域歷程探索，請先瞭解 Knowledge Catalog 如何處理圖表遍歷：
根條件：歷程搜尋的起點，由一或多個資產名稱 (例如 BigQuery 資料表或 Pub/Sub 主題) 或精細資料欄欄位定義。
方向：圖表遍歷相對於根條件的方向。您可以向上游搜尋 (查看資料來源)，也可以向下游搜尋 (查看資料去向)。
廣度優先搜尋：用於尋找連結節點的架構機制。搜尋作業會逐層遍歷歷程圖，準確計算跨區域邊界各個連結資產的執行深度。
多區域搜尋方法有何差異？
雖然這兩種方法都能讓您拼湊出跨區域的資料檢視畫面，但處理繁重工作的方式不同：
| 功能 | 伺服器端自動化 searchLineageStreaming API |
用戶端扇出 searchLinks API |
|---|---|---|
| 執行模型 | 伺服器端自動化： Google Cloud 轉送引擎會原生周遊多個區域。 | 用戶端自動化調度管理：應用程式指令碼必須手動循環及管理要求。 |
| 要求負擔 | 單一 API 要求：單一 HTTP POST 呼叫會啟動多區域搜尋。 |
多個 API 要求：每個區域和圖層都需要個別的 HTTP 呼叫。 |
| 回應處理 | 即時串流：找到結果後，系統會將結果推送至用戶端，避免逾時。 | 靜態酬載：必須手動接收、收集及合併個別 JSON 陣列。 |
| 深層圖 (超過 2 層) | 自動處理深層巢狀譜系圖，最多可達 100 層。 | 會發生 N+1 查詢問題，需要從用戶端進行緩慢的反覆來回。 |
選擇合適的多區域搜尋方法
請查看下列情境，判斷哪種多區域搜尋方法適合您的工作負載。
在下列情況下，請選擇串流 API 方法：
追蹤深層或複雜圖表：資料會經過不同區域的多個中繼資料表、bucket 或管道，需要多層級遍歷 (
maxDepth大於 2)。追蹤資料欄層級歷程：您想追蹤跨區域的欄位，或使用萬用字元 (
*) 搜尋，一次提取所有資料欄依附元件。維持輕量程式碼：您偏好發出單一 API 呼叫，並讓Google Cloud 處理轉送、簡化和圖表組合。
要求管道中繼資料：您想在同一個要求酬載中，選擇性擷取執行管道的程序結構詳細資料。
在下列情況下，請選擇用戶端展開方法：
您只追蹤淺層、單躍點歷程：歷程圖不複雜，且您只需要在少數固定的已知區域中，查詢直接父項或子項連結 (
maxDepth等於 1)。您在嚴格的舊版系統中工作：您現有的資料治理應用程式主要圍繞標準
SearchLinks端點建構，且您希望在不實作串流回應消費者的情況下，維持結構回溯相容性。
後續步驟
瞭解如何使用伺服器端自動化功能搜尋多區域歷程。
瞭解如何使用用戶端扇出搜尋多區域歷程。