Présentation du framework de résolution des entités BigQuery

Ce document décrit l'architecture du framework de résolution des entités BigQuery. La résolution d'entités met en correspondance des enregistrements entre des données partagées pour lesquelles aucun identifiant commun n'existe ou augmente les données partagées à l'aide du service d'identité d'un partenaire Google Cloud .

Ce document est destiné aux utilisateurs finaux de la résolution d'entités et aux fournisseurs d'identité. Pour en savoir plus sur l'implémentation, consultez Configurer et utiliser la résolution d'entités dans BigQuery.

Vous pouvez utiliser la résolution d'entités BigQuery pour les données préparées avant de les ajouter à une data clean room. La résolution des entités est disponible dans les modèles de tarification à la demande et des capacités, ainsi que dans toutes les éditions BigQuery.

Avantages

La résolution d'entités offre les avantages suivants aux utilisateurs finaux :

  • Résolvez les entités en place sans frais de transfert de données. Un abonné ou un partenaireGoogle Cloud fait correspondre vos données à sa table d'identité et écrit les résultats des correspondances dans un ensemble de données de votre projet Google Cloud .
  • Évitez de gérer les tâches d'extraction, de transformation et de chargement (ETL).

Les fournisseurs d'identité bénéficient des avantages suivants grâce à la résolution d'entités :

  • Proposez la résolution d'entités sous forme d'offre Software as a Service (SaaS) gérée sur Google Cloud Marketplace.
  • Utilisez des graphiques d'identité propriétaires et une logique de correspondance sans les révéler aux utilisateurs.

Architecture

BigQuery implémente la résolution d'entités à l'aide d'appels de fonctions distantes qui activent les processus de résolution d'entités dans l'environnement d'un fournisseur d'identité. Vos données ne sont pas copiées ni déplacées au cours de cette procédure. Le schéma et l'explication suivants décrivent le workflow de résolution d'entités :

Schéma représentant deux sections principales : un projet d'utilisateur final et un projet de fournisseur d'identité.

  1. L'utilisateur final accorde au compte de service du fournisseur d'identité un accès en lecture à son ensemble de données d'entrée et un accès en écriture à son ensemble de données de sortie.
  2. L'utilisateur appelle la fonction à distance qui fait correspondre ses données d'entrée aux données du graphique d'identité du fournisseur. La fonction à distance transmet les paramètres correspondants au fournisseur.
  3. Le compte de service du fournisseur lit et traite l'ensemble de données d'entrée.
  4. Le compte de service du fournisseur écrit les résultats de la résolution d'entité dans l'ensemble de données de sortie de l'utilisateur.

Les sections suivantes décrivent les composants de l'utilisateur final et les projets du fournisseur.

Composants de l'utilisateur final

Les composants de l'utilisateur final sont les suivants :

  • Appel de fonction distante : appel qui exécute une procédure définie et mise en œuvre par le fournisseur d'identité. Cet appel lance le processus de résolution d'entités.
  • Ensemble de données d'entrée : ensemble de données source contenant les données à mettre en correspondance. L'ensemble de données peut éventuellement contenir une table de métadonnées avec des paramètres supplémentaires. Les fournisseurs spécifient les exigences de schéma pour les ensembles de données d'entrée.
  • Ensemble de données de sortie : ensemble de données de destination dans lequel le fournisseur stocke les résultats correspondants sous forme de table de sortie. Le fournisseur peut également écrire une table d'état de job contenant des informations sur le job de résolution d'entités dans cet ensemble de données. L'ensemble de données de sortie peut être identique à l'ensemble de données d'entrée.

Composants du fournisseur d'identité

Les composants du fournisseur d'identité sont les suivants :

  • Plan de contrôle : contient une fonction distante BigQuery qui orchestre le processus de mise en correspondance. Cette fonction peut être implémentée en tant que job Cloud Run ou fonction Cloud Run. Le plan de contrôle peut également contenir d'autres services, tels que l'authentification et l'autorisation.
  • Plan de données : contient l'ensemble de données du graphe d'identité et la procédure stockée qui met en œuvre la logique de mise en correspondance du fournisseur. La procédure stockée peut être implémentée en tant que procédure stockée SQL ou procédure stockée Apache Spark. L'ensemble de données du graphique d'identité contient les tables auxquelles les données utilisateur final sont mises en correspondance.

Étapes suivantes