Multiregionale Suche nach Herkunft

Wenn Sie Daten in einer komplexen Organisation verwalten, ist es für eine gute Data Governance und ein effektives Cloud-Datenmanagement unerlässlich, die Datenherkunft zu kennen. In diesem Leitfaden wird beschrieben, wie Sie die Suche in mehreren Regionen in Knowledge Catalog (ehemals Dataplex Universal Catalog) verwenden, um Ihre Daten über geografische Grenzen hinweg zu verfolgen.

Die Datenherkunft in Knowledge Catalog ist standardmäßig ein regionaler Dienst. Immer wenn Ihre Daten verschoben oder transformiert werden, werden die resultierenden Lineage-Daten wie Links, Prozesse und Ereignisse in der Region gespeichert, in der die entsprechende Aktion stattgefunden hat.

In der Praxis erstrecken sich Datenpipelines jedoch häufig über mehrere Google Cloud Projekte und Regionen hinweg. Sie haben beispielsweise eine BigQuery-Tabelle in us-central1, in der Daten in einen Speicher-Bucket in europe-west1 kopiert werden. Wenn Sie Ihre Daten-Assets über diese Grenzen hinweg nachverfolgen und vollständige Herkunftsdiagramme erstellen möchten, müssen Sie eine Suche in mehreren Regionen durchführen.

Im Knowledge Catalog gibt es zwei Möglichkeiten, diese regionenübergreifenden Herkunftsdiagramme zu finden und zu verknüpfen:

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

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 Downstream-Daten (um zu sehen, wohin Ihre Daten fließen) suchen.

  • Breitensuche: Der Architekturmechanismus, 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.

Wie unterscheiden sich die Suchmethoden für mehrere Regionen?

Mit beiden Methoden können Sie eine regionenübergreifende Ansicht Ihrer Daten erstellen. Die Verarbeitung der Daten 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: Ein einzelner HTTP-Aufruf von POST startet die Suche in mehreren Regionen. 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 Grafiken (mehr als 2 Ebenen) Verarbeitet automatisch tief verschachtelte Lineage-Diagramme mit bis zu 100 Ebenen. Es tritt das N+1-Abfrageproblem auf. Es sind iterative, langsame Roundtrips vom Client erforderlich.

Die richtige multiregionale Suchmethode auswählen

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

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

  • Komplexe oder tief verschachtelte Diagramme mit Daten, die in verschiedenen Regionen durch mehrere Zwischentabellen, ‑Buckets oder ‑Pipelines fließen, erfordern eine mehrstufige Traversierung (maxDepth > 2).

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

  • Leichter Code: Sie möchten lieber einen einzelnen API-Aufruf senden undGoogle Cloud die Weiterleitung, Deduplizierung und Diagrammerstellung übernehmen lassen.

  • 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