Resolver gargalos no Dataflow

Um gargalo ocorre quando uma etapa, um estágio ou um worker atrasa o job geral. Os gargalos podem levar a workers ociosos e aumentar a latência.

Se o Dataflow detectar um gargalo, o gráfico de jobs vai mostrar um alerta, e o painel Informações da etapa vai listar o tipo de gargalo e a causa, se for conhecida. O Dataflow também exporta informações de detecção de gargalos para uma métrica do Monitoring, que apresenta os dados como uma série temporal. Assim, é possível ver gargalos ao longo do tempo ou no passado.

Entender os gargalos

Quando o Dataflow executa um pipeline de streaming, o job consiste em uma série de componentes, como redistribuições de streaming, linhas de execução de processamento de função definida pelo usuário (DoFn) e criação de pontos de verificação de estado persistente. Para facilitar o fluxo de dados, o Dataflow usa filas para conectar esses componentes. Os dados são enviados do upstream para o downstream.

Em muitos pipelines, a capacidade geral de transmissão é limitada por um único componente, criando um gargalo. A taxa em que os dados podem passar por um gargalo limita a velocidade com que o pipeline pode aceitar e processar dados de entrada.

Por exemplo, considere um pipeline em que o processamento de DoFn ocorre depois de uma ordem aleatória de streaming. Uma fila entre eles armazena em buffer os dados embaralhados, mas não processados. Se o processamento DoFn não conseguir consumir dados tão rápido quanto a ordem aleatória de streaming os produz, a fila vai aumentar. Um gargalo prolongado pode fazer com que a fila atinja a capacidade máxima. Nesse ponto, o embaralhamento é pausado, e o backlog é propagado para cima. As filas mais acima também acumulam backlogs, causando uma lentidão que se estende à fonte de dados. Isso significa que todo o pipeline não consegue acompanhar a entrada.

Quando um gargalo acontece, uma parte substancial do pipeline pode parecer não íntegra, mesmo que um único ponto no pipeline esteja causando o acúmulo. Esse comportamento pode dificultar a depuração de gargalos. O objetivo da detecção de gargalos é identificar o local e a causa exatos, eliminando as suposições para que você possa corrigir a causa raiz.

O Dataflow detecta um gargalo quando um atraso excede o limite de cinco minutos. Se o atraso não ultrapassar esse limite, o Dataflow não vai detectar um gargalo.

A detecção de gargalos nem sempre exige que você tome medidas e depende do seu caso de uso. Um pipeline pode operar normalmente com atrasos temporários de mais de cinco minutos. Se isso for aceitável para seu caso de uso, talvez não seja necessário resolver os gargalos indicados.

Tipos de gargalos

Quando o Dataflow detecta um gargalo, a interface de monitoramento indica a gravidade do problema. Os gargalos se enquadram nas seguintes categorias:

O processamento está travado.
O progresso do pipeline é completamente interrompido nessa etapa.
O processamento está progredindo, mas está atrasado.
O pipeline não consegue processar os dados recebidos na mesma velocidade em que eles chegam. Como resultado, o backlog está crescendo.
O processamento está progredindo, mas o backlog é estável
O pipeline está progredindo, e a taxa de processamento é comparável à taxa de entrada. O processamento é rápido o suficiente para que o backlog não aumente, mas o backlog acumulado também não está diminuindo significativamente.
O processamento está progredindo e está se recuperando de um backlog.
O backlog está diminuindo, mas o gargalo atual impede que o pipeline se recupere mais rápido. Se você iniciar um pipeline com um backlog, esse estado poderá ser normal e não exigir intervenção. Monitore o progresso para ver se o backlog continua diminuindo.

Causas de gargalos

Esta seção lista as causas de gargalos que podem ser detectadas. Use essas informações para resolver o problema. Em alguns casos, pode haver várias causas relacionadas. Por exemplo, se os workers estiverem subprovisionados, a utilização da vCPU poderá ser alta. O uso alto de vCPU pode deixar as operações mais lentas, o que pode criar um atraso elevado na fila. A análise de causa provável pode mostrar todos esses fatores como causas do gargalo.

Operações com longo processamento

Algumas operações nesse cálculo têm um longo tempo de processamento. Isso ocorre sempre que um pacote de entrada é enviado ao worker que executa o DoFn e um tempo significativo se passou sem que os resultados estejam disponíveis.

Isso geralmente é resultado de uma única operação de longa duração no código do usuário. Outros problemas podem se manifestar como operações com longo tempo de processamento. Por exemplo, erros gerados e repetidos dentro do DoFn, novas tentativas por longos períodos ou falhas da estrutura do worker devido a fatores como OOMs podem causar esses longos tempos de processamento.

Se o cálculo afetado estiver no código do usuário, procure maneiras de otimizar o código ou limitar o tempo de execução. Para ajudar na depuração, os registros do worker mostram rastreamentos de pilha de operações que estão travadas por mais de 5 minutos.

Confirmação de chave muito grande

Consulte Exceção de commit de chave muito grande.

Permissão negada para o coletor do BigQuery

Esse erro indica que a conta de serviço que executa o pipeline não tem as permissões necessárias para gravar no recurso do BigQuery.

Para validar esse problema usando os registros do worker:

  1. No console do Google Cloud , abra a página Detalhes do job do Dataflow.
  2. No painel de baixo, clique na guia Registros e selecione Registros de worker.
  3. Procure mensagens de erro que sugiram que as permissões ou o acesso foram negados (por exemplo, PERMISSION_DENIED, 403 Forbidden, Access Denied ou actuallyForbidden).
  4. Inspecione a mensagem de registro para identificar o conjunto de dados ou a tabela de destino e a permissão específica que está faltando (como bigquery.tables.updateData).

Para resolver o problema:

  • Confirme se a conta de serviço recebeu o papel de Editor de dados do BigQuery (roles/bigquery.dataEditor) no conjunto de dados e na tabela de destino.
  • Se você estiver gravando em vários projetos, verifique se as permissões foram concedidas à conta de serviço diretamente no projeto de destino que hospeda o conjunto de dados do BigQuery e se o VPC Service Controls (se ativado) permite a comunicação entre os dois projetos.

Se essas etapas não resolverem o problema, consulte Papéis e permissões predefinidos do BigQuery para identificar e conceder as permissões granulares necessárias para sua configuração específica.

Recurso de coletor do BigQuery esgotado

Esse erro indica que o pipeline excedeu um limite de cota do BigQuery. A causa mais provável é a cota insuficiente no projeto de destino do BigQuery para processar o volume de dados que está sendo gravado.

Para validar esse problema usando os registros do worker:

  1. No console do Google Cloud , abra a página Detalhes do job do Dataflow.
  2. No painel de baixo, clique na guia Registros e selecione Registros de worker.
  3. Procure mensagens de erro que sugiram que os recursos ou as cotas estão esgotados ou que os limites de taxa foram excedidos (por exemplo, RESOURCE_EXHAUSTED, 429 Too Many Requests, quotaExceeded ou rateLimitExceeded).
  4. Inspecione a mensagem de registro para confirmar qual operação e limite de cota foram excedidos (por exemplo, capacidade de processamento ou limites de conexão da API Storage Write AppendRows ou limites de limitação de taxa de inserção por streaming).

Para resolver o problema:

  • Determine qual implementação de coletor do BigQuery seu pipeline está usando (por exemplo, a API Storage Write ou inserções por streaming).
  • Analise o uso da cota do BigQuery no console do Google Cloud . Procure especificamente cotas relacionadas ao tipo de coletor, como conexões simultâneas, capacidade de processamento ou linhas de inserção por streaming por segundo.
  • Se você se aproximar ou exceder esses limites com frequência, solicite um aumento de cota.

Se essas etapas não identificarem o limite específico que está sendo excedido, consulte Resolver erros de cota e limite para investigar mais a fundo.

Falha na RPC do coletor do BigQuery

Esse erro indica que as solicitações de RPC do pipeline para o BigQuery estão falhando. As possíveis causas incluem problemas transitórios de rede ou serviço, payloads de solicitação inválidos, incompatibilidades de esquema ou erros de tempo limite e prazo excedidos.

Para validar esse problema usando os registros do worker:

  1. No console do Google Cloud , abra a página Detalhes do job do Dataflow.
  2. No painel de baixo, clique na guia Registros e selecione Registros de worker.
  3. Procure mensagens de erro ou exceções relacionadas a operações de gravação do BigQuery (por exemplo, DEADLINE_EXCEEDED, UNAVAILABLE, INVALID_ARGUMENT ou erros de validação de esquema).
  4. Inspecione o stack trace e a mensagem de erro para determinar o modo de falha específico retornado pela API BigQuery.

Para resolver o problema:

  • Depois de identificar a mensagem de erro ou o código de status específico nos registros do worker, consulte a referência de mensagens de erro do BigQuery para orientações de solução de problemas específicas desse erro.
  • Se o pipeline usar a API Storage Write, consulte Tratamento de erros na documentação da API BigQuery Storage Write para informações sobre como lidar com erros específicos de gravação e stream.
Tempo de processamento longo em todas as operações

As operações nesse cálculo estão demorando muito, o que sugere um problema no DoFn fornecido pelo usuário.

Essa causa é diferente de Operações com tempo de processamento longo. Enquanto essa causa afeta algumas operações, a outra indica que todas as operações nesse cálculo são afetadas.

Verifique os registros de worker em busca de erros, exceções ou stack traces que indiquem lentidão ou threads presos. Se você estiver usando o SDK do Apache Beam para Python e as operações forem inerentemente de longa duração por design (por exemplo, chamadas lentas de API externa ou E/S de alta latência), considere usar uma Async DoFn. Esse recurso pode melhorar a capacidade de processamento, evitando que o processamento seja bloqueado nessas tarefas de longa duração.

Leitura lenta do estado persistente

A computação está gastando uma quantidade significativa de tempo lendo o estado persistente como parte da execução do DoFn. Isso pode ser resultado de um estado persistente excessivamente grande ou de muitas leituras. Considere reduzir o tamanho do estado persistido ou a frequência de leituras. Otimize os padrões de acesso ao estado combinando várias operações de leitura de estado ou usando o estado de mapa em vez do estado de valor, quando apropriado. Isso também pode ser um problema temporário devido à lentidão do estado persistente subjacente.

Gravação lenta do estado persistente

A computação está gastando uma quantidade significativa de tempo gravando o estado persistente durante o commit dos resultados do processamento. Isso pode ser resultado de um estado persistente excessivamente grande. Considere reduzir o tamanho do estado persistido. Otimize os padrões de acesso ao estado combinando várias operações de gravação de estado quando apropriado. Isso também pode ser um problema temporário devido à lentidão do estado persistente subjacente.

Commit rejeitado

O processamento de dados não pode ser confirmado no estado persistente porque é inválido. Isso geralmente acontece quando um dos limites operacionais é excedido. Confira os registros para mais detalhes ou entre em contato com o suporte.

Partições de origem do Apache Kafka insuficientes

O cálculo da origem do Apache Kafka tem partições insuficientes. Para resolver esse problema, tente o seguinte:

  • Aumente o número de partições do Kafka.
  • Inclua a redistribuição usando .withRedistribute() ao configurar a leitura de E/S do Kafka para paralelizar os dados de maneira mais eficiente. Inclua .withRedistributeNumKeys(N) em que N > partitions para fornecer um limite superior no número total de chaves. Ter um número limitado de chaves oferece eficiência ao agrupar registros.
  • Para minimizar o custo do embaralhamento de redistribuição, use .withOffsetDeduplication(). Esse modo minimiza a quantidade de dados que precisam ser mantidos como parte da redistribuição, sem deixar de oferecer processamento exatamente uma vez.

Para mais informações, consulte Paralelismo na página Ler do Apache Kafka para o Dataflow.

Origem do Apache Kafka com grande volume de estado persistido

O cálculo da origem do Apache Kafka está redistribuindo um grande volume de dados, o que pode gerar alta latência e custo. Para resolver esse problema, tente o seguinte:

  • Se o processamento único for necessário para o pipeline, minimize o custo do embaralhamento de redistribuição usando o modo de eliminação de duplicação de deslocamento. Esse modo minimiza a quantidade de dados que precisam ser mantidos como parte da redistribuição, sem deixar de oferecer processamento exatamente uma vez.
  • Se o processamento "pelo menos uma vez" for suficiente para o pipeline, a configuração permitir duplicados poderá ser ativada.

Para mais informações, consulte Ler do Apache Kafka para o Dataflow.

Paralelismo de origem insuficiente

Um cálculo de origem tem paralelismo insuficiente. Se possível, aumente a paralelização na origem. Se não for possível aumentar a paralelização e o job usar o modo pelo menos uma vez, tente adicionar uma transformação Redistribute ao pipeline.

Chaves com acesso frequente ou insuficiência de paralelismo entre as chaves

O job tem chaves com acesso frequente ou paralelismo insuficiente entre as chaves.

Para cada chave de fragmentação, o Dataflow processa as mensagens em série. Enquanto o Dataflow processa um lote de mensagens para uma determinada chave, outras mensagens recebidas para essa chave são enfileiradas até que o lote atual seja concluído.

Se o Dataflow não conseguir processar chaves distintas suficientes em paralelo, isso pode causar um gargalo. Por exemplo, os dados podem ter poucas chaves distintas ou algumas chaves podem estar super-representadas nos dados ("chaves ativas"). Para resolver isso, modifique a lógica do pipeline para redistribuir os dados. Por exemplo, adicione um sufixo aleatório às chaves de agrupamento para dividir as chaves ativas e agregue os resultados em uma etapa subsequente. Para mais detalhes, consulte Resolver problemas de teclas de atalho.

vCPUs com provisionamento insuficiente

O job não tem vCPUs de worker suficientes. Essa situação ocorre quando o job já está escalonado ao máximo, a utilização da vCPU é alta e ainda há um backlog. Talvez seja necessário aumentar o número máximo de workers provisionados para esse job. Por exemplo, é possível aumentar esse número com uma atualização do intervalo de escalonamento automático. Outra opção é procurar maneiras de diminuir o uso de vCPU com mudanças no código do pipeline ou na carga de trabalho. Use o Cloud Profiler para buscar oportunidades de otimização.

Uso alto de vCPU, aguardando o escalonamento vertical

O job tem um uso alto de vCPU, mas há espaço para escalonamento vertical. Essa condição provavelmente será temporária até que o escalonamento vertical possa ocorrer. É possível monitorar o escalonamento automático para conferir as decisões tomadas. Se essa condição persistir por muito tempo ou ocorrer com frequência, talvez seja necessário mudar a configuração de escalonamento automático definindo uma dica de utilização de worker diferente para permitir que o job faça o escalonamento vertical de maneira mais proativa.

Carga de vCPU não balanceada criando gargalos em alguns workers atípicos

O job tem vCPUs de worker suficientes, mas alguns workers mostram utilização muito alta de vCPU. Isso geralmente é causado por uma distribuição desigual do trabalho. As possíveis causas incluem partições de origem carregadas de forma desigual ou teclas de atalho.

Para resolver esse problema, tente o seguinte:

  • Determine a causa do carregamento desigual e tente corrigir. Por exemplo, verifique se as partições de origem estão distribuídas de maneira uniforme.
  • Se não for possível corrigir a carga desigual, considere mudar o formato da VM de worker para aumentar as vCPUs por worker e reduzir a utilização máxima. Para mais informações sobre como configurar vCPUs por worker, consulte Configurar VMs de worker do Dataflow.
Problema na comunicação com os workers

O Dataflow não consegue se comunicar com todas as VMs de worker. Verifique o status das VMs de worker do job. Estas são as possíveis causas:

  • Há um problema ao provisionar as VMs de worker.
  • O pool de VM de worker é excluído enquanto o job está em execução.
  • Problemas de rede.
A origem do Pub/Sub tem erros de pull.

Há erros ao extrair da origem do Pub/Sub. Verifique se o tópico e as assinaturas necessários existem e confira a cota e a configuração. Você também pode verificar se há erros nos registros.

A origem do Pub/Sub tem paralelismo insuficiente

O cálculo da origem do Pub/Sub tem um número insuficiente de chaves do Pub/Sub. Para aumentar o número de chaves, defina a opção de serviço num_pubsub_keys. Para mais informações, consulte Paralelismo de origem do Pub/Sub.

A origem do Pub/Sub foi limitada por um motivo desconhecido

A computação de origem do Pub/Sub é limitada durante a leitura do Pub/Sub por um motivo desconhecido. Esse problema pode ser temporário. Verifique se há problemas de configuração do Pub/Sub, permissões do IAM ausentes ou limites de cota. No entanto, se nenhuma das áreas anteriores for a causa raiz e o problema persistir, entre em contato com o suporte.

A publicação do coletor do Pub/Sub está lenta ou travou

O cálculo do coletor do Pub/Sub está lento ou travou. Esse problema pode ser causado por um problema de configuração ou um limite de cota.

Tempo alto na fila de trabalho

A idade de trabalho mais antiga qualificada é alta devido a um grande número de chaves e à taxa de processamento delas. Nessa situação, cada operação pode não ser anormalmente longa, mas o atraso geral na fila é alto.

O Dataflow usa uma única linha de execução de processamento por chave de fragmentação, e o número de linhas de execução de processamento é limitado. O atraso na fila é aproximadamente igual à proporção de chaves para linhas de execução, multiplicada pela latência na linha de execução de cada pacote de processamento para uma chave:

(key count / total harness threads) * latency per bundle

Tente as seguintes correções:

  • Aumente o número de workers. Consulte Escalonamento automático de streaming.
  • Aumente o número de linhas de execução de uso de worker. Defina a opção de pipeline numberOfWorkerHarnessThreads / number_of_worker_harness_threads.
  • Diminua o número de chaves.
  • Diminua a latência da operação.
Um problema temporário com o back-end do Streaming Engine

Há um problema de configuração ou operacional com o back-end do Streaming Engine. Esse problema pode ser temporário. Se o problema persistir, entre em contato com o suporte.

Causa indeterminada

Não é possível determinar a causa do backlog com certeza. Esse problema pode ser temporário. Se o problema persistir, entre em contato com o suporte.

Métricas de gargalo

As seguintes métricas de job fornecem informações sobre gargalos:

A seguir