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.
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.
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.
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.
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.
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.
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.
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 é 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.
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:
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.
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.
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.
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.
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: