Resolver gargalos no Dataflow

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

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

Entender gargalos

Quando o Dataflow executa um pipeline de streaming, o job consiste em uma série de componentes, como embaralhamentos 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 de 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, o que causa 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 gargalo

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 diminui significativamente.
O processamento está progredindo e está se recuperando de um backlog
O backlog está diminuindo, mas o gargalo atual impede que o pipeline recupere o atraso mais rapidamente. 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 dos gargalos que podem ser detectados. 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 causar lentidão nas operações, o que, por sua vez, 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

O cálculo tem um tempo de processamento longo. Isso acontece 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 há mais de 5 minutos.

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. 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 muito grande. Considere reduzir o tamanho do estado persistido. 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 persistidos 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 persistidos 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 puder processar chaves distintas suficientes em paralelo, isso poderá causar um gargalo. Por exemplo, os dados podem ter poucas chaves distintas ou algumas chaves podem estar super-representadas nos dados ("chaves quentes"). Para mais informações, consulte Resolver problemas de jobs de streaming lentos ou travados.

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 está 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 fazendo mudanças no código do pipeline ou na carga de trabalho. Você pode usar 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 de escalonamento automático. 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 um 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 uma 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 trabalho do job. Estas são as possíveis causas:

  • Ocorreu 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. Também é possível 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 principal 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