Lorsque vous connectez Snowflake ou Databricks à Perplexity, Computer génère un Carte des données de votre entrepôt de données ou lakehouse. Data Map capture les informations clés de votre modèle de données — les tables et colonnes importantes, les schémas de requêtes courants et les relations entre les objets — afin que Computer puisse convertir les questions en langage naturel en requêtes précises.
Considérez cela comme une carte de votre environnement de données qui aide Computer à comprendre ce qui se trouve où et comment cela est généralement utilisé. Une fois générée, la Data Map continue de s’améliorer au fil du temps : elle apprend grâce aux retours des utilisateurs, peut être modifiée directement par les administrateurs et est versionnée afin que les changements puissent toujours être examinés et annulés.
Comment cela fonctionne
Une fois la génération de Data Map lancée, Computer explore votre modèle de données en fonction des autorisations de votre compte connecté. Ce processus examine vos schémas, tables, vues et schémas d’utilisation historiques afin de construire une compréhension complète de vos données.
La Data Map est stockée de manière sécurisée dans un dépôt versionné propre à chaque organisation, accessible uniquement aux membres de votre organisation. Chaque modification — qu’elle provienne d’une régénération, de modifications par un administrateur ou de mises à jour autoapprenantes — est enregistrée afin de pouvoir être examinée et annulée.
Génération de la carte des données
Il y a une carte de données par organisation, partagée par chaque membre de cette organisation. Lorsqu’un administrateur lance la génération, il le fait au nom de l’ensemble de l’organisation, et non d’un utilisateur en particulier.
Snowflake
La génération de la Data Map pour Snowflake est lancée par un administrateur de l’organisation depuis les paramètres du connecteur Snowflake. Perplexity propose deux connecteurs Snowflake, et les administrateurs génèrent la Data Map à partir de celui que leur organisation a configuré :
-
Snowflake (clé paire ou PAT) — les requêtes sont exécutées en tant que compte de service configuré.
-
Snowflake (OAuth utilisateur) — les requêtes s’exécutent sous l’identité Snowflake de l’administrateur qui lance la génération.
Quelle que soit l’identité utilisée, elle doit pouvoir lire les vues d’utilisation du compte Snowflake (voir Exigences ci-dessous). Si ces autorisations manquent, la génération échoue immédiatement avec une erreur d’autorisation claire plutôt que de produire une Data Map partielle.
Databricks
Pour Databricks, la génération est lancée depuis les paramètres du connecteur à l’aide de l’identité OAuth Databricks de l’initiateur. Computer énumère les catalogues, schémas et tables que l’utilisateur peut voir dans Unity Catalog et lit les tables système Databricks pour les signaux d’utilisation. Ce que l’initiateur peut voir dans Unity Catalog détermine ce qui apparaît dans la Data Map.
Contexte complémentaire (Snowflake et Databricks)
Vous pouvez ajouter Contexte supplémentaire — téléversez des fichiers ou ajoutez des notes décrivant vos données (par exemple, ce que représentent les tables clés, les définitions métier, les schémas de requêtes courants) — pour aider Computer à interpréter vos données plus précisément. Le contexte supplémentaire est intégré à chaque exécution de génération et est non affecté par la régénération, afin que vous puissiez continuer à l’enrichir au fil du temps sans craindre de le perdre.
Afficher les connaissances
Une fois la génération terminée, le Générer une carte des données le bouton de la fenêtre modale du connecteur devient Voir les connaissances«. En cliquant Voir les connaissances ouvre le Éditeur de la carte des données», où les administrateurs peuvent parcourir, modifier et gérer tout ce que Computer a appris à propos de vos données. Régénérer la carte des données est également disponible depuis la fenêtre modale du connecteur une fois qu’une Data Map initiale existe — voir Régénération de la carte des données pour ce qu’il fait et ce qui est conservé.
Combien de temps cela prend-il ?
La génération d’une carte des données peut prendre jusqu’à 90 minutes", selon la taille et la complexité de votre entrepôt de données ou lakehouse. Vous n'avez pas besoin de laisser la page ouverte — le processus s'exécute en arrière-plan et le Voir les connaissances le bouton apparaîtra dans la fenêtre modale du connecteur une fois l’opération terminée.
L’éditeur de carte des données
L’éditeur de la carte des données est la vue destinée aux administrateurs de votre carte des données, accessible depuis les outils d’administration de l’organisation. Il sépare les connaissances Snowflake et Databricks en sections distinctes, et le contexte métier sous-jacent, les clusters de tables et les modèles de requêtes sont organisés sous forme de fichiers que vous pouvez lire et modifier directement.
Depuis l’éditeur, les administrateurs peuvent :
-
Parcourir la carte de données complète — contexte métier, regroupements de tables, modèles de requêtes courants.
-
Modifier les fichiers directement. Les modifications enregistrées sont appliquées immédiatement à la Data Map en direct et deviennent la nouvelle source de vérité ; elles n’ont pas besoin de passer par le pipeline de validation.
-
Examiner et appliquer les modifications proposées par l’IA depuis le pipeline d’auto-apprentissage. Les administrateurs peuvent approuver la proposition (les modifications sont appliquées à la Data Map) ou rejeter il (la proposition est abandonnée). La modification d’une proposition en place avant approbation n’est pas prise en charge à ce jour — les administrateurs qui souhaitent obtenir un résultat différent peuvent la rejeter puis effectuer eux-mêmes la modification.
-
Afficher l’historique des versions de n’importe quel fichier et revenir en arrière si nécessaire.
Les modifications directes dans l’éditeur sont durables pour une utilisation normale, mais elles coexistent avec le contenu généré automatiquement et ne sont pas conservés si vous régénérez la carte des données pour cet entrepôt — voir Régénération de la carte des données below.
Autoapprentissage à partir des retours
La Data Map s’améliore à mesure que votre équipe l’utilise. Lorsqu’un utilisateur corrige l’agent de données dans un fil de discussion — par exemple, "use fct_queries au lieu de query_events pour les comptages de requêtes" ou "exclure type = 'internal' « à partir des métriques de volume de requêtes" — Computer capture ce retour et l’utilise pour améliorer la Data Map pour tout le monde.
Le pipeline est conçu pour être safe, révisable", et partagé(e) à l’échelle de l’organisation:
1. Capture des commentaires
Lorsqu’un utilisateur fournit un retour dans une session Data Scientist, Computer consigne une correction structurée — le fichier concerné, la section, la modification proposée et le contexte de la session qui l’a générée. La Data Map elle-même n’est jamais modifiée en direct depuis une session utilisateur ; les retours sont toujours d’abord enregistrés dans ce journal.
2. Compactage quotidien en une mise à jour proposée
Une fois par jour, Computer examine les corrections enregistrées au cours des 24 dernières heures pour chaque organisation et produit un seul élément consolidé mise à jour proposée vers la carte des données :
-
Plusieurs corrections apportées à la même zone sont fusionné en une seule modification.
-
Corrections contradictoires (par exemple, l’un dit « inclure toujours les tâches cron », un autre dit « exclure toujours les tâches cron ») sont mettre de côté pour examen par un humain plutôt que d’être résolues automatiquement.
-
Chaque correction est dirigé vers le bon entrepôt — une correction spécifique à Snowflake ne se répercutera pas dans Databricks Data Map, et inversement.
-
Les corrections qui ne peuvent pas être fusionnées ou orientées avec certitude sont signalées à un administrateur afin qu’il les examine, au lieu d’être appliquées silencieusement.
Le résultat est présenté dans l’éditeur de Data Map sous la forme d’une proposition unique que les administrateurs peuvent examiner.
3. Revue par l’administrateur
Administrateurs approuver la proposition (les modifications sont appliquées à la carte des données) ou rejeter it (la proposition est abandonnée). L’approbation est ce qui « déploie » les changements — la prochaine question de données que votre équipe posera utilisera la Data Map mise à jour. Il n’y a pas d’étape de publication distincte.
Ce schéma avec intervention humaine est intentionnel : il permet à Computer d’apprendre en continu à partir de l’utilisation réelle, tout en laissant aux administrateurs le contrôle de ce qui est considéré comme une vérité de référence digne de confiance.
Qui peut faire quoi ?
-
Tout utilisateur dans un fil de discussion de Data Scientist, peut donner un retour qui alimente la mise à jour proposée du lendemain.
-
Les administrateurs de l’organisation peut parcourir et modifier directement les fichiers Data Map, et approuver ou rejeter les mises à jour quotidiennes proposées dans l’éditeur Data Map.
-
Il y a une carte de données par organisation — chaque membre de l’organisation effectue des requêtes sur la même carte des données partagée. Il n’existe pas de carte des données propre à chaque utilisateur.
Régénération de la carte des données
Les administrateurs peuvent exécuter Régénérer la carte des données à tout moment depuis la fenêtre modale du connecteur. Aujourd’hui, la régénération est un reconstruire à partir de zéro pour l’entrepôt que vous régénérez:
-
La carte des données de cet entrepôt a été entièrement remplacée par un résultat mis à jour. Les modifications manuelles apportées par l’administrateur à la Data Map de cet entrepôt ne sont pas conservées.
-
Le de l’autre entrepôt Data Map reste inchangé — la régénération de Snowflake n’affecte pas Databricks, et inversement.
-
Contexte supplémentaire est conservé et réappliqué à la nouvelle exécution.
-
Retour en attente (les corrections consignées ce jour-là mais pas encore intégrées dans une mise à jour proposée) sont conservées. Les retours déjà approuvés et appliqués à la Data Map font partie de ce qui est remplacé.
-
L’historique complet des versions est conservé, de sorte que les versions précédentes de la Data Map restent consultables.
Étant donné que la régénération remplace la Data Map d’un entrepôt ainsi que toutes les modifications apportées par un administrateur, elle doit être exécutée intentionnellement. Une régénération plus sûre qui préserve les modifications de l’administrateur — ainsi qu’une option distincte et explicite de « réinitialisation complète » — figurent sur la feuille de route, mais ne sont pas encore disponibles dans le produit.
Exigences
Snowflake
L'identité utilisée pour générer la Data Map — le compte de service pour l’authentification par paire de clés / PAT, ou l’utilisateur Snowflake de l’administrateur à l’origine pour l’authentification OAuth — doit pouvoir lire ces deux vues dans le SNOWFLAKE.ACCOUNT_USAGE schema:
-
SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY -
SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY(Édition Enterprise de Snowflake ou supérieure)
Important : ACCOUNT_USAGE est réservé aux administrateurs par défaut. La cause la plus fréquente d’un échec de génération est un rôle qui peut lire vos bases de données habituelles, mais qui n’a pas accès à ACCOUNT_USAGE». La solution consiste à accorder IMPORTED PRIVILEGES sur le SNOWFLAKE database.
Si vous n’avez pas déjà accordé cet accès lors de la configuration initiale, exécutez la commande suivante en tant que ACCOUNTADMIN:
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE <your_role>;
Puis vérifiez depuis le rôle de connexion :
SELECT 1 FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY LIMIT 1; SELECT 1 FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY LIMIT 1;
Si ACCESS_HISTORY n'est pas disponible (édition Standard de Snowflake), la génération revient à QUERY_HISTORY seul. La Data Map fonctionnera toujours, mais avec un signal légèrement moins précis sur le lignage des colonnes et le nombre d’accès aux tables.
Pour obtenir les instructions complètes de configuration, consultez Connecter Perplexity à Snowflake.
Databricks
La génération Databricks utilise l’identité OAuth de l’initiateur et hérite de ses autorisations Unity Catalog — aucun droit supplémentaire n’est requis. Voici quelques points pratiques à connaître :
-
Unity Catalog est requis. Computer lit les tables système Databricks pour l’historique des requêtes, qui dépendent de Unity Catalog. Les espaces de travail fonctionnant uniquement sur
hive_metastoreéchouera à la vérification d'accès lors de la génération. -
A L’entrepôt SQL doit être en cours d’exécution lorsque la génération est lancée. Si aucun entrepôt n’est en cours d’exécution, démarrez-en d’abord un dans Databricks.
-
Ce que l’initiateur peut voir dans Unity Catalog définit ce qui se retrouve dans le Data Map. Si un catalogue ou un schéma est masqué pour cet utilisateur, Computer ne peut pas l’inclure.
Pour obtenir les instructions complètes de configuration, consultez Connexion de Perplexity avec Databricks.


