четверг, 12 июля 2012 г.

Map Reduce 2.0 или Eще Один Переговорщик

В конце 2011 года apache выпустил новый релиз hadoop под номером 0.23. По сравнению с известием о выходе первой стабильной версии hadoop 1.0.0, это событие оказалось не таким заметным. Однако новая версия хадупа имеет ряд очень важных улучшений, такие как
  •  высокодоступная нейм нода (High Available NameNode)
  •  федерация нейм нод
  •  новая версия MapReduce, названная YARN или MapReduce 2.0
Идея изменить архитектуру вычислений на MapReduce кластере созревала давно. Разработчикам hadoop не нравилось, что job tracker является единой точкой отказа, узким местом в производительности больших кластеров, а вычислительные мощности расходуются неоптимальным образом. Поэтому в 2010 году в Yahoo начал разрабатываться проект новой системы кластерных вычислений, результатом которой стал YARN.
О стабильности и надежности нового релиза можно судить по тому, что на
его основе cloudera уже сделала новую сборку своего дистрибутива - cdh4.

Что же такое YARN?

YARN - это сокращение от "Yet Another Resource Negotiator" - "еще один переговорщик о ресурсах", или, для любителей рекурсии, "YARN Application Resource Negotiator" - "посредник ресурсов YARN приложений".

Суть нововведения можно понять, сравнив архитектуру старой и новой версии.
Классическая архитектура map-reduce на хадуп кластере состоит из одного jobTracker'a, который раздает задачи и кучи taskTracker'ов, которые эти задачи выполняют. JobTracker выделяет необходимые для задачи ресурсы, запускает ее на выделенных слотах для мепов и редьюсов, сообщает пользователю о ходе выполнения. размера кластера

В архитектуре YARN функции Job Tracker'a решено было разделить между сущностями Resource Manager и Application Master.
 
Resource Manager, так же как и JobTracker это тоже отдельный демон, который крутится на выделенном сервере и контролирует, сколько свободных ресурсов есть в системе, выдает их приложениям и берет назад после завершения работы приложений. Все рабочие машины владеют некоторым количеством "Контейнеров" (Container, на рисунке обозначен как Cont).
У контейнеров есть свои параметры, которые можно настроить при запрашивании. Сейчас это только размер используемой оперативной памяти, но к ней может добавиться и процессорное время и ширина канала.
Контейнеры на каждом из узлов контролируются демоном Node Manager.
При запуске нового приложения на кластере Resource Manager выделяет один контейнер, в котором запускается Application Master (на картинке обозначен как AM). Этот самый Application Master и является главным процессом распределенного приложения, который запрашивает себе еще ресурсов и контролирует все выполнение на кластере. За ресурсами Application Master обращается к Resource Manager.

Новая  архитектура стала ближе к Google MapReduce, который гуглоиды описали в своей статье.

Чего удалось добиться в Ярне.


Во-первых, задачи по координации и выполнению отдельных задач переносятся с единого JobTracker'а на ноды кластера. Таким образом в большом кластере с большим количеством задач JobTracker перестает быть узким местом. Новая архитектура позволяет создавать кластера размером до 10 000 машин, тогда как классический map-reduce не поддерживал кластеры больше чем из 4000 серверов.

Слоты для мапа и редьюса в новой архитектуре заменились на универсальные контейнеры. Это позволяет лучше использовать ресурсы кластера, создавая когда нужно больше map или reduce задач. Маленькие задачи вообще могут запускаться в том же контейнере, что и Application Manager.

Новая архитектура повышает отказоустойчивость кластера. Если Application Master падает или становится недоступным, Resource Manager может создать еще один контейнер и перезапустить Aplication Master в нем. Сам Resource Manger в процессе своей работы делает снапшоты состояний, по которым, в случае падения его можно запустить еще раз и текущего состояния. Сейчас снапшоты сохраняются на диск. В будущем планируется хранить снапшоты в zookeeper и сделать Resource Manager высоко доступным.

Можно заметить, что в новой архитектуре исчезли  все упоминания о мапперах, редьюсерах и вообще map-reduce. Схема стала универсальной, а MapReduce была вынесена и превратилась в одну из библиотек, которую можно запускать на кластере.
На выделяемых контейнерах кластера можно также запускать  MPI задачи, распределенные shell команды. Полный список того, какие типы
распределенных приложений поддерживает YARN можно увидеть на сайте Апача.

Поэксперементировать с YARN можно на локальной машине, установив его в псевдораспределенном режиме. Дистрибутив и подробные инструкции по установке можно найти на сайте cloudera.

YARN обеспечивает полную поддержку ранее написанного map-reduce кода, правда для запуска его под YARN требуется просто пересобрать код. При этом и старое и новое hadoop API поддерживаются. Пример с подсчетом количества кликов пользователей, который разбирался в своем прошлом посте, стал нормально собираться и работать, после того как я изменил список необходимых hadoop библиотек в файле сборки.

Распределенные приложения для YARN можно писать и самому (это могут быть, например, системы типа master-workers или что-то подобное). Апач в своей вики выложил подробную инструкцию как это делать.

2 комментария:

  1. Глупый вопрос: а если упадёт Resource Manager? Понятно, что новая схема является более производительной, но вот насчёт более надёжной...как я понял (может быть, и неправильно), корректное функционирование системы всё ещё зависит от одного её элемента.
    P.S. И как расшифровать фразу "планируется сделать высокодоступным"?

    ОтветитьУдалить
    Ответы
    1. Как я понимаю, надежность кластера повышается засчет того, что управление выполнением задачи вынесено в отделное приложение.
      Если это приложение упадет из-за программной ошибки, то resource manager останется в целости и сохранности и перезапустит его.

      По resource manager как единой точки отказа - yahoo написал про yarn в своем блоге:
      (http://developer.yahoo.com/blogs/hadoop/posts/2011/02/mapreduce-nextgen)

      Availability: ResourceManager - The ResourceManager uses Apache ZooKeeper for fail-over. When the ResourceManager fails, a secondary can quickly recover via cluster state saved in ZooKeeper. The ResourceManager, on a fail-over, restarts all of the queued and running applications.

      То есть в кластере можно предусмотреть вспомогательный Resource Manager и в случае падения переключить работу на него.

      При подготовке статьи я больше опирался на "Hadoop The Definitive Guide 3rd edition" (выпущена в мае 2012), в которой сказано, что хранение состояния Resource Manager в Zookeeper еще на стадии разработки, и надежное восстановление после сбоя Resource Manager ожидается в недалеком будущем.

      Удалить