Apache Iceberg - зачем он нужен?

Iceberg всё чаще встречается в вакансиях и архитектуре. Что это: база данных, альтернатива Parquet или часть Spark?

Iceberg - открытый табличный формат. Он не заменяет Parquet и не выполняет запросы вместо Spark или Trino.

Допустим, в S3 лежит таблица из множества Parquet-файлов. Parquet определяет устройство каждого файла, но ничего не знает о таблице целиком.

Какие файлы сейчас актуальны? Что делать, если две джобы одновременно записывают данные? Как вернуть таблицу в состояние до неудачной загрузки?

Iceberg хранит над файлами метаданные: схему, партиционирование, статистику и историю изменений.

Таблица состоит из snapshots - её версий. Каждый snapshot содержит точный список файлов на определённый момент.

При записи создаются новые файлы и метаданные, затем выполняется атомарный коммит. Другие запросы видят либо предыдущую версию таблицы, либо уже полностью записанную новую.

Что это даёт?

1. Конкурентная запись

Несколько джоб могут одновременно работать с таблицей. При коммите Iceberg проверяет, не изменились ли затронутые данные, и обнаруживает конфликт.

2. Time travel и rollback

Можно прочитать таблицу в состоянии на определённый момент или вернуть её к предыдущему snapshot после ошибочной загрузки.

3. Безопасное изменение схемы

Колонки можно добавлять, удалять и переименовывать. Iceberg различает их по внутренним ID, поэтому переименование не считается удалением одной колонки и созданием другой.

4. Скрытое партиционирование

В запросе можно фильтровать обычную колонку с timestamp, а Iceberg сам определит подходящие партиции. Способ партиционирования можно менять без немедленной перезаписи старых файлов.

5. Планирование чтения

По статистике в метаданных движок заранее исключает файлы, в которых нет нужных данных. Для таблиц с миллионами файлов это сильно сокращает объём чтения.

Почему недостаточно DWH, например Greenplum?

В MPP-СУБД хранение и вычисления находятся в одном кластере. Расширяя его ради растущего объёма данных, приходится добавлять и вычислительные ресурсы.

В S3 хранение масштабируется отдельно, а разные движки могут работать с одними файлами. Iceberg добавляет им возможности таблицы. При этом DWH продолжает решать свои задачи.

Почему Iceberg появился только сейчас?

Раньше большие данные строились вокруг Hadoop, HDFS и пакетных загрузок. Для многих задач каталогов и партиций хватало.

С распространением объектных хранилищ одну таблицу начали использовать разные движки. Понадобился общий формат для управления миллионами файлов, каталоги с атомарными коммитами и поддержка в самих движках. Поэтому Iceberg стал востребован именно сейчас.

Что Iceberg даёт этим движкам?

Iceberg - не отдельный сервер. Это спецификация таблицы, библиотеки и интеграции.

Они объясняют движку, как найти нужные файлы, применить фильтры, прочитать таблицу, записать новую версию и выполнить коммит. Движок занимается вычислениями, а Iceberg отвечает за состояние таблицы.

Снаружи всё действительно выглядит просто. Но внутри snapshot ссылается на manifest list, тот - на manifests, а в них уже хранятся списки data files и статистика.

Iceberg также разрешает конфликты между параллельными записями, повторяет неудачные коммиты, отслеживает удаления и сохраняет файлы, которые ещё нужны старым snapshots.

Таблицы приходится обслуживать: объединять небольшие файлы, удалять старые snapshots, очищать потерянные файлы и оптимизировать manifests.

То есть идея простая, а реализация нет. Пользователь видит обычную таблицу именно потому, что основная сложность спрятана внутри формата и его интеграций.

————
Как вам формат? Хочу чаще делать посты, писать на понятном языке про всякие de-шные (и не только) технологии.


it пингвин | data engineer 🐧