Apache Iceberg 1.12.0 — обновления и миграция

Релиз Apache Iceberg 1.12.0 вышел в конце сентября 2026 года и добавляет поддержку спецификации v3 в большем числе движков, расширяет операции REST-каталога и повышает стабильность потоковой записи. Изменения касаются Spark, Flink и Kafka, поэтому инженерам стоит оценить совместимость до обновления. В статье разберём, какие функции появились, какие ограничения сохранились и как подготовить миграцию в собственном контуре.

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

Новые возможности для Spark и Flink

В версии 1.12.0 расширили работу со спецификацией v3: теперь больше операций с метаданными и типами данных доступны напрямую из Spark 3.5 и Flink 1.18. Раньше часть функций требовала обходных путей через промежуточные таблицы, теперь они выполняются нативно. Это сокращает количество шагов при преобразовании схемы и добавлении partition-эволюции. Spark здесь выступает как мощный движок для пакетной и интерактивной обработки данных, а Flink — как платформа для потоковой обработки в реальном времени. Такие изменения полезны командам, которые часто меняют структуру таблиц или добавляют новые колонки без остановки работы.

Для Flink добавили улучшенную поддержку exactly-once при записи в Iceberg через Kafka. Exactly-once означает гарантию, что каждое событие обрабатывается ровно один раз, без дублирования или потери данных. Раньше при сбоях чекпоинтов возникали дубли или пропуски, теперь механизм восстановления стал устойчивее. Инженеры, которые строят пайплайны на Flink с Kafka в качестве источника, получат меньше ручных проверок после перезапуска задач. Kafka здесь служит распределённой шиной для передачи событий, и улучшения снижают риск несогласованности данных в долгосрочных потоках.

REST-каталог получил дополнительные методы для управления ветками и тегами. REST-каталог — это способ хранения метаданных таблиц через HTTP-интерфейс, что позволяет управлять таблицами без тяжёлых внешних систем. Это упрощает работу с несколькими окружениями без отдельного Nessie или Hive Metastore. Nessie и Hive Metastore — это альтернативные каталоги для отслеживания версий таблиц и схем. В то же время список поддерживаемых операций пока неполный: отсутствуют некоторые массовые операции над метаданными, которые уже есть в других каталогах. При оценке стоит проверить, нужны ли именно эти недостающие функции в текущих рабочих процессах.

Изменения в потоковой записи и ограничения

Стриминговый writer стал надёжнее за счёт новых механизмов обработки коммитов и отката. Writer — это компонент, отвечающий за запись данных в таблицы Iceberg. При использовании Kafka как источника событий теперь можно задавать более точные границы окна коммита, что снижает риск частичных записей. Однако для этого требуется обновить конфигурацию Flink-задач, иначе поведение останется прежним. Это важно учитывать при планировании, поскольку нестабильная запись может привести к потерям или дубликатам в аналитических отчётах.

Важное ограничение: не все типы данных v3 уже работают стабильно в потоковом режиме. Например, nested types и certain timestamp precision пока требуют дополнительных проверок. Nested types — это сложные вложенные структуры данных, такие как массивы внутри структур. Если пайплайн использует сложные схемы, перед обновлением нужно провести тестовую запись на реальных данных. Это поможет избежать неожиданных ошибок при масштабировании.

Ещё один момент касается совместимости с более старыми читателями. Таблицы, созданные или изменённые в 1.12.0, могут не читаться корректно клиентами на версии 1.10 и ниже. Это нужно учитывать при поэтапном обновлении кластера. Если в инфраструктуре остаются старые версии движков, миграция может потребовать временного параллельного хранения данных в двух форматах.

Breaking changes и план миграции

Основные breaking changes связаны с удалением устаревших методов в REST API и изменением поведения некоторых настроек writer. Breaking changes — это изменения, которые могут сломать существующий код или конфигурации. Часть параметров, которые раньше считались deprecated, теперь игнорируются полностью. Перед обновлением следует проверить конфигурационные файлы Spark и Flink на наличие этих ключей. Это снижает риск неожиданных сбоёв после перехода.

Миграция рекомендуется проводить в несколько этапов: сначала обновить каталог, затем протестировать batch-записи, потом перевести стриминговые задачи. При этом важно сохранить возможность отката на предыдущую версию Iceberg в течение хотя бы одной недели после перехода. Откат позволяет быстро вернуться к стабильной версии, если возникнут проблемы с производительностью или совместимостью.

Отсутствие полноценной документации по rollback-стратегиям для REST-каталога усложняет планирование. Инженерам придётся самостоятельно проверять поведение при частичном откате метаданных. При принятии решения о миграции стоит взвесить, насколько критична эта нехватка документации для конкретной команды и есть ли ресурсы на дополнительное тестирование.

Особенности внедрения в российских контурах

В изолированных окружениях без доступа к внешним облачным каталогам REST-решения Iceberg 1.12.0 дают больше свободы, чем раньше. Можно развернуть собственный REST-сервис и управлять ветками таблиц без Hive Metastore, что упрощает архитектуру. Однако требуется самостоятельно обеспечить отказоустойчивость этого сервиса, так как готовых enterprise-решений на базе Iceberg 1.12.0 в РФ пока мало. Это особенно актуально для команд, работающих в закрытых сетях, где важна полная независимость от внешних провайдеров.

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

Обновляться стоит командам, которые уже сталкиваются с ограничениями v2 при потоковой записи или нуждаются в расширенных операциях REST. Если текущая версия 1.10 или 1.11 работает стабильно и нет планов на сложные схемы, с миграцией можно повременить до появления 1.13. Подробный гайд по обновлению доступен в оригинальной статье.

Источник

Это краткий разбор материала Dremio. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Apache Iceberg 1.12.0 — обновления и миграция.

Курс по теме — Каталог курсов Школы Больших Данных