UAM был введен в https://issues.apache.org/jira/browse/YARN-420. Первоначальная цель была
Было бы полезным улучшить эту модель, позволив
AM запускается клиентом самостоятельно без необходимости
RM. Эти AM будут запущены на компьютере шлюза, который может общаться с
кластер. Это откроет новые варианты использования, такие как
1) Простая отладка AM, особенно во время начальной разработки. Имея
АМ запускается на произвольном узле кластера, поэтому на него трудно смотреть
логи или прикрепить отладчик к АМ. Если он может быть запущен локально
тогда эти задачи будут проще.
2) Запуск AM, которые нуждаются в специальных
привилегии, которые могут быть недоступны на машинах, управляемых
NodeManager
Теперь UAM также играет важную роль в разработке федерации пряжи. По тому, как вы цитировали.
AMRMProxy может выдавать себя за AM в других подкластерах, отправляя
неуправляемый AM, и перенаправляя сердцебиение AM к соответствующим
поднаправления.
Идея проста. В федерации только один «настоящий» AM создается после подачи заявки (в домашнем подкластере). Однако для того, чтобы распределить контейнеры задач в других (вторичных) подкластерах, приложению необходимы AM в вторичных подкластерах, чтобы общаться с их RM. Федерация пряжи решает эту проблему, регистрируя UAM в подкластере, задачей которого является только пересылка пульса allocate
.
Вы можете взглянуть на код
FederationInterceptor
sendRequestsToResourceManagers()
UnmanagedAMPoolManager
UnmanagedApplicationManager