Apache Iceberg — the friendly introApache Iceberg — дружелюбное введение

Apache Iceberg is a table format for data lakes. You have lots of data files (usually Parquet) sitting in cloud storage like S3. On their own, those are just files. Iceberg adds a layer of metadata on top that makes the whole pile behave like one proper table — one you can safely query, update, and change over time.

Apache Iceberg — это табличный формат для озёр данных. У тебя в облачном хранилище (например S3) лежит много файлов с данными (обычно Parquet). Сами по себе это просто файлы. Iceberg добавляет сверху слой метаданных, который заставляет всю кучу вести себя как одна нормальная таблица — которую можно безопасно запрашивать, обновлять и менять со временем.

These are easy to confuse but very different:

Их легко перепутать, но они очень разные:

Before table formats, a "table" in a data lake was just a folder of files (the old Hive way). That caused real pain:

До табличных форматов «таблица» в озере данных была просто папкой файлов (старый подход Hive). Это давало реальную боль:

• No safe updates. A reader could see half-written data while a job was still writing.
• Listing files was slow. Finding the right files meant scanning the whole directory.
• Schema changes were scary. Renaming or reordering a column could silently corrupt reads.
• No history. Once you overwrote data, the old version was gone — hard to debug or roll back.

• Нет безопасных обновлений. Читатель мог увидеть полузаписанные данные, пока джоб ещё пишет.
• Перечисление файлов медленное. Найти нужные файлы — значит просканировать всю директорию.
• Изменения схемы пугали. Переименование или перестановка колонки могли тихо испортить чтение.
• Нет истории. Перезаписал данные — старая версия исчезла; трудно отлаживать и откатывать.

① ACID transactions (atomic commits)① ACID-транзакции (атомарные коммиты)

A write either fully appears or not at all. Readers always see a complete, consistent version — never a half-written mess. Multiple jobs can write without corrupting each other.

Запись либо появляется целиком, либо никак. Читатели всегда видят полную согласованную версию — никогда полузаписанный хаос. Несколько джобов могут писать, не портя друг друга.

② Snapshots & time travel② Снапшоты и time travel

Every change creates a new snapshot (a version of the table). You can query the table as of a past snapshot or timestamp, and roll back if a bad job wrote garbage.

Каждое изменение создаёт новый снапшот (версию таблицы). Можно запросить таблицу на момент прошлого снапшота или времени и откатиться, если плохой джоб записал мусор.

③ Schema evolution③ Эволюция схемы

Add, drop, rename, or reorder columns safely. Iceberg tracks columns by a hidden id, not by position or name, so old data still reads correctly after a change.

Безопасно добавлять, удалять, переименовывать, переставлять колонки. Iceberg отслеживает колонки по скрытому id, а не по позиции или имени, поэтому старые данные читаются верно после изменения.

④ Hidden partitioning④ Скрытое партиционирование

Iceberg remembers how the table is partitioned (e.g. by day) and applies it automatically. You query WHERE event_time > ... and it skips irrelevant files — you don't have to add a manual WHERE partition_day = ... and you can't forget it.

Iceberg помнит, как таблица партиционирована (например по дню), и применяет это автоматически. Ты пишешь WHERE event_time > ..., а он пропускает ненужные файлы — не нужно вручную добавлять WHERE partition_day = ... и нельзя про это забыть.

⑤ Engine-agnostic & open⑤ Не привязан к движку, открытый

Spark, Flink, Trino and others can all read and write the same Iceberg table. Your data isn't locked into one vendor's product.

Spark, Flink, Trino и другие могут читать и писать одну и ту же таблицу Iceberg. Твои данные не заперты в продукте одного вендора.

Iceberg keeps a small tree of metadata files that point down to your data files. A query reads the metadata first to figure out exactly which data files it needs — and skips the rest.

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

The min/max stats in manifests let Iceberg skip whole files that can't match your filter — fast queries without scanning everything.

Статистика min/max в манифестах позволяет Iceberg пропускать целые файлы, которые не могут попасть под фильтр — быстрые запросы без сканирования всего.

• Reliable updates & deletes. Real MERGE/upsert and row-level deletes on a data lake (e.g. for GDPR or fixing bad rows).
• Safe reprocessing. Time travel + snapshots let you debug "what did the table look like then?" and roll back a bad load.
• Cheap schema changes. Add a column without rewriting the whole table.
• Fewer small-file headaches. Iceberg supports compaction to merge tiny files into big ones for speed.
• No vendor lock-in. Open format, many engines — pick the best tool per job.

• Надёжные обновления и удаления. Настоящий MERGE/upsert и удаление по строкам в озере данных (например для GDPR или фикса плохих строк).
• Безопасная переобработка. Time travel + снапшоты позволяют отладить «как таблица выглядела тогда?» и откатить плохую загрузку.
• Дешёвые изменения схемы. Добавить колонку без перезаписи всей таблицы.
• Меньше боли с мелкими файлами. Iceberg поддерживает компакцию — слияние крошечных файлов в крупные ради скорости.
• Нет привязки к вендору. Открытый формат, много движков — выбираешь лучший инструмент под задачу.