YARN и MapReduce Framework
Я знаком с основами YARN-фреймворка, но все еще чувствую недостаток понимания в отношении MapReduce.
С YARN я прочитал, что MapReduce - это только одно из приложений, которые могут работать поверх YARN; например, в YARN на одном и том же кластере могут выполняться различные задания, задания MapReduce, задания Spark и т. д.
Дело в том, что каждый тип задания имеет свой "вид" "фаз работы", например, когда мы говорим о MapReduce, он имеет различные фазы, такие как Mapper, Sorting, Shuffle, Reducer и т. Д.
Специфично для этого сценария, кто "решает", "контролирует" эти фазы? Это MapReduce Framework?
Как я понимаю, YARN - это инфраструктура, на которой работают разные рабочие места; поэтому, когда мы отправляем задание MapReduce, оно сначала переходит в инфраструктуру MapReduce, а затем код выполняется YARN? У меня есть это сомнение, потому что YARN - это механизм выполнения общего назначения, поэтому он не будет обладать знанием мапперов, редукторов и т. Д., Специфичных для MapReduce (и других видов заданий), поэтому MapReduce Framework работает поверх YARN, с помощью YARN при выполнении заданий, и MapReduce Framework знает, какие этапы он должен пройти для выполнения определенного вида заданий?
Любое разъяснение, чтобы понять это, было бы очень полезно.
2 ответа
Если вы посмотрите на это изображение из документации Hadoop:
Вы увидите, что нет конкретного компонента "согласования заданий", но есть компонент, запрашивающий ресурсы, который называется "мастер приложения". Как вы упомянули, YARN осуществляет управление ресурсами, а в отношении оркестровки приложений - останавливается на абстрактном уровне.
ApplicationMaster для каждого приложения, по сути, является библиотекой, специфичной для платформы, и ему поручено согласование ресурсов из ResourceManager и работа с NodeManager для выполнения и мониторинга задач.
При применении к Spark некоторые компоненты на этом рисунке будут:
- Клиент: процесс spark-submit
- App Master: мастер приложений Spark, который выполняет драйвер и мастер приложений (режим кластера) или просто мастер приложений (режим клиента)
- Контейнер: искровые рабочие
Инфраструктура Spark YARN предоставляет мастер приложений (в терминах YARN), который знает об архитектуре Spark. Поэтому, когда драйвер работает, либо в режиме кластера, либо в режиме клиента, он по-прежнему принимает решение о заданиях / этапах / задачах. Это должно зависеть от приложения / фреймворка (Spark является "фреймворком", когда дело доходит до YARN).
Из документации Spark по развертыванию YARN:
В режиме кластера драйвер Spark запускается в главном процессе приложения, которым управляет YARN в кластере, и клиент может уйти после запуска приложения. В режиме клиента драйвер запускается в клиентском процессе, а мастер приложения используется только для запроса ресурсов из YARN
Вы можете расширить эту абстракцию, чтобы уменьшить карту, учитывая ваше понимание этой структуры.
Поэтому, когда мы отправляем задание MapReduce, оно сначала отправляется в Resource Manager, который является главным демоном YARN. Диспетчер ресурсов затем выбирает диспетчер узлов (которые являются подчиненными процессами YARN) для запуска контейнера, в котором он будет запрашивать диспетчер узлов для запуска очень легкого процесса, известного как Application Master. Затем менеджер ресурсов попросит мастера приложений запустить выполнение задания. Мастер приложений сначала пройдет через часть драйвера задания, откуда он узнает о ресурсах, которые будут использоваться для задания, и, соответственно, запросит диспетчер ресурсов для этих ресурсов. Теперь диспетчер ресурсов может назначить ресурсы мастеру приложений немедленно или, если кластер занят, тогда этот запрос будет перепланирован на основе различных алгоритмов планирования. После получения ресурсов мастер приложения перейдет к узлу имени, чтобы получить метаданные всех блоков, которые должны быть обработаны для этой работы. После получения метаданных мастер приложения запрашивает менеджеров узлов узлов, в которых хранятся блоки (если эти узлы слишком заняты, то узел в той же стойке, в противном случае любой случайный узел в зависимости от осведомленности о стойке) и просит менеджеров узлов: запускать контейнеры для обработки их соответствующих блоков. Блоки будут обрабатываться независимо и параллельно в своих соответствующих узлах. После завершения всей обработки результат будет сохранен в HDFS.