Содержание


Использование Hadoop YARN

Введение в Yet Another Resource Negotiator

Comments

Инфраструктура Apache Hadoop с MapReduce является рабочей лошадкой распределенной обработки данных. Благодаря уникальной архитектуре масштабируемого физического кластера и элегантной инфраструктуре обработки, первоначально разработанной Google, Hadoop способствовала взрывному росту в новой области обработки больших данных. Hadoop также создала богатую и разнообразную экосистему приложений, включая Apache Pig (мощный язык сценариев) и Apache Hive (хранилище данных с SQL-подобным интерфейсом).

К сожалению, эта экосистема построена на парадигме программирования, которая не способна решить все проблемы больших данных. Хотя инструменты Pig и Hive упрощают специфичную модель программирования, которую предоставляет MapReduce, она не является панацеей для больших данных. Начнем наше знакомство с MapReduce 2.0 (MRv2), которую еще называют Yet Another Resource Negotiator (YARN), с краткого обзора ее предшественницы.

Краткое введение в Hadoop и MRv1

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

Простая иллюстрация архитектуры кластера Hadoop
Простая иллюстрация архитектуры кластера Hadoop
Простая иллюстрация архитектуры кластера Hadoop

Кластер Hadoop можно разделить на два абстрактных объекта: механизм MapReduce и распределенная файловая система. Механизм MapReduce обеспечивает выполнение задач map (отображение) и reduce (сокращение) в рамках кластера и возврат результатов. При этом распределенная файловая система предоставляет схему хранения, позволяющую реплицировать данные между узлами. Распределенная файловая система Hadoop (HDFS) поддерживает большие файлы (как правило, кратные 64 МБ).

Запросом клиента к кластеру Hadoop управляет JobTracker. JobTracker, взаимодействуя с NameNode, распределяет задание как можно ближе к данным, с которыми оно будет работать. NameNode является главным узлом файловой системы и обеспечивает сервисы метаданных для распределения и репликации данных. JobTracker распределяет задачи map и reduce в доступные слоты в одном или нескольких TaskTrackers. TaskTracker выполняет задачи map и reduce с данными DataNode (подчиненные узлы распределенной файловой системы). После завершения задач map и reduce TaskTracker уведомляет об этом JobTracker, который определяет завершение всех задач и сообщает об этом клиенту.

InfoSphere BigInsights Quick Start Edition

InfoSphere BigInsights Quick Start Edition представляет собой бесплатную загружаемую версию Hadoop-платформы IBM InfoSphere BigInsights. Quick Start Edition позволяет опробовать возможности, созданные IBM в развитие проекта с открытым исходным кодом Hadoop, такие как Big SQL, анализ текста и BigSheets. Управляемое обучение с помощью пошаговых руководств и видеоматериалов для самостоятельного изучения поможет приступить к работе с Hadoop. Вы сможете в свое свободное время экспериментировать с большими данными без ограничений по времени и объему. Смотрите видеоматериалы, изучайте руководства (в формате PDF), а также загружайте BigInsights Quick Start Edition.

Как показано на рисунке 1, в MRv1 реализован относительно простой менеджер кластеров для MapReduce-обработки. MRv1 реализует иерархическую схему управления кластером, в которой задания больших данных отфильтровываются в кластер как отдельные задачи map и reduce, а затем собираются обратно в задание для отображения пользователю. Но в этой простоте скрываются явные и неявные проблемы.

Недостатки MRv1

У первой версии MapReduce были как сильные, так и слабые стороны. Сегодня MRv1 является стандартом системы обработки больших данных. Тем не менее эта архитектура имеет недостатки, которые в основном проявляются в больших кластерах. Если число узлов в кластере превышает 4000 (каждый узел может быть многоядерным), возникает некоторая непредсказуемость. Одна из самых больших проблем – каскадные сбои, когда точечный сбой приводит к серьезному повреждению всего кластера из-за попыток репликации данных и перегрузки работоспособных узлов (вследствие "затопления" сети сообщениями).

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

Теперь посмотрим, как новая архитектура YARN поддерживает MRv2 и другие приложения, используя различные модели обработки.

Введение в YARN (MRv2)

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

Напомним, что подход с использованием JobTracker и TaskTracker был главным недостатком MRv1 из-за ограничений масштабирования и наличия режимов отказов, вызванных сетевыми издержками. Эти демоны были также характерны для модели обработки MapReduce. С целью ликвидировать эту зависимость JobTracker и TaskTracker были удалены из YARN и заменены новым набором демонов, не привязанных к приложениям.

Новая архитектура YARN
Новая архитектура YARN
Новая архитектура YARN

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

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

NodeManager управляет всеми узлами в кластере YARN. NodeManager предоставляет сервисы на каждом узле кластера, начиная с контроля управления контейнером в течение его жизненного цикла и заканчивая мониторингом ресурсов и отслеживанием состояния узла. В отличие от MRv1, управлявшей задачами map и reduce через слоты, NodeManager управляет абстрактными контейнерами, которые представляют собой ресурсы на узле, доступные для конкретного приложения. YARN по-прежнему использует слой HDFS с главными узлами NameNode для сервисов метаданных и DataNode для сервисов хранения, реплицированных по всему кластеру.

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

Из всего вышесказанного становится ясно, что прежнюю архитектуру Hadoop сильно ограничивал JobTracker, отвечавший за управление ресурсами и планирование заданий в кластере. Новая архитектура YARN отказывается от этой модели; теперь за управление использованием ресурсов приложениями отвечает ResourceManager, а за управление выполнением заданий – ApplicationMasters. Это изменение устраняет узкое место, а также повышает возможность масштабирования кластеров Hadoop до гораздо более крупных конфигураций, чем прежде. Кроме того, помимо традиционной MapReduce, YARN позволяет одновременно применять различные модели программирования, в том числе обработку графов, итерационную обработку, машинное обучение и кластерные вычисления, используя стандартные схемы передачи информации, такие как Message Passing Interface.

Что следует знать

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

Для иллюстрации эффективности YARN в сравнении с MRv1 рассмотрим параллельную задачу расшифровки путем полного перебора хеша LAN Manager, который раньше использовался в Windows® для хеширования паролей. В этом случае методика MapReduce не имеет смысла из-за слишком высоких издержек на этапах отображения/сокращения. Более логичным является распределение нагрузки, при котором каждый контейнер получает часть области поиска, выполняет перебор и сообщает о нахождении правильного пароля. Идея в том, чтобы определять пароль динамически с помощью функции (побитовой обработки) вместо отображения всех возможных вариантов в структуру данных, которое делает стиль MapReduce избыточным и громоздким.

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

Разработка YARN-приложений

Мощь YARN и новые возможности создания специализированных интегрированных сред поверх Hadoop несут в себе и новые сложности. Создание приложений для YARN значительно сложнее, чем создание традиционных MapReduce приложений поверх Hadoop (до появления YARN), потому что необходимо разработать ApplicationMaster, запускаемый демоном ResourceManager при поступлении запроса от клиента. ApplicationMaster требует реализации ряда протоколов для связи с ResourceManager (запрос ресурсов) и NodeManager (выделение контейнеров). Для тех, кто уже пользуется MapReduce, переход на ApplicationMaster требует лишь минимальной доработки, так что на развертывание заданий MapReduce затрачивается примерно столько же усилий, сколько в Hadoop до появления YARN.

Жизненные циклы приложений в YARN и MRv1 во многом похожи. YARN выделяет ресурсы в кластере, выполняет обработку, предоставляет точки взаимодействия для мониторинга процесса выполнения приложения и, наконец, освобождает ресурсы и делает генеральную уборку после завершения приложения. Шаблон этого жизненного цикла предоставляет проект под названием Kitten (см. раздел Ресурсы). Kitten представляет собой набор инструментов и код, которые упрощают разработку приложений в YARN, позволяя сосредоточиться на логике приложения и с самого начала игнорировать детали выделения ресурсов и выполнения с помощью ограничений различных объектов кластера. Также Kitten предоставляет набор сервисов для обработки взаимодействий с другими объектами кластера (например, ResourceManager). С Kitten поставляется в качестве примера вполне работоспособный вариант ApplicationMaster. В качестве сервиса настройки Kitten использует сценарий на языке Lua.

Двигаясь дальше

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


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


Похожие темы

  • Оригинал статьи: Moving ahead with Hadoop YARN (EN).
  • Для получения последних новостей о Hadoop и других элементах его экосистемы посетите сайт проекта Apache Hadoop. Вы познакомитесь с Hadoop, а также с направлениями его развития (новыми технологиями, такими как YARN) и совершенствования (новыми технологиями, такими как Pig, Hive и многие другие).
  • Хотя инфраструктура YARN еще только разрабатывается, вы можете узнать о ранних подходах к программированию приложений с использованием модели YARN. Полезным ресурсом является Writing YARN Applications. На этом ресурсе рассматриваются некоторые новые проблемы, связанные с YARN, и обсуждаются различные протоколы связи между объектами YARN.
  • Используйте распространяемый Apache исходный код Distributed Shell Source.
  • Дополнительная информация о бесплатных курсах Big Data University по разным темам, начиная с основ Hadoop и базовых элементов анализа текста и заканчивая SQL доступом для Hadoop и потоковыми вычислениями в режиме реального времени.
  • Статья об MRv2 в Apache Hadoop 0.23 является хорошим введением в технические детали кластера YARN (EN).
  • Статья Kitten для разработчиков, которым нравится возиться с YARN является полезным введением в абстракцию Kitten для разработки YARN-приложений (EN).
  • Ресурсы, которые помогут приступить к работе с InfoSphere BigInsights, платформой IBM, расширяющей проект с открытым исходным кодом Hadoop такими возможностями, как Big SQL, анализ текста и BigSheets.
  • Загрузите ПО InfoSphere BigInsights Quick Start Edition в виде дистрибутива или образа VMware.
  • Ресурсы, которые помогут приступить к работе с InfoSphere Streams, созданной IBM высокопроизводительной вычислительной платформой, позволяющей пользовательским приложениям быстро поглощать, анализировать и сопоставлять информацию, поступающую из тысяч источников в режиме реального времени.
  • Загрузите ПО InfoSphere Streams в виде установочной копии или образа VMware.
  • Используйте InfoSphere в IBM SmartCloud Enterprise.

Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=958829
ArticleTitle=Использование Hadoop YARN
publish-date=12302013