MRv2 / YARN Особенности
Я пытаюсь понять, какова цель нового API, и, читая через Интернет, я нашел разные ответы на те же вопросы, с которыми я имел дело.
Вопросы, на которые я хотел бы знать ответы:
1) Какой из демонов MRv2/YARN отвечает за запуск контейнеров приложений и мониторинг использования ресурсов приложений.
2) Какие две проблемы MRv2/YARN предназначены для решения?
Я постараюсь сделать эту ветку образовательной и конструктивной для других читателей, указав ресурсы и фактические данные из моих поисков, поэтому я надеюсь, что я бы не предоставил слишком много информации, в то время как я мог бы просто задать вопросы и сделать свой пост короче.
Для 1-го вопроса, читая в документации, я мог найти 3 основных ресурса, на которые можно положиться:
Из документации Hadoop:
ApplicationMaster<->NodeManager Запустить контейнеры. Связь с NodeManager с помощью объектов NMClientAsync, обработка событий контейнера с помощью NMClientAsync. CallbackHandler
ApplicationMaster связывается с кластером YARN и управляет выполнением приложения. Он выполняет операции в асинхронном режиме. Во время запуска приложения основными задачами ApplicationMaster являются:
а) связь с ResourceManager для согласования и выделения ресурсов для будущих контейнеров, и
б) после размещения контейнеров, общение с YARN NodeManager (NM) для запуска контейнеров приложений на них.
Из документации Hortonworks
ApplicationMaster, по сути, является экземпляром библиотеки, специфичной для фреймворка, и отвечает за согласование ресурсов с ResourceManager и работу с NodeManager для выполнения и мониторинга контейнеров и их потребления ресурсов. Он отвечает за согласование соответствующих контейнеров ресурсов с ResourceManager, отслеживание их состояния и мониторинг прогресса.
Из документации Cloudera:
Демоны MRv2 -
ResourceManager - по одному на кластер - запускает ApplicationMasters, распределяет ресурсы на подчиненных узлах
ApplicationMaster - по одному на задание - запрашивает ресурсы, управляет отдельными задачами Map и Reduce
NodeManager - один на подчиненный узел - управляет ресурсами на отдельных подчиненных узлах
JobHistory - по одному на кластер - архивирует метрики и метаданные вакансий
Возвращаясь к вопросу (какие демоны отвечают за запуск контейнеров приложений и мониторинг использования ресурсов приложений), я задаю себе вопрос:
Это NodeManager? Это ApplicationMaster?
Из того, что я понимаю, ApplicationMaster - это тот, кто заставляет NodeManager фактически выполнять свою работу, так что это все равно, что спрашивать, кто отвечает за поднятие коробки с земли, это были те руки, которые действительно поднимали ум, кто контролирует тело и заставляет их делать подъем...
Думаю, это сложный вопрос, но на него должен быть только один ответ.
На второй вопрос, читая онлайн, я мог найти разные ответы на многих ресурсах и, таким образом, путаницу, но мои основные источники:
Из документации Cloudera:
MapReduce v2 ("MRv2") - построен на вершине YARN (еще один другой ресурс NegoGator)
- использует архитектуру ResourceManager/NodeManager
- Увеличивает масштабируемость кластера
- Ресурсы узла могут быть использованы для любого типа задачи
- Улучшает использование кластера
- Поддержка не /MR рабочих мест
Возвращаясь к вопросу (Какие две проблемы MRv2/YARN предназначены для решения?), Я знаю, что MRv2 внес несколько изменений, таких как предотвращение нехватки ресурсов на JobTracker (в MRv1 максимальное количество узлов в кластере может быть около 4000, а в MRv2 более чем в 2 раза превышает это число), и я также знаю, что он обеспечивает возможность запуска платформ, отличных от MapReduce, таких как MPI.
Из документации:
Application Master обеспечивает большую часть функциональных возможностей традиционного ResourceManager, так что вся система может масштабироваться более резко. В тестах мы уже успешно смоделировали 10 000 узловых кластеров, состоящих из современного оборудования, без существенных проблем.
а также:
Перемещение всего кода, специфичного для фреймворка приложения, в ApplicationMaster обобщает систему, так что теперь мы можем поддерживать несколько фреймворков, таких как MapReduce, MPI и Graph Processing.
Но я также думаю, что это связано с тем фактом, что NameNode был единственной точкой отказа, а в новой версии есть Standby NameNode в режиме высокой доступности (я мог бы путать функции старого и нового API с функциями MRv1 против MRv2, и это может быть причиной моего вопроса):
До Hadoop 2.0.0 NameNode был единственной точкой отказа (SPOF) в кластере HDFS. У каждого кластера был один NameNode, и если этот компьютер или процесс стал недоступен, кластер в целом был бы недоступен до тех пор, пока NameNode не будет перезапущен или запущен на отдельной машине.
Так что, если вам нужно будет выбрать 2 из 3, какие из них будут 2, которые служат двумя проблемами, на которые рассчитана MRv2/YARN?
-Ресурсное давление на JobTracker
-Возможность запуска каркасов, отличных от MapReduce, таких как MPI.
-Один точка отказа в NameNode.
Заранее спасибо! D
3 ответа
Какой из демонов MRv2/YARN отвечает за запуск контейнеров приложений и мониторинг использования ресурсов приложений.
ResourceManager (RM) отвечает за запуск ApplicationMaster(AM) для конкретной работы один раз, AM отвечает за AM за согласование, распределение и мониторинг ресурсов задания (контейнеров).
Я рекомендую вам прочитать раздел Анатомия задания MapReduce из Руководства по определению Hadoop, глава 6, для более подробного объяснения того, как ресурсы задания распределяются как в MR1, так и в MR2.
Какие две проблемы MRv2/YARN предназначен для решения?
YARN пытается отделить функциональность JobTracker в MR1(что было узким местом для масштабирования) с собственными абстракциями:
- Управление ресурсами кластера - менеджер ресурсов
- Управление жизненным циклом приложения - Application Master для конкретного приложения / работы
Так что, если вам нужно будет выбрать 2 из 3, какие из них будут 2, которые служат двумя проблемами, для решения которых предназначена MRv2/YARN?
-Ресурсное давление на JobTracker
-Возможность запуска каркасов, отличных от MapReduce, таких как MPI.
-Один точка отказа в NameNode.
Из ваших 2 из 3 ответов я бы выбрал 1 и 2.
Согласно cloudera http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cdh_ig_mapreduce_to_yarn_migrate.html
TaskTracker был заменен NodeManager, службой YARN, которая управляет ресурсами и развертыванием на хосте. Он отвечает за запуск контейнеров, каждый из которых может содержать карту или уменьшить задачу.
Так что это NodeManager, который запускает контейнеры для задачи mapred.
Контейнер ApplicationMaster запускается ResourceManager, хотя.
Просто для пояснения вышесказанного "Контейнер ApplicationMaster запускается ResourceManager, хотя" означает - ResourceManager инструктирует NodeManager запустить главный контейнер приложения. Фактический запуск Application Master Container также выполняется NodeManager.