Архитектура Apache Iceberg: как устроена таблица поверх S3 (Ч. 2)

👍 👍 👍 👍 Архитектура Apache Iceberg: как устроена таблица поверх S3 (Ч. 2) В прошлом посте обсуждали связку Trino + Iceberg. Теперь разберёмся, за счёт чего Iceberg вообще превращает “папку с файлами в S3” в полноценную аналитическую таблицу. ⚙️ Как устроен Iceberg Если упрощать, у Iceberg несколько уровней: 1 Catalog 2 Metadata layer 3 Snapshot 4 Manifest list/manifest files 5 Data/Delete files Вся магия Iceberg в слое метаданных, который управляет тем, какие файлы относятся к таблице, в каком состоянии она находится сейчас и какую версию данных должен читать движок. Ниже разберем каждую сущность отдельно: 1 Catalog Это слой, который отвечает за учёт таблиц и их текущего состояния. Он хранит: ➖ список таблиц ➖ путь к актуальному metadata file каждой таблицы То есть каталог — это не хранилище данных, а реестр актуальных версий таблиц. Каталог может быть разным, Iceberg не привязан к одному хранилищу метаданных — можно выбрать, где хранить этот “реестр”: Hive Metastore (вариант из Hadoop-мира), JDBC Catalog (таблицы в обычной БД), Project Nessie (каталог с git-подобными ветками) или другие форматы. В них меняется реализация, но логика остается той же. 2 Metadata layer Это основной уровень управления таблицей. Главный metadata file хранит: ➖ схему таблицы ➖ список snapshot’ов ➖ ссылки на manifest list Каждое изменение таблицы создаёт новый metadata file (далее подробнее о нем). За счёт этого Iceberg поддерживает версионирование, роллбэк, тайм тревел и безопасное изменение схемы 3 Snapshot’ы Это конкретная зафиксированная версия таблицы в момент времени. Iceberg не “переписывает таблицу целиком” при каждом изменении. Он создаёт новый snapshot, который ссылается на актуальный набор файлов через manifest list. То есть: таблица = не просто набор файлов, а грубо говоря цепочка snapshot’ов, у каждого из которых своё состояние данных 4 Manifest list и manifest files Вот здесь начинается самое важное для производительности. Manifest list — это список manifest-файлов, относящихся к конкретному snapshot’у. А сами manifest files уже содержат информацию о data files и delete files: какие файлы входят в таблицу, какие у них партиции и статистики (min/max, null count и т.д.). За счёт этого движок ещё на этапе planning понимает, какие файлы можно вообще не читать. Именно так работают file/metadata pruning и data skipping. 5 Data files Это уже сами файлы с данными в object storage: Parquet, ORC, Avro. Чаще всего в аналитике используют Parquet. Важно, что сами data files не знают, что они часть таблицы — они просто хранят данные. Вся логика таблицы находится на уровне метаданных. 5 Delete files Iceberg поддерживает не только append, но и DELETE / UPDATE / MERGE. Для этого используются delete files: position deletes — удаление строк по позиции в файле, equality deletes — удаление по значению ключа. При чтении движок учитывает и data files, и delete files, чтобы собрать актуальное состояние таблицы. Как происходит commit Iceberg не переписывает таблицу целиком. При изменении он создаёт новые data/delete files, новые manifest’ы, собирает новый snapshot, формирует новый metadata file и обновляет указатель в catalog. По сути commit — это переключение таблицы на новую версию. За счёт этого Iceberg даёт atomic commit, snapshot isolation и optimistic concurrency control. Как выполняется запрос Если совсем упростить: catalog → metadata file → snapshot → manifest list → manifest files → нужные data files. То есть движок не читает все файлы в S3 подряд, а заранее отсекает лишние. Поэтому Iceberg — это не просто папка с parquet-файлами, а полноценный табличный формат поверх object storage. Резюмируя, Iceberg — это слой метаданных и snapshot-логики, который превращает S3 в управляемую аналитическую таблицу. ❤️‍🔥 Подписывайтесь и поддержите канал бустом ↗️ Менторю и помогаю выйти на оффер ❓ Был ли у вас на проекте Iceberg или пока не доходили до него? @data_driven_bogdan