Resolva problemas de gargalos no Dataflow

Um gargalo ocorre quando um passo, uma fase ou um trabalhador abranda o trabalho geral. Os gargalos podem levar a trabalhadores inativos e a um aumento da latência.

Se o Dataflow detetar um gargalo, o gráfico de tarefas mostra um alerta e o painel Informações do passo indica o tipo de gargalo e a causa, se for conhecida. O Dataflow também exporta informações de deteção de gargalos para uma métrica do Stackdriver, que apresenta os dados como uma série cronológica. Isto permite-lhe ver gargalos ao longo do tempo ou no passado.

Compreenda os gargalos

Quando o Dataflow executa um pipeline de streaming, a tarefa consiste numa série de componentes, como misturas de streaming, threads de processamento de funções definidas pelo utilizador (DoFn) e criação de pontos de verificação de estado persistente. Para facilitar o fluxo de dados, o Dataflow usa filas para ligar estes componentes. Os dados são enviados do upstream para o downstream.

Em muitos pipelines, a capacidade de débito geral é limitada por um único componente, o que cria um gargalo no pipeline. A taxa a que os dados se podem mover através de um gargalo limita a rapidez com que o pipeline pode aceitar e processar dados de entrada.

Por exemplo, considere um pipeline em que o processamento DoFn ocorre a jusante de uma mistura de streaming. Uma fila entre eles armazena os dados aleatórios, mas não processados. Se o processamento DoFn não conseguir consumir dados tão rapidamente quanto a ordenação aleatória de streaming os produz, a fila aumenta. Um gargalo prolongado pode fazer com que a fila atinja a sua capacidade. Nesse ponto, a aleatorização adicional é pausada e a fila de espera é propagada a montante. As filas mais a montante também acumulam atrasos, o que acaba por causar um abrandamento que se estende à origem de dados. Isto significa que todo o pipeline não consegue acompanhar o ritmo da entrada.

Quando ocorre um gargalo, uma parte substancial do pipeline pode parecer não estar em bom estado, apesar de um único ponto no pipeline estar a causar o atraso. Este comportamento pode dificultar a depuração de gargalos. O objetivo da deteção de gargalos é identificar a localização e a causa exatas, eliminando as conjeturas, para que possa corrigir a causa principal.

O Dataflow deteta um gargalo quando um atraso excede o limite de cinco minutos. Se o atraso não ultrapassar este limite, o Dataflow não deteta um gargalo.

A deteção de gargalos nem sempre requer a sua intervenção e depende do seu exemplo de utilização. Um pipeline pode funcionar normalmente com atrasos temporários superiores a cinco minutos. Se isto for aceitável para o seu exemplo de utilização, pode não ter de resolver os gargalos indicados.

Tipos de gargalo

Quando o Dataflow deteta um gargalo, a interface de monitorização indica a gravidade do problema. Os gargalos enquadram-se nas seguintes categorias:

O processamento está bloqueado e não está a progredir
O progresso do pipeline é completamente interrompido neste passo.
O processamento está em curso, mas está atrasado.
O pipeline não consegue processar os dados recebidos tão rapidamente quanto chegam. Como resultado, o atraso está a aumentar.
O processamento está em curso, mas o atraso é constante
O pipeline está a progredir e a taxa de processamento é comparável à taxa de entrada. O processamento é suficientemente rápido para que o atraso não aumente, mas o atraso acumulado também não está a diminuir significativamente.
O processamento está em curso e a recuperar de um atraso
A acumulação está a diminuir, mas o gargalo atual impede que o pipeline recupere mais rapidamente. Se iniciar um pipeline com um backlog, este estado pode ser normal e não exigir qualquer intervenção. Monitorize o progresso para ver se o backlog continua a diminuir.

Causas dos gargalos

Esta secção apresenta as causas dos gargalos que podem ser detetados. Use estas informações para resolver o problema. Em alguns casos, podem existir várias causas, e estas podem estar relacionadas. Por exemplo, se os trabalhadores tiverem um aprovisionamento insuficiente, a utilização da CPU virtual pode ser elevada. A utilização elevada da vCPU pode fazer com que as operações fiquem mais lentas, o que, por sua vez, pode criar um atraso na fila elevado. A análise da causa provável pode apresentar todos estes elementos como as causas do gargalo.

Operações com um tempo de processamento longo

A computação tem um longo tempo de processamento. Isto ocorre sempre que um pacote de entrada é enviado para o trabalhador que executa o DoFn e decorreu um período significativo sem que os resultados estejam disponíveis.

Normalmente, isto é o resultado de uma única operação de execução prolongada no código do utilizador. Outros problemas podem manifestar-se como operações de processamento demoradas. Por exemplo, os erros gerados e repetidos no interior do DoFn, as repetições durante longos períodos ou as falhas do ambiente de execução do trabalhador devido a fatores como OOMs podem causar estes longos tempos de processamento.

Se o cálculo afetado estiver no código do utilizador, procure formas de otimizar o código ou limitar o tempo de execução. Para ajudar na depuração, os registos do trabalhador mostram rastreios de pilha para quaisquer operações que estejam bloqueadas durante mais de 5 minutos.

Leitura lenta do estado persistente

O cálculo está a demorar muito tempo a ler o estado persistente como parte da execução do DoFn. Isto pode ser o resultado de um estado persistente excessivamente grande ou de demasiadas leituras. Considere reduzir o tamanho do estado persistente ou a frequência de leituras. Este problema também pode ser temporário devido à lentidão do estado persistente subjacente.

Escrita de estado persistente lenta

A computação está a gastar uma quantidade significativa de tempo a escrever o estado persistente durante a confirmação dos resultados do processamento. Isto pode ser o resultado de um estado persistente excessivamente grande. Considere reduzir o tamanho do estado persistente. Este problema também pode ser temporário devido à lentidão do estado persistente subjacente.

Confirmação rejeitada

Não é possível confirmar o processamento de dados para o estado persistente porque é inválido. Normalmente, isto deve-se ao facto de exceder um dos limites operacionais. Verifique os registos para ver mais detalhes ou contacte o apoio técnico.

Partições de origem do Apache Kafka insuficientes

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

  • Aumente o número de partições do Kafka.
  • Inclua a redistribuição com .withRedistribute() quando configurar a leitura de Kafka IO para paralelizar os dados de forma mais eficiente. Inclua .withRedistributeNumKeys(N), onde N > partitions, para fornecer um limite superior para o número total de chaves. Ter um número limitado de chaves oferece eficiência através da união de registos.
  • Para minimizar o custo da reorganização de redistribuição, use .withOffsetDeduplication(). Este modo minimiza a quantidade de dados que têm de ser mantidos como parte da mistura, ao mesmo tempo que oferece um processamento exatamente uma vez.

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

A origem do Apache Kafka tem um grande volume de estado persistente

O cálculo da origem do Apache Kafka está a redistribuir um volume elevado de dados que pode incorrer em custos e latência elevados. Para resolver este problema, experimente o seguinte:

  • Se for necessário o processamento exatamente uma vez para o pipeline, minimize o custo da ordenação aleatória de redistribuição usando o modo de desduplicação de desvio. Este modo minimiza a quantidade de dados que têm de ser mantidos como parte da mistura, ao mesmo tempo que oferece um processamento exatamente uma vez.
  • Se o processamento pelo menos uma vez for suficiente para o pipeline, pode ativar a configuração permitir duplicados.

Para mais informações, consulte o artigo 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 conseguir aumentar a paralelização e a tarefa usar o modo pelo menos uma vez, experimente adicionar uma transformação Redistribute ao pipeline.

Teclas de atalho ou paralelismo de teclas insuficiente

O trabalho tem teclas de atalho ou paralelismo de teclas insuficiente.

Para cada chave de divisão, o Dataflow processa as mensagens em série. Enquanto o Dataflow está a processar um lote de mensagens para uma determinada chave, as outras mensagens recebidas para essa chave são colocadas em fila até que o lote atual seja concluído.

Se o Dataflow não conseguir processar chaves distintas suficientes em paralelo, pode causar um gargalo. Por exemplo, os dados podem ter poucas chaves distintas ou determinadas chaves podem estar sobrerepresentadas nos dados ("chaves populares"). Para mais informações, consulte o artigo Resolva problemas de trabalhos de streaming lentos ou bloqueados.

vCPUs com aprovisionamento insuficiente

A tarefa não tem vCPUs de trabalho suficientes. Esta situação ocorre quando a tarefa já está dimensionada ao máximo, a utilização da CPU virtual é elevada e ainda existe um atraso. Pode ter de aumentar o número máximo de trabalhadores aprovisionados para esta tarefa. Por exemplo, pode aumentar este número através de uma atualização ao intervalo de dimensionamento automático. Em alternativa, procure formas de diminuir a utilização de vCPU através de alterações ao código do pipeline ou à carga de trabalho. Pode usar o Cloud Profiler para procurar oportunidades de otimização.

Utilização elevada da vCPU, a aguardar o aumento da escala

A tarefa tem uma utilização elevada da vCPU, mas existe espaço para aumentar a escala. É provável que esta condição seja temporária até que seja possível aumentar a escala. Pode monitorizar o ajuste de escala automático para ver as decisões de ajuste de escala automático. Se esta condição persistir durante muito tempo ou ocorrer com frequência, pode ter de alterar a configuração do dimensionamento automático definindo uma sugestão de utilização de trabalhadores diferente para permitir que a tarefa seja dimensionada de forma mais proativa.

Carga de vCPU desequilibrada que cria gargalos em alguns trabalhadores atípicos

O trabalho tem vCPUs de trabalhador suficientes, mas alguns trabalhadores mostram uma utilização de vCPU muito elevada. Isto é frequentemente causado por uma distribuição desigual do trabalho. As causas potenciais incluem partições de origem carregadas de forma desigual ou teclas de atalho.

Para resolver este problema, experimente o seguinte:

  • Determine a causa do carregamento desigual e tente corrigi-la. Por exemplo, certifique-se de que as partições de origem estão distribuídas uniformemente.
  • Se não for possível corrigir a carga desigual, considere alterar o formato da VM de trabalho para aumentar as vCPUs por trabalhador e reduzir a utilização máxima. Para mais informações sobre a configuração de vCPUs por trabalhador, consulte o artigo Configure VMs de trabalhadores do Dataflow.
Problema ao comunicar com os trabalhadores

O Dataflow não consegue comunicar com todas as VMs de trabalho. Verifique o estado das VMs de trabalho da tarefa. As causas possíveis incluem:

  • Existe um problema no aprovisionamento das VMs de trabalho.
  • O conjunto de VMs de trabalho é eliminado enquanto a tarefa está em execução.
  • Problemas de rede.
A origem do Pub/Sub tem erros de obtenção.

Existem erros ao extrair dados da origem do Pub/Sub. Verifique se o tópico e as subscrições necessários existem e valide a quota e a configuração. Também pode verificar se existem erros nos registos.

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 o artigo Paralelismo de origem do Pub/Sub.

Fonte do Pub/Sub limitada por motivo desconhecido

O cálculo da origem do Pub/Sub está limitado durante a leitura do Pub/Sub, por um motivo desconhecido. Este problema pode ser temporário. Verifique se existem problemas de configuração do Pub/Sub, autorizações do IAM em falta ou limites de quota. No entanto, se nenhuma das áreas anteriores for a causa principal e o problema persistir, contacte o apoio técnico.

A publicação do Pub/Sub sink é lenta ou fica bloqueada

O cálculo do destino do Pub/Sub está lento ou bloqueado. Este problema pode dever-se a um problema de configuração ou a um limite de quota.

Tempo de fila de trabalho elevado

A idade mínima elegível para trabalhar é elevada devido ao grande número de chaves e à taxa de processamento das chaves. Nesta situação, cada operação pode não demorar um tempo anormalmente longo, mas o atraso geral na fila é elevado.

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

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

Experimente as seguintes correções:

  • Aumente o número de trabalhadores. Consulte o artigo Ajuste de escala automático de streaming.
  • Aumente o número de threads do arnês do trabalhador. Defina a numberOfWorkerHarnessThreads / number_of_worker_harness_threads opção de tubagem.
  • Diminua o número de chaves.
  • Diminuir a latência da operação.
Um problema transitório com o back-end do motor de streaming

Existe um problema de configuração ou operacional com o back-end do Streaming Engine. Este problema pode ser temporário. Se o problema persistir, contacte o apoio técnico.

Uma causa indeterminável

Não é possível determinar com certeza a causa do atraso. Este problema pode ser temporário. Se o problema persistir, contacte o apoio técnico.

Métricas de gargalo

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

  • job/is_bottleneck: Se uma fase específica do pipeline do Dataflow é uma restrição, juntamente com o respetivo tipo de restrição e a causa provável.

  • job/backlogged_keys: O número de chaves pendentes para uma fase de gargalo.

  • job/recommended_parallelism: O paralelismo recomendado para uma fase de modo a reduzir os gargalos.

O que se segue?