Проблема мелких файлов на практике

Я игралась с iceberg-таблицами, и у меня странно долго работали запросы. Исходные данные: 2,8 млрд строк и 111гб. Я поресерчила, что запросы сильно тормозят на этапе чтения. Пошла смотреть, как лежат данные, и увидела в каждой партиции по 100 файлов размером 1кб 🥺 `hdfs dfs -count /my_table

#1825 182400

1825 партиций, 182400 файлов - представляете, сколько накладных расходов открыть каждый файлик?

В чем особенность айсберга - вы не можете просто взять и переложить/пересохранить данные. Потому что в мете лежат ссылочки на файлики с данными. У вас просто все поломается 😒 Для компакта есть процедура рерайта:

`spark.sql("""CALL system.rewrite_data_files( table => 'my_db.my_table', options => map('target-file-size-bytes', '134217728') --128 мб )""")

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

После процедуры стало 6283 актуальных файликов - теперь все лежит как надо 👍

На картинке - запрос spark.table().cache().count(), который до компакта проходился по 5730 партициям, а теперь всего 856

Что получилось:

  • файлы уменьшились в 30 раз
  • таски в 6,7 раз
  • время в 1,8 раз``
Проблема мелких файлов на практике
Я игралась с iceberg-таблицами, и у меня странно долго работали запросы. Исходные данные: 2,8 млрд строк и 111гб | Сетка — социальная сеть от hh.ru