Это седьмой день моего участия в августовском испытании обновлений, подробности о мероприятии:Испытание августовского обновления

текст

ПРЯЖА классическаяСтруктура Master-Slave (Master/Slave),Как показано ниже.

在这里插入图片描述

Вообще говоря, служба YARN состоит из одного ResourceManager (RM) и нескольких NodeManager (NM), причем ResourceManager является главным узлом (master), а NodeManager — подчиненным узлом (slave).

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

имя компонента	эффект
ResourceManager	Это независимый запущенный процесс на Мастере, отвечающий за унифицированное управление ресурсами, планирование, распределение и т. д. кластера;
ApplicationManager	Он эквивалентен опекуну и менеджеру этого Приложения, ответственному за мониторинг и управление конкретной операцией всех Попыток этого Приложения на каждом узле в кластере, а также отвечает за обращение за ресурсами к Yarn ResourceManager, возврат ресурсов и т. д.;
NodeManager	Это независимо работающий процесс на ведомом устройстве, который отвечает за отчет о состоянии узла (используйте такую информацию, как диск, память, процессор и т. д.);
Container**	Это единица распределения ресурсов в пряже, включая такие ресурсы, как память, ЦП и т. д. YARN распределяет ресурсы в единицах контейнеров;

До Hadoop 3.x Container поддерживал только ресурсы памяти и ЦП, а Hadoop 3.x стал поддерживать пользовательские типы ресурсов, что значительно расширило возможности управления ресурсами.

Как взаимодействуют вышеперечисленные компоненты?

ResourceManager отвечает за унифицированное управление и планирование ресурсов в каждом NodeManager. Когда пользователь отправляет приложение, ему необходимо предоставить ApplicationMaster для отслеживания и управления программой, которая отвечает за подачу заявок на ресурсы в ResourceManager и просит NodeManger запускать задачи, которые могут занимать определенное количество ресурсов.

Поскольку разные ApplicationMaster распределены по разным узлам, они не влияют друг на друга.

Каждое приложение, отправленное Клиентом в ResourceManager, должно иметь ApplicationMaster, который запускается в контейнере узла Slave после того, как ResourceManager выделяет ресурсы, и конкретная задача выполнения действий также выполняется в контейнере узла Slave.

Пополнить

在这里插入图片描述

ResourceManager

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

Он в основном состоит из двух компонентов: планировщика (Scheduler) и диспетчера приложений (ApplicationManager).

Планировщик

Планировщик распределяет ресурсы в системе для каждого работающего приложения в соответствии с такими ограничениями, как мощность и очереди (например, назначение определенных ресурсов для каждой очереди, выполнение максимального количества заданий и т. д.). Следует отметить, что планировщик является «чистым планировщиком», он выполняет любую работу, связанную с конкретным приложением, например, не отвечает за мониторинг или отслеживание состояния выполнения приложения и т. д., а также не отвечает за перезапуск из-за сбой выполнения приложения или аппаратное обеспечение.Неудачные задачи, вызванные сбоем, передаются мастеру приложений, связанному с приложением для завершения.

Планировщик распределяет ресурсы только в соответствии с требованиями к ресурсам каждого приложения, а единица выделения ресурсов представлена абстрактным понятием «Контейнер ресурсов» (Resource Container, сокращенно Контейнер).Контейнер — это динамическая единица распределения ресурсов. ресурсы инкапсулируются вместе, чтобы ограничить количество ресурсов, используемых каждой задачей.

Диспетчер приложений (менеджер приложений)

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

ApplicationMaster

Управляйте каждым экземпляром приложения, работающего в YARN. Управление заданиями или приложениями осуществляется процессом ApplicationMaster, и Yarn позволяет нам разрабатывать ApplicationMasters для наших собственных приложений.

Функции

сегментация данных;
Запрашивать ресурсы для приложения и далее распределять на внутренние задачи (TASK);
Мониторинг задач и отказоустойчивость;
Отвечает за координацию ресурсов из ResourceManager и мониторинг простого выполнения и использования ресурсов через NodeManager.

Можно сказать, что связь между ApplicationMaster и ResourceManager является основной частью всего приложения Yarn от отправки до эксплуатации, и это фундаментальный шаг Yarn для динамического управления всем кластером. применение и повторное освобождение ресурсов посредством связи с ResourceManager.

NodeManager

Во всем кластере есть несколько менеджеров узлов, отвечающих за ресурсы и их использование на каждом узле.

NodeManager — подчиненная служба: она отвечает за получение запросов на выделение ресурсов от ResourceManager и назначение конкретных контейнеров приложениям. В то же время он также отвечает за мониторинг и передачу информации об использовании контейнера в ResourceManager. Взаимодействуя с ResourceManager, NodeManager отвечает за распределение ресурсов во всем кластере Hadoop.

Функции

NodeManager отслеживает использование ресурсов на этом узле и рабочее состояние каждого контейнера (таких ресурсов, как процессор и память).
Получать и обрабатывать командные запросы от ResourceManager и назначать Контейнер задаче приложения;
Регулярно отчитывайтесь перед RM, чтобы обеспечить бесперебойную работу всего кластера.RM отслеживает состояние работоспособности всего кластера, собирая отчетную информацию каждого NodeManager, а NodeManager отвечает за мониторинг своего собственного состояния работоспособности;
Обработка запросов от ApplicationMaster;
Управление журналами на каждом узле;
Выполнение некоторых дополнительных сервисов, применяемых к Yarn, таких как процесс перемешивания MapReduce;

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

Container

Контейнер — это абстракция ресурсов в YARN, которая инкапсулирует многомерные ресурсы на узле, такие как память, ЦП, диск, сеть и т. д. Когда AM запрашивает ресурсы у RM, ресурсы, возвращаемые RM для AM, представлены Container. YARN назначает Контейнер каждой задаче, и задача может использовать только ресурсы, описанные в этом Контейнере.

Связь между Контейнерами и узлами кластера заключается в том, что узел будет запускать несколько Контейнеров, но Контейнер не будет охватывать узлы. Любое задание или приложение должно выполняться в одном или нескольких контейнерах.В структуре Yarn ResourceManager отвечает только за сообщение ApplicationMaster, какие контейнеры доступны, и ApplicationMaster также должен обратиться к NodeManager, чтобы запросить выделение определенных контейнеров.

Следует отметить, что Контейнер — это динамическая единица разделения ресурсов, которая динамически генерируется в соответствии с потребностями приложения. Пока что YARN поддерживает только два ресурса, ЦП и память, и использует облегченный механизм изоляции ресурсов Cgroups для изоляции ресурсов.

Функции

Абстракция среды задачи;
описывать спектр информации;
Набор ресурсов для выполнения задач (процессор, память, ввод-вывод и т. д.);
среда выполнения задачи

Resource Request

Цель разработки 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>

JobHistoryServer

Служба истории заданий записывает исторический статус выполнения заданий, запланированных в пряже. Следующие команды не требуют какой-либо настройки на компьютерах узла данных в кластере. Вы можете запустить их непосредственно с помощью одной команды. После успешного запуска JobHistoryServer появится процесс (используйте команду jps для просмотра, которая будет представлена ниже), а подробности журнала можно просмотреть с порта 19888.

Два способа запуска JobHistoryServer (Hadoop 3.x)

[hadoop@node1 ~]$ mr-jobhistory-daemon.sh start historyserver
WARNING: Use of this script to start the MR JobHistory daemon is deprecated.
WARNING: Attempting to execute replacement "mapred --daemon start" instead.

[hadoop@node1 ~]$ mapred --daemon start historyserver
[hadoop@node1 ~]$

TimelineServer

Он используется для записи данных службы журнала, как правило, для записи данных службы журнала в сочетании с третьими сторонами (такими как искра и т. д.) С момента введения на официальном веб-сайте это эффективное дополнение к функции JobHistoryServer.

JobHistoryServer может записывать информацию о задании только типа mapreduce.В дополнение к тому, что JobHistoryServer может записывать информацию во время выполнения задания, существуют более подробные информационные записи, такие как очередь, в которой выполняется задание, и пользователь, установленный при выполнении задания. это какой пользователь.

Согласно пояснению на официальном сайте,JobHistoryServer может записывать только записи приложений mapreduce.TimelineServer более мощный и может записывать сторонние вычислительные движки, но он не заменяет JobHistoryServer.. Эти два являются дополнительными отношениями между функциями.

упражняться

Выполните следующие команды на трех машинах, чтобы запустить JobHistoryServer по очереди.

mapred --daemon start historyserver

На этом этапе, после запуска JobHistoryServer на трех узлах, запустите здесь программу подсчета слов.

Мы используем предоставленный официальный пример WordCount.

[hadoop@node1 ~]$ hadoop jar /opt/bigdata/hadoop-3.2.2/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.2.jar wordcount /test/words /test/output
2021-06-17 22:06:18,348 INFO client.RMProxy: Connecting to ResourceManager at node1/172.16.68.201:18040
2021-06-17 22:06:19,108 INFO mapreduce.JobResourceUploader: Disabling Erasure Coding for path: /tmp/hadoop-yarn/staging/hadoop/.staging/job_1614270487333_0009
2021-06-17 22:06:19,346 INFO input.FileInputFormat: Total input files to process : 1
2021-06-17 22:06:19,844 INFO mapreduce.JobSubmitter: number of splits:1
2021-06-17 22:06:20,026 INFO mapreduce.JobSubmitter: Submitting tokens for job: job_1614270487333_0009
2021-06-17 22:06:20,028 INFO mapreduce.JobSubmitter: Executing with tokens: []
2021-06-17 22:06:20,253 INFO conf.Configuration: resource-types.xml not found
2021-06-17 22:06:20,253 INFO resource.ResourceUtils: Unable to find 'resource-types.xml'.
2021-06-17 22:06:20,356 INFO impl.YarnClientImpl: Submitted application application_1614270487333_0009
2021-06-17 22:06:20,403 INFO mapreduce.Job: The url to track the job: http://node1:18088/proxy/application_1614270487333_0009/
2021-06-17 22:06:20,404 INFO mapreduce.Job: Running job: job_1614270487333_0009
2021-06-17 22:06:26,536 INFO mapreduce.Job: Job job_1614270487333_0009 running in uber mode : false
2021-06-17 22:06:26,538 INFO mapreduce.Job:  map 0% reduce 0%
2021-06-17 22:06:31,614 INFO mapreduce.Job:  map 100% reduce 0%
2021-06-17 22:06:36,653 INFO mapreduce.Job:  map 100% reduce 100%
2021-06-17 22:06:36,666 INFO mapreduce.Job: Job job_1614270487333_0009 completed successfully
2021-06-17 22:06:36,763 INFO mapreduce.Job: Counters: 54
        File System Counters
                FILE: Number of bytes read=54
                FILE: Number of bytes written=470051
                FILE: Number of read operations=0
                FILE: Number of large read operations=0
                FILE: Number of write operations=0
                HDFS: Number of bytes read=115
                HDFS: Number of bytes written=28
                HDFS: Number of read operations=8
                HDFS: Number of large read operations=0
                HDFS: Number of write operations=2
                HDFS: Number of bytes read erasure-coded=0
        Job Counters 
                Launched map tasks=1
                Launched reduce tasks=1
                Data-local map tasks=1
                Total time spent by all maps in occupied slots (ms)=2460
                Total time spent by all reduces in occupied slots (ms)=2545
                Total time spent by all map tasks (ms)=2460
                Total time spent by all reduce tasks (ms)=2545
                Total vcore-milliseconds taken by all map tasks=2460
                Total vcore-milliseconds taken by all reduce tasks=2545
                Total megabyte-milliseconds taken by all map tasks=2519040
                Total megabyte-milliseconds taken by all reduce tasks=2606080
        Map-Reduce Framework
                Map input records=2
                Map output records=6
                Map output bytes=46
                Map output materialized bytes=54
                Input split bytes=93
                Combine input records=6
                Combine output records=5
                Reduce input groups=5
                Reduce shuffle bytes=54
                Reduce input records=5
                Reduce output records=5
                Spilled Records=10
                Shuffled Maps =1
                Failed Shuffles=0
                Merged Map outputs=1
                GC time elapsed (ms)=154
                CPU time spent (ms)=1330
                Physical memory (bytes) snapshot=546705408
                Virtual memory (bytes) snapshot=5198422016
                Total committed heap usage (bytes)=368574464
                Peak Map Physical memory (bytes)=319201280
                Peak Map Virtual memory (bytes)=2592329728
                Peak Reduce Physical memory (bytes)=227504128
                Peak Reduce Virtual memory (bytes)=2606092288
        Shuffle Errors
                BAD_ID=0
                CONNECTION=0
                IO_ERROR=0
                WRONG_LENGTH=0
                WRONG_MAP=0
                WRONG_REDUCE=0
        File Input Format Counters 
                Bytes Read=22
        File Output Format Counters 
                Bytes Written=28

Посетите страницу в это время:http://node1:18088/cluster (обратите внимание, что узел node1 настроен локально) 在这里插入图片描述

Щелкнув ссылку «История», вы перейдете на новую страницу. В нижней части страницы вы увидите карту и сокращение, перечисленные в TaskType. Итого представляет данные задачи карты и сокращения, необходимые для выполнения программы mapreduce, работающей в этот раз.

在这里插入图片描述

Как показано ниже, мы нажимаем соединение с картой в столбце TaskType.

Как показано на рисунке ниже, мы можем видеть соответствующую информацию о задаче карты, такую как статус выполнения, время начала и время завершения. 在这里插入图片描述

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

Из приведенных выше операций мы видим, что JobHistoryServer — это запись исторической информации об операциях во время работы задания, которая нам удобна для анализа задания.