Monitoramento de atividades¶

Detalhes da consulta¶

A Query Details tab fornece os resultados da consulta juntamente com informações adicionais. A Query Details tab é a guia padrão para a página de consulta. A Query Details tab apresenta as seguintes seções:

• Details

• SQL Text

• Results

A seção Details fornece informações adicionais sobre a execução da consulta, inclusive:

• O status da consulta.

• Quando a consulta começou.

• Quando a consulta terminou.

• A duração da consulta.

• A ID da consulta.

• A ID da sessão.

• O status do driver.

• O driver do cliente.

A seção SQL Text fornece o texto real da consulta. Passe o mouse sobre o texto SQL para abrir o texto em uma planilha ou copiar o texto.

A seção Results fornece os resultados da consulta. Selecione Export Query para exportar os resultados como um arquivo .csv.

Perfil de consulta¶

A guia Query Profile permite explorar o plano de execução da consulta e compreender detalhes granulares sobre cada etapa de execução.

O perfil da consulta é uma ferramenta poderosa para compreender a mecânica das consultas. Pode ser usado sempre que você precisar saber mais sobre o desempenho ou comportamento de uma determinada consulta. É projetado para ajudar a detectar erros típicos em expressões de consulta SQL para identificar possíveis gargalos de desempenho e oportunidades de melhoria.

Esta seção fornece uma breve visão geral de como navegar e usar o perfil de consulta.

• Plano de execução da consulta

• Nó do operador

• Navegação no perfil de consulta

• Painéis informativos

Interface	Descrição
Plano de execução da consulta	O plano de execução da consulta aparece no centro do perfil da consulta. O plano de execução da consulta é composto por nós de operador, que representam operadores de conjunto de linhas. As setas entre os nós do operador indicam os conjuntos de linhas que fluem de um operador para outro.
Nó do operador	Cada nó de operador inclui o seguinte: O tipo de operador e o número da ID. O tempo usado para executar este operador, representado como uma porcentagem da duração da consulta. Uma visualização dos detalhes do operador. Por exemplo, o nome de uma tabela ou de uma lista de expressões.
Navegação no perfil de consulta	No canto superior esquerdo do perfil de consulta, use os botões para: Passar pelas etapas de execução. Ajustar o plano de execução da consulta na janela. Ampliar e reduzir o plano de execução da consulta. Nota As etapas só aparecem se a consulta foi executada em etapas.
Painéis informativos	O perfil de consulta fornece vários painéis de informação. Os painéis aparecem no plano de execução da consulta. Os painéis que aparecem dependem do foco do plano de execução da consulta. O perfil de consulta inclui os seguintes painéis de informação: Profile Overview Statistics Most Expensive Nodes Attributes Para saber mais sobre as informações fornecidas pelos painéis, consulte Referência do histórico de consultas.

Visão geral do perfil¶

O painel fornece informações sobre quais tarefas de processamento consumiram tempo de consulta. O tempo de execução fornece informações sobre “onde o tempo foi gasto” durante o processamento de uma consulta. O tempo gasto pode ser dividido nas seguintes categorias:

• Processing — tempo gasto no processamento de dados pela CPU.

• Local Disk IO — hora em que o processamento foi bloqueado pelo acesso a disco local.

• Remote Disk IO — hora em que o processamento foi bloqueado pelo acesso a disco remoto.

• Network Communication — tempo em que o processamento aguardava a transferência dos dados da rede.

• Synchronization — diversas atividades de sincronização entre os processos participantes.

• Initialization — tempo gasto na preparação do processamento da consulta.

Estatísticas¶

Uma das principais fontes de informações fornecidas no painel de detalhes são as diversas estatísticas, agrupadas nas seções seguintes:

• IO — informações sobre as operações de entrada-saída realizadas durante a consulta:

  • Scan progress — a porcentagem de dados verificados para uma determinada tabela até o momento.

  • Bytes scanned — o número de bytes verificados até o momento.

  • Percentage scanned from cache — a porcentagem de dados verificados a partir do cache do disco local.

  • Bytes written — bytes gravados (por exemplo, ao carregar em uma tabela).

  • Bytes written to result — bytes gravados no objeto de resultado. Por exemplo, select * from . . . produziria um conjunto de resultados em formato tabular representando cada campo na seleção. Em geral, o objeto de resultado representa tudo o que é produzido como resultado da consulta, e Bytes gravados no resultado representa o tamanho do resultado retornado.

  • Bytes read from result — bytes lidos do objeto de resultado.

  • External bytes scanned — bytes lidos a partir de um objeto externo, por exemplo, um estágio.

• DML — estatísticas para consultas de linguagem de manipulação de dados (DML):

  • Number of rows inserted — número de linhas inseridas em uma tabela (ou tabelas).

  • Number of rows updated — número de linhas atualizadas em uma tabela.

  • Number of rows deleted — número de linhas excluídas de uma tabela.

  • Number of rows unloaded — número de linhas descarregadas durante a exportação de dados.

• Pruning — informações sobre os efeitos da remoção realizada na tabela:

  • Partitions scanned — número de partições verificadas até o momento.

  • Partitions total — número total de partições em uma determinada tabela.

• Spilling — informações sobre o uso do disco para operações onde os resultados intermediários não cabem na memória:

  • Bytes spilled to local storage — volume de dados despejados para o disco local.

  • Bytes spilled to remote storage — volume de dados despejados no disco remoto.

• Network — comunicação em rede:

  • Bytes sent over the network — quantidade de dados enviados pela rede.

• External Functions — informações sobre chamadas para funções externas:

  As seguintes estatísticas são mostradas para cada função externa chamada pela instrução SQL. Se a mesma função foi chamada mais de uma vez a partir da mesma instrução SQL, então as estatísticas são agregadas.

  • Total invocations — número de vezes que uma função externa foi chamada. (Isto pode ser diferente do número de chamadas de funções externas no texto da instrução SQL devido ao número de lotes em que as linhas estão divididas, o número de novas tentativas (se houver problemas transitórios na rede), etc.)

  • Rows sent — número de linhas enviadas para funções externas.

  • Rows received — número de linhas recebidas de volta das funções externas.

  • Bytes sent (x-region) — número de bytes enviados para funções externas. Se o rótulo incluir “(x-region)”, os dados foram enviados através de regiões (o que pode ter impacto no faturamento).

  • Bytes received (x-region) — número de bytes recebidos de funções externas. Se o rótulo incluir “(x-region)”, os dados foram enviados através de regiões (o que pode ter impacto no faturamento).

  • Retries due to transient errors — número de tentativas de repetição devido a erros transitórios.

  • Average latency per call — média de tempo por invocação (chamada) entre o momento em que Snowflake enviou os dados e o recebimento dos dados devolvidos.

  • HTTP 4xx erros — número total de solicitações de HTTP que retornaram um código de status 4xx.

  • HTTP 5xx erros — número total de solicitações de HTTP que retornaram um código de status 5xx.

  • Latency per successful call (avg) — latência média para solicitações de HTTP bem-sucedidas.

  • Avg throttle latency overhead — sobretaxa média por solicitação bem-sucedida devido a uma desaceleração causada pela limitação (HTTP 429).

  • Batches retried due to throttling — número de lotes que foram repetidos devido a erros HTTP 429.

  • Latency per successful call (P50) — latência de percentil 50 para solicitações de HTTP bem-sucedidas. 50 por cento de todas as solicitações bem-sucedidas levaram menos do que esse tempo para serem concluídas.

  • Latency per successful call (P90) — latência de percentil 90 para solicitações de HTTP bem-sucedidas. 90 por cento de todas as solicitações bem-sucedidas levaram menos do que esse tempo para serem concluídas.

  • Latency per successful call (P95) — latência de percentil 95 para solicitações de HTTP bem-sucedidas. 95 por cento de todas as solicitações bem-sucedidas levaram menos do que esse tempo para serem concluídas.

  • Latency per successful call (P99) — latência de percentil 99 para solicitações de HTTP bem-sucedidas. 99 por cento de todas as solicitações bem-sucedidas levaram menos do que esse tempo para serem concluídas.

• Extension Functions — informações sobre chamadas para funções de extensão:

  • Java UDF handler load time – quantidade de tempo para o manipulador da UDF de Java carregar.

  • Total de invocações do manipulador da UDF de Java — número de vezes que o manipulador da UDF de Java é invocado.

  • Max Java UDF handler execution time — quantidade de tempo máxima para que o manipulador da UDF de Java seja executado.

  • Avg Java UDF handler execution time — quantidade média de tempo para executar o manipulador da UDF de Java.

  • Java UDTF process() invocations — número de vezes que o método de processo da UDTF foi invocado.

  • Java UDTF process() execution time — quantidade de tempo para executar o processo da UDTF de Java.

  • Avg Java UDTF process() execution time — quantidade média de tempo para executar o processo da UDTF de Java.

  • Java UDTF’s constructor invocations — número de vezes que o construtor da UDTF foi invocado.

  • Java UDTF’s constructor execution time — quantidade de tempo para executar o construtor da UDTF de Java.

  • Avg Java UDTF’s constructor execution time — quantidade média de tempo para executar o construtor da UDTF de Java.

  • Java UDTF endPartition() invocations — número de vezes que o método endPartition da UDTF foi invocado.

  • Java UDTF endPartition() execution time — quantidade de tempo para executar o método endPartition da UDTF de Java.

  • Avg Java UDTF endPartition() execution time — quantidade média de tempo para executar o método endPartition da UDTF de Java.

  • Max Java UDF dependency download time — quantidade máxima de tempo para baixar as dependências da UDF de Java.

  • Max JVM memory usage — pico de uso de memória conforme relatado pelo JVM.

  • Java UDF inline code compile time in ms — tempo de compilação para o código inline da UDF de Java.

  • Python total UDF invocações do manipulador — número de vezes que o manipulador da UDF de Python foi invocado.

  • Total Python UDF handler execution time — tempo total de execução do manipulador da UDF de Python.

  • Avg Python UDF handler execution time — quantidade média de tempo para executar o manipulador da UDF de Python.

  • Python sandbox max memory usage — pico de uso de memória pelo ambiente sandbox do Python.

  • Avg Python env creation time: Download and install packages — quantidade média de tempo para criar o ambiente Python, incluindo download e instalação de pacotes.

  • Conda solver time — quantidade de tempo para executar o solucionador Conda para resolver pacotes Python.

  • Conda env creation time — quantidade de tempo para criar o ambiente Python.

  • Python UDF initialization time — quantidade de tempo para inicializar a UDF de Python.

  • Number of external file bytes read for UDFs — número de bytes de arquivos externos lidos para UDFs.

  • Number of external files accessed for UDFs — número de arquivos externos acessados para UDFs.

  Se o valor de um campo, por exemplo “Retries due to transient errors”, for zero, então o campo não é exibido.

Nodos mais caros¶

O painel lista todos os nós que duraram 1% ou mais do tempo total de execução da consulta (ou o tempo de execução da etapa de consulta exibida, se a consulta foi executada em várias etapas de processamento). O painel lista os nós por tempo de execução em ordem decrescente, permitindo aos usuários localizar rapidamente os nós mais custosos em termos de tempo de execução.

Atributos¶

As seções seguintes fornecem uma lista dos tipos de operadores mais comuns e seus atributos:

“Explosão” de junções¶

Um dos erros comuns dos usuários de SQL é unir tabelas sem fornecer uma condição de junção (resultando em um “produto cartesiano”), ou fornecer uma condição em que os registros de uma tabela correspondem a vários registros de outra tabela. Para tais consultas, o operador Join produz significativamente (muitas vezes por ordem de magnitude) mais tuplas do que consome.

Isto pode ser observado verificando o número de registros produzidos por um operador Join, e normalmente também se reflete em um operador Join que consome muito tempo.

UNION sem ALL¶

Em SQL, é possível combinar dois conjuntos de dados com constructos UNION ou UNION ALL. A diferença entre eles é que UNION ALL simplesmente concatena as entradas, enquanto UNION faz o mesmo, mas também realiza a eliminação de duplicatas.

Um erro comum é usar UNION quando a semântica UNION ALL é suficiente. Estas consultas aparecem no perfil de consulta como um operador UnionAll com um operador extra Aggregate por cima (que realiza a eliminação de duplicatas).

Consultas grandes demais para caber na memória¶

Para algumas operações (por exemplo, eliminação de duplicatas para um conjunto de dados grande), a quantidade de memória disponível para os servidores usados para executar a operação pode não ser suficiente para armazenar resultados intermediários. Como resultado, o mecanismo de processamento de consultas começará a despejar os dados no disco local. Se o espaço em disco local não for suficiente, os dados despejados são salvos em discos remotos.

Este despejo pode ter um efeito profundo no desempenho da consulta (especialmente se for utilizado disco remoto para despejo). Para sanar isso, recomendamos:

• Usar um warehouse maior (aumentando efetivamente a memória disponível/espaço em disco local para a operação), e/ou

• Processar dados em lotes menores.

Remoção ineficiente¶

O Snowflake coleta estatísticas ricas em dados, permitindo não ler partes desnecessárias de uma tabela com base nos filtros de consulta. Entretanto, para que isso tenha efeito, a ordem do armazenamento de dados precisa ser correlacionada com os atributos do filtro de consulta.

A eficiência da remoção pode ser observada comparando as estatísticas de partições verificadas e partições totais nos operadores TableScan. Se a primeira for uma pequena fração da segunda, a remoção foi eficiente. Caso contrário, não teve efeito.

Naturalmente, a remoção só pode ajudar para consultas que realmente filtram uma quantidade significativa de dados. Se as estatísticas de remoção não mostram redução de dados, mas há um operador Filter acima de TableScan que filtra uma série de registros, isto pode sinalizar que uma organização de dados diferente pode ser benéfica para esta consulta.

Para obter mais informações sobre remoção, consulte Explicação das estruturas de tabela do Snowflake.