Multiregionale Suche nach Herkunft

In diesem Dokument werden die Konzepte, Methoden und Anwendungsfälle für die Suche nach der Datenherkunft in mehreren geografischen Regionen in Knowledge Catalog (ehemals Dataplex Universal Catalog) beschrieben.

Die Datenherkunft in Knowledge Catalog ist ein regionaler Dienst. Lineage-Daten, einschließlich Links, Prozesse und Ereignisse, werden am geografischen Standort aufgezeichnet und gespeichert, an dem die zugrunde liegende Datentransformation oder der Datenfluss stattgefunden hat.

Datenpipelines für Unternehmen erstrecken sich jedoch häufig über mehrere Google CloudProjekte und ‑Regionen hinweg (z. B. eine BigQuery-Tabelle in us-central1, in der Daten in einen Speicher-Bucket in europe-west1 kopiert werden). Um Daten-Assets umfassend über diese Grenzen hinweg nachzuvollziehen, müssen Sie eine multiregionale Herkunftssuche durchführen.

Knowledge Catalog bietet zwei Methoden zum Ermitteln und Aggregieren von regionenübergreifenden Lineage-Diagrammen:

  • Serverseitige Automatisierungsmethode mit der searchLineageStreaming API (Vorschau) – Empfohlen
  • Die clientseitige Fan-out-Methode, die die searchLinks API verwendet

Wichtige Konzepte

Um die Ermittlung von Lineage in mehreren Regionen zu verstehen, ist es hilfreich, zu wissen, wie das System die Graphdurchläufe verarbeitet:

  • Stammkriterien: Der Ausgangspunkt Ihrer Lineage-Suche, definiert durch einen oder mehrere Asset-Namen (z. B. eine BigQuery-Tabelle oder ein Pub/Sub-Thema) oder detaillierte Spaltenfelder.

  • Richtung: Die Ausrichtung des Diagrammdurchlaufs relativ zu den Stammkriterien. Sie können nach Upstream-Daten (um zu sehen, woher Ihre Daten stammen) oder nach Downstream-Daten (um zu sehen, wohin Ihre Daten fließen) suchen.

  • Breitensuche: Der architektonische Mechanismus, der zum Auffinden verbundener Knoten verwendet wird. Bei der Suche wird der Lineage-Graph Schicht für Schicht durchlaufen. Dabei wird die Ausführungstiefe jedes verbundenen Assets über regionale Grenzen hinweg genau berechnet.

Vergleich von Suchmethoden

Mit beiden Methoden können Sie eine regionsübergreifende Ansicht Ihrer Daten erstellen. Die Verarbeitung erfolgt jedoch unterschiedlich:

Funktion Serverseitige Automatisierung
searchLineageStreaming API		 Clientseitiges Fan-out
searchLinks API
Ausführungsmodell Serverseitige Automatisierung: Die Google Cloud Routing-Engine durchläuft mehrere Regionen nativ. Clientseitige Orchestrierung: Ihr Anwendungsskript muss Anfragen manuell durchlaufen und verwalten.
Anfrage-Overhead Einzelne API-Anfrage: Mit einem einzelnen HTTP-Aufruf von POST wird die Suche in mehreren Regionen gestartet. Mehrere API-Anfragen: Für jede Region und jede Grafikebene ist ein separater HTTP-Aufruf erforderlich.
Antwortverarbeitung Echtzeitstream: Die Ergebnisse werden an den Client gesendet, sobald sie gefunden werden. So werden Zeitüberschreitungen vermieden. Statische Nutzlasten: Einzelne JSON-Arrays müssen manuell empfangen, erfasst und zusammengeführt werden.
Tiefe Graphen (mehr als 2 Layer) Verarbeitet automatisch tief verschachtelte Lineage-Diagramme mit bis zu 100 Ebenen. Leidet unter dem N+1-Abfrageproblem; erfordert iterative, langsame Roundtrips vom Client.

Die richtige Methode für Ihren Anwendungsfall auswählen

Anhand der folgenden Szenarien können Sie ermitteln, welche Methode für die Suche in mehreren Regionen für Ihre Arbeitslast geeignet ist.

Wählen Sie die Streaming-API-Methode für die folgenden Anwendungsfälle aus:

  • Tiefgehende oder komplexe Diagramme nachvollziehen: Ihre Daten werden über mehrere Zwischentabellen, ‑Buckets oder ‑Pipelines in verschiedenen Regionen übertragen, was eine mehrstufige Traversierung (maxDepth > 2) erfordert.

  • Herkunft auf Spaltenebene nachverfolgen: Sie möchten Felder regionenübergreifend nachverfolgen oder Platzhaltersuchen (*) verwenden, um alle Spaltenabhängigkeiten gleichzeitig abzurufen.

  • Leichter Code: Sie bevorzugen es, einen einzelnen API-Aufruf zu senden undGoogle Cloud das Routing, die Deduplizierung und die Diagrammerstellung zu überlassen.

  • Pipeline-Metadaten erforderlich: Sie möchten optional strukturelle Details zu den Prozessen abrufen, die Ihre Pipelines im selben Anfrage-Payload ausführen.

Wählen Sie die clientseitige Fan-out-Methode für die folgenden Szenarien aus:

  • Sie verfolgen nur eine einfache, einstufige Herkunft: Ihr Herkunftsgraph ist nicht komplex und Sie müssen nur direkte übergeordnete oder untergeordnete Links (maxDepth = 1) in einer kleinen, festen Anzahl bekannter Regionen nachschlagen.

  • Sie arbeiten mit strengen Legacy-Systemen: Sie haben eine bestehende Anwendung zur Datenverwaltung, die stark auf dem Standardendpunkt SearchLinks basiert, und möchten die strukturelle Abwärtskompatibilität beibehalten, ohne Streaming-Antwort-Consumer zu implementieren.

Nächste Schritte