Если ты ИТшник, то нельзя просто так взять и выйти на работу 2-го января: пересмотреть 3-ий сезон битвы экстрасенсов или запись программы «Гордон» на НТВ (дело умственных способностей вкуса).
Нельзя потому, что у других сотрудников обязательно будут для тебя подарки: у секретарши закончился кофе, у МП — закончились дедлайны, а у администратора баз данных — амнезия память.
Оказалось, что инженеры из команды Hadoop тоже любят побаловать друг друга новогодними сюрпризами.

2008

2 января. Упуская подробное описание эмоционально-психологического состояния лиц, участвующих в описанных ниже событиях, сразу перейду к факту: поставлен таск MAPREDUCE-279 ^[1] «Map-Reduce 2.0». Оставив шутки про число, обращу внимание, что до 1-ой стабильной версии Hadoop остается чуть менее 4 лет.

За это время проект Hadoop пройдет эволюцию из маленького инновационного снежка, запущенного в 2005, в большой снежный com ком, надвигающийся на ИТ, в 2012.
Ниже мы предпримем попытку разобраться, какое же значение январский таск MAPREDUCE-279 играл (и, уверен, еще сыграет в 2013) в эволюции платформы Hadoop.

2011

В феврале 2011 года инженеры Yahoo порадовали мир статьей «The Next Generation of Apache Hadoop MapReduce» [2]. В октябре 2011 года Apache Software Foundation опубликовало в своей wiki-труд под названием «Apache Hadoop NextGen MapReduce (YARN)» [1]. 27 декабря на сайте Apache Software Foundation мир увидел надпись:

…release 1.0.0 available. After six years of gestation, Hadoop reaches 1.0.0!

и ссылку стабильную версию Hadoop v1.0.

2012

Hadoop 2.0.0-alpha стал доступен для скачивания в конце мая. В мае же в печать вышла книга «Hadoop: The Definitive Guide, Third Edition» (автор Tom White), где довольно значительный объем отводится YARN. В начале июня Tom White выступил с презентацией «MapReduce 2.0» (видео ^[2]) на Chicago Hadoop User Group. В это же месяце Cloudera с анонсировала поддержку Hadoop 2.0.0 Alpha в своем продукте CDH4. Немногим позже о поддержке Hadoop 2.0 в своих дистрибутивах заявила и компания Hortonworks.

17 сентября на сайте Apache Software Foundation было опубликовано, что YARN and MapReduce v2 доступны в Hadoop 0.23.3.

Ниже будут рассмотрены походы к распределенным вычислениям в классическом Hadoop MapReduce и новой архитектуре, описаны приемы и компоненты, реализующие концепции новой модели, а также проведено сравнение классической и 2.0 архитектур.

1. Hadoop MapReduce Classic

Hadoop – популярная программная платформа (software framework) построения распределенных приложений для массово-параллельной обработки (massive parallel processing, MPP) данных.

Hadoop включает в себе следующие компоненты:

• HDFS – распределенная файловая система;
• Hadoop MapReduce – программная модель (framework) выполнения распределенных вычислений для больших объемов данных в рамках парадигмы map/reduce.

Концепции, заложенные в архитектуру Hadoop MapReduce ^[3] и структуру HDFS ^[4], стали причиной ряда узких мест в самих компонентах, в том числе и единичные точки отказа. Что, в конечном итоге, определило ограничения платформы Hadoop в целом.

К последним можно отнести:

• Ограничение масштабируемости кластера Hadoop: ~4K вычислительных узлов; ~40K параллельных заданий;
• Сильная связанность фреймворка распределенных вычислений и клиентских библиотек, реализующих распределенный алгоритм. Как следствие:
  • Отсутствие поддержки альтернативной программной модели выполнения распределенных вычислений: в Hadoop v1.0 поддерживается только модель вычислений map/reduce.
• Наличие единичных точек отказа и, как следствие, невозможность использования в средах с высокими требованиями к надежности;
• Проблемы версионной совместимости: требование по единовременному обновлению всех вычислительных узлов кластера при обновлении платформы Hadoop (установке новой версии или пакета обновлений);
• Отсутствие поддержки работы с обновляемыми/потоковыми данными.

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

2. Hadoop MapReduce Next

Основные изменения коснулись компонента выполнения распределенных вычислений Hadoop MapReduce.

Классический Hadoop MapReduce представлял собой один процесс JobTracker и произвольное количество процессов TaskTracker.

В новой архитектуре Hadoop MapReduce функции JobTracker по управлению ресурсами и планированию/координации жизненного цикла выполнения заданий были разделены на 2 отдельных компонента:

• менеджер ресурсов ResourceManager;
• планировщик и координатор приложения ApplicationMaster.

Рассмотрим каждый компонент подробнее.

ResourceManager

ResourceManager (RM) – глобальный менеджер ресурсов, чьей задачей является распределение ресурсов, затребованных приложениями и наблюдение за вычислительными узлами, на которых эти приложения выполняются.

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

• Scheduler – планировщик, ответственный за распределение ресурсов между затребовавшими ресурсы приложениями.
  Scheduler является «чистым» планировщиков: он не ведет мониторинга и не отслеживает статус приложений.
• ApplicationsManager (AsM) – компонент, ответственный за запуск экземпляров ApplicationMaster, а также мониторингов узлов (контейнеров), на которых происходит выполнение, и перезапуск «мертвых» узлов.

Стоит отметить, что Scheduler в ResourceManager является сменным компонентом (pluggable). Всего имеются 3 типа Scheduler: FIFO scheduler (по умолчанию), Capacity scheduler и Fair scheduler. В версии Hadoop 0.23 первые 2 типа планировщиков поддерживаются, 3-ий — нет.

Ресурсы у RM запрашиваются для абстрактного понятия Container, о котором речь еще пойдет и которому можно задать такие параметры как требуемое процессорное время, объем оперативной памяти, необходимая пропускная способность сети. На декабрь 2012 года поддерживается только параметр «объем RAM».

Введение RM позволяет относиться к узлам кластера как к вычислительным ресурсам, что качественно повышает утилизацию ресурсов кластера.

ApplicationMaster

ApplicationMaster (AM) – компонент, ответственный за планирование жизненного цикла, координацию и отслеживание статуса выполнения распределенного приложения. Каждое приложение имеет свой экземпляр ApplicationMaster.

На этом уровне как раз стоит рассмотреть YARN.

YARN (Yet Another Resource Negotiator) – это программный фреймворк выполнения распределенных приложений (каким экземпляр ApplicationMaster и является). YARN предоставляет компоненты и API, необходимые для разработки распределенных приложений различных типов. Сам фреймворк берет на себя ответственность по распределению ресурсов в ответ на запросы ресурсов от выполняемых приложений и ответственность за отслеживанием статуса выполнения приложений.

Модель YARN более общая (generic), чем модель, реализованная в классическом Hadoop MapReduce.

Благодаря YARN на Hadoop-кластере возможно запускать не только «map/reduce»-приложения, но и распределенные приложения, созданные с использованием: Open MPI, Spark, Apache HAMA, Apache Giraph, etc. Есть возможность реализовать и другие распределенные алгоритмы (вот она сила ООП!). Подробные инструкции ^[5] описаны в Apache Wiki.

В свою очередь, MapReduce 2.0 (или MR2, или MRv2) – это фреймворк выполнения распределенных вычислений в рамках программной модели map/reduce, «лежащий» над уровнем YARN.

Разделение ответственности по управлению ресурсами и планированию/координации жизненного цикла приложения между компонентами ResourceManager и ApplicationMaster придали платформе Hadoop более распределенный характер. Что, в свою очередь, положительно сказалось на масштабируемости платформы.

NodeManager

NodeManager (NM) – агент, запущенный на вычислительном узле, в чьи обязанности входит:

• отслеживание используемых вычислительных ресурсов (CPU, RAM, network, etc.);
• отправка отчетов по используемым ресурсам планировщику менеджера ресурсов ResourceManager/Scheduler.

Протоколы взаимодействия

Управляющие команды и передача статусов различным компонентов платформы Hadoop проходят посредством следующих протоколов:

• ClientRMProtocol – протокол взаимодействия клиента с ResourceManager для запуска, проверки статуса и закрытия приложений.
  
• AMRMProtocol — протокол взаимодействия экземпляров ApplicationMaster с ResourceManager для подписки/отписки AM, отправки запроса и получения ресурсов от RM.
  
• ContainerManager — протокол взаимодействия ApplicationMaster с NodeManager для запуска/остановки и получения статуса контейнеров, находящихся под управлением NM.
  

3. Hadoop MapReduce. Vis-à-vis

В части 1 «Hadoop MapReduce Classic» было дано введение в платформу Hadoop и описаны основные ограничения платформы. В части 2 «Hadoop MapReduce Next» были описаны концепции и компоненты, введенные в новую версию фреймворка распределенных вычислений Hadoop MapReduce.

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

— О терминологии
Так как далее речь будет идти о сравнении классической и «2.0» версий Hadoop MapReduce, то во избежание:

• неоднозначностей, связанных с обсуждаемой версией, и/или
• бесконечных уточнений версии, о которой идет речь,

буду далее придерживаться следующей условной терминологии:

• Hadoop MapReduce 1.0 – «классический» plain (если не оговорено иное) Hadoop MapReduce;
• Hadoop MapReduce 2.0 – это YARN и MapReduce v2.0.

—

Архитектура

В Hadoop MapReduce 1.0 кластер имеет единственный узел JobTracker, который занимается распределением задач по многочисленным узлам TaskTracker, непосредственно выполняющим задачи.

В новой архитектуре Hadoop MapReduce ответственность по управлению ресурсами и планированию/координации за жизненным циклом выполнения приложений разделены между ResourceManager (per-cluster) и ApplicationMaster (per-application), соответственно.

Каждый вычислительный узел разделен на произвольное количество контейнеров Container, содержащих предопределенное количество ресурсов: CPU, RAM и т.д. Наблюдение за контейнерами ведет NodeManager (per-node).

Ниже представлена иллюстрация взаимодействия отдельных компонент Hadoop MapReduce в классическом варианте архитектуры

и YARN-подобной архитектуру (новые типы коммуникаций между компонентами выделены жирным).

Далее рассмотрим, как новая архитектура Hadoop MapReduce повлияла на такие аспекты платформы как доступность, масштабируемость, утилизация ресурсов.

Доступность

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

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

Для ResourceManager сохранением состояния занимается Apache ZooKeeper. И при сбое менеджера ресурсов, создается новый процесс RM с состоянием, которое было до сбоя. Таким образом, последствия от сбоя RM сводятся к тому, что перезапустятся все запланированные и запущенные приложения.

Для ApplicationMaster используется собственный механизм checkpoint’ов. В процессе работы AM сохраняет свое состояние в HDFS. Если AM становится недоступным, то RM перезапускает его с состоянием из snapshot’а.

Масштабируемость

Разработчики, работающие с Hadoop MapReduce 1.0, неоднократно указывали, что предел масштабируемости Hadoop-кластера лежит в районе 4K машин. Основная причина этого ограничения — узел JobTracker довольно значительное количество своих ресурсов тратит на задачи, связанные с жизненным циклом приложения. Последние можно отнести к задачам специфическим для конкретного приложения, а не для кластера в целом.

Разделение ответственности за задачи, относящиеся к разным уровням, между ResourceManager и ApplicationMaster стало, пожалуй, главным ноухау Hadoop MapReduce 2.0.

Планируется, что Hadoop MapReduce 2.0 может работать на кластерах до 10K+ вычислительных узлов, что является существенным прогрессом, в сравнении с классической версией Hadoop MapReduce.

Утилизация ресурсов

Невысокая утилизация ресурсов вследствие жесткого деления ресурсов кластера на map- и reduce-слоты нередко также является объектом критики классического Hadoop MapReduce. На смену концепции слотов в MapReduce 1.0 пришла концепция универсальных контейнеров – набора взаимозаменяемых изолированных ресурсов.

Введения понятия «Container» в Hadoop MapReduce 2.0, по сути, добавил платформе Hadoop еще одно свойство – мультитенантность. Отношение к узлам кластера как к вычислительным ресурсам позволит избавиться от негативного влияния слотов на утилизацию ресурсов.

Связанность

Одной из архитектурных проблем Hadoop MapReduce 1.0 было сильная связанность 2-ух, по сути, не взаимозависимых систем: фреймворка распределенных вычислений и клиентских библиотек, реализующих распределенный алгоритм.

Это связанность стала причиной невозможности запуска на Hadoop-кластере MPI или других, альтернативных map/reduce, распределенных алгоритмов.

В новой архитектуре был выделен фреймворк распределенных вычислений YARN и фреймворк вычислений в рамках программной модели map/reduce, базирующийся на основе YARN – MR2.

MR2 является application-specific фреймворком, представленным ApplicationMaster, в то время как YARN «представлен» компонентами ResourceManager и NodeManager и полностью независим от специфики распределенного алгоритма.

За кадром

Целостной картины не будет, если не упомянуть 2 аспекта:
1. В статье рассматривался только фреймворк распределенных вычислений.
За рамками статьи остались изменения, коснувшиеся хранилища данных. Наиболее заметные из них — высокая доступность узла имен HDFS и федерации узлов имен HDFS.
2. Описанное выше будет реализовано только в Hadoop v2.0 (на время написания статьи доступен alfa-версия). Так YARN и MR2 доступны уже в Hadoop v0.23, но без поддержки высокой доступности NameNode.

Отдельно отмечу, что на июньской конференции Chicago HUG 2012, о которой я упомянул во введении, Tom White говорил, что в Hadoop 2.0 Alpha еще есть работы, связанные и с производительность, и с безопасностью, и с ResourceManager.

Заключение

Проект Hadoop в 2010 приятно удивлял идеями, в 2011 – скоростью распространения, в 2012 поразил масштабом изменений.

Не буду тратить Ваше время на «традиционное» краткое изложение того, что изменили YARN и MR2 в платформе Hadoop. Это без сомнения качественный скачок платформы.

Сейчас Hadoop выглядит как дефакто отраслевой стандарт в задачах, связанных с Big Data. Будущий релиз версии 2.0 даст разработчикам открытый, отказоустойчивый, великолепно масштабируемый, расширяемый инструмент массово-параллельной обработки, не «зацикленный» исключительно на программной модели map/reduce.

Звучит невероятно. Еще невероятнее, что это совсем недалекая реальность. Остается только один ньанс — быть этой реальности готовым.

Список источников

[1] Apache Hadoop NextGen MapReduce (YARN) ^[6]. Apache Software Foundation, 2011.
[2] Arun C Murthy. The Next Generation of Apache Hadoop MapReduce ^[7]. Yahoo, 2011.
[3] Ahmed Radwan. MapReduce 2.0 in Hadoop 0.23 ^[8]. Cloudera, 2012.
[4] Tom White. Hadoop: The Definitive Guide, 3rd Edition. O'Reilly Media / Yahoo Press, 2012.
[5] Apache Hadoop Main 2.0.2-alpha API ^[9]. Apache Software Foundation, 2012.

Постскриптум и прочие переживания автора

* Cloudera позволяет скачать дистрибутив CDH4 (с поддержкой YARN) для запуска на локальной машине в псевдораспределенном режиме. Дистрибутив и инструкции ^[10].

Автор: codezombie

Источник ^[11]