Flink
Nível médioComo faço deploy de um job do Flink - session mode ou application mode?
O Flink dá duas formas genuinamente diferentes de rodar um job, e o trade-off está em exatamente uma dimensão: se um job problemático pode derrubar outros junto com ele.
Um cluster de sessão é um JobManager de longa duração que aceita múltiplos jobs, submetidos um de cada vez ou concorrentemente. Um cluster de aplicação sobe do zero para o main() de exatamente um job e é desmontado quando ele termina. Mesmo runtime do Flink por baixo, isolamento de falhas bem diferente.
O que cada modo realmente entrega
No session mode, você submete jars a um JobManager já rodando, que os agenda em quaisquer
TaskManagers registrados - rápido para iterar (sem startup de cluster por submissão), e um encaixe natural
para um ambiente compartilhado de dev/staging onde subir infraestrutura por job é desperdício. No
application mode, o próprio JobManager roda o main() do seu job - o cluster existe só
para esse job, do início ao encerramento, e nada mais pode ser agendado nele.
O trade-off de isolamento de falhas que realmente importa
O JobManager de um cluster de sessão é um recurso compartilhado: um job cujo main()
vaza memória, registra classes demais, ou de outra forma se comporta mal no nível do JobManager pode
degradar ou derrubar todo outro job naquela mesma sessão - não só o dele. Application mode dá a cada job
seu próprio JobManager, então o raio de impacto de um job com mau comportamento para nele mesmo. Isso quase
nunca é sobre performance bruta (a execução no nível de task é a mesma de qualquer forma) - é inteiramente
sobre se o deploy ruim de um time pode acionar o alerta de outro time.
O padrão prático: session mode para desenvolvimento interativo e jobs pontuais onde o overhead de um cluster por job não vale a pena; application mode para qualquer coisa rodando sem supervisão em produção, especificamente por causa do isolamento, não porque é mais rápido.
Onde isso ainda precisa de bom senso
O startup de cluster por job do application mode adiciona latência real antes que um job realmente comece a processar - tudo bem para um job de streaming de longa duração onde o tempo de startup é desprezível frente ao tempo total de execução, mais perceptível para jobs Flink tipo batch curtos rodados com frequência, onde o startup do cluster pode ser uma fração significativa do tempo total do job. Não há uma resposta universal aqui - depende de como o tempo de execução do job se compara ao próprio custo de startup, o que vale a pena realmente medir em vez de presumir.
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.