Hadoop YARN — gestão de recursos em clusters BigData

YARN (Yet Another Resource Negotiator) é a camada de gestão de recursos do ecossistema Hadoop moderno. Substituiu o JobTracker/TaskTracker do Hadoop 1.x e tornou possível correr não apenas MapReduce, mas também Spark, Tez, e outras frameworks sobre o mesmo cluster de forma eficiente. Entender o YARN é fundamental para quem gere ou usa clusters BigData on-premise.

Arquitectura fundamental

O YARN divide a gestão de recursos em dois componentes distintos:

• ResourceManager: o daemon central (activo + standby para HA) que conhece todos os recursos disponíveis no cluster e decide como alocá-los
• NodeManager: corre em cada nó do cluster, reporta recursos disponíveis ao ResourceManager e executa os containers alocados

Quando uma aplicação (Spark job, Hive query) é submetida, o YARN cria um ApplicationMaster — um processo da própria aplicação que negoceia containers com o ResourceManager e coordena a execução distribuída.

Schedulers — a escolha mais importante

O scheduler do YARN determina como os recursos são partilhados entre jobs concorrentes. Há três opções:

• FIFO Scheduler: simples, não recomendado para produção. Um job grande bloqueia todos os outros.
• Capacity Scheduler: divide o cluster em queues com capacidade garantida. Cada queue tem um percentagem mínima de recursos garantida, e pode usar recursos não utilizados de outras queues. É o scheduler padrão e o mais comum em produção.
• Fair Scheduler: distribui recursos equitativamente entre todos os jobs activos. Bom para clusters partilhados onde todos os jobs têm igual prioridade.

Configuração do Capacity Scheduler para multi-tenant

Num cluster partilhado entre equipas (Data Engineering, Analytics, ML), configuro tipicamente queues por equipa com capacidades mínimas garantidas e máximos que permitem burst:

yarn.scheduler.capacity.root.queues=engineering,analytics,ml
yarn.scheduler.capacity.root.engineering.capacity=40
yarn.scheduler.capacity.root.analytics.capacity=30
yarn.scheduler.capacity.root.ml.capacity=30
yarn.scheduler.capacity.root.engineering.maximum-capacity=70

Com esta configuração, a equipa de Engineering tem 40% garantido mas pode usar até 70% quando as outras queues estão ociosas.

Monitorização e tuning

Os problemas mais comuns em produção são: jobs que ficam pending por falta de memória (containers demasiado grandes), YARN não recobrando recursos de jobs pendurados, e desequilíbrio entre nós. O YARN Web UI (porta 8088 por defeito) é o ponto de partida para diagnóstico — mostra recursos disponíveis, jobs activos, e histórico.

Para produção, configura sempre: memory overcommit controlado, preemption no Capacity Scheduler (permite ao YARN retomar recursos de jobs de baixa prioridade para jobs urgentes), e alertas sobre utilização de queues.