A B C D E F G H I K L M N O P R S T W Y Z Б В Е И К М О П Т Ц

Apache Iceberg

Iceberg для хранения ваших данных - https://bigdataschool.ru/blog/

Apache Iceberg – это открытый формат таблиц для огромных аналитических наборов данных в озерах данных (Data Lake). По своей сути, Apache Iceberg не является ни системой хранения, ни движком для обработки запросов; это спецификация, которая определяет, как организовать файлы данных (например, Parquet, Avro, ORC) и метаданные, чтобы обеспечить функциональность, присущую традиционным базам данных, прямо поверх объектных хранилищ вроде Amazon S3.

Ключевое отличие от старых форматов, таких как Hive, заключается в том, что Iceberg (далее Айсберг) отслеживает отдельные файлы, а не каталоги, что обеспечивает атомарные коммиты, надежную эволюцию схемы и высокую производительность без необходимости в централизованном метасторе, который часто становится узким местом. Это позволяет выполнять ACID-транзакции, путешествовать во времени по состоянию данных (Time Travel) и безопасно изменять схему таблицы без переписывания всех данных.

Ключевые проблемы традиционных озер данных, которые решает Iceberg

Традиционные озера данных, часто построенные на базе Apache Hive, сталкиваются с рядом хронических проблем, превращающих их из ценного ресурса в “болото данных” (Data Swamp). Apache Iceberg был создан для решения именно этих проблем.

Lakehouse vs DataLake - https://bigdataschool.ru/copyright/bigdataschool.ru
Различия Data Lake и LakeHouse в картинках от “Школы Больших Данных”

Во-первых, это проблема согласованности данных. Операции в Hive не являются атомарными. Если задание записи данных завершается сбоем на полпути, в озере остаются “мусорные” данные, которые сложно отследить и удалить. Айсберг решает эту проблему с помощью атомарных операций фиксации (коммитов) метаданных. Каждое изменение — это создание новой, целостной версии таблицы, что гарантирует, что потребители данных видят либо старое, либо новое состояние, но никогда не промежуточное.

Во-вторых, производительность сканирования метаданных. В Hive для получения списка файлов таблицы необходимо рекурсивно обходить каталоги файловой системы, что становится крайне медленным при наличии миллионов файлов и партиций. Айсберг хранит полный список файлов данных в компактных файлах метаданных (manifest files). Благодаря этому движку запросов не нужно взаимодействовать с файловой системой для планирования, что значительно ускоряет выполнение запросов.

Наконец, это хрупкость и сложность эволюции схемы и партиционирования. Изменение типа столбца или схемы партиционирования в Hive — сложная и рискованная операция, часто требующая переписывания всей таблицы. Apache Iceberg поддерживает безопасную эволюцию схемы (schema evolution) и партиций, позволяя изменять структуру таблицы без изменения существующих данных.

 

Архитектура и ключевые компоненты Apache Iceberg

 

Архитектура Apache Iceberg логически разделена на несколько уровней, что обеспечивает его гибкость и расширяемость.

  1. Слой каталога (Iceberg Catalog): Это точка входа для любого движка обработки данных, такого как Trino или Spark. Каталог отвечает за сопоставление имени таблицы с расположением ее текущего файла метаданных. Iceberg поддерживает различные реализации каталогов, включая Hive Metastore, AWS Glue Catalog, JDBC и REST-каталоги, что обеспечивает широкую совместимость.
  2. Слой метаданных (Metadata Layer): Это ядро Apache Iceberg. В отличие от Hive, который полагается на один центральный Metastore, Айсберг использует древовидную структуру метаданных:
    • Файл метаданных (Metadata file): Корневой файл, содержащий информацию о схеме таблицы, спецификации партиционирования, снапшотах и расположении текущего списка манифестов.
    • Список манифестов (Manifest list): Файл, который содержит указатели на один или несколько файлов манифеста. Каждый снапшот таблицы соответствует одному списку манифестов.
    • Файл манифеста (Manifest file): Файл, содержащий список файлов данных (data files), а также статистику по ним (например, минимальные и максимальные значения для столбцов), что используется для оптимизации запросов и отсечения ненужных файлов.
  3. Слой данных (Data Layer): Это фактические файлы с данными, хранящиеся в объектном хранилище. Apache Iceberg поддерживает несколько форматов файлов, включая Apache Parquet, Apache ORC и Apache Avro. Данные организованы в соответствии со структурой, описанной в файлах манифеста.
  1. Архитектура Apache Iceberg

 

Apache Iceberg в сравнении с Parquet и ORC

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

Однако, Parquet и ORC сами по себе не предоставляют функций, подобных ACID-транзакциям или schema evolution. Эти форматы просто описывают, как данные хранятся внутри файла. Они не управляют коллекцией файлов как единой таблицей. Айсберг , напротив, предоставляет именно эти возможности. Он отслеживает, какие файлы Parquet или ORC принадлежат к таблице. Более того, Айсберг управляет изменениями и версиями этих файлов. Таким образом, Айсберг добавляет табличную семантику к хранилищам данных. Он повышает надежность и управляемость data lakes. Например, он позволяет выполнять атомарные обновления данных. Это невозможно только с использованием Parquet или ORC.

 

Основные возможности Apache Iceberg

 

Формат Apache Iceberg (далее Айсберг) предоставляет инженерам данных мощные инструменты для управления жизненным циклом данных.

  • ACID-транзакции: Айсберг обеспечивает атомарность, согласованность, изоляцию и долговечность транзакций через атомарную замену указателя на файл метаданных. Это позволяет безопасно выполнять одновременные операции записи и чтения.
  • Эволюция схемы (Schema Evolution): Айсберг позволяет добавлять, удалять, переименовывать столбцы и изменять их порядок без переписывания данных. Каждому значению в таблице привязан уникальный ID поля, что гарантирует корректное чтение данных независимо от изменений в схеме.
  • Эволюция партиционирования (Partition Evolution): Вы можете изменить логику разбиения таблицы (например, перейти от дневных партиций к часовым) без необходимости переписывать старые данные. Айсберг будет корректно обрабатывать запросы к данным как со старой, так и с новой схемой партиционирования.
  • Путешествия во времени (Time Travel): Каждый коммит в Айсберг создает новый снапшот таблицы. Это позволяет выполнять запросы к состоянию таблицы на определенный момент времени или на определенный номер снапшота. Эта функция бесценна для аудита, отладки конвейеров данных и восстановления после сбоев.
  • Скрытое партиционирование (Hidden Partitioning): Айсберг может автоматически генерировать значения для партиций на основе значений в столбцах. Например, он может создать партицию 2023-10-25 из столбца с временной меткой timestamp. Это избавляет пользователей от необходимости знать детали физической структуры таблицы при написании запросов. Для знакомства с технологиями обработки больших данных вы можете прийти наш курс “Архитектор больших данных” .

Интеграция Айсберг с Apache Kafka

 

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

Для соединения этих двух систем обычно используется движок потоковой обработки, такой как Apache Flink или Spark Streaming. Apache Flink, благодаря своему мощному SQL-интерфейсу и нативному коннектору для Iceberg, является особенно популярным выбором.

Вот пример, как можно настроить конвейер данных из Kafka в Айсберг с помощью Flink SQL:

 

-- Шаг 1: Создаем таблицу-источник, которая читает данные из топика Kafka.
-- Сообщения в Kafka предполагаются в формате JSON.
CREATE TABLE kafka_event_stream (
    event_id STRING,
    event_timestamp_ms BIGINT,
    user_id STRING,
    event_type STRING,
    -- Преобразуем timestamp в удобный для Flink формат
    event_time AS TO_TIMESTAMP_LTZ(event_timestamp_ms, 3)
) WITH (
    'connector' = 'kafka',
    'topic' = 'server-events',
    'properties.bootstrap.servers' = 'kafka-broker-1:9092',
    'properties.group.id' = 'flink-iceberg-consumer',
    'format' = 'json',
    'scan.startup.mode' = 'latest-offset'
);

-- Шаг 2: Создаем таблицу-приемник в формате Iceberg.
-- Flink будет автоматически управлять созданием файлов и коммитами метаданных.
CREATE TABLE iceberg_events_sink (
    event_id STRING,
    event_time TIMESTAMP(3),
    user_id STRING,
    event_type STRING
) WITH (
    'connector' = 'iceberg',
    'catalog-name' = 'my_iceberg_catalog',
    'warehouse' = 's3://my-data-lake/warehouse',
    'write.upsert.enabled' = 'false' -- Включить, если нужны обновления
);

-- Шаг 3: Запускаем потоковую вставку данных из Kafka в Iceberg.
-- Flink будет непрерывно читать данные из Kafka и записывать их в таблицу Iceberg.
INSERT INTO iceberg_events_sink
SELECT
    event_id,
    event_time,
    user_id,
    event_type
FROM kafka_event_stream;

 

Эта архитектура (возможна поддержка Shift Left Architecture) обеспечивает отказоустойчивую доставку данных “exactly-once” из Apache Kafka в ваше озеро данных, делая свежие данные доступными для аналитики практически в реальном времени.

Shift left architecture на Kafka,Flink и Iceberg - https://bigdataschool.ru

Интеграция Apache Iceberg с ClickHouse

ClickHouse, как аналитическая СУБД, известная своей скоростью, может эффективно работать с данными в формате Iceberg. Это позволяет объединить мощь транзакционного озера данных с производительностью ClickHouse. Интеграция выполняется с помощью движка таблиц Iceberg.

Предположим, у вас есть таблица Айсберг, хранящаяся в Amazon S3. Для доступа к ней из ClickHouse нужно создать таблицу, указав путь к метаданным.

 

-- Создание таблицы в ClickHouse для чтения данных из существующей таблицы Iceberg
CREATE TABLE iceberg_events (
    event_id UUID,
    event_time DateTime,
    user_id String,
    payload String
)
ENGINE = Iceberg('https://s3.amazonaws.com/your-bucket/path/to/iceberg_table/', 'aws_access_key_id', 'aws_secret_access_key');

-- После создания таблицы можно выполнять сверхбыстрые аналитические запросы
-- ClickHouse будет использовать метаданные Iceberg для оптимизации чтения
SELECT
    user_id,
    count(*) AS event_count
FROM iceberg_events
WHERE event_time >= '2023-10-01 00:00:00'
GROUP BY user_id
ORDER BY event_count DESC
LIMIT 10;

 

Эта связка идеально подходит для сценариев, где данные готовятся и обновляются в озере данных с помощью таких инструментов, как Spark или Flink, а ClickHouse используется для интерактивной аналитики и построения дашбордов. Другой популярный инструмент для работы с данными это Apache Spark.

Использование Айсберг с Trino

 

Trino (ранее известный как PrestoSQL) является одним из ключевых движков для работы с Apache Iceberg. Он предоставляет полную поддержку SQL, включая DML-операции (INSERT, UPDATE, DELETE, MERGE), что делает его мощным инструментом для управления данными в озере.

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

Пример использования операции MERGE для обновления данных о пользователях:

-- Операция MERGE позволяет атомарно вставлять, обновлять или удалять записи
-- на основе совпадения с исходной таблицей.
MERGE INTO iceberg_schema.users_iceberg t
USING staging_schema.user_updates s
ON t.user_id = s.user_id
-- Если пользователь существует и его статус изменился, обновляем запись
WHEN MATCHED AND t.status <> s.status THEN
    UPDATE SET status = s.status, updated_at = s.event_time
-- Если пользователя не существует, вставляем новую запись
WHEN NOT MATCHED THEN
    INSERT (user_id, email, status, created_at, updated_at)
    VALUES(s.user_id, s.email, s.status, s.event_time, s.event_time);

 

Эта возможность делает Trino отличным выбором для построения архитектуры Lakehouse, где озеро данных становится не просто хранилищем для RAW-данных, но и полноценной средой для структурированной аналитики и бизнес-анализа. Подробнее прочитать про SQL можно в нашем блоге.

Заключение

Apache Iceberg — это не просто очередной формат файлов, а фундаментальный сдвиг в подходе к построению озер данных. Он приносит надежность, производительность и гибкость, которые ранее были доступны только в дорогих и закрытых хранилищах данных. Благодаря поддержке со стороны ведущих движков обработки данных, таких как ClickHouse, Trino, Spark и Flink, Iceberg быстро становится отраслевым стандартом для создания открытых, масштабируемых и надежных аналитических платформ. Внедрение Apache Iceberg позволяет компаниям строить долговечные архитектуры данных, готовые к будущим вызовам и эволюции технологий.

Использованные референсы и материалы

  1. Официальная документация Apache Iceberg https://iceberg.apache.org/
  2. Статья “Diving Deep into Apache Iceberg” в блоге Tabular https://tabular.io/blog/deep-dive-into-iceberg/
  3. Статья “What is Apache Iceberg?” в блоге Dremio https://www.dremio.com/wiki/apache-iceberg/
  4. Статья “Apache Iceberg vs. Delta Lake vs. Apache Hudi” от Onehouse https://www.onehouse.ai/blog/apache-iceberg-vs-delta-lake-vs-apache-hudi