18. Otimização e memória do Spark

Uma transformação distribuída pode ficar lenta por shuffle, partições desiguais, excesso de objetos ou recomputação. Aumentar executores é apenas uma das possíveis intervenções. A escolha depende de como o plano usa CPU, memória, rede e disco.

Plano e funções integradas

Spark avalia muitas transformações de forma preguiçosa. Medir apenas a criação do DataFrame mede a construção do plano, não o processamento completo. Compare uma ação que produza ou consuma o resultado real, usando entradas equivalentes e conferindo a saída.

Funções integradas permitem otimizações que UDFs podem dificultar e evitam certos custos de comunicação e representação. Substitua uma UDF quando houver operação equivalente, testando nulos, tipos e casos de fronteira. Um caminho nativo pode fazer fallback para operações ou tipos não suportados; examine o plano antes de atribuir isso à capacidade.

Uma UDF pode introduzir custos de serialização e execução fora de caminhos mais otimizáveis. Quando existe função integrada equivalente, a substituição merece teste. A equivalência inclui comportamento com None, tipos e valores extremos, não apenas o caso comum. Caminhos nativos também possuem suporte específico; um fallback pode resultar de operador ou tipo incompatível. O plano ajuda a localizar o trecho. Aumentar executores sem essa análise pode ampliar recursos mantendo o mesmo custo estrutural.

Partições, shuffle e joins

Shuffle redistribui dados entre executores e pode ser caro em rede, memória e disco. Escolha chaves e particionamento conforme operações e distribuição. Partições excessivas aumentam overhead; poucas partições grandes limitam paralelismo e elevam pressão de memória.

Broadcast join pode evitar redistribuir uma tabela grande quando o outro lado é realmente pequeno e adequado à memória disponível. Não force broadcast de um conjunto grande apenas por existir a opção. Adaptive Query Execution pode ajustar estratégias e tratar situações em execução, mas não elimina a necessidade de modelar corretamente as chaves e a cardinalidade.

Skew concentra trabalho em poucas partições. Observe tarefas e distribuição antes de alterar a quantidade global. Reparticionar sem mudar a causa pode conservar a concentração. Estratégias específicas devem preservar a semântica, especialmente quando envolvem decompor chaves ou recombinar agregados.