Apache Iceberg deep dive на собеседовании Data Engineer

Зачем разбирать на собесе

Iceberg — стандарт modern lakehouse. На собесе DE: «как Iceberg отличается от Hive», «partition evolution», «time travel mechanism».

Структура Iceberg-таблицы

table/
  metadata/
    v1.metadata.json     ← table metadata
    snap-N.avro           ← snapshot
    manifest-list-N.avro  ← list of manifests
    manifest-M.avro       ← list of data files
  data/
    partition_X/
      file-1.parquet      ← actual data
      file-2.parquet

Слои:

1. Metadata file — current state, schema, partition spec, snapshot list.
2. Manifest list — для каждого snapshot — список manifests.
3. Manifest — список data files, partition info, statistics.
4. Data files — Parquet / ORC / Avro.

Snapshots

Каждый change (INSERT, UPDATE, DELETE) создаёт новый snapshot.

-- before insert: snapshot S1
INSERT INTO events VALUES (...)
-- after: snapshot S2

INSERT INTO events VALUES (...)
-- after: snapshot S3

Snapshots — immutable. Старые сохраняются (до retention).

Snapshot содержит:

• Список manifests.
• Statistics.
• Operation type (append, overwrite, delete).
• Parent snapshot ID.

Partition evolution

В Hive partitioning жёсткое — нельзя менять без перезаписи. Iceberg — можно.

-- Initial: PARTITION BY toYear(event_date)
ALTER TABLE events ADD PARTITION FIELD month(event_date);
-- Now data partitioned by year/month for new writes
-- Old data still partitioned by year — Iceberg хорошо обрабатывает

Иногда нужно — данные разной волны имеют разную структуру. Iceberg справляется.

Hidden partitioning

В Hive: чтобы получить partition pruning, надо WHERE по partition column.

-- Hive: нужно явно
WHERE event_date_year = '2026' AND event_date = '2026-05-07'

В Iceberg: pruning по transformations.

-- Iceberg: достаточно WHERE event_date
WHERE event_date = '2026-05-07'
-- Iceberg сам поймёт, какие партиции читать

Time travel

Запрос на любой момент истории.

SELECT * FROM events VERSION AS OF 1234567   -- snapshot ID
SELECT * FROM events FOR TIMESTAMP AS OF '2026-04-01 12:00:00'

Применения:

• Audit / compliance.
• Reproducibility ML training.
• Debugging.
• Rollback.

Compaction

Много small files → плохая производительность. Compaction — объединение в большие.

CALL iceberg.system.rewrite_data_files('events');

Также:

• Expire snapshots — удалить старые, освободить storage.
• Remove orphan files — файлы, не привязанные к snapshots.

Регулярный maintenance — важная часть Iceberg операций.

Частые ошибки

Ожидать что Spark / Trino автоматически compact. Compaction вручную / по расписанию.

Не expire snapshots. Метаданные растут, queries замедляются.

Большой retention period. Каждый снапшот хранит metadata. На active table 7 дней — стандарт.

Читать через Hive engine. Iceberg вкладывается в Spark / Trino / Flink. Не Hive.

Игнорировать catalog. Iceberg требует catalog (Glue / Hive / Nessie / REST). Без него — file-based, только для тестов.

Связанные темы

• Lakehouse Iceberg Delta для DE
• Hive Metastore для DE
• Schema evolution для DE
• Медальон-архитектура для DE
• Подготовка к собесу Data Engineer

FAQ

Iceberg vs Delta vs Hudi?

Все 3 — table format поверх Parquet. Iceberg — most adopted, vendor-neutral. Delta — Databricks-родной. Hudi — Uber-разработка, фокус на CDC.

Это официальная информация?

Нет. Статья основана на документации Apache Iceberg.

Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.