Yarn hadoop что это
Big Data
пятница, 5 февраля 2016 г.
Основной идеей YARN-a является разделение обязанностей менеджера ресурсов(resource management) кластера Hadoop, планировщика и системы мониторинга задач(job scheduling/monitoring) в отдельные службы(демоны).
ResourceManager распределяет ресурсы между всеми приложениями в системе.
ResourceManager имеет 2-а основных компонента: Scheduler (планировщик) и ApplicationsManager.
Планировщик(Scheduler) ответственный за выделение ресурсов, контроль и ограничение приложений, очередей и т.д. Планировщик не ответственный за мониторинг и трекинг статусов приложений. Также он не ответственный за рестарт упавших тасок из-за програмной или апаратной ошибки. Он выполняет свою роботу на основе требований к ресурсам от приложений. Он делает это опираясь на абстрактное понятие контейнер(Container), который включает в себя такие ресурсы как выделенная память, ЦПУ, диск, работа с сетью.
Планировщик имеет в себе настраиваемую политику, которая описывает распределение ресурсов вычислительного кластера среди приложений, очередей и т.д. Примерами таких подключаемых политик являются CapacityScheduler и e FairScheduler.
ApplicationsManager ответственнен за обслуживание выделенных ресурсов для job-a, переговоры с доступным контейнером, который выполнит приложение и позаботится о рестарте контейнера ApplicationsManager-а в случае сбоя.
ApplicationMaster для каждого приложения ответственнен за выделение ресурсов планировщиком для контейнера в котором будет выполнятся приложение. Также он затрекает статус и прогресс выполнения приложения.
Yarn hadoop что это
Продолжая обучение основам Apache Hadoop для начинающих администраторов, сегодня рассмотрим архитектуру и принципы работы YARN в кластере. Также разберем, какие отказы могут случиться на каждом из его компонентов и как Resource Manager системы YARN обеспечивает высокую доступность кластера Apache Hadoop.
Зачем Apache Hadoop нужен YARN и как он работает
Поскольку Hadoop работает в кластере, ему необходима система планирования заданий и управления распределенными приложениями. Эту роль выполняет один из 4-х основных модулей проекта, YARN – набор системных служб (демонов), которые обеспечивают совместное использование, масштабирование и надежность работы распределенных приложений. Таким образом, YARN является интерфейсом между аппаратными ресурсами кластера и распределенными приложениями, использующих его мощности для обработки и аналитики больших данных.
YARN разделяет функции управления ресурсами и планирования/мониторинга заданий на отдельные демоны, чтобы иметь глобальный диспетчер ресурсов (ResourceManager) и мастер приложения (ApplicationMaster) для каждого отдельного задания или их конвейера в виде направленного ациклического графа (DAG, Directed Acyclic Graph).
ResourceManager и диспетчер узлов (NodeManager) образуют структуру вычисления данных, где ResourceManager распределяет ресурсы между всеми приложениями в системе, а NodeManager является агентом инфраструктуры для каждой машины. Он отвечает за контейнеры, отслеживает использование ресурсов (ЦП, память, диск, сеть) и сообщает об этом планировщику (Scheduler) ResourceManager. Этот планировщик отвечает за распределение ресурсов между запущенными приложениями на основе требований приложений к ресурсам в виде контейнера, который включает память, процессор, диск, сеть и т. д., с учетом известных ограничений емкости, очередей и пр. Scheduler не отслеживает статус выполнения самих приложений и не дает гарантий перезапуска невыполненных задач из-за программного или аппаратного сбоя. ApplicationMaster для каждого приложения является специфической библиотекой платформы, которая согласовывает ресурсы с ResourceManager и работает с NodeManager для выполнения и мониторинга задач [1].
Таким образом, сбой в YARN может случиться из-за отказов на уровне мастера приложения, диспетчера ресурсов, диспетчера узлов и отдельных задач (Tasks) [2].
Отказы на уровне Application Master
ApplicationManager отвечает за прием отправок заданий, согласование первого контейнера для выполнения конкретного приложения ApplicationMaster и предоставляет службу для перезапуска его контейнера в случае сбоя. ApplicationMaster для каждого приложения отвечает за согласование с планировщиком соответствующих контейнеров ресурсов, отслеживание их статуса и мониторинг выполнения [2].
Если в Hadoop произойдет сбой мастера приложения, вся информация, связанная с выполнением этого конкретного задания, будет потеряна. По умолчанию максимальное количество попыток запуска ApplicationMaster равно 2: задание завершается ошибкой, если мастер приложения не сработал дважды. Управлять количеством повторных попыток запуска ApplicationMaster можно, задав значение свойства yarn.resourcemanager.am.max-plays.
Мастер приложения отправляет периодические heartbeat-сигналы в диспетчер ресурсов, который обнаружит сбой при отказе ApplicationMaster и запустит его новый экземпляр в новом контейнере, используя историю заданий для восстановления состояния, чтобы не запускать повторно уже запущенные задачи. Такое восстановление по умолчанию включено, но его можно отключить, установив для свойства yarn.app.mapreduce.am.job.recovery.enable значение false.
Клиент MapReduce опрашивает мастер приложения о ходе выполнения задания, поэтому при выходе мастера приложения из строя, клиенту необходимо найти новый экземпляр. Для этого во время инициализации задания клиент запрашивает у диспетчера ресурсов адрес мастера приложения, а затем кэширует его, чтобы не отправлять запросы каждый раз. Если мастер приложения выходит из строя, на клиенте возникает тайм-аут обновления статуса выполнения задания. Поэтому клиент снова отправит запрос диспетчеру ресурсов о новом адресе мастера приложения.
Что не так с менеджером узлов и при чем здесь мастер Hadoop-приложения
NodeManager будет отправлять контрольный сигнал (heartbeat) каждые 3 секунды диспетчеру ресурсов. Если диспетчер узлов выходит из строя из-за сбоя или работает очень медленно, ResourceManager будет ждать heartbeat-сигнала в течение 10 минут. Если он не будет получен, RM удалит узел из своего пула, чтобы запланировать контейнеры.
Если ApplicationMaster запущен в диспетчере отказавшего узла, то он будет перезапущен на другом узле, и это не будет засчитано в счетчике свойства yarn.resourcemanager.am.max-plays, т.к. было вызвано не ошибкой самого мастера приложения. На отказавших узлах даже завершенные задачи незавершенных полностью заданий, т.к. их промежуточный результат в локальной файловой системе отказавшего NodeManager, может быть недоступен для Reduce-шага задачи MapReduce.
NodeManager’ы могут быть занесены в черный список при большом количестве отказов приложения, даже если сам NodeManager не выходил из строя. Внесение в черный список выполняется мастером приложения, если на диспетчере узлов не удается выполнить более трех задач.
Менеджер ресурсов в YARN
До Hadoop 2.4 ResourceManager был единственной точкой отказа YARN в кластере Hadoop. Поэтому для обеспечения высокой доступности добавлена избыточность в виде пары Active/Standby диспетчеров ресурсов. В любой момент времени один ResourceManager находится в активном состоянии, а другие или находятся в режиме ожидания. Триггер перехода к активному состоянию поступает от администратора через CLI-интерфейс или через интегрированный контроллер аварийного переключения, если включено автоматическое переключение при сбое.
При включенном перезапуске ResourceManager, переведенный в активное состояние, загружает внутреннее состояние и продолжает работать с того места, где остановился предыдущий активный диспетчер ресурсов. Переход диспетчера ресурсов из режима ожидания в активный выполняется контроллером аварийного переключения. Контроллер аварийного переключения по умолчанию является автоматическим, который использует выборы лидера ZooKeeper, чтобы гарантировать активность только одного ResourceManager в один момент времени.
Информация обо всех запущенных приложениях хранится в высокодоступном хранилище состояний, так что резервный ResourceManager может восстановить состояние ядра отказавшего активного диспетчера ресурсов. Информация о менеджере узлов не сохраняется в хранилище состояний, поскольку она может быть относительно быстро восстановлена новым менеджером ресурсов, когда NodeManager отправят свои первые heartbeat-сигналы.
Существует две реализации хранилища состояний диспетчера ресурсов (RMStateStore) [2]:
Задать нужное хранилище состояний для ResourceManager можно в свойстве yarn.resourcemanager.store.class, которое может принимать следующие значения, определяющее имя соответствующего класса [3]:
Далее необходимо настроить свойства выбранного хранилища состояний согласно рекомендациям из официальной документации Apache Hadoop [3].
Сбой задачи в Apache Hadoop
Сбой задачи обычно происходит из-за исключений во время выполнения или из-за внезапного выхода из строя задачи JVM. Задача будет отправлять контрольный сигнал в мастер приложения каждые 3 секунды, но если он не получит обновлений в течение 10 минут, то будет считать задачу неудачной и повторит попытку ее выполнения.
Когда мастер приложения получает уведомление о неудачной попытке выполнения задачи, он перепланирует ее выполнение, пытаясь избежать узлов, на которых она завершилась неудачно. Но если задачу не удалось выполнить 4 раза, она не будет повторяться снова и задание вернет статус ошибки.
Выполнение некоторых задач может быть специально прервано, что отличается от неудачной попытки. Например, когда есть вероятность дублирования или отказа менеджера узла, на котором выполнялась задача. Как и в случае отказа NodeManager, эти попытки не будут учтены в счетчике свойства yarn.resourcemanager.am.max-plays, т.к. вызваны не ошибкой самого ApplicationMaster [2].
Об обновлениях YARN в свежем релизе Apache Hadoop 3.3.1, выпущенном в июне 2021 года, читайте в нашей новой статье. А практически освоить все тонкости администрирования и эксплуатации Apache Hadoop для хранения и аналитики больших данных вам помогут специализированные курсы в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Платформа Apache Hadoop YARN
Содержание
Данная статья представляет перевод оригинальных публикаций следующих авторов:
Переводчик выражает благодарность Виктору Жуковскому за ценные правки и обсуждение рукописи.
Apache Hadoop YARN – предыстория и обзор
Парадигма MapReduce
По существу модель вычислений MapReduce состоит, во-первых, из выполняемой параллельно фазы отображения, в которой входные данные разделяются на конечное множество блоков для последующей обработки. Во-вторых, модель состоит из фазы свёртки, в которой вывод фазы отображения агрегируется для получения конечного результата. Простая по сути и должным образом ограниченная программная модель приводит к эффективному и легко масштабируемому на тысячи пользовательских узлов программному коду.
Apache Hadoop MapReduce — наиболее популярная реализация модели MapReduce с открытым программным кодом.
В частности, если модель MapReduce используется в паре с распределённой файловой системой Apache Hadoop HDFS, предоставляющей высокую пропускную способность операций ввода/вывода в больших кластерах, то мы получаем исключительно экономичную и в тоже время весьма производительную систему — ключевой фактор в популярности Hadoop. Один из принципов работы — это уменьшение перемещения данных между узлами кластера. Иными словами мы перемещаем вычисления к данным, а не данные по сети к вычислениям. А именно, задачи MapReduce могут быть запущены на том физическом узле, который хранит данные в HDFS, при этом задействовав информацию о топологии кластера. Это значительно уменьшает нагрузку на сетевой ввод/вывод и проводит к тому, что весь ввод/вывод осуществляется в пределах локального диска либо одного вычислительно сегмента — важнейшее преимущество.
Платформа Apache Hadoop MapReduce
Apache Hadoop MapReduce — это проект с открытым исходным кодом копании Apache Software Foundation, представляющий собой реализацию модели вычислений MapReduce, описанную выше. Сам проект Apache Hadoop MapReduce можно разбить на несколько основных частей:
Такое распределение ответственности имеет значительные преимущества, в особенности для конечных пользователей — они могут полностью сосредоточиться на разработке приложения с использованием программного интерфейса MapReduce, поручив платформе MapReduce и системе MapReduce управление такими низкоуровневыми процессами как распределение ресурсов, обеспечение отказоустойчивости, планировка заданий.
В данный момент система Apache Hadoop MapReduce состоит из трекера заданий (JobTracker) — главного процесса и трекеров задач (TaskTrackers) — подчинённых ему процессов.
Трекер заданий (JobTracker) отвечает за управление ресурсами (управление рабочими узлами, например, трекерами задач (TaskTrackers), которые там работают), за отслеживание потребления/доступности ресурсов и также за жизненный цикл задания (запуск отдельных задач задания, отслеживание прогресса выполнения задач, обеспечение отказоустойчивости задач).
Трекер задач (TaskTrackers) имеет простые обязанности — запуск/остановка задач по команде трекера заданий (JobTracker) и переодическое предоставление трекеру заданий информации о статусе задачи.
С течением времени мы вносили новые изменения, например реализация высокой доступности трекера заданий (способность трекера заданий восстановить себя после сбоя), но это привело к более ресурсоёмкой поддержке трекера заданий и не решило главных задач: поддержка модели вычислений, отличной от MapReduce и обновление пользовательского программного обеспечения.
Зачем поддерживать модели вычислений, отличные от MapReduce?
Модель вычислений MapReduce прекрасно подходит для многих приложений, но не для всех: другие программные модели лучше удовлетворяют требованиям, возникающим при обработке графов (Google Pregel / Apache Giraph) и интерактивном моделировании (MPI). Если данные уже загружены в HDFS, то исключительно важно иметь несколько путей для их обработки.
Более того, поскольку MapReduce по своей сути пакетно-ориентировання модель вычислений, то поддержка обработки данных в реальном или практически реальном времени (например, потоковые вычисления и CEPFresil) — это те задачи, которые нам предстоит решить в ближайшем будущем.
Зачем улучшать масштабируемость?
Вспомним закон Мура (эмпирическое наблюдение, изначально сделанное Гордоном Муром, согласно которому количество транзисторов, размещаемых на кристалле интегральной схемы, удваивается каждые 24 месяца — прим. перев.). По аналогии вычислительная мощность компьютеров, доступных в дата-центрах, за фиксированную стоимость продолжает быстро расти. Например, сравним типичную мощность узла кластера за разные годы:
В общем при той же цене, серверы стали в два раза мощнее, чем они были два-три года назад — по каждому из параметров. Apache Hadoop MapReduce успешно управлял кластером из порядка 5000 узлов с аппаратным обеспечением 2009 года выпуска. Следовательно возможность масштабирования должна отражать существующие тенденции в росте аппаратного обеспечения узлов кластера.
Какие общие сценарии освобождения ресурсов кластера?
В текущей системе (Apache Hadoop MapReduce версии 1 — прим. перев.) трекер заданий рассматривает кластер как набор узлов с чётко заданным описанием слотов отображений и слотов свёрток, которые не являются взаимозаменяемыми. Проблемы с освобождением ресурсов возникают когда слоты отображений могут быть «заполненными», в то время как слоты свёрток пусты (и наоборот). Исправление подобной ситуации необходимо для того чтобы гарантировать, что вся система в целом использует максимум своей мощности.
В чём смысл гибкости платформы для заказчиков?
В промышленном использовании Hadoop часто устанавливается как распределённая многопользовательская система. Как результат, изменения и обновления в программном обеспечении Hadoop затрагивают большинство компонент, если не все. С другой стороны пользователи очень болезненно реагируют на необходимость изменения своего кода в связи с изменениями в Hadoop. Поэтому для Hadoop очень важно сделать возможным одновременную работу нескольких версий платформы MapReduce.
Введение в Apache Hadoop YARN
Главная идея YARN — предоставить две основные функции трекера задний — управление ресурсами и запуск/мониторинг задач — двум отдельным компонентам: глобальному менеджеру ресурсов (ResourceManager) и мастеру приложений (ApplicationMaster, AM). Причём каждое приложение пользователя имеет отдельный экземпляр мастера приложений. Менеджер ресурсов имеет подчинённый процесс, который называется менеджер узлов (NodeManager, NM). Менеджер узлов работает отдельно на каждом узле и представляет собой часть общей системы по управлению приложениями в распределённом режиме.
Менеджер ресурсов является последней инстанцией, решающей вопросы распределения ресурсов между всеми приложениями системы. Мастер приложений, запускаемый для каждого приложения в отдельности, — это, в сущности, платформенно зависимый элемент, запрашивающий ресурсы у менеджера ресурсов и взаимодействующий с менеджерами узлов для выполнения и мониторинга задач.
Менеджер ресурсов имеет подключаемый планировщик, который отвечает за выделение ресурсов разнообразным работающим приложениям. Планировщик представляет собой только планировщик и ничего более в том смысле, что он не выполняет мониторинга и не отслеживает статус приложения, не давая ни каких гарантий по повторному запуску аварийно остановленных задач, вне зависимости от причины останова — программного исключения или аппаратного сбоя. Планировщик выполняет свою работу основываясь на запросах приложения о необходимых ресурсах; он использует абстрактное понятие контейнер ресурсов, который включает в себя такие элементы как память, процессор, диск, сеть и другие.
Менеджер узлов — это подчинённый процесс, работающий на каждом узле и отвечающий за запуск контейнеров приложений, мониторинг использования ресурсов контейнера (процессор, память, диск, сеть) и передачу этих данных менеджеру ресурсов. Мастер приложений, запускаемый для каждого приложения в отдельности, отвечает за получение соответствующего контейнера от планировщика, отслеживание статуса контейнера и его прогресса использования. С точки зрения системы, мастер приложений работает как самый обыкновенный контейнер.
Ниже представлена архитектура YARN.
Одна из ключевых деталей реализации MapReduce в новой системе YARN состоит в том, что мы использовали повторно существующую платформу MapReduce без существенного вмешательства в исходный код платформы. Нам было очень важно гарантировать совместимость кода для существующий MapReduce приложений и пользователей.
Apache Hadoop YARN — концепции и применение
Как было сказано выше YARN — это, по существу, система управления распределёнными приложениями. Она состоит из глобального менеджера ресурсов, который управляет всеми доступными ресурсами кластера и, работающих на каждом узле менеджеров узлов, которыми управляет менеджер ресурсов. Менеджер узлов отвечает за распределение ресурсов на каждом узле.
Рассмотрим компоненты более подробно.
Менеджер ресурсов
В YARN менеджер ресурсов — это только планировщик и не более. По существу он строго ограничен лишь тем, что распределяет ресурсы системы между конкурирующими за ними приложениями, если хотите он как брокерская фирма, котирующая ценные бумаги. Он оптимизирует высвобождение ресурсов кластера (следит, чтобы не было «простаивающих в холостую» ресурсов) с учётом множества ограничений, таких как обязанность выделить все необходимые ресурсы, которые запрашивает приложение, равнодоступность ресурсов для всех приложений и права доступа к ресурсам. Для реализации различных ограничений менеджер ресурсов имеет подключаемый планировщик, который позволяет при необходимости использовать алгоритмы сбалансированного распределения ресурсов.
Мастер приложений
Многие проводят параллели между YARN и существующей системой Hadoop MapReduce (называемой MR1 в Apache Hadoop 1.x). Однако существует ключевое различие — это новая концепция мастера приложений.
Мастер приложений, в действительности является экземпляром библиотеки, специфической относительно платформы. Он отвечает за получение ресурсов от менеджера ресурсов. Мастер приложений взаимодействует с менеджером узлов для выделения и мониторинга контейнеров. В обязанности мастера приложений входит запрос у менеджера ресурсов соответствующего контейнера ресурсов, отслеживание статуса контейнера и мониторинг прогресса выполнения задачи.
Мастер приложений позволяет платформе YARN достичь следующих ключевых характеристик:
Добавим также несколько дополнительных характеристик YARN платформы:
Полезно помнить, что в реальности каждое приложение имеет свой собственный экземпляр менеджера приложений. Тем не менее, также вполне допустимо реализовать мастер приложений, управляющий набором приложений (например, мастер приложений для Pig или Hive, который управляет целым набором задач MapReduce). К тому же, эта концепция была развита для управления долгоживущими сервисами, которые в свою очередь управляют своими собственными приложениями (например, запускать HBase в YARN с помощью HBaseAppMaster).
Модель ресурсов
YARN поддерживает очень общую модель ресурсов для приложений. Приложение (с помощью мастера приложений) может запрашивать ресурсы предельно точно определяя свои требования, такие как:
Контейнер и запрос на предоставление ресурсов
YARN задумывался так, чтобы позволить отдельным приложениям (через мастер приложений) использовать ресурсы кластера в распределенном многопользовательском окружении. Также важно знать топологию кластера для эффективного планирования и оптимизации доступа к данным, то есть уменьшение до минимума перемещения данных.
Для достижения поставленных целей, главный планировщик (в составе менеджера ресурсов) имеет полную информацию о запросах приложений на ресурсы, что позволяет ему делать распределение ресурсов оптимальным образом между всеми приложениями кластера. Это приводит нас к понятию запросам на предоставление ресурсов, а затем и к понятию контейнер.
По сути, приложение может выполнить запрос на предоставление необходимых ресурсов посредством мастера приложений. Планировщик отвечает на запрос о предоставлении ресурсов выдачей контейнера, который удовлетворяет требованиям, выставленным мастером приложений в запросе. Давайте рассмотрим запрос на предоставление ресурсов более подробно. Запрос имеет следующую форму:
Для лучшего понимания рассмотрим каждый компонент запроса на предоставление ресурса более подробно:
Теперь рассмотрим контейнеры. По сути контейнер — это выделенные ресурсы, результат успешного выполнения менеджером ресурсов определённого запроса на выделение ресурсов. Контейнер предоставляет права приложению для использование заданного количества ресурсов (память, процессор) на заданном узле.
Мастер приложений должен взять контейнер и передать его менеджеру узлов, управляющему узлом, на котором расположен контейнер для использования ресурсов при запуске пользовательских задач. Конечно, в безопасном режиме работы кластера проверяются привилегии на выделение ресурсов, чтобы гарантировать отсутствие неправомерных запросов на выделение ресурсов.
Запуск и спецификация контейнера
Поскольку контейнер, как описано выше, это всего лишь право использовать заданное количество ресурсов на заданном узле кластера (на котором находится менеджер узлов), то мастер приложений должен предоставить менеджеру узлов более подробную информацию для фактического запуска контейнера.
YARN позволяет запускать приложения на разных языках и в отличии от существующей версии Hadoop MapReduce hadoop-1.x (также известной как MR1) не ограничен языком программирования Java.
Программный интерфейс запуска YARN контейнера не зависит от платформы и содержит:
YARN — обзор и анализ
Вооружившись знаниями из предыдущих разделов будет полезно выяснить как собственно приложения работают в YARN. Запуск приложения состоит из следующих шагов:
Пройдёмся по последовательности шагов для выполнения приложения (номера шагов показаны ниже на диаграмме):
Apache Hadoop YARN — Менеджер ресурсов
Как описано выше, менеджер ресурсов (RM) — это фоновый процесс, который управляет доступными ресурсами кластера и следовательно, помогает управлять распределёнными приложениями в YARN системе. Он работает совместно с менеджерами узлов (NM), один экземпляр которого работает на каждом узле, и мастерами приложений (AM), один экземпляр которого запускается при запуске приложения.
Компоненты менеджера ресурсов
Менеджер ресурсов состоит из следующих компонент:
Выводы
В архитектуре YARN, менеджер ресурсов в основном предназначен только лишь для управления ресурсами, то есть он распределяет доступные ресурсы системы среди соревнующихся за них приложений, в то время как состоянием самого приложения он не управляет. Из-за такого чёткого распределения ответственности совместно с модульностью менеджера ресурсов, описанной выше и мощным API, он способен выполнить важнейшую из задач, возложенных на него: обеспечить масштабируемость и поддержку альтернативных парадигм программирования (отличных от MapReduce — прим. перев.).
Для обеспечения разных политик ограничений, планировщик, описанный выше представляет собой подключаемый программный модуль менеджера ресурсов.
Apache Hadoop YARN – Менеджер узлов
Менеджер узлов — это сервис, работающий на каждом узле и отвечающий за отдельные узлы Hadoop кластера. Это включает в себя постоянное взаимодействие с менеджером ресурсов (RM), наблюдение за жизненным циклом контейнеров, мониторинг использования ресурсов (память, центральный процессор) отдельного контейнера, отслеживание работоспособности узлов, управление журналами и вспомогательными сервисами, которые используются разнообразными YARN приложениями.
Компоненты менеджера узлов
Менеджер узлов состоит из следующих компонент:
Краткий обзор функциональности
Запуск контейнера
Для запуска контейнера менеджер узла ожидает получить детальную информацию о программе, которая будет запускаться в контейнере в качестве части спецификации контейнера. Она включает в себя командую строку контейнера, переменные окружения, список ресурсов (файлов), необходимых для работы контейнера и произвольные токены безопасности.
При получении запроса на запуск контейнера — менеджер узлов, во-первых, если включён безопасный режим работы, проверяет допустимость выполнения запроса авторизированным пользователем и правильность присвоения ресурсов. Менеджер узлов выполняет следующий набор шагов для запуска контейнера:
Агрегация журналов
Работа с журналами пользователей в прошлом была одной из наиболее значительных трудностей в платформе Hadoop. Вместо усечения пользовательских журналов и хранения их на отдельных узлах подобно трекеру задач, менеджер узлов решает задачу управления журналами предоставляя возможность перемещать журналы в файловую систему (например в HDFS) после того как приложение завершилось.
Журналы всех контейнеров, принадлежащих одному приложению, запущенному на конкретном менеджере узлов, агрегируются (допустимо также архивирование) и записываются в файл, чьё местоположение в файловой системе заранее настроено. Пользователи могут получить доступ к этим журналам инструментов командной строки YARN, веб-интерфейса или непосредственно обратившись к файловой системе.
Преимущества вспомогательных сервисов
Каким образом такой этап MapReduce вычислений как тасовка получает преимущества вспомогательных сервисов менеджеров узлов? Такая функциональность как тасовка, необходимая при работе приложения в модели вычислений MapReduce, реализована как вспомогательный сервис. Этот сервис запускает веб-сервер Netty и имеет функционал для выполнения специфических запросов на тасовку, поступающих от заданий свёртки (Reduce). Мастер приложений определяет идентификатор сервиса и токены безопасности (при необходимости) для сервиса тасовки. Менеджер узлов предоставляет мастеру приложений порт, на котором работает сервис тасовки. Этот порт передаётся также задачам свёртки.
Выводы
В платформе YARN менеджер узлов предназначен только для управления абстрактными контейнерами, то есть только отдельными процессами, запущенными в контейнере, а не для управления задачами отображения/свёртки в целом. Менеджер узлов к тому же не использует концепцию «именных» слотов, так что слоты отображений и слоты свёрток не используются. Благодаря такому чёткому распределению обязанностей совместно с модульной архитектурой, описанной выше, менеджер узлов масштабируется гораздо лучше, к тому же его код более прост в поддержке.