Hadoop Flashcards
Расскажи про архитектуру Hadoop? #Ярослав #wildberries
o Основные компоненты: HDFS (хранилище) и YARN (менеджер ресурсов).
o В HDFS – NameNode управляет метаданными, DataNode хранят блоки.
o YARN координирует запуск задач (ResourceManager) и управление контейнерами (NodeManager).
o MapReduce – фреймворк для параллельной обработки данных поверх YARN.
NameNode
* Основной управляющий узел HDFS.
* Хранит метаданные о структуре файловой системы: информацию о файлах, блоках, их расположении на DataNodes и структуру каталогов.
* Есть возможность настроить Secondary NameNode (или Standby NameNode в режиме высокодоступного кластера - High Availability), который периодически копирует метаданные от основного NameNode для резервирования.
DataNode
* Узлы хранения данных.
* Хранят блоки данных и отвечают за операции записи и чтения по запросу от клиентов или NameNode.
* Регулярно отсылают информацию о состоянии блоков в NameNode для мониторинга целостности и доступности данных.
ResourceManager
* Центральный узел управления ресурсами для YARN.
* Принимает запросы от ApplicationMaster и выделяет контейнеры с ресурсами на узлах для выполнения задач.
* Состоит из Scheduler и Application Manager, которые управляют выделением ресурсов и мониторингом приложений.
NodeManager
* Агент на каждом рабочем узле, который управляет ресурсами (процессор, память) для YARN.
* Запускает контейнеры по запросу от ResourceManager и контролирует их выполнение.
* Обеспечивает мониторинг состояния ресурсов на узле и отправляет отчёты ResourceManager.
ApplicationMaster
* Создаётся для каждого приложения, запускаемого на YARN.
* Управляет выполнением конкретного приложения (например, MapReduce или Spark), запрашивая ресурсы у ResourceManager.
* Координирует выполнение задач и следит за прогрессом приложения.
Secondary NameNode
* Резервный узел для основного NameNode, который периодически сохраняет метаданные и журналы.
* В современных кластерах часто заменяется на Standby NameNode для более надёжного резервирования в режиме высокодоступности (HA).
Кейс: вставляем кучу строк по одной (одну процессим и сразу вставляем, и так для каждой) в Hadoop – какая тут может возникнуть проблема? как избежать? #wildberries
- Проблема:
- HDFS (Hadoop Distributed File System) не предназначен для частых мелких записей. Каждый раз при записи файла происходит накладная операция — создаётся файл-«контейнер» в HDFS, который хранится в блоках по 128 МБ (или 256 МБ в некоторых конфигурациях).
- Если писать «построчно», то каждая строка может становиться отдельным маленьким файлом в HDFS. В итоге получим огромное количество крошечных файлов (small files problem), что приводит к перегрузке метаданных NameNode и снижению производительности (NameNode хранит метаданные о всех файлах и блоках).
- Как избежать:
1. Бачивые вставки (Bulk loading): Собирать данные в буфер (например, в локальный файл или промежуточную очередь Kafka/Flume/HDFS sink) и загружать большими партиями. Тогда каждый батч генерирует относительно крупный файл (сотни МБ).
2. Использование партицированной структуры и механизмов типа INSERT OVERWRITE или INSERT INTO в Hive/Spark, но с учётом, что данные тоже должны поступать пакетно.
3. Комбайн-файлов (File compaction): Некоторые инструменты (например, Hive, Spark, HBase compactions) могут периодически сливать маленькие файлы в крупные.
4. Стриминг (Kafka + Spark Streaming/Flume/NiFi): Данные принимаются в потоковом режиме, но внутри системы настроен механизм, агрегирующий записи в более крупные файлы.
Что такое Yarn? #wildberries Астон
YARN (Yet Another Resource Negotiator)YARN управляет распределением ресурсов в кластере и выполняет задачи по управлению и планированию вычислительных процессов.
ResourceManager: Централизованный компонент, который управляет распределением ресурсов и назначает задачи на узлы.
NodeManager: Узел, который отвечает за выполнение задач на DataNode, контролирует использование ресурсов на узле и отчитывается ResourceManager.
ApplicationMaster: Управляет выполнением конкретного приложения и координирует задачи на узлах.
Какая структура у HDFS? #Cian #Ярослав
- NameNode — «головной узел» (master), хранит метаданные о всех файлах и блоках (где какой блок находится). Без NameNode работа HDFS невозможна, так как именно он управляет файловой системой.
2. DataNode — «рабочие узлы», на которых физически лежат блоки данных. Каждый блок файла может реплицироваться на несколько DataNodes (по умолчанию репликация = 3).
3. Secondary NameNode или Checkpoint Node — вспомогательная служба, которая периодически объединяет журналы транзакций NameNode и снапшоты (FSImage), чтобы NameNode не распухал. (В современных кластерах могут использоваться HA-NameNode, JournalNode и т.д.)
Как всё устроено:
* Файл в HDFS делится на блоки (обычно 128 МБ). Каждый блок распределён по DataNodes.
* NameNode хранит только информацию о том, какой файл, какие у него блоки и где эти блоки лежат.
* При чтении/записи клиент запрашивает у NameNode список DataNode и взаимодействует с ними напрямую (NameNode не гоняет «полный» поток данных).
- Итог: HDFS — это распределённая файловая система, где метаданные держит один координатор (NameNode), а данные рассыпаются на несколько DataNodes в виде блоков. Это даёт масштабирование и отказоустойчивость (при условии репликации).
Проблема маленьких файлов в HDFS #Cian
+Как решить проблему мелких файлов
Во-первых, о чём это и почему это проблема: нет единой системы, которая решает любые проблемы эффективно. Hadoop оптимизирован под работу с большими файлами (в идеале размером >= 1 блок), сравни 128 МБ с средним JSON’ом в пару КБ. Поэтому, если бэкендеры льют данные в HDFS в привычном виде, кластер начинает очень быстро деградировать в плане производительности.
Почему? Как писал выше, создание каждого блока создаёт запись о метаданных в NameNode. И если этих файлов миллионы (общий объём – единицы Тб) вместо десятка тысяч (тот же объём с размером блока в 128 МБ), это создаёт “оверхэд”, т.е. избыточную нагрузку. Дольше происходит поиск нужных блоков для доступа к файлам, чтение и запись.
Если добавим в систему Hive Metastore, ему тоже становится плохо от такого. В метасторе хранится связь между таблицами и файлами, а также метаданные о партициях. В нём тоже создаётся слишком много записей для работы с, относительно хадупа, не таким большим объёмом данных.
Как решить проблему? Провести “compaction” данных, т.е. объединить много маленьких файлов в малое количество б’ольших файлов. Например, прочитать партицию Spark или подобным инструментом, записать в соседнюю директорию, а потом произвести своп. Проверить, что файлы по прежнему читаются и их стало сильно меньше, и потом удалить прошлую версию партиции. Тогда куча мусорных метаданных удалится и из NameNode с Metastore. Удобнее всего проводить эту операцию при охлаждении данных, когда в архив переносятся файлы с объединением партиций (дни до недель или месяцев, месяцы до кварталов или лет).
Ну и иногда можно договориться с бэкендерами и попросить накапливать батчи на их стороне перед записью, чтобы файлы стали крупнее :)
Как выглядит партиция в Хадупе? #Ярослав
Вложенные друг в друга директории.
Например, таблица orders в бд shop с партициями по году и месяцу может выглядеть так:
/shop.db/orders/year=2024/month=06/part-00000-33b48309-0442-4e86-870f-f3070268107f-c000.snappy.parquet
/shop.db/orders/year=2024/month=06/part-00001-33b48309-0442-4e86-870f-f3070268107f-c000.snappy.parquet
/shop.db/orders/year=2024/month=06/part-00002-33b48309-0442-4e86-870f-f3070268107f-c000.snappy.parquet
/shop.db/orders/year=2024/month=07/part-00000-5daj5809-1551-8h46-83jn-dsdad8sdads6-d1d0.snappy.parquet
/shop.db/orders/year=2024/month=07/part-00001-5daj5809-1551-8h46-83jn-dsdad8sdads6-d1d0.snappy.parquet
При этом колонки year и month будут исключены из паркетов, т.к. их значения уже хранятся в названиях директорий. При обращении к таблице обычно они подтягиваются движком и отображаются.
Как автоматизировать решения проблемы мелких файлов в Hadoop? #Иннотех #мир
Автоматизировать решение проблемы мелких файлов в Hadoop можно следующими способами:
Объединение файлов при загрузке
Использовать Hadoop Archive (HAR) для группировки файлов.
Загружать данные в большие последовательные файлы (SequenceFile, Avro, Parquet).
Использовать Apache Flume или Apache NiFi для объединения потоков данных.
Оптимизация на уровне HDFS
Настроить HDFS Balancer для перераспределения блоков.
Увеличить размер блоков HDFS (dfs.blocksize).
Объединение файлов в Spark/MapReduce
Использовать coalesce() или repartition() в Apache Spark.
Запускать MapReduce-задачи для слияния файлов перед обработкой.
Hive & Impala
Настроить Hive compaction (major/minor compaction) в ACID-таблицах.
Использовать INSERT OVERWRITE для перезаписи данных в крупных файлах.
Airflow/DAG
Настроить DAG в Apache Airflow, который периодически запускает процессы объединения файлов.
Чем Hadoop отличается от PgSQL #Астон
o Hadoop – распределенная система для хранения и обработки больших объемов данных (batch-ориентирована), а PostgreSQL – реляционная СУБД с сильной транзакционной семантикой.
o Hadoop масштабируется горизонтально (добавлением узлов), PostgreSQL чаще масштабируют вертикально (увеличивая ресурсы одного сервера) или используют шардирование.
o Hadoop фокусируется на аналитической обработке, PostgreSQL – на OLTP (оперативных транзакциях) и аналитике меньших объемов.
Какой размер блоков в Hadoop? #Ярослав
По умолчанию в современных версиях Hadoop размер блока 128 МБ (ранее было 64 МБ), но этот параметр можно конфигурировать.
Как в хадупе получить Merge Join? — хотел услышать про бакетинг. #wildberries
- Понятие Merge Join: В классических СУБД (Postgres, Oracle) Merge Join выполняется над отсортированными наборами. В Hadoop (в частности, в Hive) схожий механизм достигается благодаря bucketing и sorting.
- Bucketing (бакетинг) в Hive**:
1. Используем DDL типа:
CREATE TABLE mytable (
…
)
CLUSTERED BY (join_key)
SORTED BY (join_key)
INTO N BUCKETS;
- При таком определении таблица делится на «бакеты» (файлы), причём каждая строчка попадает в бакет по хешу join_key.
- Если мы одинаково настроим bucketing (и sorting) для двух таблиц по одним и тем же ключам и с одинаковым числом бакетов, то при JOIN по join_key Hive понимает, что данные внутри каждого бакета уже отсортированы и «соотносятся» (co-located).
* Эффект:
o Hive (или Spark SQL) может выполнить более эффективный Merge Join, так как внутри каждого бакета данные уже отсортированы, и можно «сливать» (merge) без дополнительной сортировки или shuffle.
o Условие, чтобы число бакетов и ключи бакетинга в обеих таблицах совпадали. Тогда join внутри каждого бакета идёт локально, упрощая перераспределение.
- Важно:
o Bucketing разумно использовать, если данные часто джойнятся по одному и тому же ключу. Иначе выгоды может не быть.
o Нужно следить за количеством бакетов (N), чтобы не получить слишком мелкие файлы или наоборот слишком большие перекосы.
Вывод: Чтобы получить что-то аналогичное Merge Join в Hive, часто применяют bucketing + sorting по ключам, согласованным между таблицами.
Без чего не может работать Hadoop? #Rubbles
- На базовом уровне Hadoop (HDFS) не может работать без NameNode, так как именно NameNode управляет метаданными всей файловой системы.
o Если NameNode упал (и нет кластерного HA-решения), данные становятся недоступны, хотя физически блоки на DataNodes существуют. - Если смотреть шире, можно сказать, что без YARN (или другого resource manager) полный стект (Hadoop 2.x/3.x) не сможет распределять задания (MapReduce, Spark и т.д.) по кластерам.
o Но чисто HDFS (без исполнения вычислительных задач) может жить без YARN. - Часто говорят, что NameNode — это «точка единого отказа» (Single Point of Failure). В современных продакшен-кластерах обычно используют HA NameNode (двойной NameNode + журнал JN), чтобы избежать SPOF.
Сколько займёт файл 10мб в хадупе? #Ярослав
30 МБ суммарно на трёх дата нодах + 420 байт в NameNode
Хадуп хранит данные по блокам, обычно 128МБ. Однако это не значит, что будет зарезервировано всё место блока, поэтому будет создана информация об одном блоке и одном файле размером 10 МБ. Если бы файл был больше размера блока, тогда занял бы кратное количество блоков с округлением вверх (300 МБ = 3 блока и тд).
С другой стороны, есть репликация (стандартный фактор репликации = 3). Это значит, что если мы помещаем один файл, он будет храниться в трёх местах (две копии). Такая избыточность в хранении позволяет использовать “дешёвое” железо, которое будет периодически умирать, а копии файлов будут восстанавливаться из других реплик.
Обычно не больше одной реплики блока на диск и не больше двух реплик на серверную стойку (группу нод). Поэтому 10 МБ х 3 = 30 МБ.
Бонус: на NameNode хранятся метаданные о том, как называется файл, где лежат реплики, на какие блоки разбит (если размер больше 1 блока).
. Метаданные об имени, дате создания и других атрибутах: 150 байт
. Маппинг блоков, связь между файлом и блоками: 150 байт (т.к. 1 файл = 1 блок)
. Инфа о репликах, на какой ноде лежит очередная копия блока: 40 байт х 3 = 120 байт
Что такое map reduce? #тг
MapReduce – это модель параллельных вычислений, представленная компанией Google, которая используется для работы с большими объёмами данных в Hadoop кластере.
Модель вычислений MapReduce состоит из стадий:
1. Map: выполняемая параллельно фаза отображения, в которой входные данные разделяются на конечное множество блоков для последующей обработки. Как правило, вычисления легковесны, выполняются параллельно и независимо. Например, нам нужно по какому-то условию отфильтровать данные.
2. Shuffle: операция передачи данных от Map к Reduce (перемешивание и рассылка).
3. Reduce: фаза свёртки, в которой вывод фазы отображения агрегируется для получения конечного результата. На каждый Reducer попадут значения с одним ключом (будут сгруппированы). Например, операции группировки, сортировки, нахождения агрегированных значений.
Что такое HDFS блоки и какие у них есть минусы?
Блок — это кусочек файла стандартного размера. Во второй версии HDFS, которая сейчас считается основной, это 128 МБ. Соответственно, исходный файл разделяется на блоки по 128 МБ, которых может быть десять, а несколько тысяч. Каждый блок с информацией реплицируется на несколько узлов для обеспечения отказоустойчивости.
Минусы HDFS блоков:
Фрагментация и дисковая неэффективность – если файл меньше блока, он всё равно занимает весь блок, что приводит к потере места. Высокая задержка при малых файлах – метаданные хранятся в NameNode, а их большое количество замедляет работу. Ограничение по количеству блоков – NameNode хранит информацию о каждом блоке в оперативной памяти, что создаёт лимит на общее число файлов в системе. Оверхед на репликацию – HDFS создаёт несколько копий (обычно 3) для отказоустойчивости, что увеличивает использование дискового пространства. Медленный доступ к отдельным файлам – HDFS оптимизирован для последовательного чтения больших файлов, а случайный доступ работает медленно.
