Multiregionale Suche nach Herkunft

Mit der multiregionalen Herkunftssuche in Knowledge Catalog (ehemals Dataplex Universal Catalog) können Sie Daten-Assets über Google Cloud Projekte und Regionen hinweg verfolgen, um vollständige Herkunftsdiagramme zu erstellen. Diese ganzheitliche Übersicht hilft Ihnen, die Data Governance aufrechtzuerhalten und Abhängigkeiten in Ihrer Organisation zu analysieren, wenn Pipelines geografische Grenzen überschreiten. Sie können überregionale Graphen mithilfe der empfohlenen serverseitigen Automatisierung mit der searchLineageStreaming API (Vorabversion) oder des clientseitigen Fan-Outs mit der searchLinks API erkennen und verbinden. Eine Anleitung zur Verwendung der Streaming API finden Sie unter Multiregionale Herkunft mit serverseitiger Automatisierung suchen.

Standardmäßig ist die Datenherkunft in Knowledge Catalog ein regionaler Dienst. Wenn Ihre Daten verschoben oder transformiert werden, werden die resultierenden Lineage-Daten wie Links, Prozesse und Ereignisse in der Region gespeichert, in der die Aktion stattgefunden hat. In der Praxis erstrecken sich Datenpipelines jedoch häufig über mehrereGoogle Cloud -Projekte und -Regionen. Sie haben beispielsweise eine BigQuery-Tabelle in us-central1, die Daten in einen Storage-Bucket in europe-west1 kopiert. In diesem Fall ist eine multiregionale Suche erforderlich, um Ihre Daten-Assets über diese Grenzen hinweg zu verfolgen.

Um die multiregionale Herkunftserkennung zu verstehen, ist es hilfreich zu wissen, wie Knowledge Catalog die Graph-Durchquerung handhabt:

  • Stammkriterien: Der Ausgangspunkt Ihrer Herkunftssuche, 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 Upstream (um zu sehen, woher Ihre Daten stammen) oder Downstream (um zu sehen, wohin Ihre Daten gehen) suchen.

  • Breitensuche: Der Architekturmechanismus, der zum Suchen verbundener Knoten verwendet wird. Die Suche durchläuft das Herkunftsdiagramm Ebene für Ebene und berechnet die Ausführungstiefe jedes verbundenen Assets über regionale Grenzen hinweg genau.

Wie unterscheiden sich die multiregionalen Suchmethoden?

Mit beiden Methoden können Sie eine regionenübergreifende Ansicht Ihrer Daten erstellen, aber die aufwendige Arbeit wird unterschiedlich erledigt:

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 in einer Schleife ausführen und verwalten.
Anfrage-Overhead Einzelne API-Anfrage: Ein einzelner HTTP-POST-Aufruf startet die multiregionale Suche. Mehrere API-Anfragen: Erfordert einen separaten HTTP-Aufruf für jede Region und jede Diagrammebene.
Antwortverarbeitung Echtzeitstream: Die Ergebnisse werden an den Client gesendet, sobald sie gefunden werden, um Zeitüberschreitungen zu vermeiden. Statische Nutzlasten: Einzelne JSON-Arrays müssen manuell empfangen, erfasst und zusammengeführt werden.
Tiefe Diagramme (mehr als 2 Ebenen) Verarbeitet automatisch tiefe, verschachtelte Herkunftsdiagramme mit bis zu 100 Ebenen. Leidet unter dem N+1-Abfrageproblem; erfordert iterative, langsame Hin- und Rückflüge vom Client.

Die richtige multiregionale Suchmethode auswählen

Prüfen Sie die folgenden Szenarien, um festzustellen, welche multiregionale Suchmethode für Ihre Arbeitslast geeignet ist.

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

  • Tiefe oder komplexe Graphen verfolgen: Ihre Daten werden über mehrere Zwischentabellen, Buckets oder Pipelines in verschiedenen Regionen verschoben, was eine mehrstufige Traversierung (maxDepth größer als 2) erfordert.

  • Herkunft auf Spaltenebene verfolgen: Sie möchten Felder über Regionen hinweg verfolgen oder Platzhaltersuchen (*) verwenden, um alle Spaltenabhängigkeiten auf einmal abzurufen.

  • Leichtgewichtigen Code beibehalten: Sie möchten einen einzelnen API-Aufruf ausführen undGoogle Cloud das Routing, die Deduplizierung und die Diagrammerstellung übernehmen lassen.

  • Pipelinemetadaten anfordern: Sie möchten optional Strukturdetails zu den Prozessen abrufen, die Ihre Pipelines in derselben Anfrage-Nutzlast ausführen.

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

  • Sie verfolgen nur eine flache Herkunft mit einem Hop: Ihr Herkunftsdiagramm ist nicht komplex und Sie müssen nur direkte übergeordnete oder untergeordnete Links (maxDepth ist gleich 1) in einer kleinen, festen Anzahl bekannter Regionen nachschlagen.

  • Sie arbeiten mit strengen Legacy-Systemen: Sie haben eine vorhandene Data-Governance-Anwendung, 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