Execução especulativa no Spark: rede de segurança ou multiplicador de custo escondido?

Com a especulação ativada, o Spark observa tarefas rodando significativamente mais lento que a mediana do seu stage e lança uma tentativa duplicada em outro lugar, ficando com a que terminar primeiro.

O caso em que funciona exatamente como deveria

Uma única tarefa travada em 10x a duração mediana enquanto todas as outras tarefas do stage terminam normalmente é o caso de livro-texto: um nó instável, um vizinho barulhento numa infraestrutura compartilhada, um soluço transitório de disco ou rede. A especulação lança uma duplicata, a duplicata termina num nó saudável, e o job se recupera sem ninguém ser alertado - exatamente a rede de segurança que ela foi feita para ser.

O caso em que piora as coisas

O skew de dados produz o mesmo sintoma superficial - uma tarefa muito mais lenta que as demais - por um motivo completamente diferente: essa tarefa simplesmente tem mais dados para processar. A especulação lança uma duplicata de uma tarefa que nunca ia terminar rápido não importa qual nó a executasse, então você paga por duas tentativas lentas em vez de uma, sem nenhuma melhora no tempo real de conclusão. A tarefa com skew termina por último de qualquer jeito.

Como distinguir os dois antes de ativar o interruptor

Verifique o tamanho de entrada de dados, não só a duração, da tarefa lenta em comparação com suas pares no mesmo stage. Um tamanho de entrada aproximadamente igual com uma tarefa muito mais lenta aponta para um problema de infraestrutura no qual a especulação realmente ajuda. Uma tarefa lenta com visivelmente mais dados de entrada (dos "Input Metrics" ou dos bytes de shuffle read no event log) é skew - o ajuste ali é reparticionar ou fazer «salting» na chave do join, não especulação, que só dobra o custo de uma tarefa que sempre ia ser a mais demorada.