hadoop что такое yarn
Apache Hadoop YARN
The fundamental idea of YARN is to split up the functionalities of resource management and job scheduling/monitoring into separate daemons. The idea is to have a global ResourceManager (RM) and per-application ApplicationMaster (AM). An application is either a single job or a DAG of jobs.
The ResourceManager and the NodeManager form the data-computation framework. The ResourceManager is the ultimate authority that arbitrates resources among all the applications in the system. The NodeManager is the per-machine framework agent who is responsible for containers, monitoring their resource usage (cpu, memory, disk, network) and reporting the same to the ResourceManager/Scheduler.
The per-application ApplicationMaster is, in effect, a framework specific library and is tasked with negotiating resources from the ResourceManager and working with the NodeManager(s) to execute and monitor the tasks.
The ResourceManager has two main components: Scheduler and ApplicationsManager.
The Scheduler is responsible for allocating resources to the various running applications subject to familiar constraints of capacities, queues etc. The Scheduler is pure scheduler in the sense that it performs no monitoring or tracking of status for the application. Also, it offers no guarantees about restarting failed tasks either due to application failure or hardware failures. The Scheduler performs its scheduling function based on the resource requirements of the applications; it does so based on the abstract notion of a resource Container which incorporates elements such as memory, cpu, disk, network etc.
The Scheduler has a pluggable policy which is responsible for partitioning the cluster resources among the various queues, applications etc. The current schedulers such as the CapacityScheduler and the FairScheduler would be some examples of plug-ins.
The ApplicationsManager is responsible for accepting job-submissions, negotiating the first container for executing the application specific ApplicationMaster and provides the service for restarting the ApplicationMaster container on failure. The per-application ApplicationMaster has the responsibility of negotiating appropriate resource containers from the Scheduler, tracking their status and monitoring for progress.
MapReduce in hadoop-2.x maintains API compatibility with previous stable release (hadoop-1.x). This means that all MapReduce jobs should still run unchanged on top of YARN with just a recompile.
YARN supports the notion of resource reservation via the ReservationSystem, a component that allows users to specify a profile of resources over-time and temporal constraints (e.g., deadlines), and reserve resources to ensure the predictable execution of important jobs.The ReservationSystem tracks resources over-time, performs admission control for reservations, and dynamically instruct the underlying scheduler to ensure that the reservation is fullfilled.
In order to scale YARN beyond few thousands nodes, YARN supports the notion of Federation via the YARN Federation feature. Federation allows to transparently wire together multiple yarn (sub-)clusters, and make them appear as a single massive cluster. This can be used to achieve larger scale, and/or to allow multiple independent clusters to be used together for very large jobs, or for tenants who have capacity across all of them.
Apache Hadoop YARN
The fundamental idea of YARN is to split up the functionalities of resource management and job scheduling/monitoring into separate daemons. The idea is to have a global ResourceManager (RM) and per-application ApplicationMaster (AM). An application is either a single job or a DAG of jobs.
The ResourceManager and the NodeManager form the data-computation framework. The ResourceManager is the ultimate authority that arbitrates resources among all the applications in the system. The NodeManager is the per-machine framework agent who is responsible for containers, monitoring their resource usage (cpu, memory, disk, network) and reporting the same to the ResourceManager/Scheduler.
The per-application ApplicationMaster is, in effect, a framework specific library and is tasked with negotiating resources from the ResourceManager and working with the NodeManager(s) to execute and monitor the tasks.
The ResourceManager has two main components: Scheduler and ApplicationsManager.
The Scheduler is responsible for allocating resources to the various running applications subject to familiar constraints of capacities, queues etc. The Scheduler is pure scheduler in the sense that it performs no monitoring or tracking of status for the application. Also, it offers no guarantees about restarting failed tasks either due to application failure or hardware failures. The Scheduler performs its scheduling function based the resource requirements of the applications; it does so based on the abstract notion of a resource Container which incorporates elements such as memory, cpu, disk, network etc.
The Scheduler has a pluggable policy which is responsible for partitioning the cluster resources among the various queues, applications etc. The current schedulers such as the CapacityScheduler and the FairScheduler would be some examples of plug-ins.
The ApplicationsManager is responsible for accepting job-submissions, negotiating the first container for executing the application specific ApplicationMaster and provides the service for restarting the ApplicationMaster container on failure. The per-application ApplicationMaster has the responsibility of negotiating appropriate resource containers from the Scheduler, tracking their status and monitoring for progress.
MapReduce in hadoop-2.x maintains API compatibility with previous stable release (hadoop-1.x). This means that all MapReduce jobs should still run unchanged on top of YARN with just a recompile.
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 для каждого приложения ответственнен за выделение ресурсов планировщиком для контейнера в котором будет выполнятся приложение. Также он затрекает статус и прогресс выполнения приложения.
Hadoop что такое yarn
YARN – это система планирования заданий и управления кластером (Yet Another Resource Negotiator), которую также называют MapReduce 2.0 – набор системных программ (демонов), обеспечивающих совместное использование, масштабирование и надежность работы распределенных приложений. YARN является интерфейсом между аппаратными ресурсами кластера и приложениями, использующих его мощности для вычислений и аналитики больших данных.
История появления и роль YARN в экосистеме Apache Hadoop
Будучи впервые выпущен в 2013 году под лицензией Apache 2.0, YARN является одним из основных модулей ядра экосистемы Hadoop, отвечая за планирование заданий и управление распределенными приложениями. YARN решает проблемы 1-ой версии технологии распределенных вычислений – MapReduce, предоставляя компоненты и API для разработки Big Data приложений, обеспечивая распределение ресурсов в ответ на запросы и отслеживания статусы выполнения заданий.
Поэтому очень часто этот фреймворк называют Apache Hadoop YARN или MapReduce 2.0, хотя он используется не только в классическом Hadoop MapReduce. Благодаря более общей модели, чем в классическом Hadoop MapReduce, YARN позволяет запускать в кластере Apache Hadoop не только MapReduce-задания, но и любые распределенные приложения. В частности, в Apache Spark именно YARN обеспечивает распределённому приложению доступ к кластеру через свой диспетчер ресурсов – один из главных модулей YARN, которые мы рассмотрим далее.
Архитектура и принципы работы
YARN состоит из следующих компонентов:
ApplicationsManager отвечает за прием задач и запуск экземпляров мастера приложений (ApplicationMaster), мониторингов узлов (контейнеров), на которых происходит выполнение распределенных заданий, и предоставляет сервис для перезапуска контейнера ApplicationMaster в случае сбоя. Планировщик менеджера ресурсов (Scheduler) является не ведет мониторинг и не отслеживает статус выполнения распределенного приложений, а также не дает гарантий перезапуска неудачных задач при аппаратных или программных отказах.
Таким образом, YARN разделяет функции управления ресурсами и планирования/мониторинга заданий на отдельные демоны, имея глобальный диспетчер ресурсов и мастер приложения для каждого отдельного задания или их конвейера в виде направленного ациклического графа (DAG, Directed Acyclic Graph).
ResourceManager и диспетчер узла образуют структуру вычисления данных, где менеджер ресурсов распределяет ресурсы между всеми приложениями в системе, а NodeManager на каждом узле отвечает за контейнеры, отслеживая использование ресурсов и сообщая об этом планировщику. Планировщик распределяет ресурсы между запущенными приложениями в виде контейнера с учетом их требований и известных ограничений емкости, очередей и пр.
Компоненты YARN взаимодействуют друг с другом через следующие протоколы:
Принцип работы Hadoop YARN можно описать следующим образом:
При необходимости клиент может самостоятельно завершить работу приложения. Являясь контейнером, работающим в кластере, мастер приложения должен быть отказоустойчивым. Хотя YARN и поддерживает восстановление при сбоях, но большая часть нагрузки по обеспечению отказоустойчивости все равно лежит на мастере приложения.
Более подробно про некоторые аспекты работы YARN читайте в наших отдельных статьях:
Платформа 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 менеджер узлов предназначен только для управления абстрактными контейнерами, то есть только отдельными процессами, запущенными в контейнере, а не для управления задачами отображения/свёртки в целом. Менеджер узлов к тому же не использует концепцию «именных» слотов, так что слоты отображений и слоты свёрток не используются. Благодаря такому чёткому распределению обязанностей совместно с модульной архитектурой, описанной выше, менеджер узлов масштабируется гораздо лучше, к тому же его код более прост в поддержке.