Receber insights de desempenho da consulta

Neste documento, descrevemos como usar o gr�fico de execu��o de consultas para diagnosticar problemas de desempenho e ver insights de desempenho da consulta.

O BigQuery oferece um bom desempenho de consulta, mas tamb�m � um sistema distribu�do complexo com muitos fatores internos e externos que podem afetar a velocidade da consulta. A natureza declarativa da linguagem SQL tamb�m pode ocultar a complexidade da execu��o da consulta. Isso significa que, quando suas consultas est�o mais lentas do que o esperado ou mais lentas do que as anteriores, entender o que aconteceu pode ser um desafio.

O gr�fico de execu��o de consultas oferece uma interface intuitiva para inspecionar detalhes de desempenho das consultas. Ao us�-lo, � poss�vel analisar as informa��es do plano de consulta no formato gr�fico para qualquer consulta, esteja ela em execu��o ou conclu�da.

Tamb�m � poss�vel usar o gr�fico de execu��o de consultas para ver insights de desempenho das consultas. Os insights de desempenho oferecem sugest�es de melhor esfor�o para ajudar a melhorar o desempenho das consultas. Como o desempenho da consulta � multifacetado, os insights de desempenho talvez s� forne�am uma vis�o parcial do desempenho geral da consulta.

Permiss�es necess�rias

Para usar o gr�fico de execu��o de consulta, voc� precisa ter as seguintes permiss�es:

  • bigquery.jobs.get
  • bigquery.jobs.listAll

Essas permiss�es est�o dispon�veis por meio dos seguintes pap�is predefinidos do Identity and Access Management (IAM) do BigQuery:

  • roles/bigquery.admin
  • roles/bigquery.resourceAdmin
  • roles/bigquery.resourceEditor
  • roles/bigquery.resourceViewer

Conferir insights de desempenho da consulta

Console

Siga estas etapas para conferir os insights de desempenho da consulta:

  1. Abra a p�gina do BigQuery no console do Google Cloud.

    Acesse a p�gina do BigQuery

  2. No Editor, clique em Hist�rico pessoal ou Hist�rico do projeto.

  3. Na lista de jobs, identifique o job de consulta que interessa a voc�. Clique em A��es e escolha Abrir consulta no editor.

  4. Selecione a guia Gr�fico de execu��o para ver uma representa��o gr�fica de cada est�gio da consulta:

    O plano de consulta gr�fico no gr�fico de execu��o.

    Para determinar se um est�gio de consulta tem insights de desempenho, veja o �cone exibido. Os est�gios que t�m um �cone de informa��o t�m insights de desempenho. Os est�gios que t�m um �cone de verifica��o n�o t�m.

  5. Clique em um cen�rio para abrir o painel de detalhes dele e ver as seguintes informa��es:

    Detalhes do est�gio da consulta.

  6. Opcional: se voc� estiver inspecionando uma consulta em execu��o, clique em Sincronizar para atualizar o gr�fico de execu��o para que ele reflita o status atual da consulta.

    Sincronizar o gr�fico com uma consulta em execu��o.

  7. Opcional: para destacar os est�gios principais por dura��o de est�gio no gr�fico, clique em Destacar os principais est�gios por dura��o.

    Mostrar os principais est�gios por dura��o.

  8. Opcional: para destacar os principais est�gios por tempo de slot no gr�fico, clique em Destacar os principais est�gios por processamento.

    Mostrar os principais est�gios por processamento.

  9. Opcional: para incluir est�gios de redistribui��o aleat�ria no gr�fico, clique em Mostrar est�gios de redistribui��o aleat�ria.

    Mostrar os principais est�gios por processamento.

    Utilize essa op��o para mostrar os est�gios de reparti��o e acoplamento ocultos no gr�fico de execu��o padr�o.

    Os est�gios de reparti��o e uni�o s�o introduzidas enquanto a consulta est� em execu��o e s�o usados para melhorar a distribui��o de dados entre os funcion�rios que processam a consulta. Como esses est�gios n�o est�o relacionados ao texto da sua consulta, eles ficam ocultas para simplificar o plano de consulta exibido.

Para qualquer consulta que tenha problemas de regress�o de desempenho, os insights de desempenho tamb�m s�o exibidos na guia Informa��es do job:

Guia "Informa��es do job"

SQL

  1. No Console do Google Cloud, acesse a p�gina BigQuery.

    Ir para o BigQuery

  2. No editor de consultas, digite a seguinte instru��o:

    SELECT
      `bigquery-public-data`.persistent_udfs.job_url(
        project_id || ':us.' || job_id) AS job_url,
      query_info.performance_insights
    FROM
      `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
    WHERE
      DATE(creation_time) >= CURRENT_DATE - 30 -- scan 30 days of query history
      AND job_type = 'QUERY'
      AND state = 'DONE'
      AND error_result IS NULL
      AND statement_type != 'SCRIPT'
      AND EXISTS ( -- Only include queries which had performance insights
        SELECT 1
        FROM UNNEST(
          query_info.performance_insights.stage_performance_standalone_insights
        )
        WHERE slot_contention OR insufficient_shuffle_quota
        UNION ALL
        SELECT 1
        FROM UNNEST(
          query_info.performance_insights.stage_performance_change_insights
        )
        WHERE input_data_change.records_read_diff_percentage IS NOT NULL
      );
    

  3. Clique em Executar.

Para mais informa��es sobre como executar consultas, acesse Executar uma consulta interativa.

API

� poss�vel conseguir insights de desempenho da consulta em um formato n�o gr�fico chamando ojobs.list m�todo da API e inspecionar a JobStatistics2 informa��es retornadas.

Interpretar insights de desempenho da consulta

Use esta se��o para saber mais sobre o que os insights de desempenho significam e como lidar com eles.

Os insights de desempenho s�o destinados a dois p�blicos-alvo:

  • Analistas: voc� executa consultas em um projeto. Voc� quer saber por que uma consulta executada anteriormente est� inesperadamente mais lenta e receber dicas sobre como melhorar o desempenho de uma consulta. Voc� tem as permiss�es descritas em Permiss�es necess�rias.

  • Administradores de data lake ou data warehouse: voc� gerencia os recursos e as reservas do BigQuery da sua organiza��o. Voc� tem as permiss�es associadas ao papel de administrador do BigQuery.

Cada uma das se��es a seguir fornece orienta��es sobre o que voc� pode fazer para resolver um insight de desempenho recebido com base em um desses pap�is ocupados.

Conten��o de slot

Quando voc� executa uma consulta, o BigQuery tenta dividir o trabalho necess�rio em tarefas. Uma tarefa � uma fra��o �nica de dados que s�o entradas em ou retiradas de um est�gio. Um �nico slot seleciona uma tarefa e executa aquela parte de dados do est�gio. O ideal � que os slots do BigQuery executem essas tarefas em paralelo para alcan�ar um alto desempenho. A conten��o de slots ocorre quando sua consulta tem muitas tarefas prontas para come�ar a ser executada, mas o BigQuery n�o consegue slots suficientes dispon�veis para execut�-las.

O que fazer se voc� for analista

Reduza os dados processados na consulta seguindo as orienta��es em Reduzir os dados processados em consultas.

O que fazer se voc� for administrador

Aumente a disponibilidade ou diminua o uso de slots realizando as seguintes a��es:

  • Se voc� usar o pre�o sob demanda do BigQuery, suas consultas usar�o um pool compartilhado de slots. Em vez disso, considere mudar para os pre�os de an�lise com base em capacidade comprando reservas. As reservas permitem reservar slots dedicados para as consultas da sua organiza��o.
  • Se voc� estiver usando reservas do BigQuery, verifique se h� slots suficientes na reserva atribu�da ao projeto que estava executando a consulta. A reserva pode n�o ter slots suficientes nestes cen�rios:

    • H� outros jobs que consomem slots de reserva. Use Gr�ficos de recursos do administrador para ver como sua organiza��o est� usando a reserva.
    • A reserva n�o tem slots atribu�dos suficientes para executar consultas com rapidez suficiente. Use o Estimador de slot para ter uma estimativa do tamanho das reservas para processar as tarefas das consultas com efici�ncia.

    Para resolver isso, voc� pode tentar:

    • Adicionar mais slots (slots de valor de refer�ncia ou slots de reserva m�xima) a essa reserva.
    • Criar outra reserva e atribu�-la ao projeto que executa a consulta.
    • Distribuir consultas que usam muitos recursos ao longo do tempo em uma reserva ou em reservas diferentes.
  • Verifique se as tabelas que voc� est� consultando s�o em cluster. O clustering garante que o BigQuery possa ler rapidamente as colunas com dados correlacionados.

  • Verifique se as tabelas que voc� est� consultando est�o particionadas. No caso de tabelas n�o particionadas, o BigQuery l� toda a tabela. O particionamento de tabelas ajuda a garantir que voc� consulte apenas o subconjunto de tabelas em que tem interesse.

Cota de embaralhamento insuficiente

Antes de executar sua consulta, o BigQuery divide a l�gica da consulta em est�gios. Os slots do BigQuery executam as tarefas para cada est�gio. Quando um slot conclui a execu��o de tarefas de um est�gio, ele armazena os resultados intermedi�rios em shuffle. Os est�gios seguintes na sua consulta leem dados do embaralhamento para continuar a execu��o da consulta. A cota de embaralhamento insuficiente ocorre quando voc� tem mais dados que precisam ser gravados para serem embaralhados do que voc� tem de capacidade de shuffle.

O que fazer se voc� for analista

Da mesma forma que a conten��o de slots, reduzir a quantidade de dados que a consulta processa pode reduzir o uso do embaralhamento. Para fazer isso, siga as orienta��es em Reduzir dados processados em consultas.

Certas opera��es no SQL tendem a fazer uso mais abrangente do embaralhamento, principalmente opera��es JOIN e cl�usulas GROUP BY. Quando poss�vel, a redu��o da quantidade de dados nessas opera��es pode reduzir o uso de embaralhamento.

O que fazer se voc� for administrador

Reduza a conten��o de cota de embaralhamento realizando as seguintes a��es:

  • Assim como a conten��o de slots, se voc� usar o pre�o sob demanda do BigQuery, suas consultas usar�o um pool compartilhado de slots. Em vez disso, considere mudar para os pre�os de an�lise com base em capacidade comprando reservas. As reservas oferecem slots dedicados e capacidade de embaralhamento para as consultas dos seus projetos.
  • Se voc� estiver usando reservas do BigQuery, os slots ser�o oferecidos com capacidade dedicada de embaralhamento. Se a reserva estiver executando algumas consultas que fazem uso extensivo do embaralhamento, isso pode fazer com que outras consultas em paralelo n�o tenham capacidade suficiente de embaralhamento. � poss�vel identificar quais jobs fazem grande uso da capacidade de embaralhamento consultando a coluna period_shuffle_ram_usage_ratio na visualiza��o INFORMATION_SCHEMA.JOBS_TIMELINE.

    Para resolver isso, tente uma ou mais das seguintes solu��es:

    • Adicionar mais slots a esta reserva.
    • Criar outra reserva e atribu�-la ao projeto que executa a consulta.
    • Distribuir consultas com uso intensivo de embaralhamento ao longo do tempo em uma reserva ou em reservas diferentes.

Mudan�a da escala de entrada de dados

Esse insight de desempenho indica que sua consulta est� lendo pelo menos 50% mais dados de uma determinada tabela de entrada do que a �ltima vez que voc� a executou. Use o hist�rico de altera��es da tabela para ver se o tamanho de qualquer uma das tabelas usadas na consulta aumentou recentemente.

O que fazer se voc� for analista

Reduza os dados processados na consulta seguindo as orienta��es em Reduzir os dados processados em consultas.

Agrupamento de alta cardinalidade

Quando uma consulta cont�m uma mesclagem com chaves n�o exclusivas em ambos os lados da mesclagem, o tamanho da tabela de sa�da pode ser consideravelmente maior do que o de qualquer uma das tabelas de entrada. Esse insight indica que a propor��o de linhas de sa�da para linhas de entrada � alta e oferece informa��es sobre essas contagens de linhas.

O que fazer se voc� for analista

Verifique as condi��es de mesclagem para confirmar se o aumento no tamanho da tabela de sa�da � esperado. Evite usar correla��es. Se voc� precisar usar uma correla��o, tente usar uma cl�usula GROUP BY para pr�-agregar os resultados ou use uma fun��o de janela. Para mais informa��es, consulte Reduzir dados antes de usar um JOIN.

Desvio da parti��o

Para enviar feedback ou pedir suporte para esse recurso, envie um e-mail para bq-query-inspector-feedback@google.com.

Isso pode fazer com que as consultas sejam executadas lentamente. Quando uma consulta � executada, o BigQuery divide os dados em pequenas parti��es. N�o � poss�vel compartilhar parti��es entre slots. Portanto, se os dados forem distribu�dos de maneira desigual, algumas parti��es ficar�o muito grandes, causando falha no slot que processa a parti��o superdimensionada.

O desvio ocorre em fases JOIN. Quando voc� executa uma opera��o JOIN, o BigQuery divide os dados dos lados direito e esquerdo da opera��o JOIN em parti��es. Se uma parti��o for muito grande, os dados ser�o reequilibrados por est�gios de reparti��o. Se o desvio for muito ruim e o BigQuery n�o puder se reequilibrar ainda mais, um insight de distor��o de parti��o ser� adicionado ao est�gio "JOIN". Esse processo � conhecido como est�gios de reparti��o. Se o BigQuery detectar parti��es grandes que n�o podem ser divididas, um insight de distor��o de parti��o ser� adicionado ao cen�rio JOIN.

O que fazer se voc� for analista

Para evitar o desvio de parti��o, filtre os dados o quanto antes. Para mais informa��es sobre como evitar desvio de parti��o, consulte Filtrar dados para dados distorcidos.

Interpretar as informa��es do est�gio de consulta

Al�m de usar insights de desempenho da consulta, tamb�m � poss�vel usar as diretrizes a seguir ao analisar os detalhes do est�gio de consulta para ajudar a determinar se h� um problema com uma consulta:

  • Se o valor de Wait ms para um ou mais est�gios for alto em compara��o com as execu��es anteriores da consulta:
    • Veja se voc� tem slots suficientes dispon�veis para acomodar sua carga de trabalho. Caso contr�rio, fa�a o balanceamento de carga ao executar consultas com uso intensivo de recursos para que eles n�o concorram entre si.
    • Se o valor Wait ms estiver maior do que em um �nico est�gio, procure o est�gio antes dele para ver se um gargalo foi introduzido. Coisas como mudan�as substanciais nos dados ou no esquema das tabelas envolvidas na consulta podem afetar o desempenho da consulta.
  • Se o valor de Bytes de sa�da do embaralhamento de um est�gio for alto em compara��o com execu��es anteriores da consulta ou com um est�gio anterior, avalie as etapas processadas nesse est�gio para ver se alguma criou volumes de dados inesperados. Uma causa comum para isso � quando uma etapa processa uma INNER JOIN em que h� chaves duplicadas nos dois lados da mesclagem. Isso pode retornar uma grande quantidade inesperada de dados.
  • Use o gr�fico de execu��o para analisar os principais est�gios por dura��o e processamento. Considere a quantidade de dados que eles produzem e se est� em conformidade com o tamanho das tabelas referenciadas na consulta. Se n�o estiver, veja as etapas desses est�gios para ver se alguma deles pode produzir uma quantidade inesperada de dados tempor�rios.

A seguir