Este documento explica como minimizar o impacto das falhas de tarefas para pipelines de processamento em lote grandes. As falhas de carga de trabalho grandes são particularmente impactantes devido ao tempo e ao dinheiro necessários para recuperar e corrigir estas falhas. A repetição destas condutas desde o início quando falham é dispendiosa em termos de tempo e dinheiro.
Para reduzir as falhas dispendiosas da pipeline de processamento em lote, siga as diretrizes nesta página. Uma vez que nem sempre é possível evitar completamente elementos com falhas e falhas de pipeline, as técnicas fornecidas focam-se no aumento da resiliência, na redução do custo das falhas e na facilidade de depuração e compreensão das falhas quando ocorrem.
Para ver as práticas recomendadas gerais de pipelines, consulte o artigo Práticas recomendadas de pipelines do Dataflow.
Execute pequenas experiências para tarefas grandes
Antes de executar uma tarefa de lote grande, execute uma ou mais tarefas mais pequenas num subconjunto do conjunto de dados. Esta técnica pode fornecer uma estimativa de custos e ajudar a encontrar potenciais pontos de falha.
Estimativa de custos
A execução de experiências pode fornecer um limite mínimo estimado do custo total de execução da tarefa. Normalmente, o cálculo do custo do trabalho é cost of test
job*size(full dataset)/size(test dataset). Consoante o pipeline, o custo pode aumentar de forma superlinear ou, menos frequentemente, sublinear. No entanto, este passo
oferece frequentemente uma boa estimativa aproximada do custo do trabalho. Também pode experimentar diferentes tamanhos de entradas para obter uma melhor estimativa de como os seus custos são dimensionados. Use estas informações para decidir se quer continuar com o pipeline existente ou reestruturar o pipeline para reduzir os custos.
Encontre pontos de falha
A execução de experiências pode expor erros, potenciais pontos de falha ou potenciais problemas de configuração e eficiência. Também pode examinar outras métricas do pipeline, como as seguintes:
- Se a sua pipeline usar quase toda a memória disponível, pode ter exceções de falta de memória (OOM) sob uma carga mais elevada ou com registos excecionalmente grandes. Pode ter de aprovisionar mais memória para o trabalho final para evitar estes erros de falta de memória.
- Se o seu pipeline apresentar quedas no débito, examine os registos do pipeline para determinar o motivo. Pode encontrar um elemento bloqueado ou uma parte do conjunto de dados com um desempenho particularmente fraco. Pode processar estes pontos de dados separadamente ou aplicar um limite de tempo ao processar elementos. Para mais informações, consulte a secção Limite de tempo para registos dispendiosos neste documento.
- Se o seu pipeline tiver um desempenho muito pior numa tarefa no Dataflow do que localmente, examine a lógica do pipeline para descobrir o motivo. Por exemplo, se estiver a obter o mesmo débito com oito núcleos no Dataflow que com um núcleo localmente, o trabalho pode estar limitado pela contenção de um recurso. Se verificar que o desempenho é pior do que o esperado, considere uma ou mais das seguintes opções:
- Execute mais experiências com diferentes configurações de software ou máquinas.
- Teste localmente com vários núcleos em simultâneo.
- Inspeccione o seu código para encontrar potenciais gargalos na implementação em grande escala.
Se o seu pipeline tiver recomendações do Dataflow, siga-as para melhorar o desempenho.
Use filas de mensagens rejeitadas para processar dados incorretos inesperados
Muitas vezes, os pipelines têm êxito na maioria dos elementos de entrada, mas falham num pequeno subconjunto da entrada. Pode não detetar este problema quando executa experiências pequenas, porque estas experiências testam apenas um subconjunto da entrada. Por predefinição, o Dataflow tenta novamente estas tarefas com falhas quatro vezes no modo de lote e um número ilimitado de vezes no modo de streaming. No modo de lote, após atingir o limite de novas tentativas, toda a tarefa falha. No modo de streaming, pode ficar parado indefinidamente.
Em muitas tarefas, pode excluir estes elementos com falhas do pipeline e
concluir o resto da tarefa através de uma fila de mensagens rejeitadas (fila de mensagens não processadas). A fila de mensagens rejeitadas passa os registos com falhas para um resultado separado
PCollection, que pode gerir separadamente do resultado principal. Esta configuração permite-lhe criar uma política para estes registos. Por exemplo, pode
escrevê-los manualmente no Pub/Sub, inspecioná-los e limpá-los e, em seguida,
processar novamente os registos.
Muitas transformações do Apache Beam incluem suporte incorporado para filas de mensagens rejeitadas.
Em Java, pode aceder a eles com um objeto ErrorHandler. Em Python, pode aceder a estes elementos através do método with_exception_handling. Algumas transformações têm formas personalizadas de definir filas de mensagens rejeitadas, sobre as quais pode ler na documentação da transformação. Para mais informações,
consulte o artigo Use filas de mensagens rejeitadas para o processamento de erros.
Para determinar se a sua tarefa cumpre os critérios para uma fila de mensagens rejeitadas, consulte a secção Limitações neste documento.
Limitações da fila de mensagens não entregues
Nos seguintes cenários, uma fila de mensagens rejeitadas pode não ser útil:
- Falhas do ciclo de vida do trabalhador completo ou
DoFn. Se o processamento falhar para todo o trabalhador ou pacote, uma fila de mensagens rejeitadas não consegue detetar a falha. Por exemplo, se o seu pipeline encontrar uma exceção de falta de memória (OOM), todas as tarefas ativas na VM falham e são repetidas, sem enviar nada para a fila de mensagens rejeitadas. - Combinações ou outras agregações. Se o seu pipeline realizar cálculos que exigem que todos os elementos de entrada estejam presentes e sejam processados como parte do resultado, tenha cuidado ao usar uma fila de mensagens rejeitadas antes deste passo. A utilização de uma fila de mensagens rejeitadas exclui parte dos dados de entrada do resultado. A adição de uma fila de mensagens rejeitadas pode trocar a correção pela tolerância a falhas.
- Falhas no caminho da fila de mensagens rejeitadas. Se um elemento falhar durante o envio para o destino da fila de mensagens rejeitadas, todo o pipeline pode falhar.
Para evitar esta falha, mantenha a lógica da fila de mensagens rejeitadas o mais básica possível. Pode adicionar um passo de espera (consulte o
wait class) para garantir que a entrada principal termina antes de escrever os elementos da fila de mensagens rejeitadas. Esta configuração pode reduzir o desempenho e atrasar os sinais de erro do seu pipeline. - Elementos parcialmente transformados. Se inserir uma fila de mensagens rejeitadas a meio do pipeline, a fila de mensagens rejeitadas pode gerar o elemento parcialmente transformado e não ter acesso ao elemento original. Como resultado, não pode limpar o elemento e voltar a executar o pipeline no mesmo. Em alternativa, pode ter de aplicar uma lógica diferente para correlacionar a saída na fila de mensagens rejeitadas com o elemento original ou pode ter de interpretar e processar o elemento parcialmente transformado. Também pode resultar em resultados inconsistentes. Por exemplo, se os elementos forem enviados por dois ramos de um pipeline e cada ramo enviar elementos que causam exceções para uma fila de mensagens rejeitadas, um único elemento de entrada pode chegar a um, ao outro, a ambos ou a nenhum dos ramos.
Exceda o tempo limite de registos dispendiosos
Os pipelines podem deixar de responder enquanto processam um pequeno subconjunto de elementos que são mais caros ou que atingem uma limitação que causa falta de resposta, como um bloqueio. Para mitigar este problema, algumas transformações permitem definir um limite de tempo e falhar
os elementos com limite de tempo em quaisquer DoFns de código do utilizador que encontrem este problema. Por exemplo, pode usar o método with_exception_handling do Python. Quando usa limites de tempo com uma fila de mensagens rejeitadas, o pipeline pode continuar a processar elementos válidos e progredir, e pode voltar a processar os elementos dispendiosos separadamente. Esta configuração pode incorrer num custo de desempenho.
Para determinar que operações têm probabilidade de exigir um limite de tempo, execute pequenas experiências antes de lançar o pipeline completo.DoFn
Ative o ajuste de escala automático vertical
Se não tiver a certeza da quantidade de memória de que o seu trabalho precisa ou achar que o seu trabalho corre o risco de ficar sem memória, ative o ajuste de escala automático vertical. Esta funcionalidade ajuda a evitar falhas de OOM quando os pipelines são executados em maior escala ou quando encontram elementos excecionalmente grandes.
Uma vez que o ajuste de escala automático vertical pode aumentar o custo da sua tarefa e não impede todas as falhas de falta de memória, continua a ter de resolver os problemas de consumo excessivo de memória. A escala automática vertical também requer o Dataflow Prime, que tem limitações adicionais e um modelo de faturação diferente.
Use a execução especulativa para evitar atrasos
Para pipelines em lote, pode ativar a execução especulativa, uma funcionalidade para mitigar o impacto de tarefas lentas ou bloqueadas. Estas tarefas lentas ou bloqueadas também são conhecidas como tarefas pendentes. Esta funcionalidade inicia execuções redundantes ou de cópia de segurança de tarefas que estão a demorar demasiado tempo. A primeira tarefa a terminar é usada e a outra é cancelada, o que pode melhorar o tempo de conclusão geral do seu pipeline.
A execução especulativa pode ajudar os pipelines a serem concluídos mais rapidamente, fornecendo um caminho de execução alternativo para itens de trabalho que estão a sofrer atrasos devido a máquinas de trabalho lentas ou outros problemas transitórios, como erros não determinísticos, limitação de recursos ou problemas de conetividade.
Limitações e considerações
Antes de ativar a execução especulativa, considere o seguinte:
- Pipelines de streaming: a execução especulativa não é suportada para pipelines de streaming.
- Potencial alteração no custo: é difícil estimar o impacto no custo desta funcionalidade porque é difícil prever os atrasos e o aprovisionamento de tarefas de cópia de segurança. Por exemplo, embora um item de trabalho de cópia de segurança consuma recursos adicionais, o que pode aumentar o custo, a sua conclusão mais cedo pode, por outro lado, gerar poupanças de recursos e redução de custos. Em qualquer dos cenários, prevê-se que o impacto geral seja mínimo.
- Itens de trabalho de execução prolongada consistentes: a execução especulativa pode não ajudar significativamente com itens de trabalho de execução prolongada consistentes, como teclas de atalho, uma vez que o problema subjacente que causa a lentidão persistiria.
Para mais informações sobre os atrasos em trabalhos em lote, consulte o artigo Resolva problemas de atrasos em trabalhos em lote.
Ative a execução especulativa
Para ativar a execução especulativa, use a opção de serviço map_task_backup_modeDataflow. Estão disponíveis dois modos:
Java
--dataflowServiceOptions=map_task_backup_mode=ON--dataflowServiceOptions=map_task_backup_mode=CAUTIOUS
Python / Go
--dataflow_service_options=map_task_backup_mode=ON--dataflow_service_options=map_task_backup_mode=CAUTIOUS
No modo ON, é agendada uma tarefa de cópia de segurança se o tempo de execução esperado da tarefa original for cerca de 20% superior ao tempo de execução esperado de uma nova tarefa.
No modo CAUTIOUS, é agendada uma tarefa de cópia de segurança se o tempo de execução esperado da tarefa original for cerca de 70% superior ao tempo de execução esperado de uma nova tarefa.
Para confirmar se a execução especulativa está ativada, verifique as mensagens de registo. Procure entradas que mostrem que as tarefas de cópia de segurança foram iniciadas. Isto confirma que a execução especulativa é acionada. Para ver estes registos, aceda ao painel Registos de tarefas da sua pipeline (Tarefas > escolha a sua tarefa > secção Registos > Registos de tarefas). A mensagem de registo é apresentada da seguinte forma:
Backup issued in step STEP_NAME. ADDITIONAL_INFORMATION.
Soluções alternativas para pipelines propensos a falhas
Alguns pipelines são particularmente propensos a erros. Embora seja melhor resolver a origem destes erros, para reduzir o custo das falhas, considere as seguintes opções.
Materialize resultados intermédios
Os pipelines podem ter uma ou mais transformações particularmente caras que dominam o tempo de execução do pipeline. As falhas do pipeline após esta transformação podem ser
particularmente prejudiciais, porque todo o trabalho já concluído é perdido. Para evitar este cenário, considere escrever os PCollections intermédios gerados por passos dispendiosos num destino, como o Cloud Storage. Esta configuração reduz
o custo de uma falha. Tem de ponderar esta vantagem em relação ao custo de realizar a gravação adicional. Pode usar este resultado materializado de uma das
seguintes formas:
- Divida o pipeline original em dois pipelines: um que escreve o resultado intermédio e outro que o lê.
- Apenas em caso de falha do pipeline, leia e reduza os resultados da sua origem original e da sua coleção intermédia materializada.
Para garantir que estas materializações são escritas antes do processamento adicional, adicione um passo de espera (consulte o wait
class) antes de quaisquer passos de processamento subsequentes.