Apache Iceberg — открытый табличный формат, разработанный для хранения масштабных аналитических данных в озёрах данных. Он высоко совместим с множеством компонентов экосистемы Big Data и, по сравнению с традиционным форматом таблиц Hive, изначально обеспечивает более высокую производительность и лучшую масштабируемость. Поддерживаются ACID‑транзакции, Schema Evolution (эволюция схемы), версионирование данных, Hidden Partition (скрытое партиционирование) и междвижковая совместимость, что делает Iceberg особенно подходящим для ресурсоёмких задач аналитики больших данных.

Однако использование Iceberg сопряжено с рядом вызовов: высокой планкой входа, потребностью в бэкграунд‑обслуживании, необходимостью тонкой оптимизации производительности и продуманной стратегии data governance. Это повышает сложность системы и может ударить по производительности, поэтому пользователям важно соотнести решения с собственными требованиями и сценариями и соответствующим образом настраивать систему.

В этой статье мы подробно разберём архитектуру и особенности Iceberg, оценим его преимущества и текущие вызовы. В финале поделимся несколькими решениями StarRocks + Iceberg, чтобы на реальных сценариях показать, как строить новую парадигму аналитики в лейкхаус‑архитектуре (Lakehouse) на базе StarRocks.

Вызовы Hive в новую эпоху

Несмотря на широкое распространение Hive в экосистеме Big Data, у него есть архитектурные ограничения, которые сказываются при обработке больших наборов данных:

• Высокая стоимость обновлений, отсутствие real‑time‑сценариев: Hive не поддерживает обновления на уровне строк; чтобы изменить одну строку в партиции, часто приходится переписывать всю партицию — крайне неэффективно.

• Отсутствие ACID‑транзакций и проблемы при конкуренции: до версии 3.0 Hive не поддерживал ACID, из‑за чего не справлялся с конкурентными изменениями набора данных и часто приводил к конфликтам и несогласованности.

• Отсутствие атомарности записи: операции overwrite по нескольким партициям могут завершаться частично, создавая несогласованность и «грязные» данные.

• Высокая стоимость изменения схемы: при изменении схемы (добавление/удаление столбцов и т. п.) зачастую требуется пересоздать и повторно загрузить всю таблицу.

• Ограничения на эволюцию партиционирования: Hive не позволяет менять схему партиционирования существующей таблицы; чтобы изменить стратегию партиционирования, создают новую таблицу и мигрируют данные.

• Отсутствие метаданных на уровне файлов: формат таблиц Hive описывает только организацию на уровне партиций и не хранит сведения о конкретных файлах; чтобы их получить, нужно перечислять каталоги/объекты в файловой системе, что дорого по времени.

• Нет вывода партиционирующих столбцов: partition column задаётся явно, не выводится автоматически из data column, что усложняет управление данными и запросы.

• Задержки обновления статистики: устаревшая статистика приводит к субоптимальным планам у оптимизатора и ухудшает эффективность запросов.

• Слабая совместимость с облачными хранилищами: при работе с объектными хранилищами вроде Amazon S3 из‑за ограничений на перечисление объектов по префиксу (list) механизм партиционирования Hive часто упирается в пределы производительности.

Apache Iceberg: табличный формат нового поколения для озёр данных

Несмотря на значимую роль Hive как раннего решения для хранилищ данных, его производительность и гибкость имеют врождённые пределы, осложняющие практическую обработку и аналитику. С появлением «большой тройки» форматов для data lake — Iceberg, Hudi и Delta Lake — пользователи избавились от многих ограничений, а применение озёр данных вышло на новый виток роста.

По оценкам авторитетных экспертов по data lake, хотя сейчас Delta Lake лидирует по доле рынка, в течение ближайших трёх лет Apache Iceberg имеет все шансы обойти его и стать форматом с наибольшей долей. Этот прогноз опирается не только на технологические преимущества Iceberg, но и на широкое признание его потенциала индустрией. Примечательно, что в недавних релизах Snowflake использует табличный формат Iceberg для хранения и управления частью исходных данных, что подтверждает растущее влияние Iceberg и динамику его развития.

The Latest Data Trends and Predictions for 2024 by Dremio
https://www.youtube.com/watch?v=bULVEsss7y

Архитектура Iceberg

Архитектура Apache Iceberg состоит из трёх основных слоёв:

• Слой данных (Data Layer): фактические файлы данных (например, Parquet и ORC); физические носители хранения.

• Слой метаданных (Metadata Layer): многоуровневый; хранит структуру таблицы и индексы файлов данных.

• Слой каталога (Catalog): хранит указатели на местоположение файлов метаданных и служит их индексом.

Реализации Catalog, доступные «из коробки»:

• HadoopCatalog: управление сведениями о таблицах напрямую через каталоги файловой системы Hadoop.

• HiveCatalog: хранение метаданных таблиц в Hive Metastore для упрощённой интеграции с экосистемой Hive.

Пользователи также могут разработать собственные реализации Catalog с помощью API Iceberg и размещать метаданные в альтернативных системах.

Особенности Iceberg

Hidden Partition (скрытое партиционирование)

• Iceberg позволяет партиционировать данные по временным меткам с разной гранулярностью (год, месяц, день, час).

• Поддерживается скрытое партиционирование — детали партиций прозрачны для пользователя.

• Пример: CREATE TABLE catalog.MyTable (..., ts TIMESTAMP) PARTITIONED BY days(ts) задаёт партиционирование по дням; новые записи автоматически попадают в соответствующие партиции.

Schema Evolution (эволюция схемы)

• Поддерживаются гибкие DDL‑операции: добавление, удаление, переименование и обновление столбцов.

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

• Каждое изменение фиксируется в метаданных, что обеспечивает трассируемость и возможность запросов к историческим схемам.

• Для отслеживания столбцов используются уникальные column id, гарантирующие корректность операций чтения/записи файлов.

Partition Evolution (эволюция партиционирования)

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

• Метаданные сохраняют все исторические схемы партиционирования.

• Если данные покрывают разные стратегии партиционирования, Iceberg формирует соответствующие планы выполнения.

MVCC (многоверсионное управление конкурентным доступом)

• Применяется MVCC: запись не мешает чтению; каждое чтение обращается к последнему актуальному снапшоту.

• Операции delete и overwrite изменяют состояние файлов Parquet в Manifest, не удаляя файлы данных напрямую.

Consistency (согласованность данных)

• Поддерживается конкурентная запись; конфликты разрешаются механизмом оптимистичных блокировок (optimistic locking).

• Операции записи основываются на одном и том же снапшоте; при отсутствии конфликтов обе завершатся успешно, при конфликте — только одна.

Обновления на уровне строк: COW и MOR

• COW (Copy on Write): формат V1 — при обновлении данные копируются, изменения применяются к копии.

• MOR (Merge on Read): формат V2 — используются position delete и equality delete для логических удалений; чтение отражает актуальное состояние.

  • Position delete хранит позиционную информацию о строках для удаления — подходит при редких изменениях.

  • Equality delete хранит значения для удаления; при чтении выполняется сравнение и отбор.

Проблемы производительности запросов в Iceberg

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

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

• Особенно ощутимо это в объектных хранилищах вроде Amazon S3: даже при кэшировании входных файлов операции разбора (parsing) остаются дорогими.

• Значительная стоимость парсинга связана с тем, что Manifest‑файлы (manifest files) сильно сжаты. Типичный манифест размером 8 МБ после распаковки может занимать до 300 МБ ОЗУ. При чтении на C++ даже в лучших условиях парсинг занимает порядка 1 секунды.

• Публичные кейсы показывают: при больших объёмах метаданных (big metadata) планирование запросов может занимать до 50 минут; выполнение одиночного запроса — десятки минут. Память, потребляемая манифестами, становится критичным фактором.

• При потреблении манифестов, несмотря на многопоточные механизмы управления потоком (flow control), локальные оптимизации одного запроса (например, специфическое кэширование) могут снижать скорость чтения и негативно влиять на производительность. При высокой конкуренции задач это усиливается, и паузы GC порой превышают реальное время выполнения.

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

StarRocks — лучший ускоритель запросов к Iceberg

StarRocks не только эффективно анализирует данные во внутреннем хранении, но и выступает вычислительным движком для прямого анализа данных в озере. С помощью External Catalog в StarRocks пользователи легко выполняют запросы к данным в Iceberg без миграции. Поддерживается чтение таблиц Iceberg v1 и v2 (включая position delete и equality delete), а также запись данных в таблицы Iceberg.

Производительность запроса зависит от получения и разбора метаданных, формирования плана и его эффективного исполнения. Для запросов к Iceberg StarRocks использует нативный векторизованный движок, CBO (Cost‑Based Optimizer) и ряд дополнительных оптимизаций для lake‑запросов.

Получение и разбор метаданных

Для внешних данных StarRocks подтягивает метаданные из внешней системы и парсит их. Узкие места: удалённый файловый I/O и разбор (decompress + decode).

• Кэш метаданных StarRocks позволяет избегать повторных выборок и лишнего I/O.

• При больших объёмах метаданных узким местом становится парсинг. Манифесты Iceberg представлены в построчных форматах (например, Avro), и их разбор традиционно выполняется централизованно на планирующих узлах/FE (FrontEnd). При большом числе файлов это ведёт к росту нагрузки на CPU планировщика и увеличению времени планирования. При этом один Manifest может описывать десятки тысяч data files, из которых запрос затрагивает считаные — «рентабельность» парсинга падает.

Начиная с версии 3.3 StarRocks поддерживает распределённый Job Plan для Iceberg:

• Метаданные читаются параллельно во всей MPP‑кластерной архитектуре StarRocks.

• Чтение и фильтрация Manifest выполняются на каждом BE (BackEnd), после чего агрегированные результаты возвращаются на FE для дальнейших стадий.

• Пайплайн без сохранения состояния (stateless) — прозрачен для пользователя и лёгок внутри (без персистентных служебных данных).

Ещё один шаг — кэшировать уже разобранные манифесты. С версии 3.3 доступен Manifest Cache (кэш десериализованных Manifest). При попадании в ранее прочитанные файлы StarRocks берёт сведения прямо из кэша, резко снижая стоимость парсинга.

Эти улучшения обходят ограничения Iceberg SDK и задействуют распределённый фреймворк и конвейерный (pipeline) движок StarRocks. Это позволяет при высокой конкуренции, больших метаданных и множестве файлов таблиц преодолевать нативные пределы Iceberg, ускорять запросы и снижать нагрузку на процессы data governance и оптимизации.

Формирование эффективных планов выполнения

Чтобы строить качественные планы, CBO требуется богатая статистика, учитывающая перекосы данных, различия в размерах связанных таблиц и т. п.

• С версии 3.2 StarRocks собирает статистику по внешним таблицам (Hive и Iceberg).

• С версии 3.3 поддерживаются гистограммы и сбор статистики по подколонкам сложного типа Struct.

Эти данные существенно улучшают планы выполнения в StarRocks.

Оптимизации для открытых форматов

В озёрах данных обычно используются открытые форматы: Parquet, ORC, TextFile и др. Для них StarRocks проводит постоянные и тонкие оптимизации:

• Максимальное использование нативной информации форматов (footer, словари и пр.) для сокращения объёма сканирования.

• Стратегии минимизации удалённого I/O, включая динамически адаптивное объединение I/O.

Кроме того, для доступа к историческим данным в иных форматах расширён коннекторный фреймворк: поддержано чтение Avro, SequenceFile и RCFile.

«Чёрная магия» для сглаживания разницы между внешними и внутренними таблицами

Архитектура Lakehouse обеспечивает единый источник истины (Single Source of Truth), экономна и масштабируема. Но lake‑запросы неизбежно обращаются к открытым форматам в удалённом хранилище, что:

• повышает I/O‑затраты относительно внутренних таблиц StarRocks;

• не позволяет задействовать оптимизации нативного формата StarRocks.

Чтобы дать пользователям озера опыт уровня DWH, StarRocks предлагает два ключевых инструмента.

Data Cache

Data Cache — локальное кэширование горячих данных:

• Кэш активируется запросами, разбивает затрагиваемые удалённые данные на блоки (block‑level) и подгружает их локально (память + диск).

• При повторных обращениях чтение идёт локально без обращения к удалённому хранилищу — I/O снижается.

• Кэш прозрачен для пользователя и не нарушает согласованность данных.

• При полном попадании в кэш StarRocks обеспечивает опыт, сравнимый с внутренними таблицами.

Data Cache особенно полезен при нестабильной работе удалённых хранилищ (например, HDFS), сглаживая влияние внешней среды и стабилизируя производительность.

Интеллектуальные материализованные представления

В сценариях со сложной логикой и жёсткими требованиями к производительности и конкуренции материализованные представления (Materialized Views) дают существенный прирост:

• По заранее заданным запросам внешние данные регулярно трансформируются и загружаются во внутреннее хранение StarRocks — без самостоятельного управления импортным pipeline.

• Эти данные пользуются всеми ускорениями нативного формата StarRocks: Colocate Join, индексы и др.

• При выполнении запросов применяется интеллектуальное переписывание запросов (query rewrite): пользователь не меняет запрос, StarRocks перенаправляет его на уже материализованный результат.

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

Глубокая интеграция с экосистемой

StarRocks не только читает таблицы Iceberg v1/v2 (включая pos‑delete и eq‑delete), но и поддерживает запись обратно в Iceberg. Это позволяет:

• унифицировать активы данных в озере,

• выполнять лёгкую переработку данных непосредственно «на озере».

Сценарии:

• Выгрузка/запись данных в озеро: в задачах с высокими требованиями к свежести данные в реальном времени сначала приземляются и обновляются в StarRocks (секундная видимость), а затем, через заданный интервал, записываются обратно в Iceberg для единого управления активами (Single Source of Truth).

• Лёгкая обработка данных: благодаря сбросу промежуточных результатов на диск операторами StarRocks и механизмам изоляции ресурсов можно выполнять лёгкую переработку данных Iceberg и обратную загрузку.

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

StarRocks + Iceberg: лучшие практики пользователей

Интегрированный Lakehouse‑подход WeChat (Tencent) на базе StarRocks + Iceberg

Предпосылки и вызовы:

• Аналитика WeChat сталкивается с необходимостью обрабатывать колоссальные объёмы данных, обеспечивать сверхбыстрые отклики запросов (TP90 ≤ 5 секунд) и консолидировать вычисления и хранение.

Исследование интегрированной архитектуры Lakehouse

Построение хранилища на озере:

• Переход от Presto + Hive к StarRocks + Iceberg дал значительный прирост по свежести данных и эффективности запросов:

  • Актуальность данных улучшилась с часов/дней до минут.

  • Эффективность запросов — с минут до секунд/минут.

  • 80% крупных запросов возвращаются за секунды через StarRocks; сверхкрупные обрабатываются в Spark.

  • В планах — использовать материализованные представления для внешних таблиц StarRocks, чтобы упростить эксплуатацию и повысить эффективность.

Слияние DWH и озера:

• Хранение консолидировано за счёт федеративных запросов по источникам, без ETL — прямая аналитика по данным озера.

• Горячие данные поступают в DWH в реальном времени, «холодные» переносятся в озеро; единое управление метаданными DWH/озера обеспечивает Meta Server.

• Совмещение чтения горячих/холодных данных и поддержки офлайн‑вычислений улучшило скорость ответов и их актуальность.

Результаты:

• Lakehouse‑архитектура внедрена в ряде сервисов WeChat (прямые эфиры в видео‑каналах, клавиатура WeChat и др.).

• Кластеры — сотни машин, объём подключаемых данных — сотни миллиардов записей.

• В сценарии лайв‑трансляций число задач data‑engineering сократилось вдвое, стоимость хранения уменьшилась более чем на 65%, а время получения результатов офлайн‑задач снизилось на два часа.