{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Yuriy Gavrilov: posts tagged Iceberg",
    "_rss_description": "Welcome to my personal place for love, peace and happiness 🤖 Yuiry Gavrilov",
    "_rss_language": "en",
    "_itunes_email": "yvgavrilov@gmail.com",
    "_itunes_categories_xml": "",
    "_itunes_image": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic-square@2x.jpg?1643451008",
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/gavrilov.info\/tags\/iceberg\/",
    "feed_url": "https:\/\/gavrilov.info\/tags\/iceberg\/json\/",
    "icon": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008",
    "authors": [
        {
            "name": "Yuriy Gavrilov - B[u]g - for charity.gavrilov.eth",
            "url": "https:\/\/gavrilov.info\/",
            "avatar": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008"
        }
    ],
    "items": [
        {
            "id": "306",
            "url": "https:\/\/gavrilov.info\/all\/apache-iceberg-v3-gotov-li-on\/",
            "title": "Apache Iceberg V3: Готов ли он?",
            "content_html": "<h2>Apache Iceberg V3: Готов ли он?<\/h2>\n<p>Автор: Guy Yasoor (Ryft Blog)<br \/>\nПеревод и дополнения: Gemini 3 Pro Preview и я кофе носил<\/p>\n<p>Оригинал: <a href=\"https:\/\/www.ryft.io\/blog\/apache-iceberg-v3-is-it-ready\">https:\/\/www.ryft.io\/blog\/apache-iceberg-v3-is-it-ready<\/a><\/p>\n<p>Выход Apache Iceberg V3 — это огромный шаг вперед для экосистемы лейкхаусов (lakehouse). Спецификация V3 была финализирована и ратифицирована в начале этого года, привнеся в ядро формата несколько долгожданных возможностей: эффективные удаления на уровне строк (row-level deletes), встроенное отслеживание происхождения строк (row lineage), улучшенная обработка полуструктурированных данных и зачатки нативного шифрования.<\/p>\n<p>Этим новым возможностям уделяется много внимания, но в разговорах часто упускают вопрос, который важен не меньше: <b>Насколько V3 готов на практике?<\/b><\/p>\n<p>Честный ответ: это полностью зависит от ваших движков обработки данных (engines). Некоторые среды, такие как Spark и Flink, уже хорошо поддерживают V3. Другие — пока отстают.<\/p>\n<hr \/>\n<h3>Основные возможности V3<\/h3>\n<h4>Deletion Vectors (Векторы удаления)<\/h4>\n<p>Векторы удаления прикрепляют информацию об удалении строк непосредственно к файлам данных в виде битовых карт, избегая накопления позиционных файлов удалений (positional delete files).<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">&gt;**поИИснение:**\n&gt;В предыдущих версиях (V2) использовались **Positional Delete Files** — это отдельные Parquet-файлы, содержащие пути и позиции удаленных строк. При чтении (Merge-on-Read) движку приходилось считывать файл данных, считывать файл удалений и делать между ними `JOIN`, чтобы отфильтровать ненужное. Это требует много памяти и ввода-вывода (IO).\n&gt;\n&gt;**Deletion Vector (V3)** — это, по сути, компактная битовая карта (bitmap), хранящаяся внутри или рядом с файлом данных. Движку достаточно прочитать этот маленький массив битов пропустить удаленные строки &quot;на лету&quot;, без дорогостоящих операций слияния. Это критически ускоряет чтение активно изменяемых таблиц.<\/code><\/pre><ul>\n<li><b>Статус:<\/b>\n<ul>\n  <li>Принято в большинстве движков, реализующих V3.<\/li>\n  <li>Стабильное чтение\/запись в `Apache Spark`, `Apache Flink`.<\/li>\n  <li>Вероятно, самая готовая к продакшену функция.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h4>Row Lineage (Происхождение строк)<\/h4>\n<p>Row lineage вводит стабильные идентификаторы строк и метаданные версий. Это упрощает инкрементальную обработку, CDC, аудит и отладку.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">&gt;**поИИснение:**\n&gt;Без Row Lineage, если вы обновляете таблицу, строки часто физически перезаписываются, и их &quot;личность&quot; теряется. Чтобы понять, что изменилось, приходилось сравнивать полные копии данных (expensive diff).\n&gt;V3 присваивает строкам суррогатные ID. Это позволяет реализовать дешевый CDC (Change Data Capture): вы точно знаете, что &quot;Строка #123&quot; была обновлена, и можете каскадно обновить только связанные с ней агрегаты в витринах данных, вместо пересчета всей витрины.<\/code><\/pre><ul>\n<li><b>Статус:<\/b>\n<ul>\n  <li>Принято в большинстве движков V3.<\/li>\n  <li>Достаточно зрелая технология для V3-совместимых стеков.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h4>Тип данных VARIANT<\/h4>\n<p>`VARIANT` — это нативный тип для полуструктурированных данных, замена хранению JSON в виде простых строк. Однако текущая поддержка частичная: не хватает “шреддинга” (shredding).<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">&gt;**поИИснение:**\n&gt;В чем суть **Shredding (измельчения)**? Если вы храните JSON как строку (String), базе данных нужно парсить весь JSON для каждого запроса, чтобы достать одно поле `{&quot;user&quot;: &quot;Ivan&quot;, ...}`. Это медленно.\n&gt;Тип `VARIANT` хранит данные в бинарном формате. А **Shredding** — это оптимизация, когда движок замечает, что поле `user` встречается в 95% записей. Он автоматически вытаскивает это поле в отдельную физическую колонку Parquet, сохраняя при этом логическую структуру JSON. Это позволяет читать поле `user` так же быстро, как обычную колонку, но сохранять гибкость схемы (schema evolution), не делая `ALTER TABLE` при добавлении новых полей в JSON.<\/code><\/pre><ul>\n<li>Статус:**\n<ul>\n  <li>Поддерживается в Spark, Flink, Databricks SQL.<\/li>\n  <li>Parquet стандартизирует кодировки, что даст общее представление для оптимизации.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h4>Геопространственные типы и Шифрование<\/h4>\n<p>V3 вводит типы для гео-данных и блоки для шифрования на уровне таблицы.<\/p>\n<ul>\n<li><b>Статус:<\/b> Гео-типы доступны через расширения (`Apache Sedona`), шифрование находится на ранней стадии (только Spark\/Flink).<\/li>\n<\/ul>\n<hr \/>\n<h3>Поддержка движками: Где V3 реально работает?<\/h3>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td style=\"text-align: center\">Движок<\/td>\n<td style=\"text-align: center\">Статус V3<\/td>\n<td style=\"text-align: center\">Комментарий<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Apache Spark<\/b><\/td>\n<td style=\"text-align: center\">✅ Отличный<\/td>\n<td style=\"text-align: center\">Начиная с v4.0 — самая надежная платформа для V3.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Apache Flink<\/b><\/td>\n<td style=\"text-align: center\">✅ Хороший<\/td>\n<td style=\"text-align: center\">Идеален для стриминга, поддерживает основные фичи.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Databricks<\/b><\/td>\n<td style=\"text-align: center\">⚠️ Beta<\/td>\n<td style=\"text-align: center\">Работает, но есть ограничения по типам данных.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>AWS (Glue\/EMR)<\/b><\/td>\n<td style=\"text-align: center\">⚠️ Частичный<\/td>\n<td style=\"text-align: center\">Зависит от версии движка под капотом.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Amazon Athena<\/b><\/td>\n<td style=\"text-align: center\">❌ Нет<\/td>\n<td style=\"text-align: center\"><b>Главный блокер<\/b> для пользователей AWS.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Trino \/ Starburst<\/b><\/td>\n<td style=\"text-align: center\">🔸 Смешанный<\/td>\n<td style=\"text-align: center\">Starburst (коммерческий) поддерживает, OSS Trino — нет.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Snowflake<\/b><\/td>\n<td style=\"text-align: center\">⏳ Ожидание<\/td>\n<td style=\"text-align: center\">Активно разрабатывали спецификацию, но публичной поддержки V3 в Managed Iceberg пока нет.<\/td>\n<\/tr>\n<\/table>\n<hr \/>\n<h3>Итог: Переходить ли на V3?<\/h3>\n<p>Для большинства: <b>пока нет<\/b>.<br \/>\nКлючевые игроки (Athena, Trino OSS, Snowflake) не готовы. Переходите, только если ваш стек состоит исключительно из <b>Spark<\/b> или <b>Flink<\/b>.<\/p>\n<hr \/>\n<h3>🔮 МненИИе и гаданИИе на кофейной гуще<\/h3>\n<h4>Прогноз на год вперед<\/h4>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td style=\"text-align: center\">Аспект<\/td>\n<td style=\"text-align: center\">Прагматичный прогноз (Реализм)<\/td>\n<td style=\"text-align: center\">Супер-прогноз (Оптимизм\/Хайп)<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Принятие<\/b><\/td>\n<td style=\"text-align: center\">Крупный энтерпрайз начнет пилоты к концу года. Основная масса ждет Athena\/BigQuery.<\/td>\n<td style=\"text-align: center\">V3 станет стандартом для всех greenfield проектов весной. Утилиты миграции ускорят отказ от Hive\/Delta.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Каталоги<\/b><\/td>\n<td style=\"text-align: center\"><b>REST Catalog<\/b> убивает Hive Metastore. Появление managed REST сервисов.<\/td>\n<td style=\"text-align: center\"><b>Universal Catalog Protocol<\/b>: один каталог для Iceberg, Delta и Hudi. Формат станет прозрачным для пользователя.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Скорость<\/b><\/td>\n<td style=\"text-align: center\">+30-50% к скорости MERGE операций благодаря векторам удаления.<\/td>\n<td style=\"text-align: center\">Нейросетевые оптимизаторы запросов и p2p кэширование сделают “холодный” Iceberg по скорости равным in-memory СУБД.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Python<\/b><\/td>\n<td style=\"text-align: center\">`PyIceberg` получит полную поддержку записи (Write).<\/td>\n<td style=\"text-align: center\">Python-стек (DuckDB + PyIceberg) начнет вытеснять Spark в задачах малого\/среднего объема.<\/td>\n<\/tr>\n<\/table>\n<h4>Roadmap: 10 шагов развития<\/h4>\n<ol start=\"1\">\n<li><b>Аудит совместимости:<\/b> Проверить всех потребителей данных. Если есть Athena — V3 откладывается.<\/li>\n<li><b>Переход на REST Catalog:<\/b> Отказ от Hive Metastore.  <br \/>\n><b>поИИснение:<\/b>  <br \/>\n>REST Catalog отвязывает клиента (Spark\/Trino) от прямого доступа к файловой системе (S3\/HDFS). Это безопаснее (можно выдавать временные креды “Vended Credentials”) и позволяет менять физическое расположение данных, не ломая настройки клиентов.<\/li>\n<li><b>Апгрейд Spark\/Flink:<\/b> Только свежие версии (Spark 3.5+\/4.0) умеют работать с V3 корректно.<\/li>\n<li><b>Внедрение “Puffin” статистики:<\/b>  <br \/>\n><b>поИИснение:<\/b>  <br \/>\n>Puffin — это формат файлов-спутников для Iceberg, которые хранят продвинутую статистику, например, эскизы (sketches) для оценки уникальных значений (`count distinct`) без чтения данных. Внедрение этого шага ускоряет планирование запросов.<\/li>\n<li><b>Изолированный пилот:<\/b> Запуск V3 на одной стриминговой джобе для проверки Deletion Vectors.<\/li>\n<li><b>Оптимизация CDC:<\/b> Использование Row Lineage для дедупликации потоков.<\/li>\n<li><b>PyIceberg для легких ETL:<\/b> Замена тяжелых JVM-джоб на Python там, где объемы небольшие.<\/li>\n<li><b>Миграция JSON в VARIANT:<\/b> Как только движки поддержат шреддинг, это сэкономит гигабайты и часы CPU.<\/li>\n<li><b>Отказ от позиционных удалений:<\/b> Полное переключение write-конфигурации на векторы.<\/li>\n<li><b>Масштабирование:<\/b> Перевод основных витрин на V3.<\/li>\n<\/ol>\n<hr \/>\n<h4>💡 Было бы круто, если бы еще сделали...<\/h4>\n<p><b>Нативную поддержку самоорганизации данных (Z-Order \/ Clustering) без внешних компакторов.<\/b><\/p>\n<p><b>Почему:<\/b> Сейчас, чтобы запросы “летали” и пропускали ненужные файлы (data skipping), данные нужно сортировать (Z-Order). Это делают отдельные тяжелые джобы (`maintenance jobs`).<br \/>\nБыло бы круто, если бы спецификация позволяла <b>писателям (writers)<\/b> автоматически поддерживать приближенную кластеризацию при вставке данных (opportunistic clustering), либо если бы формат поддерживал <b>Secondary Indexes<\/b> (вторичные индексы на основе B-деревьев или Bitmap), хранящиеся прямо в слое метаданных. Это позволило бы Iceberg конкурировать с ClickHouse и Druid в сценариях интерактивной аналитики (sub-second latency), убрав необходимость в постоянном “обслуживании” таблиц.<\/p>\n",
            "date_published": "2025-12-18T22:06:36+03:00",
            "date_modified": "2025-12-18T22:05:42+03:00",
            "tags": [
                "big data",
                "Data",
                "Iceberg"
            ],
            "_date_published_rfc2822": "Thu, 18 Dec 2025 22:06:36 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "306",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "highlight\/highlight.js",
                    "highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "291",
            "url": "https:\/\/gavrilov.info\/all\/sravnenie-apache-iceberg-delta-lake-i-apache-hudi-glubokiy-anali\/",
            "title": "Сравнение Apache Iceberg, Delta Lake и Apache Hudi: Глубокий анализ (2025)",
            "content_html": "<p>С ростом популярности архитектуры <b>Data Lakehouse<\/b> усилился интерес к трём основным открытым проектам в этой области: <b>Apache Hudi<\/b>, <b>Delta Lake<\/b> и <b>Apache Iceberg<\/b>. Все три технологии продолжают активно развиваться, и в этой статье представлено актуальное сравнение их возможностей по состоянию на октябрь 2025 года.<\/p>\n<p>Оригинал тут: <a href=\"https:\/\/www.onehouse.ai\/blog\/apache-hudi-vs-delta-lake-vs-apache-iceberg-lakehouse-feature-comparison\">https:\/\/www.onehouse.ai\/blog\/apache-hudi-vs-delta-lake-vs-apache-iceberg-lakehouse-feature-comparison<\/a><\/p>\n<blockquote>\n<p><b>Примечание:<\/b> Если выбор формата вызывает сложности, обратите внимание на проект <b>Apache XTable<\/b> (Incubating), который обеспечивает интероперабельность между Hudi, Delta и Iceberg, позволяя использовать несколько форматов одновременно.<\/p>\n<\/blockquote>\n<h3>Сравнение возможностей<\/h3>\n<h4>Функциональность записи<\/h4>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td>Функция<\/td>\n<td>Apache Hudi (v1.0.2)<\/td>\n<td>Delta Lake (v4.0.0)<\/td>\n<td>Apache Iceberg (v1.10.0)<\/td>\n<\/tr>\n<tr>\n<td><b>ACID-транзакции<\/b><\/td>\n<td>✅<\/td>\n<td>✅<\/td>\n<td>✅<\/td>\n<\/tr>\n<tr>\n<td><b>Copy-on-Write<\/b><\/td>\n<td>✅<\/td>\n<td>✅<\/td>\n<td>✅<\/td>\n<\/tr>\n<tr>\n<td><b>Merge-on-Read<\/b><\/td>\n<td>✅ Полнофункциональный<\/td>\n<td>❌ Векторы удалений (эксперимент.)<\/td>\n<td>❌ Векторы удалений (огранич.)<\/td>\n<\/tr>\n<tr>\n<td><b>Эффективная bulk-загрузка<\/b><\/td>\n<td>✅ Bulk_Insert<\/td>\n<td>✅<\/td>\n<td>✅<\/td>\n<\/tr>\n<tr>\n<td><b>Индексирование<\/b><\/td>\n<td>✅ 8+ типов индексов<\/td>\n<td style=\"text-align: left\">❌ Bloom-фильтр проприетарный<\/td>\n<td>✅ Метаданные для статистики<\/td>\n<\/tr>\n<tr>\n<td><b>Частичные обновления<\/b><\/td>\n<td>✅ Partial Updates<\/td>\n<td>❌<\/td>\n<td>❌<\/td>\n<\/tr>\n<tr>\n<td><b>Миграция таблиц<\/b><\/td>\n<td>✅ Bootstrap<\/td>\n<td>✅ Convert to Delta<\/td>\n<td>❌<\/td>\n<\/tr>\n<tr>\n<td><b>Управление конкуренцией<\/b><\/td>\n<td>✅ OCC, MVCC, NBCC<\/td>\n<td>✅ OCC<\/td>\n<td>✅ OCC<\/td>\n<\/tr>\n<tr>\n<td><b>Неблокирующая конкуренция<\/b><\/td>\n<td>✅ NBCC<\/td>\n<td>❌ OCC с перезапуском<\/td>\n<td>❌ OCC с перезапуском<\/td>\n<\/tr>\n<tr>\n<td><b>Менеджеры блокировок<\/b><\/td>\n<td>✅ ФС, DynamoDB, Hive, Zookeeper<\/td>\n<td>✅ Только внешний DynamoDB<\/td>\n<td>✅ Каталог или внешние провайдеры<\/td>\n<\/tr>\n<tr>\n<td><b>Дедупликация<\/b><\/td>\n<td>✅ Ключи, Precombine<\/td>\n<td>❌ Нет первичных ключей<\/td>\n<td>❌ Нет первичных ключей<\/td>\n<\/tr>\n<tr>\n<td><b>Зависимость от каталога<\/b><\/td>\n<td>❌ Не требуется<\/td>\n<td>❌ Не требуется<\/td>\n<td>✅ Обязателен<\/td>\n<\/tr>\n<\/table>\n<p><b>Ключевые отличия:<\/b><\/p>\n<ul>\n<li><b>Hudi<\/b> предлагает наиболее продвинутые механизмы управления конкуренцией, включая неблокирующий контроль (NBCC)<\/li>\n<li>Только <b>Hudi<\/b> поддерживает настоящий Merge-on-Read без компромиссов производительности<\/li>\n<li><b>Hudi<\/b> предоставляет встроенные инструменты для дедупликации через первичные ключи<\/li>\n<\/ul>\n<h3>Метаданные таблиц<\/h3>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td>Функция<\/td>\n<td>Apache Hudi<\/td>\n<td>Delta Lake<\/td>\n<td>Apache Iceberg<\/td>\n<\/tr>\n<tr>\n<td><b>Масштабируемость метаданных<\/b><\/td>\n<td>✅ LSM-дерево + HFile (100x ускорение)<\/td>\n<td>❌ Parquet чекпойнты (медленно)<\/td>\n<td>❌ Avro манифесты (медленно)<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left\"><b>Управление индексами<\/b><\/td>\n<td>✅ Асинхронное многомодальное<\/td>\n<td>❌<\/td>\n<td>❌<\/td>\n<\/tr>\n<tr>\n<td><b>Эволюция схемы<\/b><\/td>\n<td>✅ Добавление, переупоряд., удаление<\/td>\n<td>✅<\/td>\n<td>✅<\/td>\n<\/tr>\n<tr>\n<td><b>Эволюция партиций<\/b><\/td>\n<td>✅ Кластеризация + индексы выражений<\/td>\n<td style=\"text-align: left\">✅ Эволюция партиций<\/td>\n<td style=\"text-align: center\">❌<\/td>\n<\/tr>\n<tr>\n<td><b>Первичные ключи<\/b><\/td>\n<td>✅<\/td>\n<td style=\"text-align: right\">❌ Только в проприетарной версии<\/td>\n<td>❌<\/td>\n<\/tr>\n<tr>\n<td><b>Статистика столбцов<\/b><\/td>\n<td>✅ HFile (до 50x ускорение)<\/td>\n<td>✅ Parquet чекпойнт<\/td>\n<td>✅ Avro манифест<\/td>\n<\/tr>\n<\/table>\n<p><b>Важные особенности:<\/b><\/p>\n<ul>\n<li><b>Hudi<\/b> использует оптимизированный формат HFile для метаданных, что значительно ускоряет поиск<\/li>\n<li>Только <b>Hudi<\/b> поддерживает настоящие первичные ключи как в реляционных БД<\/li>\n<li><b>Hudi<\/b> предлагает более гибкий подход к партиционированию через кластеризацию<\/li>\n<\/ul>\n<h3>Функциональность чтения<\/h3>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td>Функция<\/td>\n<td>Apache Hudi<\/td>\n<td>Delta Lake<\/td>\n<td>Apache Iceberg<\/td>\n<\/tr>\n<tr>\n<td><b>Time Travel<\/b><\/td>\n<td>✅<\/td>\n<td>✅<\/td>\n<td>✅<\/td>\n<\/tr>\n<tr>\n<td><b>Merge-on-Read запросы<\/b><\/td>\n<td>✅ Snapshot Query<\/td>\n<td>❌ Сложная поддержка<\/td>\n<td>✅ Все запросы мержат векторы удалений<\/td>\n<\/tr>\n<tr>\n<td><b>Инкрементальные запросы<\/b><\/td>\n<td>✅ + CDC запросы<\/td>\n<td>✅ CDF (эксперимент.)<\/td>\n<td>❌ Только аппенды<\/td>\n<\/tr>\n<tr>\n<td><b>CDC запросы<\/b><\/td>\n<td>✅ + before\/after images<\/td>\n<td>❌<\/td>\n<td>❌<\/td>\n<\/tr>\n<tr>\n<td><b>Вторичные индексы<\/b><\/td>\n<td>✅<\/td>\n<td>❌<\/td>\n<td>❌<\/td>\n<\/tr>\n<tr>\n<td><b>Предикаты для пропуска данных<\/b><\/td>\n<td>✅ Индексы выражений<\/td>\n<td>✅ Логические предикаты<\/td>\n<td>✅ Трансформации таблиц<\/td>\n<\/tr>\n<\/table>\n<h3>Сервисы таблиц<\/h3>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td>Функция<\/td>\n<td>Apache Hudi<\/td>\n<td>Delta Lake<\/td>\n<td>Apache Iceberg<\/td>\n<\/tr>\n<tr>\n<td><b>Авторазмер файлов<\/b><\/td>\n<td>✅<\/td>\n<td>✅<\/td>\n<td>❌ Ручное управление<\/td>\n<\/tr>\n<tr>\n<td><b>Компактизация<\/b><\/td>\n<td>✅ Управляемая<\/td>\n<td>❌ 2-этапное обслуживание<\/td>\n<td>❌ Ручное обслуживание<\/td>\n<\/tr>\n<tr>\n<td><b>Очистка<\/b><\/td>\n<td>✅ Управляемая<\/td>\n<td>❌ VACUUM вручную<\/td>\n<td>❌ Ручное удаление снапшотов<\/td>\n<\/tr>\n<tr>\n<td><b>Кластеризация<\/b><\/td>\n<td>✅ Авто + Z-order\/Hilbert<\/td>\n<td>❌ Z-order в OSS, авто – проприетар.<\/td>\n<td>❌ Z-order вручную<\/td>\n<\/tr>\n<\/table>\n<h3>Поддержка экосистемы<\/h3>\n<p>Все три формата имеют широкую поддержку в экосистеме данных:<\/p>\n<ul>\n<li><b>Apache Spark, Flink, Trino, DBT<\/b> – полная поддержка чтения\/записи во всех форматах<\/li>\n<li><b>Kafka Connect<\/b> – Hudi и Iceberg имеют нативную поддержку, Delta – только проприетарную<\/li>\n<li><b>Облачные платформы<\/b> (AWS, GCP, Azure) – все три формата поддерживаются с некоторыми ограничениями<\/li>\n<li><b>Snowflake<\/b> – нативная поддержка Iceberg, Hudi через XTable<\/li>\n<\/ul>\n<h3>Производительность: TPC-DS бенчмарки<\/h3>\n<p>Согласно независимым тестам:<\/p>\n<ul>\n<li><b>Hudi<\/b> и <b>Delta<\/b> показывают сопоставимую производительность<\/li>\n<li><b>Iceberg<\/b> consistently отстаёт по скорости выполнения запросов<\/li>\n<\/ul>\n<blockquote>\n<p><b>Важно:<\/b> При сравнении производительности учитывайте, что Hudi по умолчанию оптимизирован для mutable-нагрузок (upsert), в то время как Delta и Iceberg – для append-only. Для честного сравнения используйте `bulk-insert` режим в Hudi.<\/p>\n<\/blockquote>\n<h3>Ключевые дифференцирующие возможности<\/h3>\n<h3>Инкрементальные пайплайн<\/h3>\n<p><b>Hudi<\/b> предлагает наиболее зрелую поддержку инкрементальной обработки с трекингом всех изменений (вставки, обновления, удаления) и предоставлением их в виде change streams. Это позволяет строить эффективные ETL-пайплайны без перевычисления полных наборов данных.<\/p>\n<h3>Управление конкуренцией<\/h3>\n<p>В то время как все три системы поддерживают оптимистический контроль конкуренции (OCC), только <b>Hudi<\/b> предлагает:<\/p>\n<ul>\n<li>Неблокирующий контроль конкуренции (NBCC)<\/li>\n<li>Файл-уровневую гранулярность блокировок<\/li>\n<li>Возможность работы с асинхронными сервисами таблиц без остановки записи<\/li>\n<\/ul>\n<h3>Merge-on-Read<\/h3>\n<p>Только <b>Hudi<\/b> предоставляет полнофункциональный Merge-on-Read, который позволяет:<\/p>\n<ul>\n<li>Балансировать между производительностью записи и чтения<\/li>\n<li>Использовать row-ориентированные форматы для стриминга и column-ориентированные для аналитики<\/li>\n<li>Выполнять компактизацию асинхронно<\/li>\n<\/ul>\n<h3>Кластеризация vs Эволюция партиций<\/h3>\n<ul>\n<li><b>Iceberg<\/b>: Partition Evolution – изменение схемы партиционирования для новых данных<\/li>\n<li><b>Hudi<\/b>: Гибридный подход – coarse-grained партиционирование + fine-grained кластеризация с возможностью эволюции без перезаписи данных<\/li>\n<\/ul>\n<h3>Многомодальное индексирование<\/h3>\n<p>Только <b>Hudi<\/b> предлагает асинхронную подсистему индексирования, поддерживающую:<\/p>\n<ul>\n<li>Bloom, hash, bitmap, R-tree индексы<\/li>\n<li>10-100x ускорение point lookup запросов<\/li>\n<li>10-30x общее ускорение запросов в реальных нагрузках<\/li>\n<\/ul>\n<h3>Реальные кейсы использования<\/h3>\n<h3>Peloton<\/h3>\n<ul>\n<li>Увеличение частоты ингестии с 1 раза в день до каждых 10 минут<\/li>\n<li>Снижение времени выполнения снапшот-заданий с 1 часа до 15 минут<\/li>\n<li>Экономия затрат через оптимизацию использования EMR-кластеров<\/li>\n<\/ul>\n<h3>ByteDance\/TikTok<\/h3>\n<ul>\n<li>Обработка таблиц объемом 400+ PB<\/li>\n<li>Ежедневный прирост данных на уровне PB<\/li>\n<li>Пропускная способность >100 GB\/s на таблицу<\/li>\n<li>Выбор Hudi из-за открытости экосистемы и поддержки глобальных индексов<\/li>\n<\/ul>\n<h3>Walmart<\/h3>\n<ul>\n<li>Использование Merge-on-Read для снижения задержек<\/li>\n<li>Нативная поддержка удалений для GDPR\/CCPA compliance<\/li>\n<li>Row versioning для обработки out-of-order данных<\/li>\n<\/ul>\n<h3>Инновации сообщества<\/h3>\n<p>Многие ключевые функции data lakehouse были впервые реализованы в Hudi:<\/p>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td>Инновация Hudi<\/td>\n<td>Год<\/td>\n<td>Аналог в других проектах<\/td>\n<\/tr>\n<tr>\n<td>Транзакционные обновления<\/td>\n<td>2017<\/td>\n<td>Delta OSS (2019)<\/td>\n<\/tr>\n<tr>\n<td>Merge-on-Read<\/td>\n<td>2017<\/td>\n<td>Iceberg (2021)<\/td>\n<\/tr>\n<tr>\n<td>Инкрементальные запросы<\/td>\n<td>2017<\/td>\n<td>Delta Change Feed (2022)<\/td>\n<\/tr>\n<tr>\n<td>Z-order\/Hilbert кривые<\/td>\n<td>2021<\/td>\n<td>Delta OSS (2022)<\/td>\n<\/tr>\n<tr>\n<td>Многомодальное индексирование<\/td>\n<td>2022<\/td>\n<td>❌ Нет аналогов<\/td>\n<\/tr>\n<tr>\n<td>Контроль конкуренции без блокировок<\/td>\n<td>2024<\/td>\n<td>❌ Нет аналогов<\/td>\n<\/tr>\n<\/table>\n<h3>Заключение<\/h3>\n<h3>Критерии выбора<\/h3>\n<p><b>Выбирайте Apache Hudi если:<\/b><\/p>\n<ul>\n<li>Ваши workload’ы содержат значительное количество обновлений и удалений<\/li>\n<li>Требуется низкая задержка от конца в конец<\/li>\n<li>Нужны продвинутые возможности управления конкуренцией<\/li>\n<li>Важна производительность point lookup запросов<\/li>\n<li>Требуется гибкое управление layout данных через кластеризацию<\/li>\n<\/ul>\n<p><b>Рассмотрите Delta Lake если:<\/b><\/p>\n<ul>\n<li>Вы используете экосистему Databricks<\/li>\n<li>Workload’ы преимущественно append-only<\/li>\n<li>Достаточно базовых возможностей управления конкуренцией<\/li>\n<\/ul>\n<p><b>Apache Iceberg может подойти если:<\/b><\/p>\n<ul>\n<li>Основная задача – работа с очень большими объемами данных в cloud storage<\/li>\n<li>Требуется скрытое партиционирование с эволюцией<\/li>\n<li>Workload’ы в основном аналитические с минимальными обновлениями<\/li>\n<\/ul>\n<h3>Итоговые рекомендации<\/h3>\n<ol start=\"1\">\n<li><b>Для зрелых production-нагрузок<\/b> с frequent updates, high concurrency и low latency требованиями <b>Apache Hudi<\/b> предлагает наиболее полный набор возможностей.<\/li>\n<\/ol>\n<ol start=\"2\">\n<li><b>Не ограничивайтесь сравнением “галочек”<\/b> – оценивайте производительность на своих данных и workload’ах.<\/li>\n<\/ol>\n<ol start=\"3\">\n<li><b>Рассмотрите Apache XTable<\/b> если невозможно определиться с одним форматом или требуется интероперабельность между системами.<\/li>\n<\/ol>\n<ol start=\"4\">\n<li><b>Учитывайте roadmap проекта<\/b> – Hudi продолжает лидировать в инновациях, что может быть важно для долгосрочных инвестиций.<\/li>\n<\/ol>\n<p>Технологии data lakehouse продолжают быстро развиваться, и выбор должен основываться на конкретных требованиях ваших use cases, а не только на текущем состоянии функциональности.<\/p>\n",
            "date_published": "2025-11-01T00:53:55+03:00",
            "date_modified": "2025-11-01T00:53:37+03:00",
            "tags": [
                "big data",
                "Data",
                "Data Engineer",
                "Iceberg"
            ],
            "_date_published_rfc2822": "Sat, 01 Nov 2025 00:53:55 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "291",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "252",
            "url": "https:\/\/gavrilov.info\/all\/iceberg-v-trino-puteshestvie-po-variantam-hraneniya-szhatiya-i-k\/",
            "title": "Iceberg в Trino: Путешествие по Вариантам Хранения, Сжатия и Конфигурации для Оптимальной Производительности",
            "content_html": "<p>Iceberg, как табличный формат, совершил революцию в управлении данными в озерах данных (data lakes), предоставив транзакционные гарантии и схематическую эволюцию для данных, хранящихся в файлах. В контексте Trino, мощного распределенного SQL-движка, Iceberg раскрывает свой потенциал, позволяя пользователям взаимодействовать с данными в озерах как с традиционными базами данных. Эта статья углубится в различные варианты хранения, сжатия и конфигурации Iceberg в Trino, рассматривая преимущества и недостатки каждого, и поможет вам сделать осознанный выбор для достижения оптимальной производительности и минимизации затрат.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-07-06-v-21.08.54.png\" width=\"1784\" height=\"496\" alt=\"\" \/>\n<\/div>\n<p>Автор: Gemini Flash. 2.5<\/p>\n<h3>1. Форматы Хранения (File Formats)<\/h3>\n<p>Iceberg не хранит данные сам по себе, а указывает на файлы данных, которые могут быть разных форматов. Выбор формата данных является одним из наиболее важных решений, напрямую влияющим на производительность запросов, эффективность сжатия и общую стоимость хранения.<\/p>\n<h4>a) Parquet<\/h4>\n<ul>\n<li>Описание:** Колоночный формат хранения данных, оптимизированный для аналитических запросов. Он хранит данные в колоночной ориентации, что позволяет Trino считывать только необходимые колонки во время выполнения запросов. Parquet тесно интегрирован с концепциями Iceberg, такими как использование идентификаторов полей (Field IDs) для поддержки надежной схемы эволюции.<\/li>\n<li>Преимущества:**\n<ul>\n  <li><b>Высокая производительность в аналитике:<\/b> За счет колоночного хранения и возможности Trino применять “push-down” предикатов, Parquet обеспечивает беспрецедентную скорость для большинства аналитических запросов, избирательно считывая только необходимые данные.<\/li>\n  <li><b>Эффективное сжатие:<\/b> Колоночная ориентация позволяет применять различные алгоритмы сжатия, оптимизированные для типов данных в каждой колонке, существенно снижая объем хранимых данных и, как следствие, затраты на хранение.<\/li>\n  <li><b>Нативная поддержка схемы эволюции Iceberg:<\/b> Iceberg использует Field IDs, которые записываются в метаданды Parquet. Это ключевой механизм, позволяющий Iceberg поддерживать эволюцию схемы (добавление, удаление, переименование колонок) без перезаписи данных и без нарушения целостности запросов.<\/li>\n  <li><b>Широкая поддержка и зрелость:<\/b> Parquet является фактическим стандартом для хранения аналитических данных в экосистеме больших данных и поддерживается всеми основными инструментами (Spark, Hive, Dremio, Athena, BigQuery, Snowflake и т.д.), обеспечивая отличную интероперабельность.<\/li>\n<\/ul>\n<\/li>\n<li>Недостатки:**\n<ul>\n  <li><b>Неэффективен для точечных запросов (point lookups):<\/b> Для выборки одной или нескольких записей требуется считывать данные из нескольких колонок, что может быть менее эффективно, чем строковые форматы данных.<\/li>\n  <li><b>Сложность изменения данных:<\/b> Изменение отдельных записей требует перезаписи целых файлов или их частей, что является общей чертой для колоночных форматов.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li>Использование:<b> **Parquet – это формат по умолчанию и наиболее рекомендуемый выбор для таблиц Iceberg в Trino.<\/b> Он обеспечивает наилучший баланс производительности, эффективности хранения и простоты управления для большинства аналитических рабочих нагрузок.<\/li>\n<\/ul>\n<h4>b) ORC (Optimized Row Columnar)<\/h4>\n<ul>\n<li>Описание:** Ещё один колоночный формат, разработанный специально для Apache Hive. Он имеет много сходств с Parquet, включая колоночное хранение и эффективное сжатие. Документация Iceberg подтверждает, что ORC также может хранить необходимые метаданные (например, `iceberg.id`, `iceberg.required`) в атрибутах типов ORC для поддержки схемы эволюции.<\/li>\n<li>Преимущества:**\n<ul>\n  <li><b>Высокая производительность и эффективное сжатие:<\/b> Аналогично Parquet, ORC обеспечивает отличную производительность для аналитических запросов и эффективное сжатие.<\/li>\n  <li><b>Расширенное индексирование:<\/b> ORC часто содержит более гранулированные встроенные индексы (например, индексы позиций, Bloom-фильтры), которые могут быть полезны для некоторых специфических типов запросов.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Но Bloom-фильтры по умолчанию отключены в Trino вроде как, надо проверять этот конфиг:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Screenshot-from-2025-07-07-12-13-51.png\" width=\"1497\" height=\"672\" alt=\"\" \/>\n<\/div>\n<ul>\n<li><b>Совместимость со схемой эволюции Iceberg:<\/b> Iceberg способен адаптировать ORC-схему (даже путем изменения имен колонок) для своей ID-основанной эволюции, что делает его совместимым.<\/li>\n<li>Недостатки:**<\/li>\n<li><b>Неэффективен для точечных запросов:<\/b> Общий недостаток для всех колоночных форматов.<\/li>\n<li><b>Менее распространен как универсальный формат вне экосистемы Hive:<\/b> Хотя ORC является основным форматом для Hive, Iceberg чаще ассоциируется с Parquet как универсальным форматом хранения для Data Lake. Это может потенциально означать меньшую поддержку или оптимизацию в некоторых не-Hive инструментах.<\/li>\n<li><b>Специфические моменты с отображением типов:<\/b> Как видно из <a href=\"https:\/\/iceberg.apache.org\/spec\">Iceberg documentation<\/a>, существуют нюансы с отображением типов данных (например, `timestamp` и `timestamptz`) в ORC. Может потребоваться использование дополнительных атрибутов Iceberg (таких как `iceberg.timestamp-unit`) для корректной передачи семантики.<\/li>\n<li><b>Отсутствие “шрединга” для типа `variant`:<\/b> Документация указывает, что для ORC не поддерживается “шрединг” (оптимизированное хранение) для полуструктурированного типа `variant`, что может быть ограничением для пользователей, активно работающих с такими данными.<\/li>\n<\/ul>\n<ul>\n<li>Использование:<b> Хороший выбор для аналитических рабочих нагрузок, особенно если ваша существующая инфраструктура уже использует ORC, и вы хорошо знакомы с его нюансами. Однако, для новых развертываний Iceberg, **Parquet обычно является более простым и универсальным выбором по умолчанию<\/b>.<\/li>\n<\/ul>\n<h4>c) Avro<\/h4>\n<ul>\n<li>Описание:<b> Строковый формат данных, ориентированный на быструю сериализацию и десериализацию. Avro широко используется в Apache Kafka и для передачи данных между системами. Важно отметить, что Iceberg использует Avro в качестве формата **своих внутренних файлов метаданных<\/b> (например, манифестов и метаданных таблиц), где его строковая природа и возможности сериализации очень полезны. Iceberg также описывает, как Avro <i>может быть<\/i> использован для файлов данных, включая строгие правила для отображения типов данных Avro и использование Field IDs для поддержки эволюции схемы.<\/li>\n<li>Преимущества:**\n<ul>\n  <li><b>Отлично подходит для сериализации и передачи данных:<\/b> Благодаря своей компактности и быстрой сериализации\/десериализации, Avro идеален для потоковой передачи.<\/li>\n  <li><b>Встроенная схема (Schema-on-Read):<\/b> Схема хранится вместе с данными, что обеспечивает совместимость. Iceberg расширяет это, добавляя Field IDs в схему Avro для robustной эволюции.<\/li>\n  <li><b>Поддержка эволюции схемы:<\/b> Iceberg, благодаря внедрению Field IDs в схемы Avro и строгим правилам для `union` (например, использование `null` для опциональных полей), способен обеспечить эволюцию схемы даже для данных, хранящихся в Avro. Это <i>технически возможно<\/i> благодаря Iceberg.<\/li>\n<\/ul>\n<\/li>\n<li>Недостатки:**\n<ul>\n  <li><b>Крайне низкая производительность для аналитики:<\/b> <b>Это ключевой и самый серьезный недостаток Avro для аналитических рабочих нагрузок.<\/b> Для запросов требуется считывать всю строку данных, даже если нужны только некоторые колонки. Это приводит к значительному избытку I\/O, увеличивает потребность в памяти и катастрофически замедляет аналитические запросы по сравнению с колоночными форматами.<\/li>\n  <li><b>Неэффективное сжатие:<\/b> Сжатие применяется ко всей строке, а не к отдельным колонкам. Это значительно снижает коэффициент сжатия по сравнению с Parquet или ORC, что приводит к увеличению объема хранимых данных и, соответственно, затрат.<\/li>\n  <li><b>Отсутствие “шрединга” для типа `variant`:<\/b> Как и в ORC, Avro не поддерживает “шрединг” для полуструктурированного типа `variant`, что может ограничивать работу со сложными схемами.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li>Использование:<b> **Категорически не рекомендуется использовать Avro в качестве формата хранения <s>данных<\/s> для таблиц Iceberg, предназначенных для аналитических запросов в Trino.<\/b> Несмотря на то, что Iceberg <i>может<\/i> технически поддерживать его для данных, это приведет к серьезному ухудшению производительности и увеличению затрат. Avro прекрасно подходит для файлов метаданных Iceberg и для потоковых данных, но не для аналитического хранения.<\/li>\n<\/ul>\n<h3>2. Алгоритмы Сжатия (Compression Algorithms)<\/h3>\n<p>Выбор алгоритма сжатия напрямую влияет на размер хранимых данных, скорость чтения\/записи и потребление ресурсов CPU. Trino поддерживает различные алгоритмы сжатия для файлов Parquet и ORC.<\/p>\n<h4>a) Snappy<\/h4>\n<ul>\n<li>Описание:** Высокоскоростной алгоритм сжатия, разработанный Google. Он оптимизирован для скорости сжатия и декомпрессии, а не для максимальной степени сжатия.<\/li>\n<li>Преимущества:**\n<ul>\n  <li><b>Очень быстрая декомпрессия:<\/b> Минимальное влияние на производительность запросов, что критично для активных аналитических систем.<\/li>\n  <li><b>Сбалансированное соотношение сжатия:<\/b> Обеспечивает хорошее сокращение размера файла без значительных затрат CPU.<\/li>\n  <li><b>Широкая поддержка:<\/b> Один из наиболее часто используемых алгоритмов сжатия в экосистеме big data.<\/li>\n<\/ul>\n<\/li>\n<li>Недостатки:**\n<ul>\n  <li><b>Менее эффективное сжатие:<\/b> По сравнению с алгоритмами, ориентированными на максимальное сжатие (например, ZSTD), Snappy может занимать больше места на диске.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li>Использование:<b> **Отличный выбор по умолчанию для большинства рабочих нагрузок<\/b>, где скорость чтения является приоритетом, а степень сжатия “достаточно хороша”.<\/li>\n<\/ul>\n<h4>b) ZSTD<\/h4>\n<ul>\n<li>Описание:** Алгоритм сжатия, разработанный Facebook, предлагающий значительно лучшую степень сжатия, чем Snappy, при сохранении приемлемой скорости сжатия\/декомпрессии.<\/li>\n<li>Преимущества:**\n<ul>\n  <li><b>Высокая степень сжатия:<\/b> Заметно сокращает объем данных на диске, что приводит к значительной экономии затрат на хранение и уменьшению объема передаваемых данных (IO).<\/li>\n  <li><b>Хорошая скорость декомпрессии:<\/b> Хотя и медленнее, чем Snappy, ZSTD всё ещё очень быстр, особенно по сравнению с GZIP, что делает его пригодным для аналитических нагрузок.<\/li>\n<\/ul>\n<\/li>\n<li>Недостатки:**\n<ul>\n  <li><b>Более высокое использование CPU:<\/b> Процесс сжатия и декомпрессии требует больше ресурсов CPU, чем Snappy, что может немного увеличить нагрузку на вычислительные кластеры.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li>Использование:<b> Рекомендуется, когда **снижение затрат на хранение является приоритетом<\/b>, и вы готовы пожертвовать небольшой частью производительности CPU. Отличный выбор для архивных данных или данных с высоким коэффициентом повторения.<\/li>\n<\/ul>\n<p>Trino использует кстати уровень 3 и его поменять пока нельзя :(<\/p>\n<p><a href=\"https:\/\/github.com\/airlift\/aircompressor\/blob\/3210eb16a5ec40089398c40f40ad1d177228b414\/src\/main\/java\/io\/airlift\/compress\/zstd\/CompressionParameters.java#L26\">https:\/\/github.com\/airlift\/aircompressor\/blob\/3210eb16a5ec40089398c40f40ad1d177228b414\/src\/main\/java\/io\/airlift\/compress\/zstd\/CompressionParameters.java#L26<\/a><\/p>\n<pre class=\"e2-text-code\"><code class=\"\">public static final int DEFAULT_COMPRESSION_LEVEL = 3;<\/code><\/pre><h4>c) GZIP<\/h4>\n<ul>\n<li>Описание:** Широко распространенный и очень эффективный алгоритм сжатия.<\/li>\n<li>Преимущества:**\n<ul>\n  <li><b>Очень высокая степень сжатия:<\/b> Обеспечивает максимальное уменьшение размера файла, что идеально для архивирования.<\/li>\n<\/ul>\n<\/li>\n<li>Недостатки:**\n<ul>\n  <li><b>Очень медленная декомпрессия:<\/b> Существенно замедляет операции чтения запросов, что делает его непригодным для интерактивной аналитики.<\/li>\n  <li><b>Высокое использование CPU:<\/b> значительно увеличивает нагрузку на CPU при сжатии и декомпрессии.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li>Использование:<b> **Категорически не рекомендуется для активных аналитических данных в Iceberg.<\/b> Его использование оправдано только для долгосрочного архивирования, где данные редко запрашиваются, а максимальное сжатие является единственным приоритетом. Для активных данных он значительно ухудшит производительность Trino.<\/li>\n<\/ul>\n<h4>d) LZ4<\/h4>\n<ul>\n<li>Описание:** Еще один очень быстрый алгоритм сжатия, схожий по производительности со Snappy, но иногда предлагающий чуть лучшее сжатие.<\/li>\n<li>Преимущества:**\n<ul>\n  <li><b>Очень высокая скорость:<\/b> Схож со Snappy.<\/li>\n  <li><b>Хорошее соотношение сжатия.<\/b><\/li>\n<\/ul>\n<\/li>\n<li>Недостатки:**\n<ul>\n  <li>Схож со Snappy.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li>Использование:** Альтернатива Snappy, если требуется очень высокая скорость и хорошее сжатие.<\/li>\n<\/ul>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-07-06-v-23.42.06.png\" width=\"1714\" height=\"1126\" alt=\"\" \/>\n<\/div>\n<h3>3. Конфигурация Iceberg в Trino<\/h3>\n<p>Правильная настройка Iceberg в Trino включает в себя конфигурацию каталога и параметров создания самих таблиц.<\/p>\n<h4>a) Конфигурация Каталога (Catalog Configuration)<\/h4>\n<p>В файле `etc\/catalog\/<catalog_name>.properties` (например, `etc\/catalog\/iceberg.properties`) вы настраиваете, как Trino будет подключаться к Iceberg и где будут храниться метаданные таблиц.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">connector.name=iceberg\niceberg.catalog.type=hive_metastore # или rest, hadoop\nhive.metastore.uri=thrift:\/\/namenode:9083 # Если hive_metastore\n# Для объектного хранилища (например, S3, MinIO)\niceberg.s3.endpoint-url=http:\/\/s3.local:9000 \niceberg.s3.region=us-east-1\niceberg.s3.access-key=YOUR_ACCESS_KEY\niceberg.s3.secret-key=YOUR_SECRET_KEY\niceberg.s3.path-style-access=true # Для некоторых S3-совместимых хранилищ<\/code><\/pre><ul>\n<li>`connector.name=iceberg`: Определяет, что используется коннектор Iceberg.<\/li>\n<li>`iceberg.catalog.type`: Определяет, какой бэкенд каталога Iceberg будет использоваться для хранения метаданных (схемы таблиц, версий и расположения файлов данных).\n<ul>\n  <li>`hive_metastore`: Использует существующий Hive Metastore. Это самый распространенный вариант, если у вас уже есть Hive Metastore.<\/li>\n  <li>`rest`: Подключается к Iceberg REST Catalog (требует развертывания отдельного сервиса). Предоставляет более чистый API и может обеспечивать лучшую производительность для операций с каталогом.<\/li>\n  <li>`hadoop`: Использует HDFS для хранения метаданных Iceberg. Менее распространен для продакшн-развертываний.<\/li>\n<\/ul>\n<\/li>\n<li>Параметры хранилища данных (Data Storage):** Независимо от типа каталога, фактические файлы данных Iceberg могут храниться в S3, HDFS, Google Cloud Storage, Azure Blob Storage и т.д. Вам нужно настроить соответствующие параметры в конфигурации каталога Trino для доступа к этому хранилищу (например, `iceberg.s3.endpoint-url`, `iceberg.s3.access-key` для S3).<\/li>\n<\/ul>\n<h4>b) Конфигурация Таблиц (Table Configuration)<\/h4>\n<p>При создании таблиц Iceberg в Trino вы можете указывать различные параметры через секцию `WITH`. Это позволяет точно настроить, как Iceberg будет хранить данные.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">CREATE TABLE my_iceberg_table (\n    id INT,\n    name VARCHAR,\n    event_timestamp TIMESTAMP(6) WITH TIME ZONE,\n    data_json VARCHAR -- Пример для хранения полуструктурированных данных\n)\nWITH (\n    format = 'PARQUET', -- Формат файлов данных\n    partitioning = ARRAY['WEEK(event_timestamp)', 'bucket(16, id)'], -- Стратегия партиционирования\n    format_version = 2, -- Версия формата Iceberg (рекомендуется 2)\n    parquet_compression = 'ZSTD', -- Алгоритм сжатия Parquet\n    parquet_row_group_size = '256MB', -- Целевой размер группы строк в Parquet\n    write_target_data_file_size_bytes = '536870912', -- ~512MB, Целевой размер файлов данных, записываемых Iceberg\n    vacuum_max_snapshots_to_keep = 10, -- Количество последних снимков для хранения\n    expire_snapshots_min_retention_ms = 86400000 -- Минимальное время удержания снимков (24 часа)\n);<\/code><\/pre><ul>\n<li>`format`: Определяет формат файла данных (`’PARQUET’` или `’ORC’`). <b>По умолчанию Iceberg использует Parquet.<\/b><\/li>\n<li>`partitioning`: Определяет стратегию партиционирования данных. Это <b>критически важно для производительности запросов<\/b>, так как Trino может пропускать целые партиции, не соответствующие условиям фильтрации. Примеры: `ARRAY[‘year(column_name)’, ‘month(column_name)’]` для временных данных, `ARRAY[‘bucket(N, column_name)’]` для равномерного распределения данных на основе хеша.<\/li>\n<li>`format_version`: Версия формата Iceberg (текущие версии 1 или 2). <b>Рекомендуется использовать `2` для новых таблиц<\/b>, так как она предлагает больше возможностей (например, поддержка удаления строк, более гибкие индексы, поддержку Positional Deletes).<\/li>\n<li>`parquet_compression`: Указывает алгоритм сжатия для Parquet файлов (`’SNAPPY’`, `’ZSTD’`, `’GZIP’`, `’LZ4’`).<\/li>\n<li>`parquet_row_group_size`: Целевой размер группы строк (row group) в Parquet файле. Рекомендуемый диапазон обычно составляет от 128MB до 512MB. Большие группы строк могут улучшить сжатие и эффективность IO, но могут замедлить запись.<\/li>\n<li>`parquet_page_size`: Размер страницы в пределах группы строк Parquet. Обычно не требует частых изменений, но может влиять на сжатие и гранулярность доступа к данным.<\/li>\n<li>`write_target_data_file_size_bytes`: <b>Очень важный параметр.<\/b> Определяет целевой размер файлов данных, которые Iceberg будет записывать. Хороший диапазон — от 128 МБ до 1 ГБ (~134217728 до 1073741824 байт). Чрезмерно маленькие файлы приводят к “проблеме маленьких файлов” (Small File Problem), что увеличивает нагрузку на метаданные и замедляет запросы. Чрезмерно большие файлы могут снизить параллелизм чтения.<\/li>\n<li>`vacuum_max_snapshots_to_keep`: Количество последних снимков таблицы, которые Iceberg должен сохранять. Важно для операций `VACUUM` и возможности откатывать таблицу к предыдущим состояниям.<\/li>\n<li>`expire_snapshots_min_retention_ms`: Минимальное время удержания снимков (в миллисекундах) до их удаления.<\/li>\n<\/ul>\n<h3>Подведение Итога<\/h3>\n<p>Выбор правильных форматов, сжатия и конфигурации для Iceberg в Trino является решающим для оптимизации производительности, стоимости и управляемости вашего озера данных.<\/p>\n<ul>\n<li>Формат Хранения:**\n<ul>\n  <li><b>Parquet:<\/b> Явно превосходит для большинства аналитических рабочих нагрузок. Колоночная природа, эффективное сжатие, нативная интеграция Field IDs Iceberg для схемы эволюции и широкая поддержка делают его <b>выбором по умолчанию и наиболее рекомендуемым.<\/b><\/li>\n  <li><b>ORC:<\/b> Достойная альтернатива Parquet, особенно если ваша инфраструктура уже использует ORC. Однако, учитывая нюансы отображения типов и общий тренд, Parquet часто является предрочтительнее для новых проектов.<\/li>\n  <li><b>Avro:<\/b> <b>Категорически не подходит для хранения <s>данных<\/s> аналитических таблиц.<\/b> Несмотря на то, что Iceberg использует Avro для своих метаданных, применение его для самих данных приведет к крайне низкой производительности и высоким затратам.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li>Алгоритмы Сжатия:**\n<ul>\n  <li><b>Snappy:<\/b> Отличный компромисс между скоростью и степенью сжатия. Хорош для большинства активных данных, где скорость доступа критична.<\/li>\n  <li><b>ZSTD:<\/b> Предпочтителен, если снижение затрат на хранение является приоритетом, и вы готовы к небольшому увеличению использования CPU. Начинает обгонять Snappy по популярности для многих сценариев.<\/li>\n  <li><b>GZIP:<\/b> Избегайте для активных данных из-за низкой скорости декомпрессии. Используйте только для долгосрочного архивирования.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li>Конфигурация:**\n<ul>\n  <li><b>Партиционирование:<\/b> Критично для ускорения запросов. Выбирайте его с умом, основываясь на шаблонах запросов и объеме данных.<\/li>\n  <li><b>Версия формата Iceberg (v2):<\/b> Используйте для новых таблиц, чтобы получить доступ к последним возможностям.<\/li>\n  <li><b>Целевой размер файлов (`write_target_data_file_size_bytes`):<\/b> Настройте в диапазоне 128MB-1GB, чтобы избежать проблемы маленьких файлов и обеспечить хороший параллелизм Trino.<\/li>\n  <li><b>Параметры сжатия и размера блоков Parquet:<\/b> Настройте такие параметры, как `parquet_row_group_size` и `parquet_compression` для дальнейшей оптимизации.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Используя Iceberg с Trino, вы получаете мощную комбинацию для создания высокопроизводительных, надежных и управляемых озер данных. Тщательный выбор форматов хранения, алгоритмов сжатия и тонкая настройка конфигурации будут ключами к максимальному использованию потенциала этих технологий, обеспечивая оптимальную производительность запросов при контролируемых затратах. Начните с Parquet и Snappy\/ZSTD, а затем адаптируйте конфигурацию в зависимости от ваших конкретных рабочих нагрузок и требований к стоимости.<\/p>\n",
            "date_published": "2025-07-06T21:18:49+03:00",
            "date_modified": "2025-07-07T12:15:04+03:00",
            "tags": [
                "big data",
                "Iceberg"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-07-06-v-21.08.54.png",
            "_date_published_rfc2822": "Sun, 06 Jul 2025 21:18:49 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "252",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "highlight\/highlight.js",
                    "highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-07-06-v-21.08.54.png",
                    "https:\/\/gavrilov.info\/pictures\/Screenshot-from-2025-07-07-12-13-51.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-07-06-v-23.42.06.png"
                ]
            }
        }
    ],
    "_e2_version": 4171,
    "_e2_ua_string": "Aegea 11.4 (v4171e)"
}