Como faço deploy de um cluster Spark - Kubernetes, YARN, ou EMR - e o que muda de verdade?

O motor de execução real do Spark é idêntico não importa o que agende seus executors. A escolha de cluster manager é na verdade uma escolha sobre quem é dono do provisionamento, escalonamento e recuperação de falhas - o Spark, ou você.

O que cada opção realmente assume

O YARN é o resource manager original do Hadoop - maduro, bem entendido por quem já operou um cluster Hadoop antes, mas é um sistema separado que você provisiona, aplica patches e monitora sozinho, totalmente à parte do Spark. O Kubernetes roda os executors do Spark como pods diretamente, o que significa que o Spark compartilha seu tooling de K8s existente (RBAC, monitoramento, autoescalonamento) em vez de precisar do próprio - genuinamente atraente se K8s já é como tudo mais na sua organização é implantado, genuinamente trabalho extra se não for. As opções gerenciadas (EMR, Databricks, Dataproc) assumem a camada de cluster manager inteira - você recebe uma API de provisionamento de cluster e uma fatura, não um sistema para aplicar patches.

Onde as diferenças operacionais reais aparecem

Não no job do Spark em si - no que quebra e quem é acionado quando quebra. As filas do capacity scheduler e a saúde dos nós de um cluster YARN são problema do seu time para ajustar e monitorar; no Kubernetes, isso vira requests/limits de recursos de pods e qualquer autoscaler que você tenha configurado, que seu time de plataforma pode já possuir para tudo mais. EMR/Databricks gerenciado move falhas de nós, patches de AMI/imagem, e política de escalonamento para trás de um contrato de suporte - valor real, ao custo de perder algum acesso a ajustes de baixo nível que clusters auto-gerenciados dão (parâmetros de kernel customizados, configurações de instância não padrão).

A decisão cara de reverter

Trocar de cluster manager depois não é uma mudança de config - é reprovisionar infraestrutura, retestar limites de IAM/rede, e geralmente um período de execução em paralelo para construir confiança antes de cortar para o novo. O código do job do Spark em si quase não muda (principalmente só --master e configurações de recursos específicas do cluster manager), o que tenta a tratar a escolha do cluster manager como reversível - o que não é reversível é o tooling operacional ao redor e o conhecimento do time.