предисловие
Когда используется MapReduce, у многих людей может возникнуть вопрос: после написания MR, как задачи отображения и задачи сокращения выполняются параллельно на нескольких узлах, и как вы решаете, какая задача выполняется на каком узле? На самом деле, эти проблемы связаны с этой пряжей. Потому что фреймворк Yarn на самом деле не только поддерживает MR, но и может запускать множество программ.
Мы знаем, что программа, работающая в кластере, потребляет ресурсы, такие как процессор, память, ввод-вывод и т. д. На самом деле в hadoop1.x поведение распределения ресурсов (управление ресурсами кластера на рисунке выше) также выполняется самим MapReduce. . Когда масштаб кластера велик и приложений много, MapReduce с большей вероятностью станет узким местом системы. Итак, в hadoop2.x был представлен Yarn, но HDFS для хранения и MapReduce для вычислений остались без изменений.
Apache Hadoop YARN — это подпроект Apache Software Foundation Hadoop, представленный для отдельных компонентов управления ресурсами и вычислений Hadoop 2.0. YARN родился, потому что данные, хранящиеся в HDFS, требуют более интерактивных режимов, а не только режима MapReduce. Архитектура YARN в Hadoop2.0 предоставляет больше платформ обработки и больше не требует использования платформы MapReduce.
Когда корпоративные данные доступны в HDFS, важно иметь несколько способов обработки данных. С помощью Hadoop 2.0 и YARN организации могут использовать потоковую обработку, интерактивную обработку данных и другие приложения на основе Hadoop.
Yarn
1. Архитектура пряжи
ПРЯЖА по-прежнему остается классикойСтруктура Master-Slave (Master/Slave),Как показано ниже. Вообще говоря, служба YARN состоит из одного ResourceManager (RM) и нескольких NodeManager (NM), причем ResourceManager является главным узлом (master), а NodeManager — подчиненным узлом (slave).
Мы можем открыть наш кластерный процесс с помощью команды jps, и если вы видите процесс ResourceManager, это главный узел. Увидев, что это NodeManager, то есть подчиненный узел
1.1 Основные компоненты
| имя компонента | эффект |
|---|---|
| ResourceManager | Это независимый запущенный процесс на Мастере, отвечающий за унифицированное управление ресурсами, планирование, распределение и т. д. кластера; |
| ApplicationManager | Он эквивалентен опекуну и менеджеру этого Приложения, ответственному за мониторинг и управление конкретной операцией всех Попыток этого Приложения на каждом узле в кластере, а также отвечает за обращение за ресурсами к Yarn ResourceManager, возврат ресурсов и т. д.; |
| NodeManager | Это независимо работающий процесс на ведомом устройстве, который отвечает за отчет о состоянии узла (используйте такую информацию, как диск, память, процессор и т. д.); |
| Container | Это единица распределения ресурсов в пряже, включая такие ресурсы, как память, ЦП и т. д. YARN распределяет ресурсы в единицах контейнеров; |
ResourceManager отвечает за унифицированное управление и планирование ресурсов на каждом NadeManager..Когда пользователь отправляет приложение, ему необходимо предоставить ApplicationMaster для отслеживания и управления программой, которая отвечает за подачу заявок на ресурсы в ResourceManager и просит NodeManger запускать задачи, которые могут занимать определенное количество ресурсов.. Поскольку разные ApplicationMaster распределены по разным узлам, они не влияют друг на друга.
Каждое приложение, отправленное Клиентом в ResourceManager, должно иметь ApplicationMaster, который запускается в контейнере узла Slave после того, как ResourceManager выделяет ресурсы, и конкретная задача выполнения действий также выполняется в контейнере узла Slave.
1.2 Как работает пряжа
Основная идея YARN состоит в том, чтобы разделить две основные функции JobTracker/TaskTracker на следующие сущности:
1. 一个全局的资源管理ResourceManager
2. 每个应用程序一个ApplicationMaster
3. 每个从节点一个NodeManager
4. 每个应用程序一个运行在NodeManager上的Container
Это официальная пряжаОбщая схема каждого приложения, работающего на Yarn, Посмотрите на такую картину или посмотрите сначала на роли, которые являются двумя клиентами, одним ведущим и тремя подчиненными. Клиент должен сначала установить соединение с диспетчером ресурсов мастера (видите ли, я говорю это от NameNode HDFS к разделу контроллера и лидера Kafka, сначала свяжитесь с мастером, а затем управляйте подчиненным через мастер. Действительно все платформы больших данных одинаковы 🤣), а затем ResourceManager связывается с nodeManager посредством вычислений, и сообщение, отправленное в это время, будет содержать требования к ресурсам для запуска приложения Master (например, сколько процессоров, памяти...) и получать его в nodeManager.После прибытия сообщения будет создан контейнер с именем container.После этого контейнера в нем запускается мастер-процесс приложения.
После запуска мастера приложения он свяжется с диспетчером ресурсов. В это время диспетчер ресурсов выполнит еще один расчет, а затем вернет сообщение мастеру приложения, чтобы связаться с другими диспетчерами узлов через мастер приложения, поскольку приложение работает через несколько контейнеров. , завершены вместе. Создавайте контейнеры-контейнеры для выполнения приложений. Эти контейнеры также будут поддерживать связь с мастером приложений при выполнении задач. Когда все задачи будут выполнены, мастер приложений уничтожит эти контейнеры.
2. Описание основных компонентов
Отныне будет много очень официального текста, который на самом деле представляет собой довольно скучное накопление результатов поисковых систем.
2.1 ResourceManager
RM — это глобальный менеджер ресурсов только с одним кластером, который отвечает за управление ресурсами и их распределение во всей системе, включая обработку клиентских запросов, запуск/мониторинг ApplicationMaster, мониторинг NodeManager, а также распределение и планирование ресурсов. В основном он состоит из двух компонентов: Планировщик (Scheduler) и Диспетчер приложений (Applications Manager, ASM).
планировщик
Планировщик распределяет ресурсы в системе для каждого работающего приложения в соответствии с такими ограничениями, как мощность и очереди (например, назначение определенных ресурсов для каждой очереди, выполнение максимального количества заданий и т. д.). Следует отметить, что планировщик является «чистым планировщиком», он выполняет любую работу, связанную с конкретным приложением, например, не отвечает за мониторинг или отслеживание состояния выполнения приложения и т. д., а также не отвечает за перезапуск из-за сбой выполнения приложения или аппаратное обеспечение.Неудачные задачи, вызванные сбоем, передаются мастеру приложений, связанному с приложением для завершения.
Планировщик распределяет ресурсы только в соответствии с требованиями к ресурсам каждого приложения, а единица выделения ресурсов представлена абстрактным понятием «Контейнер ресурсов» (Resource Container, сокращенно Контейнер).Контейнер — это динамическая единица распределения ресурсов. ресурсы инкапсулируются вместе, чтобы ограничить количество ресурсов, используемых каждой задачей.
менеджер приложений
Диспетчер приложений в основном отвечает за управление всеми приложениями во всей системе, получение запросов на отправку заданий, выделение первого контейнера приложению для запуска ApplicationMaster, включая отправку приложений, согласование ресурсов с планировщиком для запуска ApplicationMaster, мониторинг рабочего состояния. ApplicationMaster и перезапустите его в случае сбоя и т. д.
2.2 ApplicationMaster
Управляйте каждым экземпляром приложения, работающего в YARN. Управление заданиями или приложениями осуществляется процессом ApplicationMaster, и Yarn позволяет нам разрабатывать ApplicationMasters для наших собственных приложений.
Функции:
- сегментация данных;
- Запрашивать ресурсы для приложения и далее распределять на внутренние задачи (TASK);
- Мониторинг задач и отказоустойчивость;
- Отвечает за координацию ресурсов из ResourceManager и мониторинг простого выполнения и использования ресурсов через NodeManager.
Можно сказать, что связь между ApplicationMaster и ResourceManager является основной частью всего приложения Yarn от отправки до работы, и это фундаментальный шаг Yarn для динамического управления всем кластером. применение и повторное освобождение ресурсов посредством связи с ResourceManager.
2.3 NodeManager
NodeManager — подчиненная служба: она отвечает за получение запросов на выделение ресурсов от ResourceManager и назначение конкретных контейнеров приложениям. В то же время он также отвечает за мониторинг и передачу информации об использовании контейнера в ResourceManager. Взаимодействуя с ResourceManager, NodeManager отвечает за распределение ресурсов во всем кластере Hadoop.
Функция: использование ресурсов NodeManager на этом узле и рабочее состояние каждого контейнера (такие ресурсы, как процессор и память).
- Получать и обрабатывать командные запросы от ResourceManager и назначать Контейнер задаче приложения;
- Регулярно отчитывайтесь перед RM, чтобы обеспечить бесперебойную работу всего кластера.RM отслеживает состояние работоспособности всего кластера, собирая отчетную информацию каждого NodeManager, а NodeManager отвечает за мониторинг своего собственного состояния работоспособности;
- Обработка запросов от ApplicationMaster;
- Управлять жизненным циклом каждого Контейнера на узле, где он находится;
- Управление журналами на каждом узле;
- Выполнение некоторых дополнительных сервисов, применяемых к Yarn, таких как процесс перемешивания MapReduce;
Когда узел запускается, он регистрируется в ResourceManager и сообщает ResourceManager, сколько ресурсов ему доступно. Во время выполнения благодаря сотрудничеству NodeManager и ResourceManager эта информация будет постоянно обновляться и обеспечивать наилучшую производительность всего кластера.
NodeManager отвечает только за управление своим контейнером, он не знает информацию об этом для запуска приложения. Компонент, ответственный за управление информацией о приложении, является ApplicationMaster
2.4 Container
Контейнер — это абстракция ресурсов в YARN, которая инкапсулирует многомерные ресурсы на узле, такие как память, ЦП, диск, сеть и т. д. Когда AM запрашивает ресурсы у RM, ресурсы, возвращаемые RM для AM, представлены Container. YARN назначает Контейнер каждой задаче, и задача может использовать только ресурсы, описанные в этом Контейнере.
Связь между Контейнерами и узлами кластера заключается в том, что узел будет запускать несколько Контейнеров, но Контейнер не будет охватывать узлы. Любое задание или приложение должно выполняться в одном или нескольких контейнерах.В структуре Yarn ResourceManager отвечает только за сообщение ApplicationMaster, какие контейнеры доступны, и ApplicationMaster также должен обратиться к NodeManager, чтобы запросить выделение определенных контейнеров.
Следует отметить, что Контейнер — это динамическая единица разделения ресурсов, которая динамически генерируется в соответствии с потребностями приложения. На данный момент YARN поддерживает только два ресурса, ЦП и память, и использует облегченный механизм изоляции ресурсов Cgroups для изоляции ресурсов.
Функции:
- Абстракция среды задачи;
- описывать спектр информации;
- Набор ресурсов для выполнения задач (процессор, память, ввод-вывод и т. д.);
- среда выполнения задачи
2.5 Запрос ресурсов и контейнер
Цель разработки Yarn — позволить нашим различным приложениям использовать весь кластер в общей, безопасной, многопользовательской форме. Более того, чтобы обеспечить эффективное планирование ресурсов кластера и доступ к данным, Yarn также должен иметь возможность воспринимать всю топологию кластера.
Для достижения этих целей планировщик ResourceManager определяет несколько гибких протоколов для запросов ресурсов приложений, с помощью которых можно лучше планировать различные приложения, работающие в кластере.Resource RequestиContainer.
Приложение сначала отправляет запрос ресурса, который соответствует его собственным потребностям, в ApplicationMaster, а затем ApplicationMaster отправляет запрос ресурса в планировщик ResourceManager в форме запроса ресурса, и планировщик возвращает назначенное описание ресурса Container в исходный ресурс-запрос.
Каждый ResourceRequest можно рассматривать как сериализуемый объект Java, который содержит следующую информацию о полях:
<!--
- resource-name：资源名称，现阶段指的是资源所在的host和rack，后期可能还会支持虚拟机或者更复杂的网络结构
- priority：资源的优先级
- resource-requirement：资源的具体需求，现阶段指内存和cpu需求的数量
- number-of-containers：满足需求的Container的集合
-->
<resource-name, priority, resource-requirement, number-of-containers>
2.6 JobHistoryServer
Служба истории заданий записывает исторический статус выполнения заданий, запланированных в пряже.Команда mr-jobhistory-daemon.sh start historyserver не требует какой-либо настройки на компьютерах узлов данных в кластере.Его можно запустить напрямую с помощью команды После успешного запуска появится процесс JobHistoryServer (используйте команду jps для просмотра, которая будет представлена ниже), а подробности журнала можно просмотреть с порта 19888.
2.6.1 Что мы увидим на пряже, если запустим программу mapreduce без запуска jobhistoryserver?
Откройте интерфейс, как показано на рисунке ниже, нажмите «История» на рисунке ниже, и страница перейдет один раз.
После нажатия на «История» страница после перехода выглядит, как показано на рисунке ниже, она пуста, потому что мы не запускали jobhistoryserver в это время.
2.6.2 Запустите команду mr-jobhistory-daemon.sh start historyserver на трех машинах, чтобы последовательно запустить jobhistoryserver.
Хорошо, теперь мы запускаем jobhistoryserver на трех узлах и запускаем здесь программу подсчета слов (не забудьте удалить выходной каталог перед запуском)
Нажав на ссылку «История», вы перейдете на страницу. В нижней части страницы вы увидите карту и сокращение, перечисленные в TaskType. Итого представляет данные задачи карты и сокращения, необходимые для выполнения программы mapreduce, работающей в этот раз.
Мы щелкаем подключение к карте в столбце TaskType и видим соответствующую информацию о задаче карты, такую как состояние выполнения, время начала и время завершения.
Мы можем использовать тот же способ для просмотра деталей выполнения задачи сокращения, который не будет повторяться здесь.
Из приведенных выше операций мы видим, что jobhistoryserver — это запись исторической информации об операциях во время работы задания, которая нам удобна для анализа задания.
2.7 Timeline Server
Он используется для записи данных службы журнала, как правило, для записи данных службы журнала в сочетании с третьими сторонами (такими как искра и т. д.) С момента введения на официальном веб-сайте это эффективное дополнение к функции jobhistoryserver. Jobhistoryserver может только записывать информацию о задании типа mapreduce. Помимо того, что jobhistoryserver может записывать информацию во время выполнения задания, существуют более подробные информационные записи, например, в какой очереди выполняется задание и какой пользователь установлен при выполнении задания. .
Record Mapreatuce Application Объяснение JobHistoryserver может быть записано только в соответствии с официальным веб-сайтом, TimeleneServer более мощным, но не заменяет, взаимосвязь между двумя дополнительными функциями трубов.
Три, принцип работы приложения пряжи
3.1 Как работает пряжа?
Основная идея YARN состоит в том, чтобы разделить две основные функции JobTracker/TaskTracker на следующие сущности:
- Глобальное управление ресурсами ResourceManager
- Один ApplicationMaster на приложение
- Один NodeManager на подчиненный узел
- Один контейнер для каждого приложения, работающего в NodeManager
3.2 Процесс подачи заявки на пряжу
Процесс выполнения Application in Yarn, весь процесс выполнения можно свести к трем этапам:
1. 应用程序提交
2. 启动应用的ApplicationMaster实例
3. ApplicationMaster 实例管理应用程序的执行
Конкретный процесс подачи:
-
Клиентская программа отправляет приложение в ResourceManager и запрашивает экземпляр ApplicationMaster.
-
ResourceManager находит NodeManager, который может запускать контейнер, и запускает экземпляр ApplicationMaster в этом контейнере.
-
ApplicationMaster регистрируется в ResourceManager.После регистрации клиент может запросить ResourceManager для получения подробной информации о своем ApplicationMaster, а затем может напрямую взаимодействовать со своим собственным ApplicationMaster (в это время клиент активно взаимодействует с ApplicationMaster, и приложение сначала отправляет сообщение ApplicationMaster, чтобы удовлетворить запрос на ресурс)
-
Во время нормальной работы ApplicationMaster отправляет запрос ресурсов в ResourceManager в соответствии с протоколом запроса ресурсов.
-
Когда Контейнер успешно выделен, ApplicationMaster запускает Контейнер, отправляя информацию о спецификации запуска контейнера в NodeManager.Информация о спецификации запуска контейнера содержит информацию, необходимую для обеспечения связи между Контейнером и ApplicationMaster.
-
Код приложения запускается в запущенном Контейнере в виде задачи и отправляет ход выполнения, статус и другую информацию в ApplicationMaster через протокол, специфичный для приложения.
-
Во время работы приложения клиент, отправляющий приложение, активно взаимодействует с ApplicationMaster для получения такой информации, как статус выполнения и ход обновления приложения.Протокол связи также является протоколом, специфичным для приложения.
-
После завершения выполнения приложения и завершения всей связанной с ним работы ApplicationMaster отменяет регистрацию в ResourceManager и завершает работу, возвращая в систему все использованные контейнеры.
Сокращенная версия:Шаг 1: Вопросы приложений пользователя в ResourceManager; Шаг 2: ResourceManager Application ApplicationMaster Applications Applications Applications и запускает первый контейнер NodeManager, связываемый, чтобы запустить ApplicationMaster; Шаг 3: ApplicationMaster обменивается регистрацией в ResourceManager, подать заявку на внутренние ресурсы для выполнения задачи после наличия ресурсов, сообщите NodeManager Communications для инициирования соответствующей задачи; Шаг 4: После завершения всех выполняемых задач ApplicationMaster ResourceManager для выхода из конца выполнения всего приложения.
3.3 mapreduce on yarn
MapReduce основан на принципе работы пряжи:
Мы выполняем обработку MapReduce, отправляя пакет jar, затем весь запущенный процесс делится на пять шагов:
1、向client端提交MapReduce job.
2、随后yarn的ResourceManager进行资源的分配.
3、由NodeManager进行加载与监控containers.
4、通过applicationMaster与ResourceManager进行资源的申请及状态的交互，由NodeManagers进行MapReduce运行时job的管理.
5、通过hdfs进行job配置文件、jar包的各节点分发。
① Процесс инициализации задания
1. Когда ResourceManager получает уведомление о вызове метода submitApplication(), планировщик начинает выделять контейнер, а затем ResouceManager отправляет процесс applicationMaster для информирования каждого менеджера nodeManager.
2. ApplicationMaster решает, как выполнять задачи.Если объем данных задания относительно невелик, applicationMaster выбирает выполнение задач в JVM. Так как же определить, большая это работа или маленькая? Когда количество мапперов в задании меньше 10, есть только один редюсер или размер читаемого файла меньше одного блока HDFS (можно изменить элементы конфигурации mapreduce.job.ubertask.maxmaps, mapreduce.job .ubertask.maxreduces и mapreduce.job.ubertask.maxbytes для настройки)
3. Перед запуском задач applicationMaster вызовет метод setupJob(), а затем создаст выходной путь вывода (это можно объяснить, независимо от того, сообщает ли ваш mapreduce об ошибке в начале, выходной путь будет создан )
② задания задач
1. Затем applicationMaster запрашивает контейнеры у ResourceManager для выполнения задач карты и редукции (шаг 8). Здесь приоритет задачи карты выше, чем у задачи редукции. Когда все задачи карты завершены, сортировка (здесь это перетасовка) (процесс будет обсуждаться позже), и, наконец, запустите задачу сокращения. (Здесь есть момент, когда задачи карты выполняются 5% времени, будет запрошено сокращение, которое будет кратко изложено ниже)
2. Запуск задач должен потреблять память и ресурсы процессора.По умолчанию ресурсы задачи карты и сокращения выделяются 1024 МБ и одному ядру (минимальная и максимальная конфигурация параметров для запуска может быть изменена, mapreduce.map.memory.mb , mapreduce.reduce.memory.mb, mapreduce.map.cpu.vcores, mapreduce.reduce.reduce.cpu.vcores.)
③ Выполнение задачи задачи
1. В это время ResourceManager назначил контейнеру задачу, и applicationMaster сообщает диспетчеру узлов запустить контейнер.Эта задача будет запущена java-приложением, основной функцией которого является YarnChild, но перед запуском задачи, сначала найдите пакет jar, необходимый для задачи, файлы конфигурации и файлы, загруженные в кэш.
2. YarnChild работает на выделенной JVM, поэтому любая проблема с картой или задачей редукции не повлияет на сбой или зависание всего нодменеджера.
3. Каждая задача может быть выполнена в одной и той же задаче JVM, а затем завершенные данные обработки записываются во временный файл. Поток данных Mapreduce
④ Ход выполнения и обновление статуса
MapReduce — это пакетный процесс с длительным временем выполнения, которое может составлять час, несколько часов или даже несколько дней, поэтому очень важно отслеживать состояние выполнения задания. Каждое задание и каждая задача имеют статус, включая задание (выполняется, успешно завершено, не удалось), а также счетчик значений, информацию о состоянии и информацию описания (информация описания обычно печатается и добавляется к коду).
Итак, как эта информация передается клиенту?
Когда задача начинает выполняться, она будет вести запись выполнения и записывать долю выполнения задачи. Для задач карты она будет записывать процент выполнения. Это может быть сложнее для сокращения, но система все равно будет оценивать степень выполнения сокращения. . При выполнении задачи map или reduce дочерний процесс продолжает взаимодействовать с applicationMaster каждые три секунды. пока работа не будет завершена
3.4 жизненный цикл применения пряжи
- RM: Resource Manager
- AM: Application Master
- NM: Node Manager
- Клиент подает заявку на РМ, включая программу АМ и команду запуска АМ.
- RM выделяет первый контейнер для AM и связывается с соответствующим NM, чтобы запустить AM приложения в контейнере.
- Когда AM запускается, он регистрируется в RM, позволяя Клиенту получать информацию AM от RM и связываться с AM напрямую.
- AM согласовывает ресурсы контейнера для приложений через протокол запроса ресурсов.
- Если выделение контейнера прошло успешно, AM требует, чтобы NM запустил приложение в контейнере, и приложение может взаимодействовать с AM независимо после его запуска.
- Приложение выполняется в контейнере и отчитывается перед AM.
- Во время выполнения приложения клиент и AM взаимодействуют друг с другом для получения состояния приложения.
- После завершения выполнения приложения AM выходит из системы и закрывает RM для освобождения ресурсов.
Подать заявку на ресурсы->Запустить appMaster->Подать заявку на контейнер для выполнения задач->Распределить задачу->Выполнить задачу->Завершение задачи->Перезапустить контейнер
4. Как использовать пряжу
4.1 Файл конфигурации
<!-- $HADOOP_HOME/etc/hadoop/mapred-site.xml -->
<configuration>
<property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
</configuration>
<!-- $HADOOP_HOME/etc/hadoop/yarn-site.xml -->
<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
</configuration>
4.2 начало и конец пряжи
Запустите ResourceManager и NodeManager (далее RM, NM соответственно)
#主节点运行命令
$HADOOP_HOME/sbin/start-yarn.sh
Остановить РМ и НМ
#主节点运行命令
$HADOOP_HOME/sbin/stop-yarn.sh
Если RM не запущен, его можно запустить отдельно
#若RM没有启动，在主节点运行命令
$HADOOP_HOME/sbin/yarn-daemon.sh start resouremanager
#相反，可单独关闭
$HADOOP_HOME/sbin/yarn-daemon.sh stop resouremanager
Если NM не запущен, он может быть запущен отдельно
#若NM没有启动，在相应节点运行命令
$HADOOP_HOME/sbin/yarn-daemon.sh start nodemanager
#相反，可单独关闭
$HADOOP_HOME/sbin/yarn-daemon.sh stop nodemanager
Пять, планировщик пряжи
Представьте, что ваша текущая компанияОдинКластер Хауп. Тем не менее, проектная группа A часто делает несколько отчетов BI с указанием времени, а проектная группа B часто использует какое-то программное обеспечение для решения временных задач. Тогда они обязательно столкнутся со сценарием сдачи задач одновременно, как распределить ресурсы для выполнения этих двух задач в это время? Должен ли я сначала выполнить задачу A, затем задачу B или запустить обе задачи одновременно?
Если у вас возникла описанная выше путаница, вы можете узнать больше о планировщике ресурсов пряжи.
Во фреймворке Yarn планировщик — очень важная часть контента. При правильных правилах планирования можно гарантировать одновременную упорядоченную работу нескольких приложений. Самым примитивным правилом планирования является FIFO, то есть какая задача выполняется первой в соответствии со временем, когда пользователь отправляет задачу, а та, которая была отправлена первой, выполняется первой. Однако очень вероятно, что большая задача монополизирует ресурсы, а другие ресурсы должны постоянно ждать. Также возможно, что куча мелких задач занимает ресурсы, а большие задачи не могут получить соответствующие ресурсы, что приводит к голоданию. Итак, хотя FIFO очень прост, он не отвечает нашим потребностям.
В идеале запросы ресурсов, сделанные приложениями пряжи, должны удовлетворяться немедленно. Однако на самом деле ресурсы ограничены: на загруженном кластере приложению часто приходится ждать, чтобы получить требуемые ресурсы. Задача планировщика пряжи — распределять ресурсы между приложениями в соответствии с заданной политикой. Планирование часто является сложной проблемой, и не существует так называемой «лучшей» стратегии, поэтому пряжа предоставляет нам несколько планировщиков и настраиваемых стратегий на выбор.
Пряжа разделена на управление планированием первого уровня и управление планированием второго уровня.Управление планированием первого уровня (ближе к нижнему уровню, ближе к операционным ресурсам, более склонно к сочетанию прикладного уровня и нижнего уровня) Управление вычислительными ресурсами (процессор, память и т. д., сложные вычисления потребляют больше ресурсов ЦП) Управление жизненным циклом приложений Вторичное управление планированием (алгоритмы собственного кода и т. д., более склонные к прикладному уровню) Управление вычислительной моделью внутри приложения Разнообразные вычислительные модели
5.1 Планировщик
В Yarn есть три планировщика на выбор: планировщик FIFO, планировщик емкости, планировщик FairS.
5.2 FIFO Scheduler
FIFO Scheduler упорядочивает приложения в очереди в порядке отправки. Это очередь в порядке очереди. Когда выполняется распределение ресурсов, ресурсы выделяются приложению, находящемуся в верхней части очереди, и приложению, находящемуся в верхней части очереди. удовлетворен, дайте следующее задание и т. д.
FIFO Scheduler — самый простой и понятный планировщик, не требующий настройки, но он не подходит для разделяемых кластеров. Большие приложения могут потреблять все ресурсы кластера, что приводит к блокировке других приложений. В общем кластере удобнее использовать планировщик емкости или планировщик ярмарки, оба из которых позволяют крупным задачам и небольшим задачам получать определенные системные ресурсы при отправке.
В следующей «Сравнительной таблице планировщика Yarn» показана разница между этими планировщиками.Как видно из рисунка, в планировщике FIFO маленькие задачи будут блокироваться большими задачами.
5.3 Capacity Scheduler
Использовать планировщик ресурсов по умолчанию
Для планировщика емкости предусмотрена выделенная очередь для выполнения небольших задач, но установка очереди для небольших задач будет занимать определенное количество ресурсов кластера заранее, что приведет к отставанию времени выполнения больших задач при использовании планировщика FIFO. , время.
Как настроить планировщик ресурсов
Иерархия очереди выглядит следующим образом:
root
├── prod
└── dev
├── spark
└── hdp
главный узел, создайте резервную копию соответствующего файла конфигурации capacity-scheduler.xml в $HADOOP_HOME/etc/hadoop/ в другом каталоге.
Если кластер Hadoop запущен, закройте кластер Hadoop.
Создайте новый файл capacity-scheduler.xml в каталоге $HADOOP_HOME/etc/hadoop/ со следующим содержимым.
Скопируйте этот xml-файл в тот же каталог удаленно
перезапустить кластер хауп
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>prod,dev</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.queues</name>
<value>hdp,spark</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.prod.capacity</name>
<value>40</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.capacity</name>
<value>60</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.maximum-capacity</name>
<value>75</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.hdp.capacity</name>
<value>50</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.spark.capacity</name>
<value>50</value>
</property>
</configuration>
В какую очередь помещается приложение, зависит от самого приложения.
Например, в MR можно указать соответствующую очередь, установив свойство mapreduce.job.queuename. Возьмите WordCount в качестве примера, как показано ниже.
Ошибка возникает, если указанная очередь не существует. Если не указано, по умолчанию используется очередь «по умолчанию», как показано ниже.
Программа упакована и отправлена в кластер для запуска, что не будет здесь демонстрироваться.
Кроме того, очень просто изменить свойства очереди и добавить новые очереди. Вам нужно отредактировать conf/capacity-scheduler.xml и запустить
$ yarn rmadmin -refreshQueues
справочник планировщика мощности
5.4 Планировщик выставок
Использовать планировщик ресурсов по умолчанию
Чтобы использовать Fair Scheduler, вам необходимо настроить yarn-site.xml и изменить значение свойства «yarn.resourcemanager.scheduler.class» на «org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler». ", следующим образом
<property>
<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>
Примечание. Точно так же все файлы yarn-site.xml в кластере должны обновляться синхронно.
В планировщике Fair нам не нужно предварительно занимать определенные системные ресурсы, и планировщик Fair будет динамически настраивать системные ресурсы для всех запущенных заданий. Как показано на рисунке ниже, когда отправляется первое большое задание, выполняется только это задание, и оно получает все ресурсы кластера; когда отправляется второе небольшое задание, планировщик Fair выделяет половину ресурсов для этого маленького задания. , чтобы две задачи справедливо делили ресурсы кластера.
Следует отметить, что в планировщике Fair на рисунке ниже будет определенная задержка от подачи второй задачи до получения ресурсов, потому что нужно дождаться, пока первая задача освободит занятый Контейнер. После завершения маленькой задачи ресурсы, занятые ею самой, будут освобождены, а большая задача получит все системные ресурсы. Конечным результатом является то, что планировщик Fair может достичь высокой степени использования ресурсов и обеспечить своевременное выполнение небольших задач.
ps: поддержка вытеснения ресурсов: установите для yarn.scheduler.fair.preemption значение true в yarn-site.xml
Шесть, статус заявки на пряжу
Мы можем видеть в веб-интерфейсе пряжи, что приложение пряжи разделено на следующие состояния:
NEW -----新建状态
NEW_SAVING-----新建保存状态
SUBMITTED-----提交状态
ACCEPTED-----接受状态
RUNNING-----运行状态
FINISHED-----完成状态
FAILED-----失败状态
KILLED-----杀掉状态
finally
Эта статья, которую мы представляем, выглядит примерно следующим образом: Сценарии применения пряжи, основные компоненты, процесс планирования приложений, типичные применения пряжи. Это важно, но в основном это концептуальная проблема, поэтому я не знал, с чего начать, когда писал ее.Создайте кластер из трех узлов (каждый с 2 ГБ памяти) и попробуйте.