Apache Iceberg V3: Готов ли он?
Apache Iceberg V3: Готов ли он?
Автор: Guy Yasoor (Ryft Blog)
Перевод и дополнения: Gemini 3 Pro Preview и я кофе носил
Оригинал: https://www.ryft.io/blog/apache-iceberg-v3-is-it-ready
Выход Apache Iceberg V3 — это огромный шаг вперед для экосистемы лейкхаусов (lakehouse). Спецификация V3 была финализирована и ратифицирована в начале этого года, привнеся в ядро формата несколько долгожданных возможностей: эффективные удаления на уровне строк (row-level deletes), встроенное отслеживание происхождения строк (row lineage), улучшенная обработка полуструктурированных данных и зачатки нативного шифрования.
Этим новым возможностям уделяется много внимания, но в разговорах часто упускают вопрос, который важен не меньше: Насколько V3 готов на практике?
Честный ответ: это полностью зависит от ваших движков обработки данных (engines). Некоторые среды, такие как Spark и Flink, уже хорошо поддерживают V3. Другие — пока отстают.
Основные возможности V3
Deletion Vectors (Векторы удаления)
Векторы удаления прикрепляют информацию об удалении строк непосредственно к файлам данных в виде битовых карт, избегая накопления позиционных файлов удалений (positional delete files).
>**поИИснение:**
>В предыдущих версиях (V2) использовались **Positional Delete Files** — это отдельные Parquet-файлы, содержащие пути и позиции удаленных строк. При чтении (Merge-on-Read) движку приходилось считывать файл данных, считывать файл удалений и делать между ними `JOIN`, чтобы отфильтровать ненужное. Это требует много памяти и ввода-вывода (IO).
>
>**Deletion Vector (V3)** — это, по сути, компактная битовая карта (bitmap), хранящаяся внутри или рядом с файлом данных. Движку достаточно прочитать этот маленький массив битов пропустить удаленные строки "на лету", без дорогостоящих операций слияния. Это критически ускоряет чтение активно изменяемых таблиц.- Статус:
- Принято в большинстве движков, реализующих V3.
- Стабильное чтение/запись в `Apache Spark`, `Apache Flink`.
- Вероятно, самая готовая к продакшену функция.
Row Lineage (Происхождение строк)
Row lineage вводит стабильные идентификаторы строк и метаданные версий. Это упрощает инкрементальную обработку, CDC, аудит и отладку.
>**поИИснение:**
>Без Row Lineage, если вы обновляете таблицу, строки часто физически перезаписываются, и их "личность" теряется. Чтобы понять, что изменилось, приходилось сравнивать полные копии данных (expensive diff).
>V3 присваивает строкам суррогатные ID. Это позволяет реализовать дешевый CDC (Change Data Capture): вы точно знаете, что "Строка #123" была обновлена, и можете каскадно обновить только связанные с ней агрегаты в витринах данных, вместо пересчета всей витрины.- Статус:
- Принято в большинстве движков V3.
- Достаточно зрелая технология для V3-совместимых стеков.
Тип данных VARIANT
`VARIANT` — это нативный тип для полуструктурированных данных, замена хранению JSON в виде простых строк. Однако текущая поддержка частичная: не хватает “шреддинга” (shredding).
>**поИИснение:**
>В чем суть **Shredding (измельчения)**? Если вы храните JSON как строку (String), базе данных нужно парсить весь JSON для каждого запроса, чтобы достать одно поле `{"user": "Ivan", ...}`. Это медленно.
>Тип `VARIANT` хранит данные в бинарном формате. А **Shredding** — это оптимизация, когда движок замечает, что поле `user` встречается в 95% записей. Он автоматически вытаскивает это поле в отдельную физическую колонку Parquet, сохраняя при этом логическую структуру JSON. Это позволяет читать поле `user` так же быстро, как обычную колонку, но сохранять гибкость схемы (schema evolution), не делая `ALTER TABLE` при добавлении новых полей в JSON.- Статус:**
- Поддерживается в Spark, Flink, Databricks SQL.
- Parquet стандартизирует кодировки, что даст общее представление для оптимизации.
Геопространственные типы и Шифрование
V3 вводит типы для гео-данных и блоки для шифрования на уровне таблицы.
- Статус: Гео-типы доступны через расширения (`Apache Sedona`), шифрование находится на ранней стадии (только Spark/Flink).
Поддержка движками: Где V3 реально работает?
| Движок | Статус V3 | Комментарий |
| Apache Spark | ✅ Отличный | Начиная с v4.0 — самая надежная платформа для V3. |
| Apache Flink | ✅ Хороший | Идеален для стриминга, поддерживает основные фичи. |
| Databricks | ⚠️ Beta | Работает, но есть ограничения по типам данных. |
| AWS (Glue/EMR) | ⚠️ Частичный | Зависит от версии движка под капотом. |
| Amazon Athena | ❌ Нет | Главный блокер для пользователей AWS. |
| Trino / Starburst | 🔸 Смешанный | Starburst (коммерческий) поддерживает, OSS Trino — нет. |
| Snowflake | ⏳ Ожидание | Активно разрабатывали спецификацию, но публичной поддержки V3 в Managed Iceberg пока нет. |
Итог: Переходить ли на V3?
Для большинства: пока нет.
Ключевые игроки (Athena, Trino OSS, Snowflake) не готовы. Переходите, только если ваш стек состоит исключительно из Spark или Flink.
🔮 МненИИе и гаданИИе на кофейной гуще
Прогноз на год вперед
| Аспект | Прагматичный прогноз (Реализм) | Супер-прогноз (Оптимизм/Хайп) |
| Принятие | Крупный энтерпрайз начнет пилоты к концу года. Основная масса ждет Athena/BigQuery. | V3 станет стандартом для всех greenfield проектов весной. Утилиты миграции ускорят отказ от Hive/Delta. |
| Каталоги | REST Catalog убивает Hive Metastore. Появление managed REST сервисов. | Universal Catalog Protocol: один каталог для Iceberg, Delta и Hudi. Формат станет прозрачным для пользователя. |
| Скорость | +30-50% к скорости MERGE операций благодаря векторам удаления. | Нейросетевые оптимизаторы запросов и p2p кэширование сделают “холодный” Iceberg по скорости равным in-memory СУБД. |
| Python | `PyIceberg` получит полную поддержку записи (Write). | Python-стек (DuckDB + PyIceberg) начнет вытеснять Spark в задачах малого/среднего объема. |
Roadmap: 10 шагов развития
- Аудит совместимости: Проверить всех потребителей данных. Если есть Athena — V3 откладывается.
- Переход на REST Catalog: Отказ от Hive Metastore.
>поИИснение:
>REST Catalog отвязывает клиента (Spark/Trino) от прямого доступа к файловой системе (S3/HDFS). Это безопаснее (можно выдавать временные креды “Vended Credentials”) и позволяет менять физическое расположение данных, не ломая настройки клиентов. - Апгрейд Spark/Flink: Только свежие версии (Spark 3.5+/4.0) умеют работать с V3 корректно.
- Внедрение “Puffin” статистики:
>поИИснение:
>Puffin — это формат файлов-спутников для Iceberg, которые хранят продвинутую статистику, например, эскизы (sketches) для оценки уникальных значений (`count distinct`) без чтения данных. Внедрение этого шага ускоряет планирование запросов. - Изолированный пилот: Запуск V3 на одной стриминговой джобе для проверки Deletion Vectors.
- Оптимизация CDC: Использование Row Lineage для дедупликации потоков.
- PyIceberg для легких ETL: Замена тяжелых JVM-джоб на Python там, где объемы небольшие.
- Миграция JSON в VARIANT: Как только движки поддержат шреддинг, это сэкономит гигабайты и часы CPU.
- Отказ от позиционных удалений: Полное переключение write-конфигурации на векторы.
- Масштабирование: Перевод основных витрин на V3.
💡 Было бы круто, если бы еще сделали...
Нативную поддержку самоорганизации данных (Z-Order / Clustering) без внешних компакторов.
Почему: Сейчас, чтобы запросы “летали” и пропускали ненужные файлы (data skipping), данные нужно сортировать (Z-Order). Это делают отдельные тяжелые джобы (`maintenance jobs`).
Было бы круто, если бы спецификация позволяла писателям (writers) автоматически поддерживать приближенную кластеризацию при вставке данных (opportunistic clustering), либо если бы формат поддерживал Secondary Indexes (вторичные индексы на основе B-деревьев или Bitmap), хранящиеся прямо в слое метаданных. Это позволило бы Iceberg конкурировать с ClickHouse и Druid в сценариях интерактивной аналитики (sub-second latency), убрав необходимость в постоянном “обслуживании” таблиц.