Содержание


Введение в YARN

Comments

В Apache Hadoop 2.0 входит механизм YARN, который отделяет компоненты управления ресурсами от компонентов обработки. Архитектура YARN не сводится к MapReduce. В данной статье описывается YARN и его преимущества перед предыдущим уровнем распределенной обработки в Hadoop. Узнайте, как улучшить работу кластеров, используя масштабируемость, эффективность и гибкость YARN.

Apache Hadoop в двух словах

Apache Hadoop – это программная инфраструктура с открытым исходным кодом, устанавливаемая в кластере стандартных машин для совместного распределенного хранения и обработки больших объемов данных. Первоначально Hadoop состояла из двух основных компонентов, которые позволяют реализовать выполнение программ в виде заданий MapReduce: распределенной файловой системы Hadoop (HDFS) и механизма распределенных вычислений.

Простая модель программирования MapReduce, которая обрела популярность благодаря Google, используется для параллельной масштабируемой обработки больших наборов данных. Модель MapReduce следует принципам функционального программирования, вследствие чего пользовательские вычисления выполняются как функции map и reduce, обрабатывающие данные в виде пар ключ-значение. Hadoop предоставляет высокоуровневый программный интерфейс для реализации пользовательских функций map и reduce в различных языках.

Также Hadoop предоставляет инфраструктуру ПО для выполнения заданий MapReduce в виде серий задач map и reduce. Задачи map вызывают функции map для обработки наборов входных данных. Затем задачи reduce вызывают функции reduce для обработки промежуточных данных, сгенерированных функциями map, формируя окончательные выходные данные. Задачи map и reduce выполняются изолированно друг от друга, что обеспечивает параллельность и отказоустойчивость вычислений.

Очень важно, что инфраструктура Hadoop берет на себя все сложные аспекты распределенной обработки: параллелизм, планирование, управление ресурсами, взаимодействие между машинами, обработку отказов ПО и оборудования и многое другое. Эта абстракция как никогда ранее упростила реализацию распределенных приложений, обрабатывающих терабайты данных на сотнях (или даже тысячах) машин, даже для разработчиков, не имеющих опыта в области распределенных систем.

Золотой век Hadoop

Хотя было несколько реализаций модели MapReduce с открытым исходным кодом, наиболее популярной быстро стала Hadoop MapReduce. Кроме того, Hadoop является одним из наиболее захватывающих проектов с открытым исходным кодом на планете, поскольку обладает несколькими замечательными функциональными возможностями, такими как высокоуровневый программный интерфейс, почти линейная масштабируемость, выполнение на стандартном оборудовании и отказоустойчивость. Он успешно используется сотнями (а может быть и тысячами) компаний и в настоящее время является стандартом для высокоуровневых масштабируемых хранения и обработки.

Некоторые ранние последователи Hadoop, такие как Yahoo! и Facebook, для удовлетворения своих постоянно растущих и изменяющихся требований к обработке данных создали масштабные кластеры, размером до 4000 узлов. Однако после создания кластера они начали замечать ограничения инфраструктуры MapReduce.

Ограничения классического MapReduce

Наиболее серьезные ограничения классического механизма MapReduce в первую очередь связаны с масштабируемостью, использованием ресурсов и поддержкой рабочих нагрузок, отличных от MapReduce. В инфраструктуре MapReduce выполнение задания управляется двумя видами процессов:

  • Один главный процесс JobTracker координирует выполнение заданий в кластере и назначает задачи map и reduce для выполнения процессом TaskTrackers.
  • Несколько подчиненных процессов TaskTracker, выполняющих назначенные задачи и периодически передающих результаты выполнения в JobTracker.
Классическая версия Apache Hadoop (MRv1)
Классическая версия Apache Hadoop (MRv1)
Классическая версия Apache Hadoop (MRv1)

Большие кластеры Hadoop выявили узкое место масштабируемости – наличие одного процесса JobTracker. Согласно Yahoo!, практические пределы такого дизайна достигаются в кластере, имеющем 5000 узлов и 40 000 одновременно выполняющихся задач. Это ограничение вынуждает создавать и поддерживать кластеры меньшего размера и меньшей мощности.

Более того, как меньшие, так и большие кластеры Hadoop никогда не используют свои вычислительные ресурсы максимально эффективно. В Hadoop MapReduce вычислительные ресурсы каждого ведомого узла делятся администратором кластера на фиксированное число слотов map и reduce, которые не являются взаимозаменяемыми. Учитывая число установленных слотов map и reduce, узел не может в любой момент выполнять больше задач map, чем имеется слотов map, даже если задачи reduce не выполняются. Это затрудняет эффективное использование кластера, потому что при заполнении всех слотов map и необходимости в дополнительных нельзя использовать любой свободный слот reduce и наоборот.

И последнее, но не менее важное: Hadoop разрабатывался только для выполнения заданий MapReduce. С появлением альтернативных моделей программирования (например, обработка графов, реализованная в Apache Giraph) растет потребность в поддержке отличных от MapReduce парадигм программирования, которые могли бы эффективно использовать те же кластеры и общие ресурсы.

В 2010 году инженеры Yahoo! приступили к работе над совершенно новой архитектурой Hadoop для преодоления вышеперечисленных ограничений и расширения функциональных возможностей.

Решение проблемы масштабируемости

В Hadoop MapReduce на процессе JobTracker лежат две обязанности:

  • Управление вычислительными ресурсами в кластере, включающее обработку списка работоспособных узлов, списка доступных и занятых слотов map и reduce, а также выделение доступных слотов для соответствующих заданий и задач согласно выбранной политике планирования.
  • Координация всех задач, выполняющихся в кластере, включающая инструкции процессам TaskTracker по запуску задач map и reduce, мониторинг выполнения этих задач, повторный запуск задач после сбоев, упреждающее выполнение медленных задач, вычисление суммарных значений счетчиков задания и многое другое.

Большое число обязанностей, порученных одному процессу, приводит к серьезным проблемам масштабируемости, особенно в большом кластере, где процессу JobTracker приходится постоянно отслеживать тысячи процессов TaskTracker, сотни заданий и десятки тысяч задач map и reduce. Приведенный ниже рисунок иллюстрирует проблему. В свою очередь процессы TaskTracker обычно выполняют всего около десятка задач, которые назначены им сильно загруженным процессом JobTracker.

Сильно загруженный JobTracker в большом кластере Apache Hadoop (MRv1)
Сильно загруженный JobTracker в большом кластере Apache Hadoop (MRv1)
Сильно загруженный JobTracker в большом кластере Apache Hadoop (MRv1)

Для решения проблемы масштабируемости предлагается простая, но эффективная идея: снять часть обязанностей с одного процесса JobTracker и делегировать некоторые из них процессам TaskTracker, поскольку многие из них находятся в кластере. Эта концепция нашла свое отражение в новом дизайне, где обязанности JobTracker (управление ресурсами кластера и координация задач) разделены на два вида процессов.

Вместо одного процесса JobTracker в новом подходе вводится менеджер кластера, полностью отвечающий за отслеживание в кластере работоспособных узлов и доступных ресурсов, а также за назначение их задачам. Для каждого задания в кластере запускается отдельный короткоживущий процесс JobTracker для управления выполнением задач только в данном задании. Интересно, что короткоживущие процессы JobTracker запускаются процессами TaskTracker, выполняющимися в ведомых узлах. Таким образом координация жизненного цикла задания распределяется между всеми доступными машинами кластера. Благодаря такому поведению больше заданий выполняется параллельно, а масшабируемость резко возрастает.

YARN – новое поколение вычислительной платформы Hadoop

Теперь немного изменим терминологию. Для лучшего понимания дизайна YARN мы будем использовать следующие термины:

  • ResourceManager (менеджер ресурсов) вместо менеджера кластера
  • ApplicationMaster (мастер приложения) вместо выделенного короткоживущего процесса JobTracker.
  • NodeManager (менеджер узла) вместо процесса TaskTracker.
  • Распределенное приложение вместо задания MapReduce.

YARN – это новое поколение вычислительной платформы Hadoop, показанное ниже.

Архитектура YARN
Архитектура YARN
Архитектура YARN

В архитектуре YARN глобальный ResourceManager работает как master-демон (обычно на выделенной машине), распределяющий ресурсы кластера между конкурирующими приложениями. ResourceManager отслеживает работоспособные узлы и доступные ресурсы в кластере и распределяет их между приложениями, запускаемыми пользователями. Являясь единственным процессом, имеющим эту информацию, ResourceManager принимает решения о распределении с учетом совместного использования, безопасности и множественной аренды (например, согласно приоритету приложения, вместимости очереди, спискам управления доступом, местоположению данных и т.д.).

Когда пользователь отправляет приложение на выполнение, запускается экземпляр нетребовательного к ресурсам процесса ApplicationMaster для координации выполнения всех задач приложения. Сюда входит мониторинг задач, повторный запуск задач после сбоев, упреждающее выполнение медленных задач и вычисление суммарных значений счетчиков приложения. Ранее эти обязанности для всех заданий выполнял один процесс JobTracker. ApplicationMaster и задачи его приложения выполняются в контейнерах ресурсов, управляемых процессами NodeManager.

NodeManager – это более универсальная и эффективная версия процесса TaskTracker. Вместо фиксированного числа слотов map и reduce NodeManager имеет несколько динамически создаваемых контейнеров ресурсов. Размер контейнера зависит от объема содержащихся в нем ресурсов, например памяти, процессора, дисковой памяти и сетевого ввода/вывода. В настоящее время поддерживаются только память и процессор (в YARN-3). В будущем для управления дисковой памятью и сетевым вводом/выводом возможно использование механизма cgroups. Число контейнеров в узле определяют параметры конфигурации и общий объем ресурсов узла (процессоров и памяти) кроме ресурсов, выделяемых для ведомых демонов и операционной системы.

Интересно, что ApplicationMaster может выполнять любой тип задач внутри контейнера. Например, MapReduce ApplicationMaster запрашивает контейнер для запуска задач map или reduce, в то время как Giraph ApplicationMaster запрашивает контейнер для запуска задач Giraph. Можно также разработать специализированный ApplicationMaster для выполнения конкретных задач и тем самым создать новую инфраструктуру распределенных приложений, которая изменит мир больших данных. Я рекомендую вам познакомиться с Apache Twill, упрощающим написание распределенных приложений поверх YARN.

С появлением YARN подход MapReduce превратился просто в распределенное приложение (хотя по-прежнему полезное и очень популярное) и теперь называется MRv2. MRv2 – это просто реализация классического механизма MapReduce (который теперь называется MRv1), выполняющегося поверх YARN.

Один кластер для выполнения любого распределенного приложения

Для ResourceManager, NodeManager и контейнера не важен тип приложения или задачи. Весь специфичный для конкретной инфраструктуры код приложения помещается в его ApplicationMaster, чтобы YARN мог поддерживать любую распределенную инфраструктуру, если кто-то реализует для нее соответствующий ApplicationMaster.

Этот универсальный подход позволяет выполнять в кластере Hadoop YARN самые разные рабочие нагрузки. Представьте себе, что в вашем центре данных есть один кластер Hadoop, который может выполнять MapReduce, Giraph, Storm, Spark, Tez/Impala, MPI и многое другое.

Подход с одним кластером обеспечивает ряд очевидных преимуществ, включая:

  • Более эффективное использование кластера, поскольку ресурсы, не используемые одной инфраструктурой, может использовать другая.
  • Более низкие эксплуатационные расходы, поскольку выполняются управление и настройка только одного кластера.
  • Уменьшение движения данных, поскольку нет необходимости перемещать их между Hadoop YARN и системами, работающими на других кластерах машин.

Управление одним кластером делает обработку данных более экологичной. Поскольку вычисления выполняет более эффективный кластер меньшего размера, используется меньше пространства в центре данных, меньше процессорной мощности и энергии, а также уменьшаются выбросы углекислого газа.

Запуск приложения в YARN

В этом разделе описывается взаимодействие процессов ResourceManager, ApplicationMaster, NodeManager и контейнеров при запуске приложения в кластере YARN. На следующем рисунке показан пример.

Запуск приложения в YARN
Запуск приложения в YARN
Запуск приложения в YARN

Предположим, что пользователи запускают приложения в ResourceManager с помощью команды hadoop jar по аналогии с MRv1. ResourceManager обрабатывает список выполняющихся в кластере приложений и список доступных ресурсов в каждом работоспособном NodeManager. ResourceManager должен определить приложение для получения следующей порции ресурсов кластера. На это решение влияет много ограничений, например вместимость очереди, списки управления доступом и равнодоступность ресурсов. ResourceManager использует подключаемый планировщие (Scheduler). Scheduler занимается только планированием, определяя очередность получения ресурсов кластера (в виде контейнеров), но не выполняет мониторинг задач в приложении и не пытается перезапустить задачи после сбоев.

Когда ResourceManager подтверждает запуск нового приложения, одним из первых решений Scheduler является выбор контейнера, в котором будет выполняться ApplicationMaster. Запущенный ApplicationMaster отвечает за весь жизненный цикл данного приложения. В первую очередь это будет передача в ResourceManager запроса ресурсов в виде контейнеров для выполнения задач приложения. Запрос ресурсов – это просто запрос числа контейнеров, удовлетворяющих следующим требованиям к ресурсам:

  • Объем ресурсов – память в мегабайтах и доля вычислительных ресурсов процессора.
  • Предпочитаемое местоположение – имя хоста (hostname), имя стойки (rackname) или * при отсутствии предпочтений.
  • Приоритет в этом приложении, а не в нескольких приложениях.

Если (и когда) это возможно, ResourceManager предоставляет контейнер (описываемый идентификатором контейнера и именем хоста), который удовлетворяет требованиям, содержащимся в запросе ресурсов. Контейнер позволяет приложению использовать указанный объем ресурсов на конкретном хосте. После предоставления контейнера ApplicationMaster дает команду NodeManager (который управляет хостом, где был размещен контейнер) использовать эти ресурсы для запуска задачи данного приложения. Этой задачей может быть любой процесс, созданный в любой инфраструктуре (например, задача MapReduce или задача Giraph). NodeManager не отслеживает задачи; он лишь выполнят мониторинг использования ресурсов в контейнере, например, для удаления контейнера, потребляющего больше памяти, чем ему было выделено.

ApplicationMaster тратит все свое время на согласование контейнеров для запуска задач приложения. Он также следит за выполнением приложения и его задач, перезапускает задачи после сбоев в созданных контейнерах и предоставляет отчеты о выполнении клиенту, запустившему приложение. После завершения приложения ApplicationMaster выключается и освобождает свой собственный контейнер.

Хотя ResourceManager не выполняет мониторинг задач приложения, он проверяет состояние процессов ApplicationMaster. В случае сбоев ResourceManager может перезапустить ApplicationMaster в новом контейнере. Можно сказать, что ResourceManager заботится об ApplicationMaster, а ApplicationMaster заботится о задачах.

Интересные факты и возможности

YARN предлагает еще несколько замечательных функциональных возможностей. Описание их всех выходит за рамки данной статьи, но некоторые заслуживают особого внимания:

  • Уберизация (uberization) – это возможность выполнять все задачи задания MapReduce в виртуальной машине процесса ApplicationMaster, если это достаточно небольшое задание. Она позволяет избежать накладных расходов на запросы контейнеров из ResourceManager и команды процессам NodeManager на запуск небольших задач.
  • Двоичная совместимость или совместимость на уровне исходных кодов заданий MapReduce, написанных для MRv1 (MAPREDUCE-5108).
  • Высокая готовность ResourceManager (YARN-149). Эта работа продолжается и уже выполнена некоторыми поставщиками.
  • Восстановление приложения после перезапуска ResourceManager (YARN-128). ResourceManager хранит информацию о выполняющихся приложениях и завершенных задачах в HDFS. После перезапуска ResourceManager воссоздает состояние приложений и выполняет только незавершенные задачи. Эта работа близка к завершению и активно тестируется сообществом. Она уже выполнена некоторыми поставщиками.
  • Упрощенные управление и доступ к журналам пользователей. Журналы, генерируемые приложениями, не остаются на отдельных ведомых узлах (как в MRv1), а перемещаются в центральное хранилище, например в HDFS. Затем их можно использовать при отладке или ретроспективном анализе для выявления проблем производительности.
  • Новый внешний вид Web-интерфейса.

Заключение

YARN – это абсолютно новая архитектура кластера Hadoop. Похоже, она изменит способ реализации и выполнения распределенных приложений в кластере стандартных машин.

YARN предлагает очевидные преимущества в масштабируемости, эффективности и гибкости по сравнению с классическим механизмом MapReduce в первой версии Hadoop. Выигрыш от использования YARN получают как маленькие, так и большие кластеры. Для конечного пользователя (разработчика, а не администратора) эти изменения почти незаметны, поскольку новый механизм позволяет выполнять немодифицированные задания MapReduce, используя те же саме программные интерфейсы MapReduce и интерфейсы CLI.

Для миграции с MRv1 на YARN нет никаких препятствий. Крупнейшие поставщики Hadoop благосклонно относятся к YARN и предлагают всестороннюю поддержку Hadoop YARN. Сегодня YARN успешно используется в производственной среде многими компаниями, такими как Yahoo!, Spotify, eBay, Xing, Allegro и многие другие.

Благодарности

Автор благодарит Петра Кревски (Piotr Krewski) и Фабиана Алениуса (Fabian Alenius) за техническое рецензирование статьи.


Ресурсы для скачивания


Похожие темы


Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=989020
ArticleTitle=Введение в YARN
publish-date=11112014