Yuriy Gavrilov: posts tagged Iceberg

Apache Iceberg V3: Готов ли он?

Thu, 18 Dec 2025 22:06:36 +0300

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), убрав необходимость в постоянном “обслуживании” таблиц.

Сравнение Apache Iceberg, Delta Lake и Apache Hudi: Глубокий анализ (2025)

Sat, 01 Nov 2025 00:53:55 +0300

С ростом популярности архитектуры Data Lakehouse усилился интерес к трём основным открытым проектам в этой области: Apache Hudi, Delta Lake и Apache Iceberg. Все три технологии продолжают активно развиваться, и в этой статье представлено актуальное сравнение их возможностей по состоянию на октябрь 2025 года.

Оригинал тут: https://www.onehouse.ai/blog/apache-hudi-vs-delta-lake-vs-apache-iceberg-lakehouse-feature-comparison

Примечание: Если выбор формата вызывает сложности, обратите внимание на проект Apache XTable (Incubating), который обеспечивает интероперабельность между Hudi, Delta и Iceberg, позволяя использовать несколько форматов одновременно.

Сравнение возможностей

Функциональность записи

Функция	Apache Hudi (v1.0.2)	Delta Lake (v4.0.0)	Apache Iceberg (v1.10.0)
ACID-транзакции	✅	✅	✅
Copy-on-Write	✅	✅	✅
Merge-on-Read	✅ Полнофункциональный	❌ Векторы удалений (эксперимент.)	❌ Векторы удалений (огранич.)
Эффективная bulk-загрузка	✅ Bulk_Insert	✅	✅
Индексирование	✅ 8+ типов индексов	❌ Bloom-фильтр проприетарный	✅ Метаданные для статистики
Частичные обновления	✅ Partial Updates	❌	❌
Миграция таблиц	✅ Bootstrap	✅ Convert to Delta	❌
Управление конкуренцией	✅ OCC, MVCC, NBCC	✅ OCC	✅ OCC
Неблокирующая конкуренция	✅ NBCC	❌ OCC с перезапуском	❌ OCC с перезапуском
Менеджеры блокировок	✅ ФС, DynamoDB, Hive, Zookeeper	✅ Только внешний DynamoDB	✅ Каталог или внешние провайдеры
Дедупликация	✅ Ключи, Precombine	❌ Нет первичных ключей	❌ Нет первичных ключей
Зависимость от каталога	❌ Не требуется	❌ Не требуется	✅ Обязателен

Ключевые отличия:

Hudi предлагает наиболее продвинутые механизмы управления конкуренцией, включая неблокирующий контроль (NBCC)
Только Hudi поддерживает настоящий Merge-on-Read без компромиссов производительности
Hudi предоставляет встроенные инструменты для дедупликации через первичные ключи

Метаданные таблиц

Функция	Apache Hudi	Delta Lake	Apache Iceberg
Масштабируемость метаданных	✅ LSM-дерево + HFile (100x ускорение)	❌ Parquet чекпойнты (медленно)	❌ Avro манифесты (медленно)
Управление индексами	✅ Асинхронное многомодальное	❌	❌
Эволюция схемы	✅ Добавление, переупоряд., удаление	✅	✅
Эволюция партиций	✅ Кластеризация + индексы выражений	✅ Эволюция партиций	❌
Первичные ключи	✅	❌ Только в проприетарной версии	❌
Статистика столбцов	✅ HFile (до 50x ускорение)	✅ Parquet чекпойнт	✅ Avro манифест

Важные особенности:

Hudi использует оптимизированный формат HFile для метаданных, что значительно ускоряет поиск
Только Hudi поддерживает настоящие первичные ключи как в реляционных БД
Hudi предлагает более гибкий подход к партиционированию через кластеризацию

Функциональность чтения

Функция	Apache Hudi	Delta Lake	Apache Iceberg
Time Travel	✅	✅	✅
Merge-on-Read запросы	✅ Snapshot Query	❌ Сложная поддержка	✅ Все запросы мержат векторы удалений
Инкрементальные запросы	✅ + CDC запросы	✅ CDF (эксперимент.)	❌ Только аппенды
CDC запросы	✅ + before/after images	❌	❌
Вторичные индексы	✅	❌	❌
Предикаты для пропуска данных	✅ Индексы выражений	✅ Логические предикаты	✅ Трансформации таблиц

Сервисы таблиц

Функция	Apache Hudi	Delta Lake	Apache Iceberg
Авторазмер файлов	✅	✅	❌ Ручное управление
Компактизация	✅ Управляемая	❌ 2-этапное обслуживание	❌ Ручное обслуживание
Очистка	✅ Управляемая	❌ VACUUM вручную	❌ Ручное удаление снапшотов
Кластеризация	✅ Авто + Z-order/Hilbert	❌ Z-order в OSS, авто – проприетар.	❌ Z-order вручную

Поддержка экосистемы

Все три формата имеют широкую поддержку в экосистеме данных:

Apache Spark, Flink, Trino, DBT – полная поддержка чтения/записи во всех форматах
Kafka Connect – Hudi и Iceberg имеют нативную поддержку, Delta – только проприетарную
Облачные платформы (AWS, GCP, Azure) – все три формата поддерживаются с некоторыми ограничениями
Snowflake – нативная поддержка Iceberg, Hudi через XTable

Производительность: TPC-DS бенчмарки

Согласно независимым тестам:

Hudi и Delta показывают сопоставимую производительность
Iceberg consistently отстаёт по скорости выполнения запросов

Важно: При сравнении производительности учитывайте, что Hudi по умолчанию оптимизирован для mutable-нагрузок (upsert), в то время как Delta и Iceberg – для append-only. Для честного сравнения используйте `bulk-insert` режим в Hudi.

Ключевые дифференцирующие возможности

Инкрементальные пайплайн

Hudi предлагает наиболее зрелую поддержку инкрементальной обработки с трекингом всех изменений (вставки, обновления, удаления) и предоставлением их в виде change streams. Это позволяет строить эффективные ETL-пайплайны без перевычисления полных наборов данных.

Управление конкуренцией

В то время как все три системы поддерживают оптимистический контроль конкуренции (OCC), только Hudi предлагает:

Неблокирующий контроль конкуренции (NBCC)
Файл-уровневую гранулярность блокировок
Возможность работы с асинхронными сервисами таблиц без остановки записи

Merge-on-Read

Только Hudi предоставляет полнофункциональный Merge-on-Read, который позволяет:

Балансировать между производительностью записи и чтения
Использовать row-ориентированные форматы для стриминга и column-ориентированные для аналитики
Выполнять компактизацию асинхронно

Кластеризация vs Эволюция партиций

Iceberg: Partition Evolution – изменение схемы партиционирования для новых данных
Hudi: Гибридный подход – coarse-grained партиционирование + fine-grained кластеризация с возможностью эволюции без перезаписи данных

Многомодальное индексирование

Только Hudi предлагает асинхронную подсистему индексирования, поддерживающую:

Bloom, hash, bitmap, R-tree индексы
10-100x ускорение point lookup запросов
10-30x общее ускорение запросов в реальных нагрузках

Реальные кейсы использования

Peloton

Увеличение частоты ингестии с 1 раза в день до каждых 10 минут
Снижение времени выполнения снапшот-заданий с 1 часа до 15 минут
Экономия затрат через оптимизацию использования EMR-кластеров

ByteDance/TikTok

Обработка таблиц объемом 400+ PB
Ежедневный прирост данных на уровне PB
Пропускная способность >100 GB/s на таблицу
Выбор Hudi из-за открытости экосистемы и поддержки глобальных индексов

Walmart

Использование Merge-on-Read для снижения задержек
Нативная поддержка удалений для GDPR/CCPA compliance
Row versioning для обработки out-of-order данных

Инновации сообщества

Многие ключевые функции data lakehouse были впервые реализованы в Hudi:

Инновация Hudi	Год	Аналог в других проектах
Транзакционные обновления	2017	Delta OSS (2019)
Merge-on-Read	2017	Iceberg (2021)
Инкрементальные запросы	2017	Delta Change Feed (2022)
Z-order/Hilbert кривые	2021	Delta OSS (2022)
Многомодальное индексирование	2022	❌ Нет аналогов
Контроль конкуренции без блокировок	2024	❌ Нет аналогов

Заключение

Критерии выбора

Выбирайте Apache Hudi если:

Ваши workload’ы содержат значительное количество обновлений и удалений
Требуется низкая задержка от конца в конец
Нужны продвинутые возможности управления конкуренцией
Важна производительность point lookup запросов
Требуется гибкое управление layout данных через кластеризацию

Рассмотрите Delta Lake если:

Вы используете экосистему Databricks
Workload’ы преимущественно append-only
Достаточно базовых возможностей управления конкуренцией

Apache Iceberg может подойти если:

Основная задача – работа с очень большими объемами данных в cloud storage
Требуется скрытое партиционирование с эволюцией
Workload’ы в основном аналитические с минимальными обновлениями

Итоговые рекомендации

Для зрелых production-нагрузок с frequent updates, high concurrency и low latency требованиями Apache Hudi предлагает наиболее полный набор возможностей.

Не ограничивайтесь сравнением “галочек” – оценивайте производительность на своих данных и workload’ах.

Рассмотрите Apache XTable если невозможно определиться с одним форматом или требуется интероперабельность между системами.

Учитывайте roadmap проекта – Hudi продолжает лидировать в инновациях, что может быть важно для долгосрочных инвестиций.

Технологии data lakehouse продолжают быстро развиваться, и выбор должен основываться на конкретных требованиях ваших use cases, а не только на текущем состоянии функциональности.

Iceberg в Trino: Путешествие по Вариантам Хранения, Сжатия и Конфигурации для Оптимальной Производительности

Sun, 06 Jul 2025 21:18:49 +0300

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

Автор: Gemini Flash. 2.5

1. Форматы Хранения (File Formats)

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

a) Parquet

Описание:** Колоночный формат хранения данных, оптимизированный для аналитических запросов. Он хранит данные в колоночной ориентации, что позволяет Trino считывать только необходимые колонки во время выполнения запросов. Parquet тесно интегрирован с концепциями Iceberg, такими как использование идентификаторов полей (Field IDs) для поддержки надежной схемы эволюции.
Преимущества:**
- Высокая производительность в аналитике: За счет колоночного хранения и возможности Trino применять “push-down” предикатов, Parquet обеспечивает беспрецедентную скорость для большинства аналитических запросов, избирательно считывая только необходимые данные.
- Эффективное сжатие: Колоночная ориентация позволяет применять различные алгоритмы сжатия, оптимизированные для типов данных в каждой колонке, существенно снижая объем хранимых данных и, как следствие, затраты на хранение.
- Нативная поддержка схемы эволюции Iceberg: Iceberg использует Field IDs, которые записываются в метаданды Parquet. Это ключевой механизм, позволяющий Iceberg поддерживать эволюцию схемы (добавление, удаление, переименование колонок) без перезаписи данных и без нарушения целостности запросов.
- Широкая поддержка и зрелость: Parquet является фактическим стандартом для хранения аналитических данных в экосистеме больших данных и поддерживается всеми основными инструментами (Spark, Hive, Dremio, Athena, BigQuery, Snowflake и т.д.), обеспечивая отличную интероперабельность.
Недостатки:**
- Неэффективен для точечных запросов (point lookups): Для выборки одной или нескольких записей требуется считывать данные из нескольких колонок, что может быть менее эффективно, чем строковые форматы данных.
- Сложность изменения данных: Изменение отдельных записей требует перезаписи целых файлов или их частей, что является общей чертой для колоночных форматов.

Использование: **Parquet – это формат по умолчанию и наиболее рекомендуемый выбор для таблиц Iceberg в Trino. Он обеспечивает наилучший баланс производительности, эффективности хранения и простоты управления для большинства аналитических рабочих нагрузок.

b) ORC (Optimized Row Columnar)

Описание:** Ещё один колоночный формат, разработанный специально для Apache Hive. Он имеет много сходств с Parquet, включая колоночное хранение и эффективное сжатие. Документация Iceberg подтверждает, что ORC также может хранить необходимые метаданные (например, `iceberg.id`, `iceberg.required`) в атрибутах типов ORC для поддержки схемы эволюции.
Преимущества:**
- Высокая производительность и эффективное сжатие: Аналогично Parquet, ORC обеспечивает отличную производительность для аналитических запросов и эффективное сжатие.
- Расширенное индексирование: ORC часто содержит более гранулированные встроенные индексы (например, индексы позиций, Bloom-фильтры), которые могут быть полезны для некоторых специфических типов запросов.

Но Bloom-фильтры по умолчанию отключены в Trino вроде как, надо проверять этот конфиг:

Совместимость со схемой эволюции Iceberg: Iceberg способен адаптировать ORC-схему (даже путем изменения имен колонок) для своей ID-основанной эволюции, что делает его совместимым.
Недостатки:**
Неэффективен для точечных запросов: Общий недостаток для всех колоночных форматов.
Менее распространен как универсальный формат вне экосистемы Hive: Хотя ORC является основным форматом для Hive, Iceberg чаще ассоциируется с Parquet как универсальным форматом хранения для Data Lake. Это может потенциально означать меньшую поддержку или оптимизацию в некоторых не-Hive инструментах.
Специфические моменты с отображением типов: Как видно из Iceberg documentation, существуют нюансы с отображением типов данных (например, `timestamp` и `timestamptz`) в ORC. Может потребоваться использование дополнительных атрибутов Iceberg (таких как `iceberg.timestamp-unit`) для корректной передачи семантики.
Отсутствие “шрединга” для типа `variant`: Документация указывает, что для ORC не поддерживается “шрединг” (оптимизированное хранение) для полуструктурированного типа `variant`, что может быть ограничением для пользователей, активно работающих с такими данными.

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

c) Avro

Описание: Строковый формат данных, ориентированный на быструю сериализацию и десериализацию. Avro широко используется в Apache Kafka и для передачи данных между системами. Важно отметить, что Iceberg использует Avro в качестве формата **своих внутренних файлов метаданных (например, манифестов и метаданных таблиц), где его строковая природа и возможности сериализации очень полезны. Iceberg также описывает, как Avro может быть использован для файлов данных, включая строгие правила для отображения типов данных Avro и использование Field IDs для поддержки эволюции схемы.
Преимущества:**
- Отлично подходит для сериализации и передачи данных: Благодаря своей компактности и быстрой сериализации/десериализации, Avro идеален для потоковой передачи.
- Встроенная схема (Schema-on-Read): Схема хранится вместе с данными, что обеспечивает совместимость. Iceberg расширяет это, добавляя Field IDs в схему Avro для robustной эволюции.
- Поддержка эволюции схемы: Iceberg, благодаря внедрению Field IDs в схемы Avro и строгим правилам для `union` (например, использование `null` для опциональных полей), способен обеспечить эволюцию схемы даже для данных, хранящихся в Avro. Это технически возможно благодаря Iceberg.
Недостатки:**
- Крайне низкая производительность для аналитики: Это ключевой и самый серьезный недостаток Avro для аналитических рабочих нагрузок. Для запросов требуется считывать всю строку данных, даже если нужны только некоторые колонки. Это приводит к значительному избытку I/O, увеличивает потребность в памяти и катастрофически замедляет аналитические запросы по сравнению с колоночными форматами.
- Неэффективное сжатие: Сжатие применяется ко всей строке, а не к отдельным колонкам. Это значительно снижает коэффициент сжатия по сравнению с Parquet или ORC, что приводит к увеличению объема хранимых данных и, соответственно, затрат.
- Отсутствие “шрединга” для типа `variant`: Как и в ORC, Avro не поддерживает “шрединг” для полуструктурированного типа `variant`, что может ограничивать работу со сложными схемами.

Использование: **Категорически не рекомендуется использовать Avro в качестве формата хранения ~~данных~~ для таблиц Iceberg, предназначенных для аналитических запросов в Trino. Несмотря на то, что Iceberg может технически поддерживать его для данных, это приведет к серьезному ухудшению производительности и увеличению затрат. Avro прекрасно подходит для файлов метаданных Iceberg и для потоковых данных, но не для аналитического хранения.

2. Алгоритмы Сжатия (Compression Algorithms)

Выбор алгоритма сжатия напрямую влияет на размер хранимых данных, скорость чтения/записи и потребление ресурсов CPU. Trino поддерживает различные алгоритмы сжатия для файлов Parquet и ORC.

a) Snappy

Описание:** Высокоскоростной алгоритм сжатия, разработанный Google. Он оптимизирован для скорости сжатия и декомпрессии, а не для максимальной степени сжатия.
Преимущества:**
- Очень быстрая декомпрессия: Минимальное влияние на производительность запросов, что критично для активных аналитических систем.
- Сбалансированное соотношение сжатия: Обеспечивает хорошее сокращение размера файла без значительных затрат CPU.
- Широкая поддержка: Один из наиболее часто используемых алгоритмов сжатия в экосистеме big data.
Недостатки:**
- Менее эффективное сжатие: По сравнению с алгоритмами, ориентированными на максимальное сжатие (например, ZSTD), Snappy может занимать больше места на диске.

Использование: **Отличный выбор по умолчанию для большинства рабочих нагрузок, где скорость чтения является приоритетом, а степень сжатия “достаточно хороша”.

b) ZSTD

Описание:** Алгоритм сжатия, разработанный Facebook, предлагающий значительно лучшую степень сжатия, чем Snappy, при сохранении приемлемой скорости сжатия/декомпрессии.
Преимущества:**
- Высокая степень сжатия: Заметно сокращает объем данных на диске, что приводит к значительной экономии затрат на хранение и уменьшению объема передаваемых данных (IO).
- Хорошая скорость декомпрессии: Хотя и медленнее, чем Snappy, ZSTD всё ещё очень быстр, особенно по сравнению с GZIP, что делает его пригодным для аналитических нагрузок.
Недостатки:**
- Более высокое использование CPU: Процесс сжатия и декомпрессии требует больше ресурсов CPU, чем Snappy, что может немного увеличить нагрузку на вычислительные кластеры.

Использование: Рекомендуется, когда **снижение затрат на хранение является приоритетом, и вы готовы пожертвовать небольшой частью производительности CPU. Отличный выбор для архивных данных или данных с высоким коэффициентом повторения.

Trino использует кстати уровень 3 и его поменять пока нельзя :(

https://github.com/airlift/aircompressor/blob/3210eb16a5ec40089398c40f40ad1d177228b414/src/main/java/io/airlift/compress/zstd/CompressionParameters.java#L26

public static final int DEFAULT_COMPRESSION_LEVEL = 3;

c) GZIP

Описание:** Широко распространенный и очень эффективный алгоритм сжатия.
Преимущества:**
- Очень высокая степень сжатия: Обеспечивает максимальное уменьшение размера файла, что идеально для архивирования.
Недостатки:**
- Очень медленная декомпрессия: Существенно замедляет операции чтения запросов, что делает его непригодным для интерактивной аналитики.
- Высокое использование CPU: значительно увеличивает нагрузку на CPU при сжатии и декомпрессии.

Использование: **Категорически не рекомендуется для активных аналитических данных в Iceberg. Его использование оправдано только для долгосрочного архивирования, где данные редко запрашиваются, а максимальное сжатие является единственным приоритетом. Для активных данных он значительно ухудшит производительность Trino.

d) LZ4

Описание:** Еще один очень быстрый алгоритм сжатия, схожий по производительности со Snappy, но иногда предлагающий чуть лучшее сжатие.
Преимущества:**
- Очень высокая скорость: Схож со Snappy.
- Хорошее соотношение сжатия.
Недостатки:**
- Схож со Snappy.

Использование:** Альтернатива Snappy, если требуется очень высокая скорость и хорошее сжатие.

3. Конфигурация Iceberg в Trino

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

a) Конфигурация Каталога (Catalog Configuration)

В файле `etc/catalog/.properties` (например, `etc/catalog/iceberg.properties`) вы настраиваете, как Trino будет подключаться к Iceberg и где будут храниться метаданные таблиц.

connector.name=iceberg
iceberg.catalog.type=hive_metastore # или rest, hadoop
hive.metastore.uri=thrift://namenode:9083 # Если hive_metastore
# Для объектного хранилища (например, S3, MinIO)
iceberg.s3.endpoint-url=http://s3.local:9000 
iceberg.s3.region=us-east-1
iceberg.s3.access-key=YOUR_ACCESS_KEY
iceberg.s3.secret-key=YOUR_SECRET_KEY
iceberg.s3.path-style-access=true # Для некоторых S3-совместимых хранилищ

`connector.name=iceberg`: Определяет, что используется коннектор Iceberg.
`iceberg.catalog.type`: Определяет, какой бэкенд каталога Iceberg будет использоваться для хранения метаданных (схемы таблиц, версий и расположения файлов данных).
- `hive_metastore`: Использует существующий Hive Metastore. Это самый распространенный вариант, если у вас уже есть Hive Metastore.
- `rest`: Подключается к Iceberg REST Catalog (требует развертывания отдельного сервиса). Предоставляет более чистый API и может обеспечивать лучшую производительность для операций с каталогом.
- `hadoop`: Использует HDFS для хранения метаданных Iceberg. Менее распространен для продакшн-развертываний.
Параметры хранилища данных (Data Storage):** Независимо от типа каталога, фактические файлы данных Iceberg могут храниться в S3, HDFS, Google Cloud Storage, Azure Blob Storage и т.д. Вам нужно настроить соответствующие параметры в конфигурации каталога Trino для доступа к этому хранилищу (например, `iceberg.s3.endpoint-url`, `iceberg.s3.access-key` для S3).

b) Конфигурация Таблиц (Table Configuration)

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

CREATE TABLE my_iceberg_table (
    id INT,
    name VARCHAR,
    event_timestamp TIMESTAMP(6) WITH TIME ZONE,
    data_json VARCHAR -- Пример для хранения полуструктурированных данных
)
WITH (
    format = 'PARQUET', -- Формат файлов данных
    partitioning = ARRAY['WEEK(event_timestamp)', 'bucket(16, id)'], -- Стратегия партиционирования
    format_version = 2, -- Версия формата Iceberg (рекомендуется 2)
    parquet_compression = 'ZSTD', -- Алгоритм сжатия Parquet
    parquet_row_group_size = '256MB', -- Целевой размер группы строк в Parquet
    write_target_data_file_size_bytes = '536870912', -- ~512MB, Целевой размер файлов данных, записываемых Iceberg
    vacuum_max_snapshots_to_keep = 10, -- Количество последних снимков для хранения
    expire_snapshots_min_retention_ms = 86400000 -- Минимальное время удержания снимков (24 часа)
);

`format`: Определяет формат файла данных (`’PARQUET’` или `’ORC’`). По умолчанию Iceberg использует Parquet.
`partitioning`: Определяет стратегию партиционирования данных. Это критически важно для производительности запросов, так как Trino может пропускать целые партиции, не соответствующие условиям фильтрации. Примеры: `ARRAY[‘year(column_name)’, ‘month(column_name)’]` для временных данных, `ARRAY[‘bucket(N, column_name)’]` для равномерного распределения данных на основе хеша.
`format_version`: Версия формата Iceberg (текущие версии 1 или 2). Рекомендуется использовать `2` для новых таблиц, так как она предлагает больше возможностей (например, поддержка удаления строк, более гибкие индексы, поддержку Positional Deletes).
`parquet_compression`: Указывает алгоритм сжатия для Parquet файлов (`’SNAPPY’`, `’ZSTD’`, `’GZIP’`, `’LZ4’`).
`parquet_row_group_size`: Целевой размер группы строк (row group) в Parquet файле. Рекомендуемый диапазон обычно составляет от 128MB до 512MB. Большие группы строк могут улучшить сжатие и эффективность IO, но могут замедлить запись.
`parquet_page_size`: Размер страницы в пределах группы строк Parquet. Обычно не требует частых изменений, но может влиять на сжатие и гранулярность доступа к данным.
`write_target_data_file_size_bytes`: Очень важный параметр. Определяет целевой размер файлов данных, которые Iceberg будет записывать. Хороший диапазон — от 128 МБ до 1 ГБ (~134217728 до 1073741824 байт). Чрезмерно маленькие файлы приводят к “проблеме маленьких файлов” (Small File Problem), что увеличивает нагрузку на метаданные и замедляет запросы. Чрезмерно большие файлы могут снизить параллелизм чтения.
`vacuum_max_snapshots_to_keep`: Количество последних снимков таблицы, которые Iceberg должен сохранять. Важно для операций `VACUUM` и возможности откатывать таблицу к предыдущим состояниям.
`expire_snapshots_min_retention_ms`: Минимальное время удержания снимков (в миллисекундах) до их удаления.

Подведение Итога

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

Формат Хранения:**
- Parquet: Явно превосходит для большинства аналитических рабочих нагрузок. Колоночная природа, эффективное сжатие, нативная интеграция Field IDs Iceberg для схемы эволюции и широкая поддержка делают его выбором по умолчанию и наиболее рекомендуемым.
- ORC: Достойная альтернатива Parquet, особенно если ваша инфраструктура уже использует ORC. Однако, учитывая нюансы отображения типов и общий тренд, Parquet часто является предрочтительнее для новых проектов.
- Avro: Категорически не подходит для хранения ~~данных~~ аналитических таблиц. Несмотря на то, что Iceberg использует Avro для своих метаданных, применение его для самих данных приведет к крайне низкой производительности и высоким затратам.

Алгоритмы Сжатия:**
- Snappy: Отличный компромисс между скоростью и степенью сжатия. Хорош для большинства активных данных, где скорость доступа критична.
- ZSTD: Предпочтителен, если снижение затрат на хранение является приоритетом, и вы готовы к небольшому увеличению использования CPU. Начинает обгонять Snappy по популярности для многих сценариев.
- GZIP: Избегайте для активных данных из-за низкой скорости декомпрессии. Используйте только для долгосрочного архивирования.

Конфигурация:**
- Партиционирование: Критично для ускорения запросов. Выбирайте его с умом, основываясь на шаблонах запросов и объеме данных.
- Версия формата Iceberg (v2): Используйте для новых таблиц, чтобы получить доступ к последним возможностям.
- Целевой размер файлов (`write_target_data_file_size_bytes`): Настройте в диапазоне 128MB-1GB, чтобы избежать проблемы маленьких файлов и обеспечить хороший параллелизм Trino.
- Параметры сжатия и размера блоков Parquet: Настройте такие параметры, как `parquet_row_group_size` и `parquet_compression` для дальнейшей оптимизации.

Используя Iceberg с Trino, вы получаете мощную комбинацию для создания высокопроизводительных, надежных и управляемых озер данных. Тщательный выбор форматов хранения, алгоритмов сжатия и тонкая настройка конфигурации будут ключами к максимальному использованию потенциала этих технологий, обеспечивая оптимальную производительность запросов при контролируемых затратах. Начните с Parquet и Snappy/ZSTD, а затем адаптируйте конфигурацию в зависимости от ваших конкретных рабочих нагрузок и требований к стоимости.