Hadoop и lakehouse

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

1. #hadoop_lakehouse1 / 5
   Зачем в HDFS большой размер блока (обычно 128 МБ) и репликация (по умолчанию 3)?

   A)Большой блок нужен, чтобы в один блок помещалось как можно больше разных мелких файлов сразу

   B)Репликация в 3 копии нужна для ускорения записи данных на диск параллельно

   C)Размер блока в HDFS не настраивается и жёстко зафиксирован на уровне ядра операционной системы

   D)Крупный блок — меньше overhead на скан; 3 реплики — надёжность+локальность

   показать ответ и разбор

   +D)Крупный блок — меньше overhead на скан; 3 реплики — надёжность+локальность

   // разбор: Большой блок (128 МБ против килобайтов у обычных ФС) выгоден для аналитики: доля времени на позиционирование (seek) и на метаданные NameNode мала относительно последовательного чтения большого блока, а число блоков (и нагрузка на NameNode) остаётся управляемым. Репликация по умолчанию 3 копии блока на разных узлах/стойках даёт отказоустойчивость (узел упал — данные живы), доступность и локальность вычислений (задачу шлют на узел, где лежит блок, — «двигаем вычисление к данным»). Отсюда и проблема мелких файлов: каждый занимает блок и запись в NameNode, раздувая метаданные.

2. #hadoop_lakehouse2 / 5
   Какую роль играет NameNode в HDFS и почему это критичная точка?

   A)Хранит метаданные (какие файлы из каких блоков и где лежат); без него кластер не найдёт данные — классический SPOF, лечится HA

   B)NameNode хранит сами блоки данных файлов, а DataNode отвечают лишь за их метаданные и имена

   C)NameNode выполняет пользовательские вычисления над данными, распределяя их между узлами кластера

   D)Отказ NameNode безопасен: соседний DataNode при его падении берёт его роль на себя

   показать ответ и разбор

   +A)Хранит метаданные (какие файлы из каких блоков и где лежат); без него кластер не найдёт данные — классический SPOF, лечится HA

   // разбор: NameNode — мастер HDFS: держит в памяти пространство имён (дерево файлов) и карту «файл → блоки → на каких DataNode они лежат». Сами данные на DataNode, но найти их без NameNode нельзя, поэтому его отказ парализует весь кластер — классическая единая точка отказа (SPOF). Метаданные в памяти также ограничивают число файлов (мелкие файлы раздувают namespace). В проде поднимают HA: активный + standby NameNode с общим журналом (JournalNodes) и автоматическим failover, чтобы пережить падение мастера. Это же причина, почему миллионы мелких файлов в HDFS — проблема.

3. #hadoop_lakehouse3 / 5
   Что такое YARN и какова его роль в Hadoop-кластере?

   A)YARN — это распределённая файловая система Hadoop, хранящая блоки данных на узлах кластера

   B)Планировщик ресурсов кластера, выдаёт контейнеры под задачи (Spark on YARN)

   C)YARN — движок SQL-запросов, транслирующий SQL в задачи над данными в хранилище Hadoop

   D)YARN отвечает за репликацию блоков между узлами ради отказоустойчивости хранения данных

   показать ответ и разбор

   +B)Планировщик ресурсов кластера, выдаёт контейнеры под задачи (Spark on YARN)

   // разбор: YARN (Yet Another Resource Negotiator) — слой управления ресурсами Hadoop. ResourceManager ведёт учёт свободных CPU/памяти по кластеру и распределяет их между приложениями, NodeManager на каждом узле запускает и следит за контейнерами, а ApplicationMaster приложения (например, Spark-джоба) договаривается с RM о контейнерах под свои исполнители. Так несколько фреймворков (Spark, MapReduce, Hive) делят один кластер, не мешая друг другу. «Spark on YARN» именно про это — Spark берёт исполнителей как контейнеры YARN. Аналогичную роль в облаке/современном стеке играет Kubernetes.

4. #hadoop_lakehouse4 / 5
   Что такое Hive metastore и зачем он нужен над файлами в озере?

   A)Hive metastore хранит сами данные таблиц в своей внутренней базе, заменяя собой HDFS и S3

   B)Metastore — это движок выполнения SQL-запросов, самостоятельно вычисляющий результаты над данными

   C)Каталог метаданных: хранит схемы, расположение и партиции таблиц поверх файлов — даёт SQL-таблицы над «кучей файлов» в HDFS/S3

   D)Metastore нужен для хранения прав доступа пользователей к таблицам хранилища

   показать ответ и разбор

   +C)Каталог метаданных: хранит схемы, расположение и партиции таблиц поверх файлов — даёт SQL-таблицы над «кучей файлов» в HDFS/S3

   // разбор: Файлы в HDFS/S3 сами по себе — просто байты; чтобы обращаться к ним как к таблицам через SQL, нужен каталог. Hive metastore хранит метаданные: имена таблиц, их схемы (колонки/типы), формат, физическое расположение файлов и список партиций. Движки (Hive, Spark SQL, Trino, Presto) спрашивают metastore «где данные таблицы orders и какая у неё схема» и читают соответствующие файлы. Так одни и те же файлы озера доступны разным движкам как согласованные таблицы. Metastore — стандарт де-факто каталога в Hadoop/lakehouse-стеке.

5. #hadoop_lakehouse5 / 5
   Чем managed-таблица Hive отличается от external?

   A)У external-таблицы DROP удаляет и метаданные, и файлы, а у managed — лишь метаданные

   B)Managed и external отличаются форматом файлов: managed — ORC, external — Parquet

   C)External-таблицу не получится читать через SQL, она доступна лишь напрямую как файлы

   D)Managed — DROP сносит файлы; external — DROP убирает лишь метаданные

   показать ответ и разбор

   +D)Managed — DROP сносит файлы; external — DROP убирает лишь метаданные

   // разбор: Различие — во владении данными. Managed (internal) таблица: Hive считает себя владельцем данных, они лежат в его складском каталоге, и DROP TABLE удаляет и метаданные, и сами файлы. External таблица: данные лежат по указанному внешнему пути и «принадлежат» кому-то ещё (другой пайплайн, общий бакет), Hive хранит лишь метаданные — DROP убирает определение таблицы, но файлы остаются. External берут, когда данными управляет внешний процесс или их читают несколько систем; managed — когда жизненный цикл данных целиком за Hive. Спутать опасно: DROP managed-таблицы необратимо сносит данные.