Описание тега hadoop-yarn

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

Инфраструктура Apache Hadoop MapReduce достигла предела масштабируемости около 4000 машин. Мы разрабатываем следующее поколение Apache Hadoop MapReduce, которое превращает инфраструктуру в общий планировщик ресурсов и определяемый пользователем компонент для каждого задания, управляющий выполнением приложения. Поскольку время простоя обходится дороже при масштабировании, высокая доступность заложена с самого начала; а также безопасность и мультиарендность для поддержки многих пользователей в больших кластерах. Новая архитектура также увеличит инновации, гибкость и использование оборудования.

Фон

Текущая реализация платформы Hadoop MapReduce уже устарела.

Учитывая наблюдаемые тенденции в размерах кластеров и рабочих нагрузках, MapReduce JobTracker нуждается в радикальной переработке для устранения ряда недостатков в его масштабируемости, потреблении памяти, модели многопоточности, надежности и производительности. За последние 5 лет были точечные исправления, однако в последнее время они стоили постоянно растущей стоимости, о чем свидетельствует возрастающая сложность внесения изменений в фреймворк. Недостатки архитектуры и меры по исправлению устарели и хорошо известны — еще в конце 2007 года, когда мы задокументировали предлагаемое исправление в jira MapReduce: MAPREDUCE-278.

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

Новое поколение MapReduce

                                Figure:  Yarn Architecture

Фундаментальная идея реархитектуры состоит в том, чтобы разделить две основные функции JobTracker, управление ресурсами и планирование/мониторинг заданий, на отдельные компоненты. Новый ResourceManager управляет глобальным назначением вычислительных ресурсов приложениям, а ApplicationMaster для каждого приложения управляет планированием и координацией приложения. Приложение — это либо одно задание в классических заданиях MapReduce, либо группа DAG таких заданий. ResourceManager и сервер NodeManager для каждой машины, который управляет пользовательскими процессами на этой машине, образуют структуру вычислений. ApplicationMaster для каждого приложения, по сути, представляет собой библиотеку, специфичную для платформы, и ему поручено согласовывать ресурсы с ResourceManager и работать с NodeManager(ами) для выполнения и мониторинга задач.

ResourceManager поддерживает иерархические очереди приложений, и этим очередям может быть гарантирован процент ресурсов кластера. Это чистый планировщик в том смысле, что он не выполняет мониторинг или отслеживание состояния приложения. Кроме того, он не дает никаких гарантий при перезапуске неудачных задач из-за сбоя приложения или сбоя оборудования.

ResourceManager выполняет свою функцию планирования на основе требований приложений к ресурсам; каждое приложение имеет несколько типов запросов ресурсов, которые представляют ресурсы, необходимые для контейнеров. Запросы ресурсов включают память, ЦП, диск, сеть и т. д. Обратите внимание, что это существенное отличие от текущей модели слотов фиксированного типа в Hadoop MapReduce, что приводит к значительному негативному влиянию на использование кластера. ResourceManager имеет подключаемый модуль политики планировщика, который отвечает за разделение ресурсов кластера между различными очередями, приложениями и т. д. Подключаемые модули планировщика могут быть основаны, например, на текущих CapacityScheduler и FairScheduler.

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

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

MRV2 поддерживает совместимость API с предыдущей стабильной версией (hadoop-1.x). Это означает, что все задания Map-Reduce должны по-прежнему выполняться без изменений поверх MRv2 только после перекомпиляции.