Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Os painéis são ferramentas valiosas de análise de dados e de tomada de decisão e tempos de carga eficientes podem melhorar significativamente a experiência do usuário. Este artigo explica como o cache e as otimizações de conjunto de dados tornam os painéis mais eficientes e com desempenho.
Desempenho de consulta
Você pode inspecionar as consultas e o desempenho delas no histórico de consultas do workspace. O histórico de consultas mostra as consultas de SQL executadas usando SQL warehouses. Clique no 
Histórico de consultas na barra lateral para exibir 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 os limites de desempenho do conjunto de dados, consulte os limites de desempenho do conjunto de dados.
Otimizações de conjuntos de dados
Seus dashboards otimizam para velocidade executando operações de filtragem e agregação, controladas por filtros ou configurações de visualização, diretamente no navegador, quando possível. Essas otimizações de desempenho têm os seguintes limites:
| Tamanho do conjunto de dados | Comportamento de processamento |
|---|---|
| Pequeno (≤ 100 mil linhas e ≤ 100 MB) | Para a velocidade ideal do painel, a filtragem e a agregação são executadas no navegador após o carregamento do conjunto de dados inicial. Como essas operações são processadas localmente, elas evitam uma interação adicional com o data warehouse e não aparecem no histórico de consultas. |
| Grande (> 100 mil linhas ou > 100 MB) | A filtragem e a agregação são tratadas no servidor de 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 de consultas. |
| Consultas combinadas (grandes conjuntos de dados) | Para consultas de visualização enviadas ao back-end, consultas de visualização separadas em relação ao mesmo conjunto de dados que compartilham as mesmas cláusulas GROUP BY 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 runtime, portanto, essas operações sempre aparecem no histórico de consultas.
Cache e atualização de dados
Os painéis mantêm um cache de resultados de 24 horas para otimizar os tempos iniciais de carregamento, operando com o melhor esforço. Isso significa que, embora o sistema sempre tente usar resultados históricos de consulta vinculados às credenciais do 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 fixa.
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 da consulta genérica. Embora o cache do painel possa 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 de cache de resultados de consulta são invalidadas.
Para painéis de várias páginas, o seguinte se aplica:
- Editar um painel de rascunho carrega e armazena em cache todos os conjuntos de dados.
- Quando os visualizadores abrem um painel publicado, somente os conjuntos de dados que suportam a página ativa são executados e armazenados em cache.
- Se um agendamento for definido, todos os conjuntos de dados serão atualizados de acordo com o agendamento 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 de controle publicado com permissões de compartilhamento de dados | Cache compartilhado. Os mesmos resultados são exibidos para todos os visualizadores. |
| Painel de rascunho ou painel publicado com permissões de dados individuais. | Por cache de usuário. Os resultados são exibidos para os visualizadores com base nas suas permissões de dados. |
Os painéis usam automaticamente os resultados da consulta armazenada em cache se os dados subjacentes permanecerem inalterados após a última consulta ou se os resultados foram recuperados há menos de 24 horas. Se houver resultados obsoletos e 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 com mais de 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 de timestamp correntes e invalidação de cache
Usar current_timestamp() ou funções semelhantes em sua consulta SQL não invalida o cache no nível do painel. No entanto, essas funções invalidam o cache de resultados da consulta, que inspeciona a consulta SQL e disparam uma atualização de cache.
Consultas agendadas
Adicionar um agendamento 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 de painel agendada, 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 carga inicial do painel.