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 🐧
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 🐧