Hadoop (hdfs) Flashcards
Что это простыми словами
Hadoop это набор компонентов, как минимум состоящий из:
* распределённая файловая система HDFS
* алгоритм обработки данных на распределённом кластере MapReduce/MR1 или YARN/MR2 (реализация с 2012 года, похожие алгоритмы, другая оркестрация ресурсов)
* Hadoop Common – набор библиотек с абстракциями для работы с кластером, скриптами для старта кластера и пр.
Также в кластер могут входить:
* Hive - SQL движок для работы с файлами как с таблицами
* Hive Metastore – часть Hive, хранит метаданные о связи “таблица” – “набор блоков”, которые могут переиспользовать другие инструменты (напр. SparkSQL)
* Spark - ETL инструмент
* HBase - распределенная NoSQL база данных, построенная поверх HDFS, для работы с данными в режиме реального времени
* Oozie - планировщик рабочих процессов для управления заданиями Hadoop
* Zookeeper - сервис координации распределенных приложений, обеспечивающий синхронизацию и управление конфигурацией
* Flume - распределенный сервис для сбора, агрегации и перемещения больших объемов лог-данных
* Sqoop - инструмент для эффективной передачи данных между Hadoop и реляционными базами данных
Архитектура
TODO
Сколько места займёт файл 10мб в HDFS; фактор репликации; размер блоков
30 МБ суммарно на трёх дата нодах + 420 байт в NameNode
Хадуп хранит данные по блокам, обычно 128МБ. Однако это не значит, что будет зарезервировано всё место блока, поэтому будет создана информация об одном блоке и одном файле размером 10 МБ. Если бы файл был больше размера блока, тогда занял бы кратное количество блоков с округлением вверх (300 МБ = 3 блока и тд).
С другой стороны, есть репликация (стандартный фактор репликации = 3). Это значит, что если мы помещаем один файл, он будет храниться в трёх местах (две копии). Такая избыточность в хранении позволяет использовать “дешёвое” железо, которое будет периодически умирать, а копии файлов будут восстанавливаться из других реплик.
Обычно не больше одной реплики блока на диск и не больше двух реплик на серверную стойку (группу нод). Поэтому 10 МБ х 3 = 30 МБ.
Бонус: на NameNode хранятся метаданные о том, как называется файл, где лежат реплики, на какие блоки разбит (если размер больше 1 блока).
* Метаданные об имени, дате создания и других атрибутах: 150 байт
* Маппинг блоков, связь между файлом и блоками: 150 байт (т.к. 1 файл = 1 блок)
* Инфа о репликах, на какой ноде лежит очередная копия блока: 40 байт х 3 = 120 байт
Как решить проблему мелких файлов
Во-первых, о чём это и почему это проблема: нет единой системы, которая решает любые проблемы эффективно. Hadoop оптимизирован под работу с большими файлами (в идеале размером >= 1 блок), сравни 128 МБ с средним JSON’ом в пару КБ. Поэтому, если бэкендеры льют данные в HDFS в привычном виде, кластер начинает очень быстро деградировать в плане производительности.
Почему? Как писал выше, создание каждого блока создаёт запись о метаданных в NameNode. И если этих файлов миллионы (общий объём – единицы Тб) вместо десятка тысяч (тот же объём с размером блока в 128 МБ), это создаёт “оверхэд”, т.е. избыточную нагрузку. Дольше происходит поиск нужных блоков для доступа к файлам, чтение и запись.
Если добавим в систему Hive Metastore, ему тоже становится плохо от такого. В метасторе хранится связь между таблицами и файлами, а также метаданные о партициях. В нём тоже создаётся слишком много записей для работы с, относительно хадупа, не таким большим объёмом данных.
Как решить проблему? Провести “compaction” данных, т.е. объединить много маленьких файлов в малое количество б’ольших файлов. Например, прочитать партицию Spark или подобным инструментом, записать в соседнюю директорию, а потом произвести своп. Проверить, что файлы по прежнему читаются и их стало сильно меньше, и потом удалить прошлую версию партиции. Тогда куча мусорных метаданных удалится и из NameNode с Metastore. Удобнее всего проводить эту операцию при охлаждении данных, когда в архив переносятся файлы с объединением партиций (дни до недель или месяцев, месяцы до кварталов или лет).
Ну и иногда можно договориться с бэкендерами и попросить накапливать батчи на их стороне перед записью, чтобы файлы стали крупнее :)
p.s. В современных форматах, таких как Iceberg, “compaction” это встроенная фича.
Как выглядят партиции
Вложенные друг в друга директории.
Например, таблица 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 будут исключены из паркетов, т.к. их значения уже хранятся в названиях директорий. При обращении к таблице обычно они подтягиваются движком и отображаются в таблице.
Роль YARN
TODO
Дистрибутивы: Cloudera vs Hortonworks vs Vanilla
TODO
