Second Brain

YARN como Cluster Manager do Spark

Created Updated 3 min read

YARN (Yet Another Resource Negotiator) é o gerenciador de recursos do ecossistema Hadoop. Quando o Spark roda em YARN, ele delega toda a alocação de CPU e memória para o YARN e só se preocupa com a lógica da aplicação.

Três componentes

ResourceManager roda em um único nó e é o árbitro central do cluster. Ele recebe os pedidos de recursos das aplicações e decide quem recebe o quê, com base na capacidade disponível e na política de fila configurada.

NodeManager roda em cada nó worker. Ele executa os containers alocados pelo ResourceManager, monitora o uso de CPU e memória de cada container e reporta o estado de volta ao ResourceManager.

ApplicationMaster é instanciado uma vez por aplicação. No Spark, o driver assume esse papel: ele negocia com o ResourceManager para obter containers para os Executors e os libera quando a aplicação termina.

flowchart TD
    RM["ResourceManager\n(nó master)"]

    subgraph NM1["Worker Node 1"]
        NM1P["NodeManager"]
        C1["Container\nExecutor 1"]
    end

    subgraph NM2["Worker Node 2"]
        NM2P["NodeManager"]
        C2["Container\nExecutor 2"]
    end

    AM["ApplicationMaster\n(Driver do Spark)"]

    AM -->|"pede containers"| RM
    RM -->|"aloca"| NM1P & NM2P
    NM1P --> C1
    NM2P --> C2
    C1 & C2 -->|"reporta progresso"| AM
    NM1P & NM2P -->|"heartbeat"| RM

Modos de deploy

Modo client: o Driver (e portanto o ApplicationMaster) roda na máquina que submete o job. Útil para desenvolvimento porque os logs aparecem diretamente no terminal. O problema é que a aplicação inteira fica dependente da conectividade dessa máquina.

spark-submit \
  --master yarn \
  --deploy-mode client \
  meu_job.py

Modo cluster: o Driver roda dentro de um container no cluster. É o padrão para produção porque o job sobrevive mesmo que a máquina cliente se desconecte.

spark-submit \
  --master yarn \
  --deploy-mode cluster \
  --executor-memory 4g \
  --executor-cores 2 \
  --num-executors 10 \
  meu_job.py

Filas e isolamento

O YARN organiza recursos em filas hierárquicas. Em ambientes multiusuário, cada time ou pipeline vai para uma fila com limites de CPU e memória configurados pelo administrador do cluster. Um job não pode consumir recursos além do que a fila permite, mesmo que o cluster tenha capacidade ociosa em outras filas (a menos que preemption esteja habilitado).

Exemplo: uma fila engenharia com 40% dos recursos do cluster garante que jobs de engenharia de dados nunca prejudiquem pipelines críticos que rodam na fila producao.

Quando usar YARN hoje

YARN faz sentido quando o cluster já roda Hadoop e há outros serviços do ecossistema (Hive, HBase, Impala) compartilhando os mesmos nós. Em ambientes cloud-native sem Hadoop, Kubernetes é a escolha mais comum. Ver spark-arquitetura para a comparação com os outros Cluster Managers.

Conexões

  • spark-arquitetura: visão geral do Driver, Executor e Cluster Manager no Spark
  • spark-mesos: alternativa ao YARN com modelo de agendamento diferente
  • spark-performance: configurações de memória e executor que interagem com o YARN

Referências

Graph View

Backlinks