Otimização e cache do conjunto de dados

Os painéis de IA/BI armazenam em cache os resultados da consulta para melhorar os tempos de carga. Esta página explica como as otimizações de cache e conjunto de dados do painel funcionam, quando os painéis usam resultados armazenados em cache e quando eles executam novamente consultas em um SQL Warehouse.

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.

Observação

Ao baixar uma tabela truncada, uma consulta é executada. Quando uma tabela exibe resultados truncados porque o conjunto de dados excede 100.000 linhas, o download dos dados como CSV executa uma consulta no SQL Warehouse. Essa consulta aparece 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. Esses dois caches são invalidados de maneiras diferentes. O cache de resultados da consulta nunca retorna dados obsoletos, pois uma alteração nos dados subjacentes invalida todas as suas entradas. O cache do painel tem um comportamento de invalidação diferente. O cache do painel pode retornar resultados com até 24 horas de idade, mesmo quando os dados subjacentes foram alterados, e uma alteração nos dados subjacentes não invalida ou atualiza automaticamente o cache do painel.

Para atualizar de forma confiável o cache do painel, configure um agendamento do painel. Uma alteração nos dados subjacentes não atualiza o cache do painel por conta própria e atualizar os dados como parte de uma etapa de pipeline não atualiza o cache do painel. Além de uma atualização agendada, o cache do painel é atualizado somente quando um painel executa uma consulta que o cache não consegue atender.

Observação

Fornecer resultados do cache do painel não inicia o SQL Warehouse. Quando um painel retorna resultados armazenados em cache, o Azure Databricks lê do cache sem executar uma consulta; portanto, o SQL warehouse subjacente não precisa estar em execução. O warehouse é iniciado somente quando um dashboard executa uma consulta que o cache não pode servir.

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.
Dashboard em rascunho ou dashboard 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 resultados foram recuperados há menos de 24 horas, mesmo que os dados subjacentes tenham sido alterados após a última consulta. 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 do 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.