Apache Iceberg: What It Is and Why Everyone's Talking About It (Рубрика Data)
Отличное короткое выступление Тима Берглунда VP Developer Relations в Confluent про Apache Iceberg и почему про него так много говорят. Если упрощать, то Apache Iceberg - это открытый формат аналитических таблиц, принесший ACID-ранзакции и эволюцию схемы в мир «сырого» дата-лейка. В этом видео Тим помимо Iceberg еще рассказывает про TableFlow от Confluent, что является автоматической материализацией Kafka-топиков в Iceberg-таблицы. Вот основные тезисы Тима
- Он начинает с рассказа про эволюцию подходов по работе с данными
- Data warehouse (DWH) : с 1990-х, ночной ETL, строгая схема, отчёты на следующий день
- Data lake: с 2010-х, сначала Hadoop, затем S3/Blob; схема on read, ELT-паттерн, масштаб до петабайт
- При переходе к data lakes потерялось: строгая схема, транзакционность и согласованность при параллельных записях
- Проблемки в data lakes были примерно такие
- Отсутствие метаданных на уровне файлов - это приводило к долгим directory-list операциям в S3; непредсказуемым SQL-запросам
- Нет ACID-транзакций - это приводило к «грязным» данным при частичных перезаписях, race conditions
- Сложная эволюция схемы - получались «zombie»-колонки, а также сложные перекатка партиций вручную
- Но тут на помощь пришел подход с Apache Iceberg, который принес слои, что решили предыдущие проблемы. Эти слои выглядят так по мере увеличения уровня абстракции - Data Files (Parquet/Avro/ORC) - неизменяемые фрагменты данных. - Manifest Files - JSON-файлы, перечисляющие конкретные Data Files плюс статистику колонок (min/max, null-count). - Manifest List - набор manifest-ов для одной операции добавления/удаления файлов - Snapshots - атомарные состояния таблицы; каждый snapshot указывает на конкретный Manifest List, тем самым формируя точку во времени - Metadata File (metadata.json) - хранит список всех snapshot-ов, схему, сорт-ордера. - Catalog - внешний сервис (Hive Metastore, JDBC-DB, REST-каталог) сопоставляет имя таблицы с текущим Metadata File
- Такая схема обеспечивает следующие свойства и механизмы, что решают указанные выше проблемы - ACID-транзакции - обеспечивается посредством copy-on-write + optimistic concurrency, а дает это безопасные параллельные INSERT/DELETE - Time Travel - обеспечивается посредством чтения по snapshot-ID или timestamp, а дает аудит и reproducible query
- Schema evolution - обеспечивается посредством полнотекстовыъ JSON-метадатанных; идентификаторов колонок, а не их порядка, а дает это возможность добавление/переименование колонок без перезаписи - Hidden Partitioning - обеспечивается это посредством вычислимых трансформ (bucket, truncate, day), что спрятаны от пользователей, а дает fast scans без manual-фильтров - Row-level Deletes - обеспечивает посрдеством V2 spec: delete deltas с позиционными ссылками, а дает GDPR-delete и upsert-паттерны
- Если говорить про физическую реализацию, то
- Iceberg сам по себе - НЕ сервер. Это спецификация + библиотеки (Java, Python, Spark, Flink, Trino, Hive)
- Метаданные и данные - обычные файлы в объект-сторидже; каталог - «плагин» (Hive Metastore, AWS Glue, REST).
- Отказоустойчивая схема без rename/list операций - важно для S3, GCS.
Часть про TableFlow от Тима я рассказывать не буду, так как мне самым важным было рассказать про часть про Apache Iceberg. Если подводить итоги, то
- Iceberg решает три исторические боли data lakes - ACID-транзакции, управляемая эволюция схемы, консистентные snapshot-ы.
- Архитектура основана на простых JSON/Parquet-файлах и внешнем каталоге; никакого «Iceberg-сервера» не требуется.
- Экосистема растёт: Netflix перешёл на «Iceberg-only» lake (≈1 EB); Databricks покупает Tabular, чтобы конвергировать Delta↔️Iceberg.
- Iceberg становится де-факто стандартом открытых табличных форматов, а в ближайшие годы data-платформы будут сходиться к унифицированному lakehouse-стеку, где Iceberg играет роль «общего языка» между потоковыми системами и батч-аналитикой
#Data #Dateabases #PlatformEngineering #Software #Architecture #Engineering #DistributedSystems