Путем сравнения архитектуры Hadoop 1.0 и 2.0 показана роль YARN как планировщика и менеджера ресурсов.
1. Фон, сгенерированный YARN
YARN произошел от MRv1 и преодолевает различные ограничения MRv1. Прежде чем официально представить YARN, нам нужно понять некоторые ограничения MRv1, которые можно обобщить в следующих аспектах:
- Плохая масштабируемость: в MRv1 JobTracker имеет как функции управления ресурсами, так и функции управления заданиями, что стало одним из самых узких мест системы и серьезно ограничивает масштабируемость кластеров Hadoop.
- Низкая надежность: структура ведущий/подчиненный, принятая в MRv1, гдеГлавный узел имеет единую точку отказа, после сбоя весь кластер становится недоступным.
- Низкое использование ресурсов: MRv1 использует модель распределения ресурсов на основе слотов. Слот представляет собой крупнозернистую единицу разделения ресурсов. Обычно задача не использует ресурсы, соответствующие слоту, и другие задачи не могут использовать эти свободные ресурсы. Кроме того, Hadoop делит слоты на два типа: Map Slot и Reduce Slot, и не позволяет их совместно использовать, что часто приводит к нехватке ресурсов в одном слоте и простою другого (например, при выполнении задания только что отправлен, будет запущен только слот карты. Задача «Уменьшить слот» в это время простаивает).
- Поддержка нескольких вычислительных платформ невозможна.
2. Что такое ПРЯЖА?
YARN на самом деле представляет собой гибкую вычислительную платформу, цель которой больше не ограничиваться поддержкой MapReduce в качестве вычислительной среды, а направлена на унифицированное управление несколькими средами. Основная идея YARN состоит в том, чтобы разделить функции управления ресурсами и планирования/мониторинга заданий на отдельные демоны. иметь глобальныйResourceManager（RM）и каждое приложениеApplicationMaster（AM）. Приложение может быть отдельным заданием или группой DAG заданий.
3. Какова роль пряжи?
3.1, способ Hadoop v1.0
В рамках Hadoop версии 1.0 обработка данных и планирование ресурсов в основном зависят от MapReduce. Конкретный процесс выглядит следующим образом:
Из приведенного выше рисунка мы можем понять метод обработки данных Hadoop v1.0. При мелкомасштабной обработке данных этот метод не слишком проблематичен. Однако в реальных сценариях часто необходимо обрабатывать большое количество данных, и этот метод столкнется со следующими проблемами:
- Поскольку в средство отслеживания заданий передается большое количество заданий по обработке данных, и могут существовать тысячи узлов данных, которые должно координировать средство отслеживания заданий, средство отслеживания заданий может легко стать узким местом в производительности и доступности всей системы.
- Ресурсы не могут быть распределены эффективно, что приводит к неравномерному распределению ресурсов. В качестве следующего примера предположим, что имеется 3 узла данных (DN), а объем памяти каждого DN составляет 4 ГБ. Пользователь отправляет 6 заданий, каждое задание требует для обработки 1 ГБ памяти, и все данные находятся на DN2. Поскольку у DN2 всего 4 ГБ памяти, задания 1-4 выполняются на DN2, а задания 5 и 6 поставлены в очередь. Однако в настоящее время и DN1, и 3 находятся в состоянии ожидания и не могут эффективно использоваться.
3.2, способ пряжи
Основываясь на вышеуказанных проблемах, Hadoop запустил YARN (еще один ресурсный переговорщик) версии 2.0. Основная идея YARN состоит в том, чтобы разделить управление ресурсами и планирование/мониторинг заданий. Архитектура YARN показана на рисунке ниже.
Основные компоненты YARN можно разделить на две части:
глобальный компонент
-
Resource Manager（RM）: В качестве глобального унифицированного управления ресурсами, планирования и распределения. Диспетчер ресурсов состоит из Планировщика (Планировщик: по сути, стратегия) и Диспетчера приложений (Диспетчер приложений, ASM: отвечает за управление приложениями, отправленными пользователями-клиентами). Планировщик выделяет ресурсы Приложению в соответствии с емкостью и состоянием очереди узла; Менеджер приложений принимает запрос, отправленный пользователем, запускает Мастер приложений в узле, отслеживает состояние Мастера приложений и выполняет необходимые перезапуски. -
Node Manager（NM）: На каждом узле есть диспетчер узлов в качестве агента, который отслеживает использование ресурсов (процессор, память, диск, сеть) узла и сообщает о состоянии узла диспетчеру ресурсов.
Компоненты для каждого приложения
-
Application Master（AM）: отвечает за планирование выполнения заданий по обработке данных. Мастер приложений связывается с диспетчером ресурсов, чтобы получить ресурсы для расчета. После получения ресурсов он связывается с диспетчером узлов на узле, выполняет задачи в назначенном контейнере и отслеживает выполнение задач. (Каждый раз, когда клиент отправляет приложение, будет создан новый ApplicationMaster. ApplicationMaster будет обращаться к ресурсам контейнера с помощью ResourceManager. После получения ресурсов запускаемая программа будет отправлена в контейнер для запуска, а затем будут запущены распределенные вычисления. быть выполнен.) -
Container: абстрактный способ ресурсов, который инкапсулирует многомерные ресурсы на узле, такие как память, ЦП, диск, сеть и т. д. Когда мастер приложений обращается за ресурсами к диспетчеру ресурсов, ресурс, возвращаемый диспетчером ресурсов мастеру приложений, является контейнером. .
Когда YARN принимает задание, отправленное пользователем, его рабочий процесс выглядит следующим образом:
YARN решает вышеуказанные проблемы следующими способами.
- Решите проблему узкого места Job Tracker с помощью Application Master. Всякий раз, когда отправляется новое задание, диспетчер ресурсов запускает новый мастер приложений на соответствующем узле, что позволяет избежать затруднений, связанных с тем, что средство отслеживания заданий становится узким местом производительности в Hadoop v1.0.
- Более эффективное планирование ресурсов. Диспетчер ресурсов может выделять запасные ресурсы для мастера приложений, чтобы помочь мастеру приложений выполнять задачи.
- Поддержка методов обработки данных, отличных от MapReduce, таких как Spark и т. д.
4. Сравнение YARN и других менеджеров ресурсов
Даже если Hadoop v2.0 применяет дизайнерские идеи YARN, все равно остается проблема: когда отправляется большое количество заданий и все вычислительные ресурсы исчерпаны, новые задания должны долго ждать обработки, даже если новые задания очень важные задачи, и остается только ждать. В YARN черезscheduler plugin(Например:FIFO Scheduler,Fair Scheduler,Capacity Scheduler) настройте различные правила планирования ресурсов, чтобы максимально облегчить эту проблему, чтобы важные задания могли получить приоритет при распределении ресурсов.