À propos des produits de données

Les produits de données de Knowledge Catalog (anciennement Dataplex Universal Catalog) vous permettent de regrouper des éléments de catalogue associés dans une seule unité organisée pour résoudre des problèmes métier spécifiques. Vous pouvez ensuite ajouter du contexte et des contrats pour aider les consommateurs de données à découvrir, évaluer et demander un accès en libre-service à des données de confiance.

Capacités clés

Les produits de données offrent les fonctionnalités clés suivantes :

  • Organisez les éléments du catalogue en une unité logique qui résout un problème métier spécifique et accélère l'obtention d'insights.
  • Distribuez des éléments de données avec un contexte incluant une description, une documentation et des aspects.
  • Établissez une relation de confiance avec des contrats qui permettent aux producteurs de données de fournir des garanties aux consommateurs de données.
  • Fournissez un workflow en libre-service permettant aux consommateurs de données d'évaluer les produits de données et d'accéder aux données.

Concepts clés

Cette section décrit les concepts et la terminologie clés liés aux produits de données.

Produit de données

Regroupement logique et organisé d'éléments de données, formellement empaqueté pour être détectable, fiable et accessible afin de résoudre des problèmes métier spécifiques.

Élément

Pointeur vers une ressource de données physique, telle qu'un ensemble de données, une table ou une vue BigQuery. Un produit de données contient un ou plusieurs éléments.

Groupe d'accès

Les groupes d'accès simplifient la gestion des autorisations pour votre produit de données. Ils mappent des rôles conviviaux (tels que Reader ou Analyst) aux groupes Google ou aux comptes de service sous-jacents. Cette abstraction permet aux propriétaires de produits de données de gérer l'accès à un niveau conceptuel et aide les consommateurs de produits de données à demander le niveau d'accès approprié.

  • Les propriétaires de produits de données configurent des groupes d'accès et peuvent éventuellement attribuer un rôle IAM par défaut, qui est automatiquement appliqué à tous les éléments compatibles du produit de données. Si aucun rôle par défaut n'est attribué, les propriétaires peuvent attribuer des rôles IAM spécifiques directement aux éléments.

  • Les consommateurs du produit de données utilisent ces groupes pour demander l'accès au produit de données.

Propriétaire de produits de données ou producteur de données

Personne ou équipe responsable de la création et de la gestion des produits de données. Cela inclut la gestion de la qualité, de l'accès et de la documentation.

Utilisateur de produit de données

Personne, équipe ou agent IA qui utilise des produits de données pour générer des insights.

Contrat

Accord entre le propriétaire du produit de données et ses consommateurs. Cet accord définit des attentes claires en définissant des conditions spécifiques pour la fourniture et l'utilisation des données, telles que leur calendrier d'actualisation et leurs normes de qualité.

Exemple d'utilisation

Prenons l'exemple d'un data scientist qui analyse une entreprise d'e-commerce. Son objectif est de trouver la valeur moyenne des commandes (AOV) par source de trafic et de voir s'il existe une corrélation entre l'âge des utilisateurs et la taille des commandes. Pour ce faire, ils doivent combiner les données de plusieurs tables, telles que order_details, user_traffic et user_demographics.

Dans une configuration classique, ce processus crée des frictions. Pour générer des insights, le data scientist doit d'abord découvrir les tables appropriées dans le vaste paysage de données de l'organisation, puis contacter chaque propriétaire de données, justifier sa demande d'accès et attendre l'approbation.

Avec les produits de données, les propriétaires de données peuvent simplifier cette expérience en regroupant les éléments pertinents dans un seul produit nommé "Données d'entreprise d'e-commerce". Ce package inclut les éléments suivants :

  • Éléments

    • Tables BigQuery order_details et user_traffic (contenant l'historique des données de commande et les sources de trafic)
    • Vue BigQuery user_demographics (fournissant des informations sur l'utilisateur sans les informations permettant de l'identifier personnellement)

  • Groupes d'accès

    • Groupes Reader et Writer prédéfinis pour simplifier les demandes d'accès

  • Contrat

    • Un contrat définissant la fréquence d'actualisation des données (par exemple, toutes les semaines à 8h00 PST)

  • Contexte

    • Documentation avec des exemples de requêtes et d'autres détails
    • Métadonnées supplémentaires pour décrire la sensibilité des données

Les data scientists peuvent désormais découvrir ce produit de données en tant qu'unité logique unique. Ils peuvent ainsi générer des insights en toute confiance pour répondre à des questions telles que "Quelle est la valeur moyenne de la commande pour chaque source de trafic ?", ce qui leur permet d'identifier les sources qui génèrent les clients les plus rentables.

Parcours utilisateur du produit de données

Le cycle de vie d'un produit de données dans Knowledge Catalog implique deux parcours utilisateur clés : un pour le propriétaire (ou producteur) du produit de données, qui crée et gère les données, et un pour le consommateur du produit de données, qui les découvre et les utilise.

Parcours du propriétaire de produits de données

Ce parcours se concentre sur le packaging, la sécurisation et la gouvernance des produits de données pour s'assurer qu'ils sont fiables et accessibles.

  • Créer : définissez le produit de données et incluez des éléments. Cela implique les actions suivantes :

    • Configurez le nom unique, le projet, la région et la description.
    • Ajoutez des éléments tels que des tables BigQuery, des ensembles de données ou des vues.
    • Configurez des groupes d'accès (par exemple, Analyst ou Reader) et mappez-les aux groupes Google ou aux comptes de service sous-jacents pour simplifier la gestion des autorisations.
    • Vous pouvez éventuellement attribuer un rôle IAM par défaut à un groupe d'accès pour accorder automatiquement des autorisations sur tous les éléments compatibles du produit de données.
    • Attribuez les rôles IAM nécessaires à ces groupes d'accès pour les éléments spécifiques.
    • Ajoutez un contrat (un aspect du système) pour communiquer formellement la cadence, la fréquence et le seuil d'actualisation des données convenus.

    Pour en savoir plus, consultez Créer des produits de données.

  • Gérer : mettez à jour le produit de données et assurez sa visibilité. Cela implique les actions suivantes :

    • Mettez à jour les informations de base, les éléments, les autorisations, les aspects supplémentaires (métadonnées) et la documentation en texte enrichi.
    • Accordez l'accès aux consommateurs pour qu'ils puissent découvrir les produits de données et demander à y accéder.

    Pour en savoir plus, consultez Gérer les produits de données.

Parcours client d'un produit de données

Ce parcours est axé sur la recherche rapide de données de confiance et l'obtention des autorisations nécessaires pour les utiliser.

  • Découvrir : trouver des données pertinentes et fiables pour un problème métier spécifique. Cela implique les actions suivantes :

    • Utilisez la recherche Knowledge Catalog avec des mots clés ou le langage naturel pour trouver le produit de données empaqueté.
    • Examinez la présentation, les éléments, le contrat et d'autres aspects du produit de données pour déterminer s'il est adapté à l'utilisation.

    Pour en savoir plus, consultez Rechercher des produits de données.

  • Demander l'accès : demandez au propriétaire du produit de données l'autorisation d'accéder aux données.

    Pour en savoir plus, consultez Demander l'accès à des produits de données.

  • Utilisation : accédez aux assets sous-jacents pour générer des insights. Cela implique l'action suivante :

    • Une fois votre demande approuvée, vous pourrez accéder au produit et à ses composants. Par exemple, si l'élément est une table BigQuery, vous pouvez accéder à BigQuery Studio et interroger directement les données.

    • Pour les applications et les workflows de développement fonctionnant en dehors deGoogle Cloud, vous pouvez exposer le produit de données à l'aide d'une passerelle de métadonnées externe. Pour en savoir plus, consultez Utiliser le serveur MCP distant Knowledge Catalog.

    Pour en savoir plus, consultez Utiliser des produits de données.

Assets compatibles

Un produit de données peut être composé d'un ou de plusieurs assets de données. Les éléments de données suivants sont acceptés :

  • Ensembles de données BigQuery
  • les tables BigQuery
  • Vues BigQuery
  • Routines BigQuery
  • Modèles BigQuery
  • Tables externes BigQuery
  • Ensembles de données Gemini Enterprise Agent Platform
  • Modèles Gemini Enterprise Agent Platform
  • Buckets Cloud Storage
  • Catalogues du catalogue REST Iceberg
  • Espaces de noms du catalogue REST Iceberg
  • Tables du catalogue REST Iceberg
  • Tableaux de bord Looker (Google Cloud Core)
  • Éléments du tableau de bord Looker (Google Cloud Core)
  • Looks Looker (Google Cloud Core)
  • Explorations Looker (Google Cloud Core)
  • Projets LookML Looker (Google Cloud Core)
  • Modèles LookML Looker (Google Cloud Core)
  • Vues LookML de Looker (Google Cloud Core)

Limites

  • Emplacement : les produits de données et leurs éléments sous-jacents doivent se trouver dans le même emplacementGoogle Cloud .
  • Modèles BigQuery : l'accès aux modèles BigQuery d'un produit de données est géré via des conditions IAM appliquées à la stratégie IAM de l'ensemble de données parent. Le partage de modèles BigQuery est soumis aux limites des conditions IAM.

  • Éléments Looker (Google Cloud Core) : l'utilisation d'éléments Looker (Google Cloud Core) dans des produits de données présente les limites suivantes :

    • Les comptes de service ne sont pas acceptés : la mise en miroir des groupes Google dans Looker (Google Cloud Core) n'accepte que les identités d'utilisateurs humains. Les groupes d'accès configurés sur les éléments Looker (Google Cloud Core) ne peuvent pas inclure de compte de service principal.
    • Les rôles IAM du groupe d'accès par défaut ne sont pas acceptés : les rôles IAM par défaut attribués au niveau du groupe d'accès ne sont pas appliqués aux éléments Looker (Google Cloud Core) et sont marqués comme unsupported. Vous devez configurer explicitement les autorisations des groupes d'accès sur chaque élément Looker (Google Cloud Core).
    • Synchronisation manuelle des autorisations dans Looker (Google Cloud Core) : les noms de rôles configurés sur un élément Looker (Google Cloud Core) dans un produit de données sont des espaces réservés informatifs pour les consommateurs. Les producteurs de données doivent configurer et gérer manuellement les niveaux d'accès aux dossiers et les rôles Looker pour le groupe dupliqué dans l'instance Looker (Google Cloud Core).

  • Quotas et limites : pour obtenir la liste complète des limites de débit et des quotas de capacité de l'API, consultez Quotas pour les requêtes API des produits de données.

  • Les buckets zonaux ne sont pas acceptés.

Étapes suivantes