Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Ответы к экзу по БД.docx
Скачиваний:
118
Добавлен:
12.02.2024
Размер:
258 Кб
Скачать
☆
  1. Hdfs. Worm подход. Почему hdfs не любит маленькие файлы? Почему Secondary NameNode нельзя считать backup Node?

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

WORM (Write Once, Read Many) подход — это подход к хранению данных, предполагающий, что данные могут быть записаны только один раз, но после этого они доступны для чтения многократно. В контексте HDFS WORM подход может использоваться для определенных типов данных, где гарантируется, что после записи они не будут изменяться (например данные конфигурации).

HDFS неэффективен при работе с маленькими файлами по следующим причинам:

    • Избыточность метаданных: Каждый файл в HDFS имеет ассоциированные с ним метаданные, которые хранятся в NameNode. При работе с множеством маленьких файлов это может привести к большому количеству метаданных, что оказывает давление на NameNode.

    • Накладные расходы на обработку: Обработка большого количества маленьких файлов требует множества операций ввода-вывода, что может снижать производительность.

Secondary NameNode нельзя считать backup Node по следующим причинам:

  • Не обрабатывает транзакции в реальном времени: Secondary NameNode обрабатывает снимки метаданных периодически (обычно, раз в час) и не реагирует на изменения метаданных в реальном времени. В случае отказа NameNode, данные, которые были изменены после последнего снимка Secondary NameNode, могут быть утрачены.

Не гарантирует непрерывную доступность: Secondary NameNode не создает мгновенные копии текущих метаданных. Восстановление требует времени, и в случае сбоя NameNode может потребоваться восстановление с использованием последнего снимка, что занимает некоторое время

  1. MapReduce. Стадии обработки клиентского запроса. Оптимизаторы: Combiner, Partitioner, Comparator с примерами использования. Хранение файлов до, вовремя и после выполнения запроса.

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

Стадии обработки клиентского запроса:

  1. Подготовка данных: Исходные данные подготавливаются для обработки в MapReduce задаче.

  2. Перед запуском MapReduce задачи входные данные разбиваются на независимые части(split)

  3. Map: предварительная обработка входных данных в виде большого список значений. При этом главный узел кластера (master node) получает этот список, делит его на части и передает рабочим узлам (worker node). Далее каждый рабочий узел применяет функцию Map к локальным данным и записывает результат в формате «ключ-значение» во временное хранилище. В MapReduce задачи может быть один или несколько Mapper (зависит от количества сплитов)сохраняет результаты в локальной системе)

  4. Shuffle: Данные распределяются на основе ключей (сформированных функцией Map) так, чтобы все данные с одинаковым ключом попали на один и тот же рабочий узел.

  5. Reduce: Данные, сгруппированные по ключам на разных рабочих узлах, передаются функции Reduce (сокращение) для получения конечных результатов. Число Reduce-ров задает сам пользователь. Reduce-фаза в MapReduce фреймворке не может начаться до завершения map-фазы из-за необходимости корректной сортировки, перемещения и подготовки данных для свертки, а также для обеспечения консистентности и точности результата.

Оптимизаторы MapReduce:

Combiner - это оптимизатор, который позволяет выполнять часть Reduce операций на данных еще до их отправки на Reduce узлы. Это позволяет уменьшить объем данных, передаваемых через сеть, и ускорить выполнение задачи.

Пример использования: если есть MapReduce задача для подсчёта слов, то Combiner может использоваться для локальной агрегации количества слов на каждом узле до отправки данных на Reduce узлы.

Partitioner - это оптимизатор, который определяет, как данные после Map стадии будут распределены между различными Reduce узлами. Это позволяет балансировать нагрузку и уменьшить количество данных, передаваемых через сеть. Этап, на котором определяется номер reducer для каждой пары key/value

Пример использования: если есть MapReduce задача для анализа данных по регионам, то Partitioner может использоваться для отправки данных о каждом регионе на отдельный Reduce узел.

Comparator - это оптимизатор, который определяет порядок сортировки ключей перед передачей на Reduce узлы. Это позволяет контролировать порядок объединения данных на Reduce узлах.

Пример использования: если есть MapReduce задача для анализа транзакций, то Comparator может использоваться для сортировки транзакций по времени перед их передачей на Reduce узлы.

Хранение файлов до, вовремя и после выполнения запроса:

  1. До выполнения запроса: Исходные данные обычно хранятся в распределенной файловой системе (HDFS), которая разбивает их на блоки и распределяет по узлам кластера.

  2. Во время выполнения запроса: Промежуточные данные и результаты этапов Map и Reduce хранятся во временных директориях на узлах кластера.

  3. После выполнения запроса: Окончательные результаты запроса сохраняются в указанной директории в распределенной файловой системе. Это позволяет последующим запросам эффективно использовать предыдущие результаты и уменьшить необходимость повторной обработки данных.