Евгений Виндюков 

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

Весь материал я публикую там. Тут просто стартовая страница

В прошлом посте я писал про мелкие файлы, которые получаются, если сохранить данные с помощью спарка в том виде, каком есть. Т.е. сохраняем в формате csv и он нам сохраняет не один файл, а много. Для сохранения в один нужно делать либо coalsece, либо repartition или toPandas (гуглите что это!)

Итак. Чем же плохи мелкие файлы. В HDFS все данные хранятся в виде блоков. Ну можно считать, что в виде файлов. Стандартно это 128Мб. Если правда файл загрузим меньшего размера, то файл остается того размера, который он и есть. Но не суть. Факт, что загрузили 500мб csv, он разбился на 4 блока. Каждый такой блочок еще и реплицируется (коппируется) по разным серверам.

Это сделано для того случая, если один из дисков вышел из строя, но данные мы не потеряли, потому что есть еще одна копия. Чисто безопасность. Фактор реппликации ставят стандартно 2 или 3. Но можно ставить любой.

Теперь понимаете, что кол-во файлов с репликами у нас выросло довольно быстро. Вместо того, чтобы хранить один единственный файл, мы храним 4 x 3 = 12 файлов (учитываем фактор реппликации).

В HDFS есть такая система, которая записывает адреса, где лежат все блоки. Нам нужно прочитать файл, а он разбит на блоки. Поэтому кто-то должен понимать, в какой последовательности собирать блоки, чтобы получить нужный файл. Эта штука называется NameNode. Она не хранит сами блоки, а хранит только метаданные. Грубо говоря адреса. Кстати, если эту NameNode уничтожить, то восстановить данные уже не получится, хотя физически на дисках они останутся. Поэтому есть Secondary NameNode, которая собирает слепок каждые несколько минут и является неким подстрахующим звеном.

Короче. Вот у вас 12 блоков, вместо одного. Естественно держать информацию о 12 блоках тяжелее, чем об одном. В какой-то момент память у вас закончится. NameNode это обычный диск и он не резиновый. Даже если у вас петабайты на HDD дисках для данных, то у NameNode может уже не оказаться места. И тогда все встанет.

В HDFS важно следить, чтобы не плодилось много мелких файлов. Спарк при сохранении таблиц как раз часто сохраняет файлы в формате parquet размером с Кб. И получается, что у вас может сохраниться до 20 000 новых файлов, хотя можно было обойтись и 4 000. Т.е. более компактно. Стремиться нужно к размеру блока в HDFS.

Резюмируем:

Много мелких файлов плохо – перегружаем память NameNode и чтение 1млн мелких фалойв это долго.

Ребят! Кто подписался. Подключите свои телеграмм и дискорд к аккаунту Boosty! Здесь я не вижу смысла писать посты. Основная тема будет именно в телеге и в дискорде!

1. SQL (Пройти полностью)

2. Python 1 (Пройти полностью)

3. Python 2 (Пройти 30-50%)

4. Pandas (Пройти полностью)

5. Pandas (Пройти 30-50%)

1. 🤖 Linux команды [Hexlet] - научись бегло пользоваться терминалом

2. 👩‍💻 Docker [40 минут Youtube] - научись собирать простые образы и контейнеры

3. Airflow [Youtube канал English] - разверни свой первый сложный Airflow docker-compose

4. 🧐 HDFS [Hadoop 1 час Youtube] - посмотри, как хранятся большие данные