10. Erros de notebooks e sessões Spark

Um erro no notebook nem sempre nasce no código da célula. O trabalho pode falhar ao obter uma sessão, preparar bibliotecas, validar parâmetros ou processar dados distribuídos. Separar essas fases evita corrigir uma consulta que ainda nem começou a executar.

Sessão, admissão e preparação

Confirme se a sessão foi criada e se o código chegou a iniciar. Espera de capacidade, preparação de ambiente e conectividade podem consumir o timeout antes do primeiro job. Use os detalhes de início e de sessão para localizar essa etapa.

High concurrency depende de condições de compatibilidade, não apenas de os notebooks estarem no mesmo workspace. Identidade, ambiente e configuração participam do compartilhamento conforme o recurso. Uma sessão isolada pode ser esperada quando essas condições diferem; não trate toda ausência de compartilhamento como defeito.

O timeout pode terminar enquanto o trabalho espera a sessão, antes de qualquer processamento de dados. Nesse caso, alterar a lógica de join ou a quantidade de partições não atua sobre a fase que falhou. Procure eventos de admissão e inicialização. Se o código começou, desça para jobs e tarefas. Essa decisão inicial reduz drasticamente a área de investigação e evita mudanças especulativas em uma transformação que pode estar correta.

Ambiente e dependências efetivas

ModuleNotFoundError ou incompatibilidade de versão exige examinar o ambiente realmente carregado. Uma biblioteca instalada manualmente em outra sessão não prova disponibilidade na execução automatizada. Confira Environment associado, versão publicada e logs de preparação.

Perfis de recurso e configuração de sessão devem respeitar o consumidor e a capacidade. Trocar o tamanho do pool não instala uma dependência ausente. Da mesma forma, publicar bibliotecas não corrige uma negativa de autorização para acessar os dados. Cada sinal aponta para um contrato diferente.