À propos de la recherche de traçabilité multirégionale

Ce document décrit les concepts, les méthodes et les cas d'utilisation pour la recherche de la traçabilité des données dans plusieurs régions géographiques dans Knowledge Catalog (anciennement Dataplex Universal Catalog).

La traçabilité des données dans Knowledge Catalog est un service régionalisé. Les données de traçabilité, y compris les liens, les processus et les événements, sont enregistrées et stockées dans l'emplacement géographique spécifique où la transformation ou le déplacement des données sous-jacentes a eu lieu.

Toutefois, les pipelines de données d'entreprise s'étendent souvent sur plusieurs Google Cloud projets et régions (par exemple, une table BigQuery dans us-central1 qui copie des données dans un bucket de stockage dans europe-west1). Pour suivre les assets de données de manière exhaustive au-delà de ces limites, vous devez effectuer une recherche de traçabilité multirégionale.

Knowledge Catalog propose deux méthodes pour découvrir et agréger des graphiques de traçabilité interrégionaux :

  • La méthode d'automatisation côté serveur qui utilise l' searchLineageStreaming API (Preview) – Recommandée
  • La méthode de distribution ramifiée côté client qui utilise l' searchLinks API

Concepts fondamentaux

Pour comprendre la découverte de la traçabilité multirégionale, il est utile de comprendre comment le système gère le balayage de graphe :

  • Critères racines : point de départ de votre recherche de traçabilité, défini par un ou plusieurs noms d'assets (tels qu'une table BigQuery ou un sujet Pub/Sub) ou des champs de colonnes précis.

  • Direction : orientation du balayage de graphe par rapport aux critères racines. Vous pouvez effectuer une recherche en amont (pour voir d'où proviennent vos données) ou en aval (pour voir où vont vos données).

  • Recherche en largeur : mécanisme architectural utilisé pour trouver des nœuds connectés. La recherche parcourt le graphique de traçabilité couche par couche, en calculant avec précision la profondeur d'exécution de chaque asset connecté au-delà des limites régionales.

Comparaison des méthodes de recherche

Bien que les deux méthodes vous permettent de reconstituer une vue interrégionale de vos données, elles gèrent la charge de travail de manière différente :

Fonctionnalité Automatisation côté serveur
API searchLineageStreaming		 Distribution ramifiée côté client
API searchLinks
Modèle d'exécution Automatisation côté serveur : le Google Cloud moteur de routage parcourt plusieurs régions de manière native. Orchestration côté client : le script de votre application doit effectuer une boucle et gérer les requêtes manuellement.
Surcharge de requête Requête API unique : un seul appel HTTP POST démarre la recherche multirégionale. Plusieurs requêtes API : nécessite un appel HTTP distinct pour chaque région et chaque couche de graphique.
Gestion des réponses Flux en temps réel : les résultats sont envoyés au client au fur et à mesure qu'ils sont trouvés, ce qui évite les délais d'attente. Charges utiles statiques : les tableaux JSON individuels doivent être reçus, collectés, et fusionnés manuellement.
Graphiques profonds (plus de deux couches) Gère automatiquement les graphiques de traçabilité profonds et imbriqués jusqu'à 100 niveaux. Souffre du problème de requête N+1 ; nécessite des allers-retours itératifs et lents depuis le client.

Choisir la méthode adaptée à votre cas d'utilisation

Examinez les scénarios suivants pour déterminer la méthode de recherche multirégionale adaptée à votre charge de travail.

Choisissez la méthode d'API de streaming pour les cas d'utilisation suivants :

  • Suivre des graphiques profonds ou complexes : vos données transitent par plusieurs tables, buckets ou pipelines intermédiaires dans différentes régions, ce qui nécessite un balayage à plusieurs niveaux (maxDepth supérieur à 2).

  • Suivre la traçabilité au niveau des colonnes : vous souhaitez suivre les champs dans plusieurs régions ou exploiter les recherches génériques (*) pour extraire toutes les dépendances de colonnes en une seule fois.

  • Maintenir un code léger : vous préférez effectuer un seul appel d'API et laisser Google Cloud gérer le routage, la déduplication et l'assemblage de graphes.

  • Nécessiter des métadonnées de pipeline : vous souhaitez récupérer de manière facultative des détails structurels sur les processus exécutant vos pipelines dans la même charge utile de requête.

Choisissez la méthode de distribution ramifiée côté client pour les scénarios suivants :

  • Vous ne suivez que la traçabilité superficielle à un seul saut : votre graphique de traçabilité n'est pas complexe et vous n'avez besoin de rechercher que les liens parents ou enfants directs (maxDepth est égal à 1) dans un petit nombre fixe de régions connues.

  • Vous travaillez dans des systèmes hérités stricts : vous disposez d'une application de gouvernance des données existante, fortement axée sur le point de terminaison SearchLinks standard, et vous souhaitez maintenir une rétrocompatibilité structurelle sans implémenter de consommateurs de réponses de streaming.

Étape suivante