07. Spark — configuração, ambientes e execução

O mesmo notebook pode funcionar em uma sessão e falhar na execução seguinte se depender de uma biblioteca instalada apenas temporariamente. Configurar Spark significa controlar tanto os recursos de computação quanto a pilha de software, para que o processamento seja reproduzível e caiba na capacidade disponível.

Pool, driver e executores

Spark distribui processamento em tarefas executadas sobre partições. O driver coordena a aplicação e os executores realizam o trabalho distribuído. Um pool define recursos disponíveis; o tamanho dos nós influencia memória e processamento. Autoscale ajusta a quantidade de nós dentro de limites, enquanto alocação dinâmica trata executores. Esses controles não alteram a versão das bibliotecas nem corrigem um algoritmo inadequado.

A escolha depende do perfil da carga. Tarefas que exigem mais memória por unidade podem precisar de outro tamanho; trabalho paralelizável pode aproveitar mais recursos simultâneos. Configurações de nó único são possíveis em cenários suportados, com driver e executor no mesmo nó. O importante é respeitar requisitos do processamento, e não decorar uma separação física obrigatória.

Um pool com nós maiores pode oferecer mais memória por unidade, enquanto mais nós ampliam a capacidade distribuída. As escolhas não são equivalentes para uma tarefa que concentra dados no driver ou para um algoritmo que mantém uma partição muito grande. Antes de dimensionar, identifique onde o trabalho acontece e quais partes podem ser distribuídas. A alocação dinâmica ajusta executores conforme as condições, mas não transforma uma operação serial em paralela nem remove limites de capacidade. O código e a política de recursos precisam ser avaliados como partes do mesmo processamento.

Environment e dependências

Um Environment reúne configurações de runtime, computação e bibliotecas para os itens que o utilizam. Salvar alterações prepara o estado; publicar valida e disponibiliza uma versão para uso. Um pacote incompatível pode impedir a publicação. O estado publicado, e não apenas o arquivo recém-editado, deve ser usado como referência de execução.

Fixar versões e testar os consumidores reduz diferenças entre sessões. Colocar uma versão nova em um feed de pacotes não implica adotá-la automaticamente em todos os ambientes: a atualização precisa seguir o fluxo de publicação aplicável. Logs de preparação das bibliotecas ajudam a separar uma falha de instalação de uma falha no código de transformação.

Para reproduzir uma execução, registre a versão do Environment publicado e não apenas a lista desejada de pacotes. Um pacote pode ter sido editado no rascunho e ainda não estar disponível aos consumidores. Quando a publicação falha, examine preparação, resolução de dependências e compatibilidade de runtime. Uma instalação temporária pode mascarar essa falha durante o desenvolvimento. O teste decisivo inicia uma sessão nova com o ambiente associado e executa o caminho automatizado, sem depender de bibliotecas ou variáveis deixadas por interações anteriores.