Apache Iceberg — это открытый формат таблиц, предназначенный для высокопроизводительной аналитики, работающей в объектных хранилищах. Отделяя состояние таблицы от структуры файлов в каталогах, Iceberg привносит ACID-транзакции, эволюцию схемы и возможность «путешествий во времени» (time travel) в объектные хранилища, такие как S3, ADLS и GCS.

На структурном уровне каталог таблиц отслеживает указатель на текущий файл метаданных, который ведет вниз по неизменяемому дереву к спискам манифестов, файлам манифестов и базовым объектам данных. Такая архитектура обеспечивает полную совместимость с различными движками, но также создает специфические характеристики накопления метаданных, которые определяют, сохранит ли озеро данных (data lakehouse) скорость выполнения запросов с течением времени.

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

Ключевые выводы

Iceberg определяет таблицы через явные деревья метаданных, а не через структуру папок, избавляя движки выполнения от накладных расходов на сканирование каталогов.
Обновления таблиц основаны на атомарной замене указателя в каталоге с использованием оптимистичного параллелизма, что обеспечивает сериализуемую изоляцию и стабильные снимки для читателей.
Файлы манифестов содержат статистику по столбцам для каждого файла данных, позволяя движкам запросов отсеивать нерелевантные файлы до начала чтения из хранилища.
Каждая запись добавляет новые файлы метаданных и объекты данных, что делает истечение срока действия снимков и уплотнение (compaction) важными эксплуатационными задачами.

Что такое Apache Iceberg и чем он не является

Apache Iceberg — это спецификация открытого формата таблиц, которая обеспечивает надежность и производительность уровня баз данных для крупномасштабных озер данных. Изначально разработанный в Netflix для преодоления узких мест масштабирования устаревших таблиц Hive, Iceberg теперь является проектом Apache Software Foundation, поддерживаемым широким сообществом разработчиков с открытым исходным кодом.

Чтобы понять Iceberg, полезно разграничить, чем он является, а чем нет:

Это открытая спецификация, а не база данных или движок выполнения. Iceberg определяет, как состояние таблицы, схемы и манифесты файлов структурированы в метаданных, позволяя таким движкам, как Trino, Spark и Flink, работать одновременно с одними и теми же таблицами.
Это слой абстракции метаданных, а не физический движок хранения. Iceberg располагается непосредственно поверх существующих объектных хранилищ, включая Amazon S3, Azure Data Lake Storage (ADLS), Google Cloud Storage (GCS), MinIO или HDFS.
Он отслеживает файлы явно, а не по каталогам. Устаревшие форматы, такие как Apache Hive, отслеживали таблицы по путям к папкам, требуя от движков перечисления целых каталогов для определения существующих файлов. Iceberg устраняет накладные расходы на перечисление каталогов, поддерживая явный канонический инвентарь каждого файла данных, принадлежащего версии таблицы.

3 уровня Iceberg

Таблица Iceberg функционирует на трех различных структурных уровнях: каталог, слой метаданных и слой данных.

Каталог

Каталог служит центральным источником истины для таблицы Iceberg, храня указатель на текущий файл метаданных таблицы. Каждый коммит — это атомарная замена этого указателя. Либо новый файл метаданных становится текущим, либо коммит завершается неудачей, и существующий указатель остается неизменным.

Поскольку каталог обеспечивает гарантию атомарной замены, выбор каталога напрямую влияет на совместимость системы. Варианты включают REST-каталог Iceberg, Hive metastore или управляемые облачные метасторы. Starburst поддерживает спецификацию Iceberg REST API в управляемых и корпоративных развертываниях, предоставляя стандартизированный слой каталога для различных движков запросов.

Слой метаданных

Слой метаданных находится непосредственно под каталогом и состоит из трех вложенных типов файлов:

Файлы метаданных таблицы: записанные в формате JSON, эти файлы фиксируют схему таблицы, спецификации партиционирования, ID текущего снимка и журнал исторических снимков. Каждая вставка, обновление или эволюция схемы добавляет новый файл метаданных таблицы.
Списки манифестов: файл Avro, представляющий конкретный снимок таблицы. Список манифестов указывает на один или несколько файлов манифестов и хранит сводки границ партиций для этих манифестов.
Файлы манифестов: файлы Avro, которые отслеживают отдельные файлы данных вместе с метриками на уровне столбцов, количеством пустых значений (null), нижними и верхними границами, а также значениями партиций. Движки запросов оценивают эту статистику, чтобы пропускать целые файлы данных во время оценки фильтров без сканирования объектного хранилища.

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

Файл метаданных — это JSON. Он содержит схему, спецификацию партиций, список снимков и текущий снимок. Каждый снимок указывает на один список манифестов, а этот список указывает на манифесты. Снимки могут совместно использовать манифесты, поэтому при истечении срока действия снимка необходимо проверять, на что все еще есть ссылки. Файлы манифестов перечисляют файлы данных вместе с их значениями партиций и статистикой на уровне столбцов. Движки используют эту статистику, чтобы пропускать файлы, которые не могут соответствовать фильтру. Метаданные выполняют отсечение, которое раньше делалось за счет структуры каталогов. Когда вы создаете таблицу, Iceberg записывает папку метаданных. Она содержит первый файл метаданных таблицы, который описывает пустую таблицу. Каждая вставка, обновление или удаление затем добавляет новые манифесты, новый список манифестов и новый файл метаданных. Эти транзакции и изменения метаданных — это то, что записывает каждая инструкция. Скрытое партиционирование также находится здесь. Преобразования партиций находятся в метаданных, поэтому вы запрашиваете обычные столбцы и никогда не ссылаетесь на пути партиций. Более того, вы можете изменить спецификацию партиций без перезаписи старых данных.

Слой данных

Слой данных состоит из базовых физических объектов хранения, содержащих ваши записи. Iceberg хранит данные в оптимизированных колоночных форматах, преимущественно Parquet или ORC.

Обновления и удаления на уровне строк записывают дополнительные файлы удаления (delete files) рядом с существующими объектами данных, а не изменяют файлы на месте. Iceberg 2 поддерживает файлы удаления по позиции и по равенству, в то время как Iceberg 3 вводит бинарные векторы удаления для оптимизации отслеживания удалений. Файлы данных остаются неизменяемыми до тех пор, пока явное задание по обслуживанию не удалит просроченные снимки и не очистит неиспользуемые файлы из хранилища.

Как чтение и запись проходят через слои

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

Путь чтения

Когда движок запросов выполняет инструкцию SELECT для таблицы Iceberg, выполнение идет сверху вниз по дереву метаданных:

Разрешение каталога: движок запросов запрашивает у каталога расположение текущего файла метаданных таблицы.
Выбор снимка: движок считывает JSON-файл метаданных таблицы и определяет ID активного снимка (или ID исторического снимка, если выполняется «путешествие во времени»).
Отсечение списка манифестов: движок открывает список манифестов снимка и оценивает сводки границ разделов, чтобы игнорировать файлы манифестов, не содержащие релевантных записей.
Отсечение манифестов и выбор файлов данных: движок считывает оставшиеся файлы манифестов, проверяя статистику минимумов/максимумов столбцов и количество пустых значений для фильтрации конкретных файлов данных.
Сканирование физического хранилища: движок считывает только оставшиеся файлы данных Parquet или ORC из объектного хранилища и выполняет оставшуюся логику запроса.

Путь записи и механизм фиксации

Когда движок выполняет операцию INSERT, UPDATE, DELETE или MERGE, выполнение происходит снизу вверх:

Прием файлов данных: движок записывает новые неизменяемые файлы данных Parquet или ORC (и любые необходимые файлы удаления) в объектное хранилище.
Создание манифеста и списка манифестов: движок записывает новые файлы манифестов, отслеживающие эти объекты данных, а затем новый файл списка манифестов, представляющий предлагаемый снимок таблицы.
Создание файла метаданных таблицы: движок записывает новый JSON-файл метаданных таблицы, содержащий предлагаемый ID снимка, обновленную схему или измененную спецификацию разделов.
Атомарная замена в каталоге: движок запрашивает каталог для атомарного обновления указателя ссылки на новый файл метаданных таблицы.

Оптимистичное управление параллелизмом

Замена в каталоге использует оптимистичное управление параллелизмом (OCC). Обновление проходит успешно только в том случае, если указатель каталога не изменился с момента начала операции записи.

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

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

Как работают снимки, ветки и теги

Iceberg рассматривает состояние таблицы как серию неизменяемых исторических точек. Отделяя физические файлы от логических ссылок, команды платформы могут запускать запросы к прошлым состояниям (time travel), изолированные ветки для тестирования и аудиторские заморозки без копирования базовых данных.

Снимки

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

Ветки

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

Например, инженеры данных могут создать ветку основной продуктовой таблицы, записать экспериментальные преобразования или запустить проверочные тесты в этой ветке и проверить результаты, не затрагивая продуктовых читателей. После прохождения проверок качества ветка может быть объединена обратно в основную ветку с помощью операции быстрого слияния (fast-forward) или выбора. Поддержка создания, записи и слияния веток движками различается, поэтому проверяйте совместимость движка запросов перед созданием рабочих процессов на основе веток.

Теги — это неизменяемые именованные ссылки, указывающие на фиксированный ID снимка. В отличие от веток, теги никогда не продвигаются и не принимают новые записи.

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

Что изменилось с v1 по v3

Спецификация формата Iceberg развивалась на протяжении трех основных версий, каждая из которых решала конкретные проблемы масштабирования и производительности в архитектуре data lakehouse.

Iceberg v1 — Аналитические таблицы данных

Версия 1 отделила логические таблицы от физических структур каталогов. Заменив неявные макеты папок явными списками метаданных, v1 установила отслеживание на уровне файлов, эволюцию схемы и базовую изоляцию снимков для аналитических рабочих нагрузок с интенсивной записью.

Iceberg v2 — Изменения на уровне строк

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

Iceberg v3 — Высокопроизводительный Lakehouse

Версия 3 оптимизирует операции на уровне строк и добавляет возможности для полуструктурированных данных:

Векторы удаления: Бинарные векторы удаления заменяют файлы удаления по позиции (которые в v3 считаются устаревшими), значительно снижая накладные расходы на слияние при чтении во время сканирования. Удаления по значению по-прежнему поддерживаются.
Тип VARIANT: Нативная поддержка полуструктурированного типа позволяет гибко запрашивать JSON-подобные данные без полной декомпозиции.
Расширенные типы и функции: Вводит точность временных меток до наносекунд, значения столбцов по умолчанию и нативное отслеживание происхождения строк при фиксации таблиц.

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

Почему проектирование метаданных требует автоматического обслуживания

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

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

Фрагментация мелких файлов: Тысячи крошечных файлов заставляют движки запросов выполнять чрезмерное количество вызовов API объектного хранилища во время сканирования, замедляя выполнение запросов.
Раздувание метаданных: Слишком большие деревья метаданных увеличивают накладные расходы на планирование запросов и повышают задержку фиксации для параллельных процессов записи.
Затраты на хранение «осиротевших» файлов: Прерванные операции записи, неудачные фиксации или несобранный «мусор» оставляют неиспользуемые файлы данных в хранилище, увеличивая счета за хранение.

Четыре основные задачи обслуживания

Поддержание оптимальной скорости запросов и предсказуемых затрат на хранение требует четырех постоянных процедур обслуживания:

Компакция файлов данных: Объединение мелких файлов данных в более крупные, однородные блоки (обычно от 128 МБ до 512 МБ) и перезапись файлов удаления по позиции для устранения трения при слиянии на стороне чтения.
Истечение срока действия снимков: Удаление ссылок на исторические снимки, вышедшие за пределы вашего окна соответствия требованиям или аудита, чтобы поддерживать размер дерева метаданных в управляемых пределах.
Удаление осиротевших файлов: идентификация и удаление неиспользуемых файлов данных и метаданных, которые остались после прерванных или неудачных операций записи.
Оптимизация манифестов: перезапись и сортировка файлов манифестов для приведения границ манифестов в соответствие с распространенными шаблонами фильтрации запросов, что повышает эффективность отсечения файлов.

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

Масштабирование Apache Iceberg с помощью Starburst

Apache Iceberg предоставляет спецификацию открытого формата таблиц, но вам все равно нужна платформа данных, способная ее использовать. Starburst предоставляет корпоративную платформу, необходимую для эксплуатации и выполнения запросов к ней в масштабе. Сочетая открытый формат с высокопроизводительным выполнением запросов, Starburst закладывает основу современного открытого data lakehouse, позволяя организациям запускать быструю интерактивную SQL-аналитику непосредственно поверх объектного хранилища без привязки к поставщику.

Starburst дополняет эту открытую основу безопасностью корпоративного уровня, автоматизированным управлением таблицами и выполнением запросов к нескольким источникам. Вместо того чтобы запирать данные в проприетарных хранилищах или принуждать к масштабным проектам миграции, Starburst позволяет командам платформы запрашивать таблицы Iceberg наряду с операционными базами данных и устаревшими системами в рамках одного SQL-запроса. Независимо от того, развернут ли Starburst как полностью управляемый облачный сервис или как самоуправляемое решение в гибридной или локальной инфраструктуре, он устраняет дублирование данных, обеспечивая при этом высокую производительность при параллельной работе.

Ускорьте архитектуру вашего Lakehouse

Готовы перейти от базовых таблиц Iceberg к высокопроизводительному автоматизированному data lakehouse? Скачайте «Руководство инженера данных по Iceberg Data Lakehouse» , чтобы узнать о лучших практиках проектирования каталогов, стратегиях автоматизированного обслуживания и оптимизации запросов для нескольких движков .

Часто задаваемые вопросы

Каковы основные структурные уровни Apache Iceberg?

Apache Iceberg работает на трех различных структурных уровнях:

Каталог: хранит указатель на текущий файл метаданных таблицы и выполняет атомарные фиксации (commits).
Уровень метаданных: состоит из JSON-файлов метаданных, списков манифестов Avro и файлов манифестов Avro, которые описывают схему таблицы, историю снимков и статистику на уровне файлов.
Уровень данных: содержит физические колоночные файлы хранения, в основном Parquet или ORC, а также любые активные файлы удаления.

Как Apache Iceberg гарантирует ACID-транзакции в объектном хранилище?

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

Чем Apache Iceberg отличается от устаревших структур таблиц Hive?

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

Что такое снимок (snapshot) и чем отличаются ветки (branches) и теги (tags)?

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

Что изменилось в Iceberg v3 и когда командам следует обновляться?

Iceberg v3 представляет бинарные векторы удаления для замены файлов удаления позиций, встроенные типы данных VARIANT для полуструктурированных JSON-данных, точность временных меток до наносекунд, значения столбцов по умолчанию и историю строк (row lineage). Время обновления должно определяться совместимостью движков, поскольку каждый движок запросов и инструмент загрузки, работающий с таблицей, должен полностью поддерживать v3 до того, как таблица будет обновлена.

Почему таблицы Apache Iceberg требуют постоянного обслуживания?

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