Resolva problemas de consultas

Este documento destina-se a ajudar a resolver problemas comuns relacionados com a execução de consultas, como identificar motivos para consultas lentas ou fornecer passos de resolução para erros comuns devolvidos por consultas com falhas.

Resolva problemas de consultas lentas

Ao resolver problemas de desempenho de consultas lentas, considere as seguintes causas comuns:

  1. Consulte a página Google Cloud Estado do serviço para ver interrupções conhecidas do serviço BigQuery que possam afetar o desempenho das consultas.

  2. Reveja a cronologia da tarefa para a sua consulta na página de detalhes da tarefa para ver quanto tempo demorou a execução de cada fase da consulta.

    • Se a maior parte do tempo decorrido se deveu a tempos de criação longos, contacte o apoio ao cliente do Google Cloud para receber assistência.

    • Se a maior parte do tempo decorrido se deveu a tempos de execução longos, reveja as estatísticas de desempenho das consultas. As estatísticas de desempenho das consultas podem informar se a sua consulta foi executada durante mais tempo do que o tempo de execução médio e sugerir possíveis causas. As possíveis causas podem incluir a contenção de slots de consultas ou uma quota de mistura insuficiente. Para mais informações sobre cada problema de desempenho das consultas e possíveis resoluções, consulte o artigo Interprete as estatísticas de desempenho das consultas.

  3. Reveja o campo finalExecutionDurationMs no JobStatistics para a sua tarefa de consulta. A consulta pode ter sido repetida. O campo finalExecutionDurationMs contém a duração em milissegundos da execução da tentativa final desta tarefa.

  4. Reveja os bytes processados na página de detalhes da tarefa de consulta para ver se é superior ao esperado. Pode fazê-lo comparando o número de bytes processados pela consulta atual com outra tarefa de consulta concluída num período aceitável. Se existir uma grande discrepância de bytes processados entre as duas consultas, é possível que a consulta tenha sido lenta devido a um grande volume de dados. Para obter informações sobre a otimização das suas consultas para processar grandes volumes de dados, consulte o artigo Otimize o cálculo de consultas.

    Também pode identificar consultas no seu projeto que processam uma grande quantidade de dados pesquisando as consultas mais caras através da vista INFORMATION_SCHEMA.JOBS.

Compare uma execução lenta e rápida da mesma consulta

Se uma consulta que era executada rapidamente estiver agora a ser executada lentamente, examine o resultado do objeto da API Jobs para identificar alterações na respetiva execução.

Resultados da cache

Confirme se a execução rápida da tarefa foi um resultado da cache consultando o valor cacheHit. Se o valor for true para a execução rápida da consulta, significa que a consulta usou resultados em cache em vez de executar a consulta.

Se espera que a tarefa lenta use resultados em cache, investigue por que motivo a consulta já não usa resultados em cache. Se não espera que a consulta obtenha dados da cache, procure um exemplo de execução de consulta rápida que não tenha acedido à cache para a investigação.

Atrasos na quota

Para determinar se a diminuição da velocidade foi causada por adiamentos de quotas, verifique o campo quotaDeferments para ambas as tarefas. Compare os valores para determinar se a hora de início da consulta mais lenta foi atrasada por adiamentos de quotas que não afetaram a tarefa mais rápida.

Duração da execução

Para compreender a diferença entre a duração da execução da última tentativa de ambas as tarefas, compare os respetivos valores para o campo finalExecutionDurationMs.

Se os valores de finalExecutionDurationMs forem bastante semelhantes, mas a diferença no tempo de execução real entre as duas consultas, calculada como startTime - endTime, for muito maior, significa que pode ter havido uma nova tentativa de execução da consulta interna para a tarefa lenta devido a um possível problema transitório. Se vir este padrão de diferença repetidamente, contacte o apoio ao cliente do Google Cloud para receber assistência

Bytes processados

Reveja os bytes processados na página de detalhes da tarefa de consulta ou consulte o totalBytesProcessed de JobStatistics para ver se é superior ao esperado. Se existir uma grande discrepância de bytes processados entre as duas consultas, a consulta pode ser lenta devido a uma alteração no volume de dados processados. Para obter informações sobre a otimização de consultas para processar grandes volumes de dados, consulte o artigo Otimize o cálculo de consultas. Os seguintes motivos podem provocar um aumento no número de bytes processados por uma consulta:

  • O tamanho das tabelas referenciadas pela consulta aumentou.
  • A consulta está agora a ler uma partição maior da tabela.
  • A consulta faz referência a uma vista cuja definição foi alterada.

Tabelas referenciadas

Verifique se as consultas leem as mesmas tabelas analisando o resultado do campo referencedTables em JobStatistics2. As diferenças nas tabelas referenciadas podem ser explicadas pelo seguinte:

  • A consulta SQL foi modificada para ler tabelas diferentes. Compare o texto da consulta para confirmar.
  • A definição da vista foi alterada entre as execuções da consulta. Verifique as definições das vistas referenciadas nesta consulta e atualize-as, se necessário.

As diferenças nas tabelas referenciadas podem explicar as alterações em totalBytesProcessed.

Utilização da vista materializada

Se a consulta referenciar quaisquer vistas materializadas, as diferenças no desempenho podem ser causadas pela escolha ou rejeição de vistas materializadas durante a execução da consulta. Inspecione MaterializedViewStatistics para compreender se alguma vista materializada usada na consulta rápida foi rejeitada na consulta lenta. Consulte os campos chosen e rejectedReason no objeto MaterializedView.

Estatísticas de colocação em cache de metadados

Para consultas que envolvam tabelas BigLake do Amazon S3 ou tabelas BigLake do Cloud Storage com a cache de metadados ativada, compare o resultado de MetadataCacheStatistics para verificar se existe uma diferença na utilização da cache de metadados entre a consulta lenta e a consulta rápida, bem como os motivos correspondentes. Por exemplo, a cache de metadados pode estar fora da janela maxStaleness da tabela.

Comparar estatísticas do BigQuery BI Engine

Se a consulta usar o BigQuery BI Engine, analise o resultado de BiEngineStatistics para determinar se os mesmos modos de aceleração foram aplicados à consulta lenta e à consulta rápida. Consulte o campo BiEngineReason para compreender o motivo de nível superior da aceleração parcial ou da não aceleração, como memória insuficiente, falta de uma reserva ou entrada demasiado grande.

Rever as diferenças nas estatísticas de desempenho das consultas

Compare as estatísticas de desempenho de consultas para cada uma das consultas analisando o gráfico de execução na Google Cloud consola ou no objeto StagePerformanceStandaloneInsight para compreender os seguintes possíveis problemas:

Preste atenção às estatísticas fornecidas para a tarefa lenta, bem como às diferenças entre as estatísticas produzidas para a tarefa rápida, para identificar alterações de fase que afetam o desempenho.

Uma análise mais detalhada dos metadados de execução de tarefas requer a análise das fases únicas de execução de consultas comparando os objetos ExplainQueryStage das duas tarefas.

Para começar, consulte as métricas Wait ms e Shuffle output bytes descritas na secção Interprete as informações da fase de consulta.

Avisos de recursos na vista INFORMATION_SCHEMA.JOBS

Consulte o campo query_info.resource_warning da vista INFORMATION_SCHEMA.JOBS para ver se existe uma diferença nos avisos analisados pelo BigQuery relativamente aos recursos usados.

Análise de estatísticas de cargas de trabalho

Os recursos de ranhuras disponíveis e a contenção de ranhuras podem afetar o tempo de execução da consulta. As secções seguintes ajudam a compreender a utilização e a disponibilidade de slots para uma execução específica de uma consulta.

Média de espaços por segundo

Para calcular o número médio de espaços usados por milissegundo pela consulta, divida o valor de milissegundos de espaços para a tarefa, totalSlotMs de JobStatistics2, pela duração em milissegundos da execução da tentativa final desta tarefa, finalExecutionDurationMs de JobStatistics.

Também pode calcular o número médio de espaços por milissegundo usados por uma tarefa consultando a vista INFORMATION_SCHEMA.JOBS

Um trabalho que execute uma quantidade semelhante de trabalho com uma quantidade maior de espaços médios por segundo é concluído mais rapidamente. Uma utilização média de slots por segundo inferior pode dever-se ao seguinte:

  1. Não estavam disponíveis recursos adicionais devido a uma contenção de recursos entre diferentes tarefas. A reserva atingiu o limite máximo.
  2. A tarefa não pediu mais espaços durante grande parte da execução. Por exemplo, isto pode acontecer quando existe uma distorção dos dados.

Modelos de gestão de cargas de trabalho e tamanho da reserva

Se usar o modelo de faturação a pedido, o número de ranhuras que pode usar por projeto é limitado. O seu projeto também pode ter ocasionalmente menos vagas disponíveis se houver uma grande quantidade de contestações pela capacidade a pedido numa localização específica.

O modelo baseado na capacidade é mais previsível e permite especificar um número garantido de espaços base.

Tenha em conta estas diferenças quando comparar uma execução de consultas feita através da opção a pedido com uma execução de consultas que usa uma reserva.

A utilização de uma reserva é recomendada para ter um desempenho de execução de consultas estável e previsível. Para mais informações sobre as diferenças entre cargas de trabalho a pedido e baseadas na capacidade, consulte o artigo Introdução à gestão de cargas de trabalho.

Simultaneidade de tarefas

A concorrência de tarefas representa a competição entre tarefas por recursos de slots durante a execução de consultas. Geralmente, uma concorrência de tarefas mais elevada provoca uma execução de tarefas mais lenta, porque a tarefa tem acesso a menos espaços.

Pode consultar a vista INFORMATION_SCHEMA.JOBS para encontrar o número médio de tarefas simultâneas que estão a ser executadas ao mesmo tempo que uma consulta específica num projeto.

Se houver mais do que um projeto atribuído a uma reserva, modifique a consulta para usar JOBS_BY_ORGANIZATION em vez de JOBS_BY_PROJECT para obter dados precisos ao nível da reserva.

Uma simultaneidade média mais elevada durante a execução da tarefa lenta em comparação com a tarefa rápida é um fator que contribui para a lentidão geral.

Considere reduzir a simultaneidade no projeto ou na reserva distribuindo as consultas com utilização intensiva de recursos ao longo do tempo numa reserva ou num projeto, ou em diferentes reservas ou projetos.

Outra solução é comprar uma reserva ou aumentar o tamanho de uma reserva existente. Considere permitir que a reserva use espaços livres.

Para saber quantos espaços deve adicionar, leia acerca da estimativa dos requisitos de capacidade de espaços.

As tarefas executadas em reservas com mais de um projeto atribuído podem ter resultados de atribuição de slots diferentes com a mesma simultaneidade média de tarefas consoante o projeto que as está a executar. Leia acerca da programação justa para saber mais.

Utilização de reservas

Os gráficos de recursos de administrador e a monitorização do Google Cloud do BigQuery podem ser usados para monitorizar a utilização das reservas. Para mais informações, consulte o artigo Monitorize as reservas do BigQuery.

Para saber se uma tarefa pediu mais espaços, consulte a métrica de unidades executáveis estimadas, que é estimatedRunnableUnits da resposta da API Jobs ou period_estimated_runnable_units na vista INFORMATION_SCHEMA.JOBS_TIMELINE. Se o valor desta métrica for superior a 0, significa que a tarefa poderia ter beneficiado de mais vagas nesse momento. Para estimar a percentagem do tempo de execução da tarefa em que a tarefa teria beneficiado de mais espaços, execute a seguinte consulta na vista INFORMATION_SCHEMA.JOBS_TIMELINE:

SELECT
  ROUND(COUNTIF(period_estimated_runnable_units > 0) / COUNT(*) * 100, 1) AS execution_duration_percentage
FROM `myproject`.`region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
WHERE job_id = 'my_job_id'
GROUP BY job_id;
 O resultado é semelhante ao seguinte: 
+---------------------------------+
|   execution_duration_percentage |
+---------------------------------+
|                            96.7 |
+---------------------------------+

Uma percentagem baixa significa que a disponibilidade de recursos de espaços não é um fator importante para a lentidão das consultas neste cenário.

Se a percentagem for elevada e a reserva não tiver sido totalmente utilizada durante este período, contacte o apoio técnico do Google Cloud para investigar.

Se a reserva foi totalmente utilizada durante a execução lenta da tarefa e a percentagem for elevada, a tarefa foi restringida em termos de recursos. Considere reduzir a simultaneidade, aumentar o tamanho da reserva, permitir que a reserva use slots inativos ou comprar uma reserva se a tarefa tiver sido executada a pedido.

Os metadados da tarefa e as conclusões da análise da carga de trabalho são inconclusivos

Se ainda não conseguir encontrar o motivo para explicar o desempenho das consultas mais lento do que o esperado, contacte o apoio ao cliente do Google Cloud para receber assistência.

Resolva problemas de falhas de consultas com gcpdiag

gcpdiag é uma ferramenta de código aberto. Não é um produto Google Cloud suportado oficialmente. Pode usar a ferramenta gcpdiag para ajudar a identificar e corrigir Google Cloud problemas do projeto. Para mais informações, consulte o projeto gcpdiag no GitHub.

A ferramenta gcpdiag ajuda a analisar as consultas do BigQuery com falhas para compreender se existe uma causa principal conhecida e uma mitigação para a falha específica.

Execute o comando gcpdiag

Pode executar o comando gcpdiag a partir da CLI do Google Cloud:

Google Cloud consola

  1. Conclua e, em seguida, copie o seguinte comando. 
    2. gcpdiag runbook bigquery/failed_query \
   --parameter project_id=PROJECT_ID \
   --parameter bigquery_job_region=JOB_REGION \
   --parameter bigquery_job_id=JOB_ID \
   --parameter bigquery_skip_permission_check=SKIP_PERMISSION_CHECK
  2. Abra a Google Cloud consola e ative o Cloud Shell.
    3. Abra a Cloud Console
  3. Cole o comando copiado.
  4. Execute o comando gcpdiag, que transfere a imagem do Docker gcpdiag e, em seguida, faz verificações de diagnóstico. Se aplicável, siga as instruções de saída para corrigir as verificações com falhas.

Docker

Pode executar o gcpdiag usando um wrapper que inicia o gcpdiag num contentor do Docker. O Docker ou o Podman têm de estar instalados.

  1. Copie e execute o seguinte comando na sua estação de trabalho local. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Execute o comando gcpdiag. 
    ./gcpdiag runbook bigquery/failed_query \
   --parameter project_id=PROJECT_ID \
   --parameter bigquery_job_region=JOB_REGION \
   --parameter bigquery_job_id=JOB_ID \
   --parameter bigquery_skip_permission_check=SKIP_PERMISSION_CHECK

Veja os parâmetros disponíveis para este manual de procedimentos.

Substitua o seguinte:

  • PROJECT_ID: o ID do projeto que contém o recurso.
  • JOB_REGION: a região onde a tarefa do BigQuery foi executada.
  • JOB_ID: o identificador da tarefa do BigQuery.
  • SKIP_PERMISSION_CHECK: (Opcional) defina este valor como True se quiser ignorar a verificação de autorizações relevante e acelerar a execução do manual de procedimentos (o valor predefinido é False).

Sinalizações úteis:

Para ver uma lista e uma descrição de todas as flags da ferramenta gcpdiag, consulte as gcpdiag instruções de utilização.

Resolução do esquema Avro

Error string: Cannot skip stream

Este erro pode ocorrer quando carrega vários ficheiros Avro com esquemas diferentes, o que resulta num problema de resolução de esquemas e faz com que a tarefa de importação falhe num ficheiro aleatório.

Para resolver este erro, certifique-se de que o último ficheiro alfabético na tarefa de carregamento contém o superconjunto (união) dos esquemas diferentes. Este é um requisito com base na forma como o Avro processa a resolução de esquemas.

Consultas simultâneas em conflito

Error string: Concurrent jobs in the same session are not allowed

Este erro pode ocorrer quando várias consultas são executadas em simultâneo numa sessão, o que não é suportado. Consulte as limitações da sessão.

Instruções DML em conflito

Error string: Could not serialize access to table due to concurrent update

Este erro pode ocorrer quando as declarações de linguagem de manipulação de dados (DML) que estão a ser executadas em simultâneo na mesma tabela entram em conflito entre si ou quando a tabela é truncada durante uma declaração de DML de mutação. Para mais informações, consulte Conflitos de declarações DML.

Para resolver este erro, execute operações DML que afetem uma única tabela de forma que não se sobreponham.

Subconsultas correlacionadas

Error string: Correlated subqueries that reference other tables are not supported unless they can be de-correlated

Este erro pode ocorrer quando a sua consulta contém uma subconsulta que faz referência a uma coluna de fora dessa subconsulta, denominada coluna de correlação. A subconsulta correlacionada é avaliada através de uma estratégia de execução aninhada ineficiente, na qual a subconsulta é avaliada para cada linha da consulta externa que produz as colunas de correlação. Por vezes, o BigQuery pode reescrever internamente consultas com subconsultas correlacionadas para que sejam executadas de forma mais eficiente. O erro de subconsultas correlacionadas ocorre quando o BigQuery não consegue otimizar suficientemente a consulta.

Para resolver este erro, experimente o seguinte:

  • Remova todas as cláusulas ORDER BY, LIMIT, EXISTS, NOT EXISTS ou IN da sua subconsulta.
  • Use uma consulta com várias declarações para criar uma tabela temporária para referenciar na sua subconsulta.
  • Reescreva a consulta para usar um CROSS JOIN.

Autorizações de controlo de acesso ao nível da coluna insuficientes

Error string: Requires fineGrainedGet permission on the read columns to execute the DML statements

Este erro ocorre quando tenta uma declaração DML DELETE, UPDATE ou MERGE sem ter a autorização de leitor detalhada nas colunas analisadas que usam o controlo de acesso ao nível da coluna para restringir o acesso ao nível da coluna. Para mais informações, consulte o artigo Impacto nas gravações do controlo de acesso ao nível da coluna.

Credenciais inválidas para consultas agendadas

Strings de erro:

  • Error code: INVALID_USERID
  • Error code 5: Authentication failure: User Id not found
  • PERMISSION_DENIED: BigQuery: Permission denied while getting Drive credentials

Este erro pode ocorrer quando uma consulta agendada falha devido a credenciais desatualizadas, especialmente quando consulta dados do Google Drive.

Para resolver este erro, siga estes passos:

Credenciais da conta de serviço inválidas

Error string: HttpError 403 when requesting returned: The caller does not have permission

Este erro pode aparecer quando tenta configurar uma consulta agendada com uma conta de serviço. Para resolver este erro, consulte os passos de resolução de problemas em Problemas de autorização e permissão.

Hora do instantâneo inválida

Error string: Invalid snapshot time

Este erro pode ocorrer quando tenta consultar dados do histórico que estão fora do período de viagem no tempo para o conjunto de dados. Para resolver este erro, altere a consulta para aceder aos dados do histórico na janela de viagem no tempo do conjunto de dados.

Este erro também pode ser apresentado se uma das tabelas usadas na consulta for eliminada e recriada após o início da consulta. Verifique se existe uma consulta ou uma aplicação agendada que execute esta operação e que tenha sido executada ao mesmo tempo que a consulta com falha. Se existir, experimente mover o processo que executa a operação de eliminação e recriação para ser executado num momento que não entre em conflito com as consultas que leem essa tabela.

O trabalho já existe

Error string: Already Exists: Job <job name>

Este erro pode ocorrer para tarefas de consulta que têm de avaliar grandes matrizes, de modo que demora mais tempo do que a média a criar uma tarefa de consulta. Por exemplo, uma consulta com uma cláusula WHERE, como WHERE column IN (<2000+ elements array>).

Para resolver este erro, siga estes passos:

Este erro também pode ocorrer quando define manualmente um ID de tarefa, mas a tarefa não devolve êxito dentro de um período de limite de tempo. Neste caso, pode adicionar um controlador de exceções para verificar se a tarefa existe. Se for o caso, pode obter os resultados da consulta a partir da tarefa.

Emprego não encontrado

Error string: Job not found

Este erro pode ocorrer em resposta a uma chamada getQueryResults, em que não é especificado nenhum valor para o campo location. Se for o caso, tente novamente a chamada e faculte um valor location.

Para mais informações, consulte o artigo Evite várias avaliações das mesmas expressões de tabelas comuns (CTEs).

Localização não encontrada

Error string: Dataset [project_id]:[dataset_id] was not found in location [region]

Este erro é devolvido quando faz referência a um recurso de conjunto de dados que não existe ou quando a localização no pedido não corresponde à localização do conjunto de dados.

Para resolver este problema, especifique a localização do conjunto de dados na consulta ou confirme que o conjunto de dados está disponível na mesma localização.

A consulta excede o limite de tempo de execução

Error string: Query fails due to reaching the execution time limit

Se a sua consulta estiver a atingir o limite de tempo de execução da consulta, verifique o tempo de execução de execuções anteriores da consulta consultando a vista INFORMATION_SCHEMA.JOBS com uma consulta semelhante ao seguinte exemplo:

SELECT TIMESTAMP_DIFF(end_time, start_time, SECOND) AS runtime_in_seconds
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE statement_type = 'QUERY'
AND query = "my query string";

Se as execuções anteriores da consulta demoraram significativamente menos tempo, use as estatísticas de desempenho de consultas para determinar e resolver o problema subjacente.

A resposta da consulta é demasiado grande

Error string: responseTooLarge

Este erro ocorre quando os resultados da sua consulta são superiores ao tamanho máximo da resposta.

Para resolver este erro, siga as orientações fornecidas para a mensagem de erro responseTooLarge na tabela de erros.

Reserva não encontrada ou com horários em falta

Error string: Cannot run query: project does not have the reservation in the data region or no slots are configured

Este erro ocorre quando a reserva atribuída ao projeto na região da consulta tem zero espaços atribuídos. Pode adicionar espaços à reserva, permitir que a reserva use espaços inativos, usar uma reserva diferente ou remover a atribuição e executar a consulta a pedido.

Tabela não encontrada

Error string: Not found: Table [project_id]:[dataset].[table_name] was not found in location [region]

Este erro ocorre quando não é possível encontrar uma tabela na consulta no conjunto de dados ou na região que especificou. Para resolver este erro, faça o seguinte:

  • Verifique se a sua consulta contém o projeto, o conjunto de dados e o nome da tabela corretos.
  • Verifique se a tabela existe na região em que executou a consulta.
  • Certifique-se de que a tabela não foi eliminada e recriada durante a execução da tarefa. Caso contrário, a propagação incompleta de metadados pode causar este erro.

Demasiadas instruções DML

Error string: Too many DML statements outstanding against <table-name>, limit is 20

Este erro ocorre quando excede o limite de 20 declarações DML no estado PENDING numa fila para uma única tabela. Normalmente, este erro ocorre quando envia tarefas DML para uma única tabela mais rapidamente do que o BigQuery consegue processar.

Uma possível solução é agrupar várias operações DML mais pequenas em trabalhos maiores, mas em menor número. Por exemplo, pode agrupar atualizações e inserções. Quando agrupa tarefas mais pequenas em tarefas maiores, o custo de execução das tarefas maiores é amortizado e a execução é mais rápida. A consolidação de declarações DML que afetam os mesmos dados geralmente melhora a eficiência das tarefas DML e é menos provável que exceda o limite da quota de tamanho da fila. Para mais informações sobre a otimização das operações DML, consulte o artigo Evite declarações DML que atualizam ou inserem linhas únicas.

Outras soluções para melhorar a eficiência da DML podem ser criar partições ou clusters nas suas tabelas. Para mais informações, consulte as práticas recomendadas.

Transação anulada devido a uma atualização simultânea

Error string: Transaction is aborted due to concurrent update against table [table_name]

Este erro pode ocorrer quando duas declarações DML de mutação diferentes tentam atualizar a mesma tabela em simultâneo. Por exemplo, suponhamos que inicia uma transação numa sessão que contém uma declaração DML de mutação seguida de um erro. Se não existir um controlador de exceções, o BigQuery reverte automaticamente a transação quando a sessão termina, o que demora até 24 horas. Durante este período, outras tentativas de executar uma declaração DML de mutação na tabela falham.

Para resolver este erro, liste as suas sessões ativas e verifique se alguma delas contém uma tarefa de consulta com o estado ERROR que executou uma declaração DML de mutação na tabela. Em seguida, termine essa sessão.

O utilizador não tem autorização

Strings de erro:

  • Access Denied: Project [project_id]: User does not have bigquery.jobs.create permission in project [project_id].
  • User does not have permission to query table project-id:dataset.table.
  • Access Denied: User does not have permission to query table or perhaps it does not exist.

Estes erros podem ocorrer quando executa uma consulta sem a autorização bigquery.jobs.create no projeto a partir do qual está a executar a consulta, independentemente das suas autorizações no projeto que contém os dados.

Também pode receber estes erros se a sua conta de serviço, utilizador ou grupo não tiver a autorização bigquery.tables.getData em todas as tabelas e vistas a que a sua consulta faz referência. Para mais informações sobre as autorizações necessárias para executar uma consulta, consulte a secção Funções necessárias.

Estes erros também podem ocorrer se a tabela não existir na região consultada, como asia-south1. Pode validar a região examinando a localização do conjunto de dados.

Ao resolver estes erros, tenha em atenção o seguinte:

  • Contas de serviço: as contas de serviço têm de ter a autorização bigquery.jobs.create no projeto a partir do qual são executadas e têm de ter a autorização bigquery.tables.getData em todas as tabelas e vistas referenciadas pela consulta.

  • Funções personalizadas: as funções de IAM personalizadas têm de ter a autorização bigquery.jobs.create explicitamente incluída na função relevante e têm de ter a autorização bigquery.tables.getData em todas as tabelas e vistas referenciadas pela consulta.

  • Conjuntos de dados partilhados: quando trabalha com conjuntos de dados partilhados num projeto separado, ainda pode precisar da autorização bigquery.jobs.create no projeto para executar consultas ou tarefas nesse conjunto de dados.

Para conceder autorização para aceder a uma tabela ou a uma vista, consulte o artigo Conceda acesso a uma tabela ou a uma vista.

Problemas de recursos excedidos

Os seguintes problemas ocorrem quando o BigQuery tem recursos insuficientes para concluir a sua consulta.

A consulta excede os recursos da CPU

Error string: Query exceeded resource limits

Este erro ocorre quando as consultas a pedido usam demasiada CPU em relação à quantidade de dados analisados. Para obter informações sobre como resolver estes problemas, consulte o artigo Resolva problemas de recursos excedidos.

A consulta excede os recursos de memória

Error string: Resources exceeded during query execution: The query could not be executed in the allotted memory

Para as declarações SELECT, este erro ocorre quando a consulta usa demasiados recursos. Para resolver este erro, consulte o artigo Resolva problemas de recursos excedidos.

Sem espaço na pilha

Error string: Out of stack space due to deeply nested query expression during query resolution.

Este erro pode ocorrer quando uma consulta contém demasiadas chamadas de funções aninhadas. Por vezes, partes de uma consulta são traduzidas em chamadas de funções durante a análise. Por exemplo, uma expressão com operadores de concatenação repetidos, como A || B || C || ..., torna-se CONCAT(A, CONCAT(B, CONCAT(C, ...))).

Para resolver este erro, reescreva a consulta para reduzir a quantidade de aninhamento.

Recursos excedidos durante a execução da consulta

Error string: Resources exceeded during query execution: The query could not be executed in the allotted memory. Peak usage: [percentage]% of limit. Top memory consumer(s): ORDER BY operations.

Isto pode acontecer com consultas ORDER BY ... LIMIT ... OFFSET .... Devido aos detalhes de implementação, a ordenação pode ocorrer numa única unidade de computação, que pode ficar sem memória se tiver de processar demasiadas linhas antes de aplicar as funções LIMIT e OFFSET, particularmente com uma função OFFSET grande.

Para resolver este erro, evite valores de OFFSET grandes em consultas ORDER BY ... LIMIT. Em alternativa, use a função de janela escalável ROW_NUMBER() para atribuir classificações com base na ordem escolhida e, em seguida, filtre estas classificações numa cláusula WHERE. Por exemplo:

SELECT ...
FROM (
  SELECT ROW_NUMBER() OVER (ORDER BY ...) AS rn
  FROM ...
)
WHERE rn > @start_index AND rn <= @page_size + @start_index  -- note that row_number() starts with 1

A consulta excede os recursos de mistura

Error string: Resources exceeded during query execution: Your project or organization exceeded the maximum disk and memory limit available for shuffle operations

Este erro ocorre quando uma consulta não consegue aceder a recursos de aleatorização suficientes.

Para resolver este erro, aprovisione mais espaços ou reduza a quantidade de dados processados pela consulta. Para mais informações sobre formas de o fazer, consulte o artigo Quota de aleatorização insuficiente.

Para mais informações sobre como resolver estes problemas, consulte o artigo Resolva problemas de recursos excedidos.

A consulta é demasiado complexa

Error string: Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex

Este erro ocorre quando uma consulta é demasiado complexa. As principais causas da complexidade são:

  • Cláusulas WITH que estão profundamente aninhadas ou são usadas repetidamente.
  • Vistas que estão profundamente aninhadas ou são usadas repetidamente.
  • Utilização repetida do operador UNION ALL.

Para resolver este erro, experimente as seguintes opções:

  • Divida a consulta em várias consultas e, em seguida, use a linguagem processual para executar essas consultas numa sequência com estado partilhado.
  • Use tabelas temporárias em vez de cláusulas WITH.
  • Reescreva a consulta para reduzir o número de objetos referenciados e comparações.

Pode monitorizar proativamente as consultas que se estão a aproximar do limite de complexidade usando o campo query_info.resource_warning na vista INFORMATION_SCHEMA.JOBS. O exemplo seguinte devolve consultas com uma elevada utilização de recursos nos últimos três dias:

SELECT
  ANY_VALUE(query) AS query,
  MAX(query_info.resource_warning) AS resource_warning
FROM
  <your_project_id>.`region-us`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 DAY)
  AND query_info.resource_warning IS NOT NULL
GROUP BY
  query_info.query_hashes.normalized_literals
LIMIT
  1000

Para mais informações sobre como resolver estes problemas, consulte o artigo Resolva problemas de recursos excedidos.

Resolva problemas de recursos excedidos

Para tarefas de consulta:

Para otimizar as suas consultas, experimente os seguintes passos:

  • Experimente remover uma cláusula ORDER BY.
  • Se a sua consulta usar JOIN, certifique-se de que a tabela maior está no lado esquerdo da cláusula. Certifique-se também de que os seus dados não contêm chaves de junção duplicadas.
  • Se a sua consulta usar FLATTEN, determine se é necessário para o seu exemplo de utilização. Para mais informações, consulte o artigo Dados aninhados e repetidos.
  • Se a sua consulta usar EXACT_COUNT_DISTINCT, considere usar COUNT(DISTINCT) em alternativa.
  • Se a sua consulta usar COUNT(DISTINCT <value>, <n>) com um valor <n> grande, considere usar GROUP BY em alternativa. Para mais informações, consulte COUNT(DISTINCT).
  • Se a sua consulta usar UNIQUE, considere usar GROUP BY em alternativa ou uma função de janela dentro de uma seleção secundária.
  • Se a sua consulta materializar muitas linhas com uma cláusula LIMIT, pondere filtrar noutra coluna, por exemplo, ROW_NUMBER(), ou remover completamente a cláusula LIMIT para permitir a paralelização da escrita.
  • Se a sua consulta usou visualizações de propriedade profundamente aninhadas e uma cláusula WITH, isto pode causar um crescimento exponencial na complexidade, atingindo assim os limites.
  • Use tabelas temporárias em vez de cláusulas WITH. Uma cláusula WITH pode ter de ser recalculada várias vezes, o que pode tornar a consulta complexa e, por isso, lenta. A persistência de resultados intermédios em tabelas temporárias reduz, em alternativa, a complexidade.
  • Evite usar consultas UNION ALL.
  • Se a sua consulta usar MATCH_RECOGNIZE, modifique a cláusula PARTITION BY para reduzir o tamanho das partições ou adicione uma cláusula PARTITION BY se não existir.

Para obter mais informações, consulte os seguintes recursos:

Para tarefas de carregamento:

Se estiver a carregar ficheiros Avro ou Parquet, reduza o tamanho das linhas nos ficheiros. Verifique se existem restrições de tamanho específicas para o formato de ficheiro que está a carregar:

Se receber este erro ao carregar ficheiros ORC, contacte o apoio técnico.

Para a API Storage:

Error string: Stream memory usage exceeded

Durante uma chamada da API Storage Read ReadRows, algumas streams com um elevado consumo de memória podem receber um erro RESOURCE_EXHAUSTED com esta mensagem. Isto pode acontecer quando lê a partir de tabelas largas ou tabelas com um esquema complexo. Como resolução, reduza o tamanho da linha de resultados selecionando menos colunas para ler (usando o parâmetro selected_fields) ou simplificando o esquema da tabela.

Resolva problemas de conetividade

As secções seguintes descrevem como resolver problemas de conetividade quando tenta interagir com o BigQuery:

Adicione o DNS da Google à lista de autorizações

Use a ferramenta Google IP Dig para resolver o ponto final DNS do BigQuery bigquery.googleapis.com para um único IP de registo "A". Certifique-se de que este IP não está bloqueado nas definições da firewall.

Em geral, recomendamos que adicione os nomes de DNS da Google à lista de autorizações. Os intervalos de IP partilhados nos ficheiros https://www.gstatic.com/ipranges/goog.json e https://www.gstatic.com/ipranges/cloud.json mudam frequentemente. Por isso, recomendamos que adicione os nomes DNS da Google à lista de autorizações. Segue-se uma lista de nomes de DNS comuns que recomendamos adicionar à lista de autorizações:

  • *.1e100.net
  • *.google.com
  • *.gstatic.com
  • *.googleapis.com
  • *.googleusercontent.com
  • *.appspot.com
  • *.gvt1.com

Identifique o proxy ou a firewall que está a rejeitar pacotes

Para identificar todos os saltos de pacotes entre o cliente e o Google Front End (GFE), execute um comando traceroute no seu computador cliente que possa realçar o servidor que está a rejeitar pacotes direcionados para o GFE. Segue-se um exemplo de um comando traceroute:

traceroute -T -p 443 bigquery.googleapis.com

Também é possível identificar saltos de pacotes para endereços IP do GFE específicos se o problema estiver relacionado com um endereço IP específico:

traceroute -T -p 443 142.250.178.138

Se existir um problema de limite de tempo do lado da Google, verá que o pedido chega até ao GFE.

Se vir que os pacotes nunca chegam ao GFE, contacte o administrador de rede para resolver este problema.

Gere um ficheiro PCAP e analise a sua firewall ou proxy

Gere um ficheiro de captura de pacotes (PCAP) e analise o ficheiro para se certificar de que a firewall ou o proxy não está a filtrar pacotes para IPs da Google e está a permitir que os pacotes alcancem o GFE.

Segue-se um comando de exemplo que pode ser executado com a ferramenta tcpdump:

tcpdump -s 0 -w debug.pcap -K -n host bigquery.googleapis.com

Configure novas tentativas para problemas de conetividade intermitentes

Existem situações em que os equilibradores de carga do GFE podem rejeitar ligações de um IP de cliente, por exemplo, se detetarem padrões de tráfego DDOS ou se a instância do equilibrador de carga estiver a ser reduzida, o que pode resultar na reciclagem do IP do ponto final. Se os balanceadores de carga do GFE interromperem a ligação, o cliente tem de detetar o pedido com tempo limite excedido e repetir o pedido ao ponto final de DNS. Certifique-se de que não usa o mesmo endereço IP até o pedido ser bem-sucedido, porque o endereço IP pode ter mudado.

Se identificou um problema com tempos limite consistentes do lado da Google em que as novas tentativas não ajudam, contacte o apoio técnico ao cliente do Google Cloud e certifique-se de que inclui um ficheiro PCAP atualizado gerado através da execução de uma ferramenta de captura de pacotes, como o tcpdump.

O que se segue?