МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ СВЯЗИ И МАССОВЫХ

КОММУНИКАЦИЙ
Ордена Трудового Красного Знамени
Федеральное государственное бюджетное образовательное учреждение
высшего образования
«Московский технический университет связи и информатики»

Кафедра «Математическая кибернетика и информационные технологии»

Отчет по лабораторной работе №2

по дисциплине «Математические методы в больших данных»

Выполнил:

Студент группы БВТ2203

Бородин К.Н.

Руководитель:

Иевлев К.О.

Москва, 2024
 Введение

Смысла MapReduce – разбиение данные на мелкие части,

обрабатываемые на нескольких хостах.

Маппер – применяет к каждому сплиту функцию и отображает их в

пары ключ значение.

Shuffle and sort – данные сортируются для подачу в редюсер.

Reducer – Данные обрабатываются согласно функцию reduce.

Combine – Если на одном рабочем узле встречается несколько значений

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

Границы сплита и блока могут не совпадать, но по умолчанию у них

размер 128 мб.

Работа с данным происходит следующим образом:

1. Данные загружаются на HDFS или на локалку, формируя InputSplit.

Данные сплита обрабатываются в контейнерах для каждого маппера.
2. Данные от маппера сохраняются локально. Промежуточные данные не
записываются в HDFS. При возникновении сбоя легче создать ещё один
маппер.
3. После шафл-н-сорт они попадают на редьюсер, после которого
записывают на HDFS. Количество финальный файлов равно количество
редьюсеров.

YARN – связывает блок хранение данные с различными инструментами

для их обработки.

Компоненты:

 Менеджер ресурсов, которые управляет ими на кластере

 Node менеджер, отвечает за выполнение данные на каждом узле данные
  Application manager управляет жизненным циклом пользовательских
заданий и потребностями отдельных приложений в ресурсах.
 Контейнер: пакет ресурсов, включая ОЗУ, ЦП, сеть, жёсткий диск и
другое на одном узле.

Менеджер ресурсов основной элемент в их распределение. После

получения запроса на обработку, передаёт части к соответствующим
менеджерам узлов. Арбитр ресурсов кластера. Оптимизирует использование
ресурсов. Состоит из планировщика и диспетчера приложений. Планировщик
отвечает за распределение ресурсов между приложениями с учетом
ограничений. Менеджер приложений отвечает за представленные вакансии,
согласовывает контейнер с диспетчером ресурсов, управляет запуском
мастеров приложений и предоставляет сервис для перезапуска контейнера
мастера приложений.

Диспетчер узлов регистрирует в диспетчере ресурсов контрольные

сообщения о состоянии работоспособности узла. Его цель – управлять
контейнерами приложений. Он постоянно обновляется с помощью
диспетчера ресурсов. Application master запрашивает у него назначенный
контейнер, отправляя ему контекст запуска контейнера. Диспетчер узлов
создаёт запрошенный процесса контейнера и запускает го. Контролирует
использование ресурсов отдельный контейнеров.

Application master – процесс, координирующий выполнение приложений в

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

Контейнер – набор физических ресурсов. Контейнер YARN управляется

контекстом запуска контейнера. Он предоставляет приложению права
использования определённого количества ресурсов
Сценарий выполнения:

1. Клиент пишет функции мапа и редюса. Происходит сабмит в менеджер

ресурсов
2. Менеджер ресурсов создаёт контейнер с application master
3. Application macter обращается к name node, чтобы получить адреса
блоков с данными для файла
4. Name node возваращает адреса всех реплик
5. Application master обращается к менеджеру ресурсов для созданий
контейнеров на тех хостах, где лежат блоки с данным.
6. Менеджер ресурсов обращается к планировщику и запрашивает
свободные слоты для выполнения задачи пользователя
7. Менеджер ресурсов возаращает информацию application master
8. Application master связывается с менеджерами узлов
9. Менеджеры узлов получают задачу запустить код в контейнере.
[Link] master периодически посылает данные о состоянии
обработки данных
11.Мапперы отработали, данные записываются на диск
12.Приосходит сортировка и перемещение данные для формирования
входные данных для редьюсера
13.Редьюсеры отрабатывают и данные записываются на hdfs
[Link] manger отменяет регистрацию в менеджере ресурсов

Кладётся одна копия мапперов, редюсеров и файлов на каждый хост

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

Планировщик FIFO – клиент который пришёл первые, занимает все

ресурсы. Данные нельзя запустить в паралель, механизм приоритетов задач.

Fair – динамическое распределние ресурсов между текущими задачим.

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

Capacity – мехинзм лимитов. Софт – гарантированно на любую задачу.

Хард – максимальный процент ресурсов класера.

Ход работы

Выполняю команду из методических материалов для просмотра всех

возможных map-reduce сценариев, рисунок 1.

Рисунок 1 – выполнение команды

Выполняю команду, для расчёта числа пи, рисунок 2.

Рисунок 2 – подсчёт числа пи.

Вывод работы представлен на рисунках 3-6.

Рисунок 3 – вывод программы.

Рисунок 4- вывод программы.

 Рисунок 5 – вывод программы.

Рисунок 6 – вывод программы.

Увеличиваю количество точек в 10 раз, результат представлен на

рисунке 7.
 Рисунок 7 – результат вычисления.

Точность стала больше. Перехожу в амбари и нахожу ссылку для

перехода в UI интерфейс, рисунок 8.
 Рисунок 8 – ссылка для перехода.

Открылось следующее окно, рисунок 9.

Рисунок 9 – yarn UI.

Нахожу свои процессы, рисунок 10.

 Рисунок 10 – мои процессы.

Получаю информацию о своих процессах, рисунки 11-12.

Рисунок 11 – информация о процессе.

Рисунок 12 – информация о процессе.

 Запускаю процесс, у которого очень много точек, и смотрю на
использование им ресурсов, рисунок 13.

Рисунок 13 – используемые ресурсы.

Resource Usage Информация по нодам

Сколько памяти занимает 4 – 4ГГБ
приложение на каждой ноде? 5 – 1ГГБ
6 – 1ГГБ
Сколько виртуальных ядер выделено 4 – 4
под задачу на каждой ноде? 5–1
6–1
Какое количество контейнеров 4–4
создано для решения задачи на 5–1
каждой ноде? 6–1
 Серверы были запущены на 4, 5 и 6 нодах.

Запускаю задачу ещё раз и смотрю активные процессы, рисунок

14.

Рисунок 14 – активные процессы.

Принудительно останавливаю свой процесс, рисунок 15.

Рисунок 15 – принудительная остановка процесса.

Статус процесса в UI изменён, рисунок 16.

Рисунок 16 – изменение статуса процесса.

Скачиваю локально примеры, рисунок 17.

Рисунок 17 – скачивание примеров локально.

На рисунках 18, 19 показан маппер и редьюсер соответсвенно.

 Рисунок 18 – маппер.

Рисунок 19 – редьюсер.
Отправляю на файлы на локальную машину, рисунок 20.

Рисунок 20 – отправка файлов.

Запускаю локально задачу, рисунок 21.

Рисунок 21 – запуск задачи локально