Quando você conecta Snowflake ou Databricks ao Perplexity, o Computer gera um Data Map do seu data warehouse ou lakehouse. O Data Map captura informações importantes sobre o seu modelo de dados — tabelas e colunas relevantes, padrões comuns de consulta e relacionamentos entre objetos — para que o Computer possa traduzir perguntas em linguagem natural em consultas precisas.
Pense nele como um mapa do seu ambiente de dados que ajuda o Computer a entender o que existe em cada lugar e como isso costuma ser usado. Depois de gerado, o Data Map continua melhorando ao longo do tempo: ele aprende com o feedback dos usuários, pode ser editado diretamente pelos administradores e é versionado para que as alterações possam sempre ser revisadas e revertidas.
Como funciona
Depois que a geração do Data Map é iniciada, o Computer explora seu modelo de dados usando as permissões da conta conectada. Esse processo examina seus schemas, tabelas, views e padrões históricos de uso para construir uma compreensão abrangente dos seus dados.
O Data Map é armazenado com segurança em um repositório versionado por organização, acessível apenas aos membros da sua organização. Toda alteração — seja por regeneração, edições de administradores ou atualizações de autoaprendizado — é registrada para que possa ser revisada e revertida.
Gerando o Data Map
Há um Data Map por organização, compartilhado por todos os membros dessa organização. Quando um administrador executa a geração, ela é realizada em nome de toda a organização, não de um único usuário.
Snowflake
A geração do Data Map para o Snowflake é iniciada por um administrador da organização nas configurações do conector do Snowflake. A Perplexity oferece dois conectores do Snowflake, e os administradores geram o Data Map a partir de qualquer um deles que esteja configurado na organização:
-
Snowflake (par de chaves ou PAT) — consultas executadas como a conta de serviço configurada.
-
Snowflake (User OAuth) — as consultas são executadas sob a identidade do Snowflake do administrador que inicia a geração.
Qualquer que seja a identidade usada, ela deve ter permissão para ler as views de uso da conta do Snowflake (veja Requisitos abaixo). Se essas permissões estiverem ausentes, a geração falha imediatamente com um erro de permissões claro, em vez de produzir um Data Map parcial.
Databricks
No Databricks, a geração é iniciada pelas configurações do conector usando a identidade OAuth do Databricks de quem iniciou. O Computer enumera os catálogos, schemas e tabelas que o usuário pode ver no Unity Catalog e lê as tabelas de sistema do Databricks para obter sinais de uso. Tudo o que quem iniciou consegue ver no Unity Catalog define o que aparece no Data Map.
Contexto suplementar (Snowflake e Databricks)
Você pode adicionar Contexto suplementar — envie arquivos ou adicione notas descrevendo seus dados (por exemplo, o que as principais tabelas representam, definições de negócio, padrões comuns de consulta) — para ajudar o Computer a interpretar seus dados com mais precisão. O contexto suplementar é fornecido a cada execução de geração e não é afetado pela regeneração, para que você possa continuar adicionando ao longo do tempo sem se preocupar em perder isso.
Ver conhecimento
Após a conclusão da geração, o botão Gerar mapa de dados no modal do conector torna-se Ver conhecimento. Clicar em Ver conhecimento abre o Data Map Editor, onde os administradores podem navegar, editar e gerenciar tudo o que o Computer aprendeu sobre seus dados. Regenerar mapa de dados também está disponível no modal do conector, assim que existir um Data Map inicial — veja Regenerando o Data Map pelo que faz e pelo que é preservado.
Quanto tempo isso leva?
Gerar um Data Map pode levar até 90 minutos, dependendo do tamanho e da complexidade do seu data warehouse ou lakehouse. Você não precisa manter a página aberta — o processo é executado em segundo plano e o botão Ver conhecimento aparecerá no modal do conector assim que o processo for concluído.
O Editor do Data Map
O Editor do Data Map é a visualização voltada para administradores do seu Data Map, acessível pelas ferramentas de administração da organização. Ele separa o conhecimento do Snowflake e do Databricks em seções distintas, e o contexto de negócios subjacente, os agrupamentos de tabelas e os padrões de consulta são organizados como arquivos que você pode ler e editar diretamente.
No editor, os administradores podem:
-
Navegar o Data Map completo — contexto de negócios, clusters de tabelas, padrões comuns de consulta.
-
Editar arquivos diretamente. As edições salvas são aplicadas imediatamente ao Data Map ativo e tornam-se a nova fonte de verdade; elas não precisam passar pelo fluxo de revisão.
-
Revisar e agir sobre as alterações propostas pela IA do pipeline de autoaprendizado. Os administradores podem aprovar a proposta (as alterações são aplicadas ao Data Map) ou rejeitá-la (a proposta é descartada). Ainda não há suporte para modificar uma proposta no local antes de aprová-la — administradores que quiserem um resultado diferente podem rejeitá-la e então fazer a edição por conta própria.
-
Ver histórico de versões de qualquer arquivo e reverta, se necessário.
As edições diretas no editor são permanentes para o uso normal, mas convivem com o conteúdo gerado automaticamente e não são preservados se você regenerar o Data Map para esse warehouse — ver Regenerando o Data Map abaixo.
Aprendizado autônomo com base em feedback
O Mapa de Dados fica melhor quanto mais a sua equipe o usa. Quando um usuário corrige o agente de dados em uma sessão — por exemplo, “use fct_queries em vez de query_events para contagens de consultas” ou “exclua type = 'internal' das métricas de volume de consultas” — o Computer captura esse feedback e o usa para melhorar o Data Map para todos.
O pipeline é projetado para ser seguro, revisável, e compartilhado por toda a organização:
1. Capturando feedback
Quando um usuário envia feedback em uma sessão de Data Scientist, o Computer registra uma correção estruturada — o arquivo que ela deve afetar, a seção, a alteração proposta e o contexto da sessão que a gerou. O Data Map em si nunca é editado ao vivo a partir de uma sessão de usuário; o feedback sempre vai primeiro para esse registro.
2. Compactação diária em uma atualização proposta
Uma vez por dia, o Computer revisa as correções registradas nas últimas 24 horas de cada organização e produz um único consolidado atualização proposta no Data Map:
-
Múltiplas correções na mesma área são mescladas em uma edição.
-
Correções conflitantes (por exemplo, uma diz "sempre inclua jobs cron", outra diz "sempre exclua jobs cron") são reservadas para revisão humana em vez de resolvidas automaticamente.
-
Cada correção é direcionada para o warehouse correto — uma correção específica do Snowflake não se propagará para o Data Map do Databricks e vice-versa.
-
Correções que não podem ser mescladas ou encaminhadas com confiança são sinalizadas para que um administrador as revise, em vez de serem aplicadas silenciosamente.
O resultado é exibido no Editor do Data Map como uma única proposta que os administradores podem revisar.
3. Revisão do administrador
Os administradores aprovam a proposta (as alterações são aplicadas ao Data Map) ou rejeitam-na (a proposta é descartada). A aprovação é o que “implanta” as alterações — a próxima pergunta de dados que sua equipe fizer usará o Data Map atualizado. Não há uma etapa separada de publicação.
Esse padrão com participação humana é intencional: ele permite que o Computer aprenda continuamente com o uso real, enquanto mantém os administradores no controle do que é confiável como verdade de referência.
Quem pode fazer o quê?
-
Qualquer usuário em uma sessão de Cientista de Dados pode fornecer feedback que alimenta a atualização proposta do dia seguinte.
-
Administradores da organização podem navegar e editar arquivos do Data Map diretamente, além de aprovar ou rejeitar as atualizações propostas diariamente no Data Map Editor.
-
Há um Data Map por organização — cada membro da organização faz consultas com base no mesmo Data Map compartilhado. Não há Data Map individual por usuário.
Regenerando o Data Map
Os administradores podem executar Regenerar Data Map a qualquer momento, pelo modal do conector. Hoje, a regeneração é uma reconstrução do zero para o warehouse que você regenerar:
-
O Data Map desse warehouse é totalmente substituído por um novo resultado. As edições manuais de administrador nesse Data Map do warehouse não são preservadas.
-
O Data Map do outro warehouse permanece inalterado — regenerar o Snowflake não afeta o Databricks, e vice-versa.
-
Contexto suplementar é preservado e reaplicado à nova execução.
-
Feedback pendente (as correções registradas naquele dia, mas ainda não consolidadas em uma atualização proposta) é preservado. O feedback que já foi aprovado e aplicado ao Data Map faz parte do que é substituído.
-
O histórico completo de versões é preservado, portanto as versões anteriores do Data Map permanecem disponíveis para inspeção.
Como a regeneração substitui o Data Map de um warehouse e quaisquer edições feitas por um administrador nele, ela deve ser executada de forma intencional. Uma regeneração mais segura que preserva as edições do administrador — e um "reset total" explícito separado — estão no roadmap, mas ainda não fazem parte do produto hoje.
Requisitos
Snowflake
A identidade usada para gerar o Data Map — a conta de serviço para autenticação com chave/par de chaves / PAT, ou o usuário Snowflake do administrador que iniciou a autenticação OAuth — deve conseguir ler ambas estas views no esquema SNOWFLAKE.ACCOUNT_USAGE:
-
SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY -
SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY(Snowflake Enterprise Edition ou superior)
Importante: ACCOUNT_USAGE é exclusivo para administradores por padrão. A causa mais comum de falha na geração é uma função que consegue ler seus bancos de dados normais, mas não tem acesso a ACCOUNT_USAGE. A correção é conceder IMPORTED PRIVILEGES no banco de dados SNOWFLAKE.
Se você ainda não concedeu esse acesso durante a configuração inicial, execute o seguinte como ACCOUNTADMIN:
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE <your_role>;
Em seguida, verifique a partir da função de conexão:
SELECT 1 FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY LIMIT 1; SELECT 1 FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY LIMIT 1;
Se ACCESS_HISTORY não está disponível (Snowflake Standard Edition), a geração faz fallback para QUERY_HISTORY sozinho. O Data Map ainda funcionará, mas com um sinal um pouco menos preciso sobre a linhagem das colunas e a contagem de acessos às tabelas.
Para obter instruções completas de configuração, consulte Conectando o Perplexity ao Snowflake.
Databricks
A geração do Databricks usa a identidade OAuth de quem iniciou a sessão e herda suas permissões do Unity Catalog — não são necessárias concessões adicionais. Alguns pontos práticos a saber:
-
Unity Catalog é obrigatório. Computer lê tabelas de sistema do Databricks para o histórico de consultas, que dependem do Unity Catalog. Workspaces que operam apenas em
hive_metastorefalharão na verificação de acesso durante a geração. -
Um warehouse de SQL deve estar em execução quando a geração for iniciada. Se nenhum warehouse estiver em execução, inicie um no Databricks primeiro.
-
Tudo o que o iniciador consegue ver no Unity Catalog define o que aparece no Data Map. Se um catálogo ou schema estiver oculto para esse usuário, o Computer não pode incluí-lo.
Para obter instruções completas de configuração, consulte Conectando o Perplexity ao Databricks.


