yarn hadoop что это
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.
Русские Блоги
Учебная серия Hadoop (3) подробный анализ YARN
1. Первое знакомство с YARN
Основная идея YARN состоит в том, чтобы разделить функции управления ресурсами и планирования / мониторинга заданий на отдельные демоны, у которых есть глобальные ResourceManager (RM) и ApplicationMaster (AM) для каждого приложения. Приложение может быть отдельным заданием или группой DAG задания.
Когда пользователь отправляет приложение, запускается облегченный экземпляр процесса с именем ApplicationMaster для координации выполнения всех задач в приложении. Это включает в себя мониторинг задач, перезапуск невыполненных задач, спекулятивное выполнение медленных задач и вычисление общего значения счетчиков приложений. ApplicationMaster и задачи, принадлежащие его приложениям, выполняются в контейнере ресурсов, управляемом NodeManager.
NodeManager имеет множество динамически создаваемых контейнеров ресурсов. Размер контейнера зависит от количества содержащихся в нем ресурсов, таких как память, ЦП, диск и сетевой ввод-вывод. В настоящее время поддерживаются только память и процессор. Количество контейнеров на узле является произведением параметров конфигурации и общего объема ресурсов узла (таких как общий ЦП и общая память), кроме ресурсов, используемых для демона и ОС.
ApplicationMaster может запускать в контейнере задачи любого типа. Например, MapReduce ApplicationMaster запрашивает контейнер для запуска сопоставления или сокращения задач, в то время как Giraph ApplicationMaster запрашивает контейнер для выполнения задач Giraph. Вы также можете реализовать собственный ApplicationMaster, который выполняет определенные задачи.
В YARN MapReduce был просто отнесен к роли распределенных приложений (но по-прежнему очень популярен и полезен) и теперь называется MRv2.
Кроме того, YARN поддерживает концепцию резервирования ресурсов через ReservationSystem.ReservationSystem позволяет пользователям указывать временные и временные ограничения (например, крайние сроки) ресурсов через файлы конфигурации и резервировать ресурсы для обеспечения предсказуемого выполнения важных заданий. ReservationSystem может отслеживать тайм-ауты ресурсов, выполнять управление зарезервированным допуском и динамически инструктировать базовый планировщик, чтобы гарантировать, что резервирование заполнено.
2. Базовые сервисные компоненты YARN
Базовая структура YARN, YARN в основном состоит из нескольких компонентов, таких как ResourceManager, NodeManager, ApplicationMaster и Container.
ResourceManager отвечает за единое управление и планирование ресурсов на каждом NadeManager. Когда пользователь отправляет приложение, ему необходимо предоставить ApplicationMaster для отслеживания и управления приложением. Он отвечает за запрос ресурсов из ResourceManager и требует, чтобы NodeManger запускал задачи, которые могут занимать определенные ресурсы. Поскольку разные ApplicationMaster распределены на разных узлах, они не будут влиять друг на друга.
Каждое приложение, отправленное клиентом в ResourceManager, должно иметь ApplicationMaster. После того, как ResourceManager выделяет ресурсы, оно запускается в контейнере подчиненного узла. Задача, которая выполняет задание, также выполняется в контейнере подчиненного узла.
2.1 ResourceManager
Планировщик выделяет ресурсы в системе каждому запущенному приложению в соответствии с ограничениями, такими как емкость и очереди (например, каждая очередь выделяет определенное количество ресурсов и выполняет не более определенного количества заданий). Следует отметить, что планировщик является «чистым планировщиком», он участвует в любой работе, связанной с конкретными приложениями, например, не отвечает за мониторинг или отслеживание состояния выполнения приложения и т. Д., А также не отвечает за перезапуск из-за сбоя выполнения приложения или оборудования. Неудачные задачи, вызванные сбоями, выполняются ApplicationMaster, связанным с приложением.
(2) Диспетчер приложений
Диспетчер приложений в основном отвечает за управление всеми приложениями во всей системе, получение запросов на отправку заданий, назначение первого контейнера приложению для запуска ApplicationMaster, включая отправку приложений, согласование ресурсов с планировщиком для запуска ApplicationMaster, мониторинг текущего состояния ApplicationMaster и В случае сбоя перезапустите его и т. Д.
2.2 ApplicationMaster
Управляйте каждым экземпляром приложения, запущенным в YARN. За управление заданиями или приложениями отвечает процесс ApplicationMaster.Yarn позволяет нам разрабатывать ApplicationMaster для наших собственных приложений.
Можно сказать, что связь между ApplicationMaster и ResourceManager является основной частью всего приложения Yarn от отправки до работы. Это фундаментальный шаг Yarn для динамического управления ресурсами всего кластера. Динамика Yarn выводится из динамики ApplicationMaster из нескольких приложений. Общайтесь с ResourceManager локально и постоянно применяйте, высвобождая, повторно применяйте и высвобождайте ресурсы.
2.3 NodeManager
Во всем кластере есть несколько NodeManager, отвечающих за ресурсы и использование каждого узла.
Функция: использование ресурсов NodeManager на этом узле и рабочее состояние каждого контейнера (ресурсы процессора и памяти)
Когда узел запускается, он регистрируется в ResourceManager и сообщает ResourceManager, сколько ресурсов у него доступно. Во время выполнения, благодаря совместной работе NodeManager и ResourceManager, эта информация будет постоянно обновляться и обеспечивать наилучшее состояние всего кластера.
2.4 Container
Связь между узлами контейнера и кластера состоит в том, что на одном узле будет работать несколько контейнеров, но один контейнер не будет охватывать узлы. Любое задание или приложение должны выполняться в одном или нескольких контейнерах. В структуре Yarn ResourceManager отвечает только за то, чтобы сообщить ApplicationMaster, какие контейнеры можно использовать, а ApplicationMaster также должен найти NodeManager, чтобы запросить выделение определенных контейнеров.
3. Процесс подачи заявки на YARN.
Процесс выполнения Application in Yarn можно разделить на три этапа:
Конкретный процесс подачи заявки:
Четыре, запрос ресурса и контейнер
Для достижения этих целей планировщик планировщика ResourceManager определяет некоторые гибкие протоколы для запросов ресурсов приложений, с помощью которых можно лучше планировать различные приложения, работающие в кластере, поэтому это было рожденоResource Requestс участиемContainer。
Приложение сначала отправляет запрос ресурса, который соответствует его собственным потребностям, в ApplicationMaster, а затем ApplicationMaster отправляет этот запрос ресурса в планировщик ResourceManager в форме запроса ресурса, а планировщик возвращает назначенный контейнер описания ресурса в исходном запросе ресурса.
Каждый ResourceRequest может рассматриваться как сериализуемый объект Java, и включаемая информация о полях выглядит следующим образом:
После того, как ApplicationMaster получит эти контейнеры, ему также необходимо взаимодействовать с NodeManager на компьютере, на котором он выделен, для запуска контейнера и выполнения связанных задач. Конечно, выделение контейнеров требует аутентификации, чтобы ApplicationMaster не запрашивал ресурсы кластера.
Пять, конфигурация ПРЯЖИ
в). Проверка: удовлетворительно JPS Команда, чтобы проверить, запущена ли YARN
Когда отображается изображение выше, это означает, что YARN успешно запущен.
Big Data от А до Я. Часть 2: Hadoop
Привет, Хабр! В предыдущей статье мы рассмотрели парадигму параллельных вычислений MapReduce. В этой статье мы перейдём от теории к практике и рассмотрим Hadoop – мощный инструментарий для работы с большими данными от Apache foundation.
В статье описано, какие инструменты и средства включает в себя Hadoop, каким образом установить Hadoop у себя, приведены инструкции и примеры разработки MapReduce-программ под Hadoop.
Общая информация о Hadoop
Как известно парадигму MapReduce предложила компания Google в 2004 году в своей статье MapReduce: Simplified Data Processing on Large Clusters. Поскольку предложенная статья содержала описание парадигмы, но реализация отсутствовала – несколько программистов из Yahoo предложили свою реализацию в рамках работ над web-краулером nutch. Более подробно историю Hadoop можно почитать в статье The history of Hadoop: From 4 nodes to the future of data
Изначально Hadoop был, в первую очередь, инструментом для хранения данных и запуска MapReduce-задач, сейчас же Hadoop представляет собой большой стек технологий, так или иначе связанных с обработкой больших данных (не только при помощи MapReduce).
Основными (core) компонентами Hadoop являются:
Некоторым из перечисленных компонент будут посвящены отдельные статьи этого цикла материалов, а пока разберём, каким образом можно начать работать с Hadoop и применять его на практике.
Установка Hadoop на кластер при помощи Cloudera Manager
Раньше установка Hadoop представляла собой достаточно тяжёлое занятие – нужно было по отдельности конфигурировать каждую машину в кластере, следить за тем, что ничего не забыто, аккуратно настраивать мониторинги. С ростом популярности Hadoop появились компании (такие как Cloudera, Hortonworks, MapR), которые предоставляют собственные сборки Hadoop и мощные средства для управления Hadoop-кластером. В нашем цикле материалов мы будем пользоваться сборкой Hadoop от компании Cloudera.
Для того чтобы установить Hadoop на свой кластер, нужно проделать несколько простых шагов:
После установки вы получите консоль управления кластером, где можно смотреть установленные сервисы, добавлять/удалять сервисы, следить за состоянием кластера, редактировать конфигурацию кластера:
Более подробно с процессом установки Hadoop на кластер при помощи cloudera manager можно ознакомиться по ссылке в разделе Quick Start.
Если же Hadoop планируется использовать для «попробовать» – можно не заморачиваться с приобретением дорогого железа и настройкой Hadoop на нём, а просто скачать преднастроенную виртуальную машину по ссылке и пользоваться настроенным hadoop’ом.
Запуск MapReduce программ на Hadoop
Теперь покажем как запустить MapReduce-задачу на Hadoop. В качестве задачи воспользуемся классическим примером WordCount, который был разобран в предыдущей статье цикла. Для того, чтобы экспериментировать на реальных данных, я подготовил архив из случайных новостей с сайта lenta.ru. Скачать архив можно по ссылке.
Напомню формулировку задачи: имеется набор документов. Необходимо для каждого слова, встречающегося в наборе документов, посчитать, сколько раз встречается слово в наборе.
Решение:
Map разбивает документ на слова и возвращает множество пар (word, 1).
Reduce суммирует вхождения каждого слова:
Теперь задача запрограммировать это решение в виде кода, который можно будет исполнить на Hadoop и запустить.
Способ №1. Hadoop Streaming
Самый простой способ запустить MapReduce-программу на Hadoop – воспользоваться streaming-интерфейсом Hadoop. Streaming-интерфейс предполагает, что map и reduce реализованы в виде программ, которые принимают данные с stdin и выдают результат на stdout.
Программа, которая исполняет функцию map называется mapper. Программа, которая выполняет reduce, называется, соответственно, reducer.
Streaming интерфейс предполагает по умолчанию, что одна входящая строка в mapper или reducer соответствует одной входящей записи для map.
Вывод mapper’a попадает на вход reducer’у в виде пар (ключ, значение), при этом все пары соответствующие одному ключу:
Данные, которые будет обрабатывать Hadoop должны храниться на HDFS. Загрузим наши статьи и положим на HDFS. Для этого нужно воспользоваться командой hadoop fs:
Утилита hadoop fs поддерживает большое количество методов для манипуляций с файловой системой, многие из которых один в один повторяют стандартные утилиты linux. Подробнее с её возможностями можно ознакомиться по ссылке.
Теперь запустим streaming-задачу:
Утилита yarn служит для запуска и управления различными приложениями (в том числе map-reduce based) на кластере. Hadoop-streaming.jar – это как раз один из примеров такого yarn-приложения.
Дальше идут параметры запуска:
В интерфейсе доступном по этому URL можно узнать более детальный статус выполнения задачи, посмотреть логи каждого маппера и редьюсера (что очень полезно в случае упавших задач).
Сам результат можно получить следующим образом:
Способ №2
Сам по себе hadoop написан на java, и нативный интерфейс у hadoop-a тоже java-based. Покажем, как выглядит нативное java-приложение для wordcount:
Этот класс делает абсолютно то же самое, что наш пример на Python. Мы создаём классы TokenizerMapper и IntSumReducer, наследуя их от классов Mapper и Reducer соответсвенно. Классы, передаваемые в качестве параметров шаблона, указывают типы входных и выходных значений. Нативный API подразумевает, что функции map на вход подаётся пара ключ-значение. Поскольку в нашем случае ключ пустой – в качестве типа ключа мы определяем просто Object.
В методе Main мы заводим mapreduce-задачу и определяем её параметры – имя, mapper и reducer, путь в HDFS, где находятся входные данные и куда положить результат.
Для компиляции нам потребуются hadoop-овские библиотеки. Я использую для сборки Maven, для которого у cloudera есть репозиторий. Инструкции по его настройке можно найти по ссылке. В итоге файл pom.xmp (который используется maven’ом для описания сборки проекта) у меня получился следующий):
Соберём проект в jar-пакет:
После сборки проекта в jar-файл запуск происходит похожим образом, как и в случае streaming-интерфейса:
Дожидаемся выполнения и проверяем результат:
Как нетрудно догадаться, результат выполнения нашего нативного приложения совпадает с результатом streaming-приложения, которое мы запустили предыдущим способом.
Резюме
В статье мы рассмотрели Hadoop – программный стек для работы с большими данными, описали процесс установки Hadoop на примере дистрибутива cloudera, показали, как писать mapreduce-программы, используя streaming-интерфейс и нативный API Hadoop’a.
В следующих статьях цикла мы рассмотрим более детально архитектуру отдельных компонент Hadoop и Hadoop-related ПО, покажем более сложные варианты MapReduce-программ, разберём способы упрощения работы с MapReduce, а также ограничения MapReduce и как эти ограничения обходить.
Спасибо за внимание, готовы ответить на ваши вопросы.
Платформа 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 менеджер узлов предназначен только для управления абстрактными контейнерами, то есть только отдельными процессами, запущенными в контейнере, а не для управления задачами отображения/свёртки в целом. Менеджер узлов к тому же не использует концепцию «именных» слотов, так что слоты отображений и слоты свёрток не используются. Благодаря такому чёткому распределению обязанностей совместно с модульной архитектурой, описанной выше, менеджер узлов масштабируется гораздо лучше, к тому же его код более прост в поддержке.