Multiregionale Lineage mit clientseitigem Fan-Out suchen

Datenherkunftslinks in mehreren Google Cloud Regionen mit einem Fan-Out-Ansatz abrufen. Sie verwenden die Data Lineage API, um Herkunftsdaten aus allen verfügbaren Regionen abzurufen und zusammenzuführen.

Warum clientseitiges Fan-Out verwenden?

Der clientseitige Fan-Out-Ansatz ist nützlich, wenn Ihre Daten-Assets auf verschiedene Standorte verteilt sind und Sie eine ganzheitliche Übersicht ihrer Herkunft benötigen.

Weitere Informationen finden Sie unter Multiregionale Herkunftssuche.

Pseudocode für die einzelnen Schritte

Die Prozedur sendet parallele Anfragen an den Endpunkt projects.locations.searchLinks in jeder Region. Sie erfassen Ergebnisse, verarbeiten die Paginierung in allen Regionen und führen die gefundenen Links zusammen. Um eine konsistente Paginierung für nachfolgende Aufrufe zu gewährleisten, verwalten Sie ein regionalPageToken. Dadurch werden nicht erreichbare Regionen berücksichtigt.

Der folgende Pseudocode beschreibt eine Prozedur, mit der Sie mit der Data Lineage API Datenherkunftslinks aus allen verfügbaren Regionen abrufen können.

  1. Eingabe einrichten:
    • linksToFetch = 5 (Anzahl der Links, die aus allen Regionen abgerufen werden sollen)
    • regionalPageToken = "" (zuletzt empfangenes regionales Seitentoken, das für die Paginierung verwendet wird)
  2. Erstellen:
    1. Liste aller Regionen für Fan-Out 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. regions alphabetisch sortieren.
  4. regionalPageToken
      parsen
    1. Wenn es leer ist, mit Schritt 5 fortfahren
    2. Wenn es nicht leer ist:
      1. regionalPageToken parsen, indem es durch den ersten 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. Das zweite Segment zur Verwendung in allen projects.locations.searchLinks beiseitelegen.
  5. Parallele Aufrufe von projects.locations.searchLinks in jeder Region in der regions Liste ausführen.
  6. Warten, bis alle Anfragen abgeschlossen sind.
  7. Erfolgreiche Antworten herausfiltern und Namen der fehlgeschlagenen Regionen in der Liste unreachable speichern.
  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. Regionsnamen in lastRegion speichern.
      2. Empfangenes Seitentoken in nextPageToken speichern.
      3. Die restlichen Antworten ignorieren.
    2. Andernfalls:
      1. Regionsnamen in lastRegion speichern.
      2. Empfangene Links in foundLinks speichern (bis zu linksToFetch).
      3. Empfangenes Seitentoken in nextPageToken speichern.
      4. Anzahl der aus der Antwort übernommenen Links in lastRegionLinksCount speichern.
      5. Wenn foundLinks kleiner als linksToFetch
          ist:
        1. Mit der nächsten empfangenen Antwort in alphabetischer Reihenfolge im Pseudocode fortfahren.
      6. Wenn foundLinks gleich linksToFetch
          ist:
        1. Eine weitere Anfrage an den Endpunkt projects.locations.searchLinks in derselben Region senden, aber den Parameter pageSize auf den Wert von lastRegionLinksCount festlegen.
        2. Empfangenes Seitentoken in nextPageToken speichern.
        3. Mit Schritt 9 fortfahren
  9. nextPageToken mit lastRegion voranstellen (d.h. [region].[receivedNextPageToken]), um nextRegionalPageToken zu erstellen und die Paginierung in nachfolgenden Aufrufen zu verarbeiten.

Nächste Schritte