Monitorar o desempenho da tabela dinâmica¶

O monitoramento de desempenho ajuda você com as seguintes tarefas:

Identificar atualizações de tabela dinâmica lentas ou caras.
Diagnosticar gargalos.
Medir o impacto das otimizações.

Este tópico explica o que observar para monitorar o desempenho de tabelas dinâmicas e como diagnosticar problemas. Para obter informações sobre ferramentas de monitoramento, consulte Monitoramento de tabelas dinâmicas.

Dica

Para obter um exemplo prático, consulte Tutorial: otimizar o desempenho de tabela dinâmica para cargas de trabalho SCD tipo 1.

Indicadores-chave de desempenho¶

Para monitorar o desempenho de tabelas dinâmicas, concentre-se nas métricas descritas nesta seção.

Duração da atualização¶

A duração da atualização mede quanto tempo cada atualização leva para ser concluída. Para identificar a degradação do desempenho, rastreie a duração da atualização ao longo do tempo.

Sinais de alerta:

A duração aumenta com o tempo: o aumento do volume de dados ou a degradação da localidade dos dados podem fazer com que os tempos de atualização aumentem constantemente.
A duração se aproxima do atraso de destino: quando as atualizações levam quase o mesmo tempo que o seu atraso de destino, você pode não atender aos requisitos de atualização dos dados.
Alta variância na duração: grandes oscilações no tempo de atualização podem indicar picos de carga de trabalho ou contenção de recursos.

Para visualizar a duração da atualização, consulte Monitore o status de atualização de suas tabelas dinâmicas.

Métricas de atraso¶

As métricas de atraso mostram a qualidade com a qual sua tabela dinâmica atende à meta de atualização. Para obter informações sobre como o atraso de destino funciona, consulte Entendendo o atraso de destino da tabela dinâmica.

Métricas principais:

Atraso real: o tempo entre a alteração dos dados de origem e a atualização da tabela dinâmica.
Proporção de tempo dentro do atraso de destino: a porcentagem de tempo em que uma tabela permaneceu dentro do atraso de destino. Uma proporção abaixo de um indica que o pipeline não está atingindo a meta de atualização.
Atraso máximo: o maior atraso real durante um determinado período.

Para visualizar as métricas de atraso, consulte Monitore o status de atualização de suas tabelas dinâmicas.

Estatísticas de partição¶

Para atualizações incrementais, o número de partições verificadas deve ser proporcional aos dados alterados, e não ao tamanho total da tabela. Um alto número de verificações de partição indica baixa localidade de dados.

Sinais de alerta:

Verificação de uma grande porcentagem do total de partições durante a atualização incremental.
Aumento das verificações de partição ao longo do tempo sem o crescimento correspondente dos dados.

Para visualizar as estatísticas de partição, consulte Análise de perfis de consulta.

Para obter orientações sobre como melhorar a localidade dos dados, consulte Melhorar a localidade de dados.

Modo de atualização¶

O modo de atualização afeta diretamente o desempenho. Verifique se sua tabela dinâmica usa o modo esperado.

Para verificar o modo de atualização, use SHOW DYNAMIC TABLES e revise as colunas refresh_mode e refresh_mode_reason. No Snowsight, visualize o modo de atualização no cabeçalho do objeto.

Para obter orientações sobre como escolher o modo de atualização correto, consulte Escolher um modo de atualização.

Diagnosticar atualizações lentas¶

Quando as atualizações demoram mais do que o esperado, siga estas etapas para identificar a causa:

Verifique o histórico de atualizações em busca de tendências na duração da atualização, como aumentos graduais ou picos repentinos (Monitore o status de atualização de suas tabelas dinâmicas).
Revise o perfil da consulta para identificar gargalos (Análise de perfis de consulta):
- Um alto número de verificações de partição sugere baixa localidade de dados.
- Bytes despejados sugerem que o warehouse é muito pequeno.
- Operadores específicos que levam muito tempo podem indicar uma oportunidade para otimizar sua consulta de tabela dinâmica.
Verifique se o atraso excede de maneira consistente sua meta, o que indica que as atualizações podem não acompanhar seu volume de dados (Monitore o status de atualização de suas tabelas dinâmicas).
Analise as dependências upstream para verificar se as tabelas upstream causam atrasos ou produzem grandes volumes de alterações.

Na exibição Graph no Snowsight, procure as seguintes condições:
- Tabelas upstream executando uma atualização (exibidas com o status executing).
- Tabelas upstream com falha ou suspensas.
- Tabelas upstream demorando mais do que o normal para atualizar.
Para acessar a exibição Graph, consulte Visualize o gráfico das tabelas conectadas às suas tabelas dinâmicas.
Verifique o volume de alterações que a tabela dinâmica processa, pois grandes volumes de alterações de dependências upstream podem deixar as atualizações mais lentas.

Use a função DYNAMIC_TABLE_REFRESH_HISTORY para ver quantas linhas foram alteradas nas atualizações recentes:
```
SELECT
  name,
  data_timestamp,
  statistics:numInsertedRows::INT AS rows_inserted,
  statistics:numDeletedRows::INT AS rows_deleted,
  refresh_action
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(
  NAME => 'my_dynamic_table'
))
ORDER BY data_timestamp DESC
LIMIT 10;
```
Copy
Quando o volume de alterações for alto em relação ao tamanho total da tabela (mais de cinco por cento das linhas da tabela), considere usar o modo de atualização completa.

Padrões comuns e ações recomendadas¶

A duração da atualização é estável, mas a latência é alta: seu atraso de destino provavelmente é muito alto para o tamanho atual do warehouse e o volume de dados. As atualizações são concluídas com sucesso, mas não conseguem acompanhar as alterações recebidas. Verifique se o seu atraso de destino e os recursos do warehouse correspondem ao seu volume de dados.
A duração da atualização aumenta repentinamente e o número de bytes despejados é alto: o warehouse não tem memória suficiente para processar a atualização, seja porque é muito pequeno ou porque outras consultas estão sendo executadas ao mesmo tempo. Aumente o tamanho do warehouse ou mova as atualizações dinâmicas de tabelas para um warehouse dedicado.
As verificações de partição aumentam com o tempo, mas o volume de dados permanece o mesmo: a localidade dos seus dados é baixa, o que força o Snowflake a verificar mais partições do que o necessário. Verifique suas chaves de clustering e a localidade dos dados. Verifique também se as alterações upstream afetam muitas partições dispersas em vez de algumas contíguas.
Cada atualização processa uma grande parte da tabela (mais de cinco por cento das linhas ou partições): a atualização incremental oferece pouco benefício quando a maior parte da tabela muda com frequência. Alterne para o modo de atualização completa ou redesenhe seu pipeline para reduzir a quantidade de dados que muda a cada atualização.

Com base nas suas descobertas, aplique as correções apropriadas de Otimização do desempenho da tabela dinâmica.

Nota

Atualizações ignoradas ou com falha geralmente são causadas por problemas de configuração, não de desempenho. Consulte Troubleshooting skipped or failed dynamic table refreshes.

Análise de perfis de consulta¶

O perfil de consulta mostra estatísticas de execução detalhadas para cada atualização. Quando uma atualização é lenta, o perfil de consulta ajuda a identificar oportunidades de otimização.

Para acessar o perfil de consulta:

Navegue até Transformation » Dynamic Tables.
Selecione a tabela dinâmica e acesse a guia Refresh History.
Selecione Show query profile ao lado da atualização que deseja analisar.

Primeiro, obtenha o ID da consulta no histórico de atualizações:

SELECT
  name,
  refresh_start_time,
  query_id
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(
  NAME => 'my_dynamic_table'
))
WHERE state = 'SUCCEEDED'
ORDER BY refresh_start_time DESC
LIMIT 5;

Copy

Em seguida, analise o perfil de consulta com a função GET_QUERY_OPERATOR_STATS:

SELECT *
FROM TABLE(GET_QUERY_OPERATOR_STATS('<query_id>'));

Copy

O que procurar¶

Partições verificadas e eliminadas: quando as verificações de partição são altas em relação ao número total de partições, a causa geralmente é a baixa localidade de dados ou clusterização ausente.
Distribuição de tempo: verifique quais operadores consomem mais tempo. Operadores que levam um tempo desproporcionalmente longo podem indicar uma oportunidade para otimizar sua consulta. Consulte Otimizar consultas para atualização incremental para obter orientações específicas sobre cada operador.
Bytes despejados no armazenamento local ou remoto: um alto número de bytes despejados geralmente indica que o warehouse é pequeno demais para a carga de trabalho de atualização ou que outras consultas em execução no mesmo warehouse reduzem a memória disponível para atualizações. Considere aumentar o tamanho do warehouse ou executar atualizações de tabelas dinâmicas em um warehouse dedicado para reduzir a contenção.

Para obter mais orientações sobre como resolver problemas encontrados no perfil de consulta, consulte Otimização do desempenho da tabela dinâmica.

Monitorar o uso do warehouse¶

Para verificar se o seu warehouse consegue lidar com a carga de trabalho de tabelas dinâmicas e encontrar maneiras de reduzir custos, monitore o uso do warehouse.

Métricas principais a serem monitoradas¶

Bytes despejados: bytes despejados no armazenamento local ou remoto significam que o warehouse pode ser pequeno demais. Considere aumentar o tamanho do warehouse. Para obter mais detalhes sobre como identificar e solucionar problemas de bytes despejados, consulte Como buscar consultas com vazamento para o armazenamento.
Utilização do warehouse: verifique se o warehouse tem recursos suficientes para as cargas de trabalho de atualização. Baixa utilização significa que você pode ter um warehouse superdimensionado. Tempos de fila altos significam que seu warehouse é pequeno demais ou executa muitas consultas simultâneas.
Enfileiramento de consultas: consultas enfileiradas atrasam as atualizações. Se as atualizações forem enfileiradas com frequência, aumente o tamanho do warehouse, use um warehouse dedicado para atualizações de tabelas dinâmicas ou considere um warehouse multicluster para lidar com cargas de trabalho variáveis.
Uso de crédito: monitore os créditos para equilibrar o desempenho com os custos. Monitore regularmente para encontrar oportunidades de dimensionar corretamente os warehouses ou ajustar os cronogramas de atualização.

Para visualizar o uso do warehouse e os tempos de fila, consulte Redução de filas. Otimize a configuração do warehouse para tabelas dinâmicas com Otimização do desempenho da tabela dinâmica.

Monitorar dependências¶

Dependências entre tabelas dinâmicas podem afetar o desempenho. Problemas de desempenho em tabelas upstream se propagam para tabelas downstream porque uma tabela downstream precisa esperar que as tabelas upstream concluam as atualizações antes de poder iniciar a própria atualização.

Para diagnosticar problemas de desempenho relacionados a dependências upstream, consulte Diagnosticar atualizações lentas.

Para visualizar o gráfico de dependências, consulte Visualize o gráfico das tabelas conectadas às suas tabelas dinâmicas.

Configurar alertas para problemas de desempenho¶

Você pode configurar alertas para receber notificações quando o desempenho piorar. Recomendamos a criação de alertas para as seguintes condições:

A duração da atualização excede um limite.
O atraso não atinge a meta de forma consistente.

Os alertas usam tabelas de eventos para rastrear eventos de atualização. Para obter instruções de configuração, consulte Monitoramento de tabelas de eventos e alertas para tabelas dinâmicas.