Spark
Nível médioComo faço deploy de um job do Spark - client mode ou cluster mode?
O spark-submit tem exatamente uma flag que decide onde o driver roda - e errar nela não falha alto, só faz a sobrevivência do seu job depender de algo de que não deveria.
Todo deploy do Spark roda um processo driver e algum número de executors - client mode e cluster mode só discordam sobre onde o driver vive. Essa única diferença tem consequências maiores do que parece.
O que --deploy-mode realmente move
No client mode, o driver roda na máquina que emitiu o spark-submit - seu laptop,
um servidor de notebook, um runner de CI - e só os executors rodam no cluster. No cluster mode, o
cluster manager (YARN, Kubernetes, standalone) inicia o driver como um processo próprio em um nó do
cluster, então a máquina que rodou spark-submit pode se desconectar completamente assim que
o job é aceito.
Por que client mode é o padrão errado para qualquer coisa sem supervisão
O driver coordena cada task e guarda o estado final do job - se ele morre, o job morre, não importa quão saudáveis estejam os executors. No client mode, isso significa que um laptop que hiberna, um kernel de notebook que reinicia, ou o timeout de job de um runner de CI matam um job do Spark que de outra forma estaria rodando bem. Não é um caso extremo teórico; é a forma mais comum como começa um chamado de "por que esse job simplesmente sumiu sem erro". Client mode é genuinamente a escolha certa para trabalho interativo - um notebook onde você quer ver a saída do driver em tempo real - só não para algo que precise sobreviver depois que você fechar o laptop.
O sinal: se a resposta para "esse job precisa continuar rodando se eu desconectar" é sim, a
resposta para --deploy-mode é cluster. Não existe uma configuração
intermediária.
O que muda operacionalmente depois que você troca
Cluster mode muda onde os logs do driver vivem - eles ficam em um nó do cluster, não no seu
terminal, então você os lê via yarn logs -applicationId ... ou kubectl logs em
vez de ver o stdout rolando. Também muda como você recupera o status de saída do job: client mode o retorna
diretamente para o shell que rodou spark-submit; cluster mode exige consultar o cluster
manager (yarn application -status, ou a Spark UI/history server), já que o processo que
submeteu encerra assim que o job é aceito, não quando termina. Nenhum dos dois é mais difícil, mas um
script de deploy escrito assumindo o comportamento síncrono do client mode vai reportar sucesso errado no
cluster mode se não for atualizado para consultar em vez disso.
Veja como isso fica no seu próprio pipeline.
Envie um event log real do Spark, um run_results.json do dbt ou uma exportação de métricas do Flink e receba recomendações concretas, para aprovar antes de aplicar - não mais uma regra geral.