Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Os painéis de IA/BI são ferramentas valiosas de análise de dados e tomada de decisão, e tempos de carregamento eficientes podem melhorar significativamente a experiência do usuário. Este artigo explica como as otimizações de conjunto de dados e de cache tornam os painéis mais eficazes e eficientes.
Desempenho de consultas
Você pode inspecionar consultas e seu desempenho no histórico de consultas do espaço de trabalho. O histórico de consultas mostra consultas SQL realizadas usando armazéns SQL. Clique no 
Histórico de consultas na barra lateral para visualizar o histórico de consultas. Consulte Histórico de consultas.
Para conjuntos de dados de painel, o Azure Databricks aplica otimizações de desempenho dependendo do tamanho do resultado do conjunto de dados. Para obter informações sobre limites de desempenho de conjuntos de dados, consulte Limites de desempenho de conjuntos de dados.
Otimizações de conjuntos de dados
Seus painéis otimizam a velocidade realizando operações de filtragem e agregação, impulsionadas por filtros ou configurações de visualização, diretamente em seu navegador quando possível. Essas otimizações de desempenho têm os seguintes limites:
| Tamanho do conjunto de dados | Comportamento de processamento |
|---|---|
| Pequeno (≤ 100K linhas e ≤ 100MB) | Para uma velocidade ideal do painel, a filtragem e a agregação são executadas no seu navegador após o carregamento do conjunto de dados inicial. Como essas operações são processadas localmente, elas evitam mais interação com o data warehouse e não aparecem no histórico de consultas. |
| Grande (> 100K linhas ou > 100MB) | A filtragem e a agregação são tratadas no servidor back-end em vez de no navegador. A consulta inicial do conjunto de dados é encapsulada em uma cláusula SQL WITH e a consulta resultante aparece no histórico da consulta. |
| Consultas combinadas (grandes conjuntos de dados) | Para consultas de visualização enviadas para o back-end, consultas de visualização separadas no mesmo conjunto de dados que compartilham as mesmas GROUP BY cláusulas e predicados de filtro são combinadas em uma única consulta para processamento. Nesse caso, os usuários podem ver uma consulta combinada no histórico de consultas que busca resultados para várias visualizações ou filtros. |
Observação
Os parâmetros substituem valores diretamente em uma consulta em tempo de execução, para que essas operações sempre apareçam no histórico de consultas.
Armazenamento em cache e atualização de dados
Os painéis mantêm um cache de resultados de 24 horas para otimizar os tempos de carregamento iniciais, operando com base no melhor esforço. Isso significa que, embora o sistema sempre tente usar resultados históricos de consulta vinculados a credenciais de painel para melhorar o desempenho, há alguns casos em que os resultados armazenados em cache não podem ser criados ou mantidos. Os dados armazenados em cache não têm limite de memória específico ou contagem de consultas fixas.
Para melhorar os tempos de carregamento, os painéis primeiro verificam o cache do painel. Se nenhum resultado de cache estiver disponível, eles verificarão o cache de resultados de consulta genérico. Enquanto o cache do painel pode retornar resultados obsoletos por até 24 horas, o cache de resultados da consulta nunca retorna dados obsoletos. Quando os dados subjacentes são alterados, todas as entradas do cache de resultados da consulta são invalidadas.
Para painéis de várias páginas, aplica-se o seguinte:
- A edição de um painel de rascunho carrega e armazena em cache todos os conjuntos de dados.
- Quando os visualizadores abrem um painel publicado, apenas os conjuntos de dados que suportam a página ativa são executados e armazenados em cache.
- Se uma agenda for definida, todos os conjuntos de dados serão atualizados de acordo com a agenda, e esses resultados serão armazenados em cache.
A tabela a seguir explica como o cache varia de acordo com o status e as credenciais do painel:
| Tipo de painel | Tipo de cache |
|---|---|
| Painel publicado com permissões de dados compartilhados | Cache compartilhado. Todos os espectadores veem os mesmos resultados. |
| Painel em rascunho ou painel publicado com permissões de dados individuais | Cache por usuário. Os visualizadores veem os resultados com base nas suas permissões de dados. |
Os painéis usam automaticamente os resultados da consulta em cache se os dados subjacentes permanecerem inalterados após a última consulta ou se os resultados tiverem sido recuperados há menos de 24 horas. Se existirem resultados obsoletos e os parâmetros forem aplicados ao painel, as consultas serão executadas novamente, a menos que os mesmos parâmetros tenham sido usados nas últimas 24 horas. Da mesma forma, a aplicação de filtros a conjuntos de dados que excedam 100.000 linhas solicita que as consultas sejam executadas novamente, a menos que os mesmos filtros tenham sido aplicados anteriormente nas últimas 24 horas.
Funções atuais de carimbo temporal e invalidação da cache
Usar current_timestamp() ou funções semelhantes na sua consulta SQL não invalida a cache ao nível do dashboard. No entanto, estas funções invalidam a cache de resultados da consulta, que inspeciona a consulta SQL, e acionam uma atualização da cache.
Consultas agendadas
Adicionar uma agenda a um painel publicado com permissões de dados compartilhados pode acelerar significativamente o processo de carregamento inicial para todos os visualizadores do painel.
Para cada atualização agendada do painel, ocorre o seguinte:
- Toda a lógica SQL que define conjuntos de dados é executada no intervalo de tempo designado.
- Os resultados preenchem o cache de resultados da consulta e ajudam a melhorar o tempo de carregamento inicial do painel.