Apache Iceberg¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Область версий: Apache Iceberg 1.9.2; format v2, engine/catalog отдельно. Проверка источников: 2026-11-02.

1. Архитектура и модель данных¶

FACT. Open table format связывает immutable data files с atomic table snapshot через metadata/catalog. Это не database server и не query engine: Spark/Flink/Trino и catalog обеспечивают исполнение/commit. Baseline format v2 отделён от новых v3 возможностей.

flowchart LR
  Writer --> Files[Data and delete files]
  Files --> Manifests[Manifest list and snapshot]
  Manifests --> Catalog[Atomic catalog commit]
  Catalog --> Reader
  Reader --> Files

2. Физическое хранение и путь записи¶

Metadata JSON ссылается на snapshots/manifest lists/manifests/data и delete files. Колонки имеют field IDs, поэтому schema evolution не полагается только на имя/позицию. Snapshot выбирает полный согласованный набор файлов; immutable objects позволяют readers продолжить старый snapshot до безопасной очистки.

Источники механизма: документация 4.

3. Индексы и путь чтения¶

Manifest/file statistics и partition transforms дают pruning; hidden partitioning отделяет логический query от directory layout. Sort order может улучшить min/max skipping, но это не B-tree, не uniqueness enforcement и не произвольный point lookup. Engine support equality/position deletes нужно проверять по версии connector.

Источники механизма: документация 2, документация 4.

4. Транзакции и consistency guarantees¶

Atomic commit меняет current metadata pointer через поддерживаемый catalog/CAS protocol. Optimistic concurrency проверяет конфликты и может потребовать retry/replanning. Изоляция row-level operations зависит от engine/settings; table snapshot atomicity не означает cross-table ACID и не включает внешние Kafka offsets автоматически.

Источники механизма: документация 1.

5. Репликация, partitioning и sharding¶

Partition spec evolution позволяет новым files использовать другой layout без полной переписи старых; reader учитывает specs metadata. Sharding compute/query — функция engine, не format. Catalog HA и object storage replication — разные failure layers. Data files replication не публикует корректно catalog автоматически.

Источники механизма: документация 2.

6. Конкурентная запись и конфликты¶

Concurrent append может быть совместим при корректном commit retry; overlapping delete/update требует проверки read/write conflicts. Retry после неопределённого commit сначала проверяет, опубликован ли snapshot. Два independent catalogs поверх одного location могут создать divergent histories; нужен единственный согласованный commit authority.

Источники механизма: документация 1.

7. Отказы и восстановление¶

Snapshot rollback помогает при логической ошибке, пока files сохранены; не восстанавливает уже удалённые объекты. Expire snapshots и remove orphan files имеют safety horizons: учитывать длинные readers, paused writers и recovery. Backup catalog metadata, access/keys и data retention совместно.

Источники механизма: документация 3.

8. Масштабирование и ограничения¶

Small files, много manifests/snapshots и delete files замедляют planning и reads. Rewrite data/manifests и expire snapshots — штатное обслуживание с I/O и конфликтами. Каталог может стать bottleneck частых commits; слишком маленький micro-batch ухудшает metadata overhead.

9. Performance trade-offs¶

Плюсы — engine interoperability и schema/partition evolution; цена — maintenance и различия connector capabilities. Merge-on-read deletes экономят rewrite сейчас ценой query work, copy-on-write — обратный trade-off в поддерживающих engine. Нельзя обещать одинаковый MERGE behavior всех readers.

10. Мониторинг и эксплуатация¶

Мониторить commit retries/conflicts, catalog availability, file-size distribution, manifest count, delete-file ratio и age snapshots. Query metrics отделять от object request cost. Периодически проверять, что retained snapshots реально читаются всеми заявленными engines.

11. Сценарии FinTech и iGaming¶

INFERENCE. История transactions/events с corrections и многоengine analytics; bronze/silver/gold snapshots. Source ledger остаётся transactional, format хранит аналитическую историю. Incremental consumption требует engine-specific semantics, не просто сравнения двух произвольных LIST.

12. Когда не выбирать¶

Не выбирать как low-latency per-account transaction engine. Не использовать unsupported connector features и небезопасный каталог. Если workload — одна маленькая локальная таблица, format/catalog maintenance может быть неоправдан.

13. Вопросы на собеседовании¶

Snapshot равно backup? Нет, общий файл может быть удалён вместе со storage/cleanup.

Почему field IDs важнее rename? Позволяют сохранить идентичность колонки без привязки к имени/позиции.

Hidden partitioning равно automatic perfect distribution? Нет, transform выбирает designer и engine всё равно оплачивает skew.

14. Практические SQL/config примеры¶

CREATE TABLE lake.betting.events (
  event_id STRING, tenant_id BIGINT, occurred_at TIMESTAMP, amount_minor BIGINT
) USING iceberg
PARTITIONED BY (days(occurred_at));

Spark SQL предполагает настроенный Iceberg catalog lake и compatible runtime. Статический Spark parser не доказывает загрузку Iceberg/поддержку transforms; runtime отсутствует.

15. Дополнительные источники¶

Типичные ошибки проектирования¶

Смешивать commit, видимость projection и backup; приписывать формату функции query engine; игнорировать версии и cleanup horizon. Product-specific ошибки и безопасные альтернативы разобраны в разделах 4–9.

Практические упражнения¶

Составьте журнал одной записи: какие файлы/metadata появляются до публикации, что увидит reader при сбое и какой cleanup безопасен. Затем предложите restore drill с проверкой итоговой полноты, включая поздние исправления.