Multiregionale Lineage mit clientseitigem Fan-Out suchen

Rufen Sie Datenherkunft-Links über mehrere Google Cloud Regionen hinweg mit einem Fan-Out-Ansatz ab. Mit der Data Lineage API können Sie Lineage-Daten aus allen verfügbaren Regionen abrufen und zusammenfassen. Das ist nützlich, wenn Ihre Daten-Assets an verschiedenen Orten verteilt sind und Sie eine ganzheitliche Übersicht ihres Lineage benötigen.

Weitere Informationen finden Sie unter Mehrregionale Herkunftssuche.

Prozedur

Bei der Prozedur werden parallele Anfragen an den projects.locations.searchLinks-Endpunkt in jeder Region gesendet. Sie sammeln Ergebnisse, verarbeiten die Paginierung über Regionen hinweg und fassen die gefundenen Links zusammen. Verwalten Sie ein regionalPageToken, um eine konsistente Paginierung für nachfolgende Aufrufe zu gewährleisten und nicht erreichbare Regionen zu berücksichtigen.

Im folgenden Pseudocode wird ein Verfahren beschrieben, das Sie mit der Data Lineage API ausführen können, um Datenherkunftsinformationen aus allen verfügbaren Regionen abzurufen.

  1. Eingabe einrichten:
    • linksToFetch = 5 (Anzahl der Links, die aus allen Regionen abgerufen werden sollen)
    • regionalPageToken = „“ (das zuletzt empfangene regionale Seitentoken, das für die Paginierung verwendet wird)
  2. Erstellen:
    1. Eine Liste aller Regionen, an die die Anfrage weitergeleitet werden soll, mit dem Namen regions.
    2. Liste der nicht erreichbaren Regionen mit dem Namen unreachable.
    3. eine leere Liste der gefundenen Links mit dem Namen foundLinks.
    4. eine leere Variable nextPageToken und nextRegionalPageToken.
    5. eine leere Variable lastRegion.
    6. eine leere Variable lastRegionLinksCount.
  3. Sortiere regions alphabetisch.
  4. Analysiere regionalPageToken
    1. Wenn sie leer ist, fahre mit Schritt 5 fort.
    2. Wenn sie nicht leer ist, dann
      1. regionalPageToken parsen, indem es zuerst durch den Punkt in zwei Segmente aufgeteilt wird
      2. Regionen herausfiltern, indem nur die Regionen berücksichtigt werden, die nach dem ersten Segment aus dem geparsten regionalPageToken kommen (in alphabetischer Reihenfolge).
      3. Speichern Sie das zweite Segment, um es in allen projects.locations.searchLinks-Aufrufen zu verwenden.
  5. Rufen Sie projects.locations.searchLinks in jeder Region in der Liste regions parallel auf.
  6. Warten Sie, bis alle Anfragen abgeschlossen sind.
  7. Erfolgreiche Antworten werden herausgefiltert und fehlgeschlagene Regionsnamen in der Liste unreachable gespeichert.
  8. Für jede der Antworten (beginnend mit der ersten Region in alphabetischer Reihenfolge)
    1. wenn keine Links zusammen mit einem nicht leeren Seitentoken zurückgegeben wurden.
      1. Speichern Sie den Namen der Geschäftsregion in lastRegion.
      2. Speichern Sie das empfangene pageToken in nextPageToken.
      3. Ignorieren Sie die verbleibenden Antworten.
    2. andernfalls
      1. Speichern Sie den Namen der Geschäftsregion in lastRegion.
      2. empfangene Links in foundLinks speichern (bis zu linksToFetch).
      3. Speichern Sie das empfangene pageToken in nextPageToken.
      4. Speichere die Anzahl der verwendeten Links aus der Antwort in lastRegionLinksCount.
      5. wenn foundLinks kleiner als linksToFetch ist
        1. Setzen Sie den Pseudocode mit der nächsten empfangenen Antwort in alphabetischer Reihenfolge fort.
      6. wenn foundLinks gleich linksToFetch
        1. Stellen Sie eine weitere Anfrage an den Endpunkt projects.locations.searchLinks in derselben Region, legen Sie den Parameter pageSize aber auf den Wert von lastRegionLinksCount fest.
        2. Speichern Sie pageToken in nextPageToken.
        3. Fahren Sie mit Schritt 9 fort.
  9. Stellen Sie nextPageToken das lastRegion (d.h. [region].[receivedNextPageToken]) voran, um nextRegionalPageToken zu erstellen, damit die Paginierung in aufeinanderfolgenden Aufrufen verarbeitet wird.

Nächste Schritte