Como escolho o número certo de shuffle partitions, memória do executor e núcleos?

Todo guia te dá uma fórmula. Quase nenhum te diz como verificar se a fórmula realmente serviu para o seu job. As duas coisas importam.

Shuffle partitions: parta do tamanho alvo da partição, não de um número fixo

spark.sql.shuffle.partitions vem 200 por padrão, independente do tamanho dos dados, o que está errado para quase toda carga real — partições demais para um job pequeno (o overhead de agendar tasks domina), partições de menos para um grande (cada partição faz spill em disco). Um ponto de partida melhor: divida o tamanho total de entrada do seu stage de shuffle por um alvo de 128-200MB por partição.

Depois verifique: após a mudança, a duração das tasks dentro daquele stage ficou mais uniforme (menos tasks de cauda longa) e os bytes de spill em disco caíram? Se o spill continua alto, você ficou aquém; se a maioria das partições agora está quase vazia, você passou do ponto.

Memória do executor: dimensione pela maior partição esperada, não pela média

OOMs de executor quase sempre vêm da maior partição de um stage, não da média — então dimensionar memória pela partição média já subestima por construção. Um piso razoável é tamanho_da_maior_partição * 3-4 (margem para o overhead de deserialização e qualquer agregação em memória), limitado pelo que o tipo de instância do seu cluster realmente consegue oferecer por executor.

Número de núcleos: mais não é de graça depois de certo ponto

Os núcleos do executor controlam quantas tasks rodam simultaneamente dentro do orçamento de memória de um único executor — levar isso longe demais faz com que essas tasks disputem o mesmo heap, o que aparece como mais tempo de GC, não mais throughput. 4-5 núcleos por executor é um teto razoável para a maioria das cargas pesadas em JVM; passar disso geralmente troca pressão de GC por um paralelismo que você não ganha de fato.