Выбор формата: Iceberg vs Delta Lake vs Hudi - матрица по кейсам

Двенадцать уроков этого модуля были посвящены глубокому погружению в одну конкретную технологию - Apache Iceberg. Мы разобрали дерево метаданных по уровням, механику атомарного коммита, Hidden Partitioning и Partition Evolution, Copy-on-Write и Merge-on-Read на уровне формата delete-файлов, продакшен-паттерн MERGE INTO для CDC, Time Travel и, наконец, три процедуры обслуживания таблицы. Это была инвестиция в глубину: студент, прошедший этот путь, понимает Iceberg не как «ещё один формат файлов с ACID», а как конкретную инженерную архитектуру с явными, измеримыми компромиссами.

Этот, завершающий модуль урок - не симметричное продолжение того же пути для Delta Lake и Apache Hudi (на это не хватило бы и отдельного модуля для каждого), а нечто иное: применение уже усвоенной дисциплины анализа к двум конкурирующим архитектурам, ровно настолько глубоко, насколько нужно для осознанного инженерного выбора. Цель урока - не очередной маркетинговый список «у всех есть ACID, Time Travel и schema evolution», а конкретный ответ на вопрос, который реально стоит перед инженером данных при проектировании новой платформы: какой формат внедрять под конкретные SLA, конкретный стек движков и конкретный профиль нагрузки, и какую цену придётся заплатить за этот выбор через два года эксплуатации.

Эволюционный контекст: зачем появились table format и почему «голый» Parquet на Hive не выжил¶

Проблема консистентности классического Data Lake¶

До того как появились Iceberg, Delta Lake и Hudi, типичный Data Lake на Hadoop/S3 представлял собой набор директорий с файлами Parquet/ORC, а единственным источником истины о структуре таблицы был Hive Metastore - реестр, хранящий путь к директории таблицы и список её партиций, но не список конкретных файлов в каждой партиции. Чтение таблицы в этой модели устроено предельно просто и предельно хрупко: движок спрашивает у Hive Metastore путь нужной партиции, а затем выполняет listStatus() непосредственно на файловой системе или объектном хранилище, чтобы узнать, какие файлы физически лежат в этой директории прямо сейчас.

Эта простота оборачивается полным отсутствием изоляции между конкурентной записью и чтением. Если writer находится в процессе записи новой партиции - создаёт первый, второй, третий файл из десяти запланированных - и в этот самый момент кто-то выполняет listStatus() той же директории, то читатель увидит ровно те файлы, что успели физически появиться к этому моменту: частичный, незаконченный результат записи, без какого-либо предупреждения о том, что операция ещё не завершена. Не существует понятия «снимок до операции» и «снимок после операции» - есть только «текущее, постоянно меняющееся содержимое директории». Если writer обрывается посередине (сбой исполнителя, отказ сети, отмена job) - результат точно такой же неопределённый: часть файлов лежит в директории, и ничто не помечает их как часть незавершённой, недействительной операции, которую следует игнорировать.

Диаграмма противопоставляет две модели не на уровне маркетинга, а на уровне конкретного механизма обнаружения файлов. В левой части (CLASSIC) Hive Metastore знает только путь к директории, а реальный список файлов добывается каждый раз заново через listStatus() непосредственно у самого хранилища - и именно поэтому читатель, оказавшийся «не в то время не в том месте», видит частичную запись. В правой части (MODERN) writer записывает все 10 файлов физически, но они существуют как «невидимые» для читателей до тех пор, пока единственный атомарный шаг - переключение указателя в Catalog - не сделает их частью официального состояния таблицы одним неделимым действием. Это и есть фундаментальный архитектурный сдвиг, который Iceberg называет Write-and-Commit Path (детально разобранный во втором уроке модуля), а Delta Lake и Hudi реализуют похожими, но не идентичными механизмами, разбираемыми в следующих разделах этого урока.

Почему directory-based партиционирование Hive деградирует на миллионах файлов¶

Третий урок модуля подробно разобрал «проклятие listStatus» именно в контексте Iceberg, но стоит явно подчеркнуть: эта проблема не специфична для Iceberg - это общая болезнь любой архитектуры, где список файлов добывается листингом файловой системы, а не читается из явной метаданной. Чем больше партиций и чем больше файлов в каждой из них, тем дороже становится сам акт планирования запроса: listStatus() - это сетевой вызов к объектному хранилищу (а не локальная операция файловой системы, как было бы на классическом HDFS), и для S3-совместимого хранилища он тарифицируется и пагинируется отдельно от самого чтения данных. На таблице с десятками тысяч партиций и миллионами файлов просто перечисление того, что нужно прочитать, начинает занимать заметную долю общего времени выполнения запроса - и это без единого байта реально прочитанных данных.

Усугубляющий фактор - то, что Hive-style партиционирование физически кодирует значение партиции в имени директории (/year=2025/month=06/day=20/), и любое изменение схемы партиционирования (например, переход от партиционирования по дню к партиционированию по часу) требует полной физической реструктуризации директорий - переписывания всего исторического датасета. Это прямой исторический предшественник проблемы, которую впятом уроке модуля решает Partition Evolution: до появления table format у инженера просто не было других вариантов, кроме болезненной ручной миграции.

Metadata-based tables: перенос списка файлов в слой метаданных как точка отсчёта эры Lakehouse¶

Концептуальный скачок, общий для всех трёх форматов этого урока, один и тот же: список файлов, составляющих таблицу, должен явно храниться в отдельном, версионируемом слое метаданных, а не каждый раз заново вычисляться листингом хранилища. Это решение одновременно даёт три свойства, которые классический Hive Data Lake не мог обеспечить в принципе:

• Атомарность коммита - переключение указателя на новую версию метаданных - это одна операция, и читатели либо видят полностью старое, либо полностью новое состояние, никогда промежуточное.

• Снимок (snapshot) как первоклассная сущность - поскольку список файлов каждой версии таблицы зафиксирован в метаданных, можно явно адресовать любую прошлую версию (фундамент Time Travel, девятый урок модуля), а не только «текущее содержимое директории».

• Дешёвое планирование без листинга хранилища - запрос читает компактный слой метаданных (во много раз меньший по объёму, чем сами данные) и узнаёт точный список нужных файлов без единого вызова listStatus() к самому хранилищу.

Именно эта общая идея - «metadata-based table» - и есть формальное определение того, что индустрия называет Open Table Format, и именно она открыла дорогу архитектуре Lakehouse: возможности получить транзакционные гарантии классического DWH (ACID, изоляция, Time Travel) при сохранении дешевизны и открытости объектного хранилища классического Data Lake, без необходимости выгружать данные в отдельную, закрытую систему хранения СУБД. Iceberg, Delta Lake и Hudi - три независимые, конкурирующие реализации одной и той же базовой идеи, и именно различия в том, как именно каждый из них реализует эту идею, формируют предмет всего оставшегося материала урока.

Большая тройка: происхождение и философия дизайна¶

Прежде чем сравнивать конкретные механизмы, важно понять происхождение каждого формата - не из праздного исторического интереса, а потому что происхождение напрямую объясняет архитектурные приоритеты, которые иначе выглядели бы как произвольные решения. Все три формата решают одну и ту же базовую задачу (раздел выше), но каждый был спроектирован конкретной компанией под конкретный, отличающийся от других профиль внутренней нагрузки, и это исходное «генетическое» давление видно в архитектуре по сей день.

Delta Lake: ДНК Databricks - простота и скорость внутри одного движка¶

Delta Lake появился в 2019 году внутри Databricks - компании, основанной создателями Apache Spark, чей основной коммерческий продукт - управляемая платформа выполнения именно Spark-нагрузок. Это происхождение напрямую объясняет главный архитектурный приоритет формата: глубочайшая, нативная интеграция со Spark Engine важнее формальной независимости от конкретного движка. Долгое время референсная и наиболее полнофункциональная реализация Delta Lake существовала только как Spark-коннектор (io.delta:delta-spark), а попытки читать Delta-таблицы из других движков (Trino, Flink) исторически были вторичными, основанными на более узких библиотеках (Delta Standalone, позже delta-rs) с отставанием по поддержке новых фич.

Эта ставка на простоту имеет реальную инженерную ценность: для команды, целиком работающей внутри Spark/Databricks, синтаксис Delta Lake ощущается органичным продолжением DataFrame API, операционная модель (OPTIMIZE, VACUUM, два понятных слова) интуитивно проще, чем три отдельные процедуры обслуживания Iceberg, разобранные в десятом уроке, а коммерческий движок Databricks (Photon) исторически давал наибольший прирост производительности именно на Delta-таблицах - что неудивительно, поскольку оба продукта разрабатываются одной командой с обоюдной осведомлённостью о внутреннем устройстве друг друга.

Apache Iceberg: ДНК Netflix - строгая спецификация и независимость от движка¶

Apache Iceberg родился в Netflix в 2017 году как прямой ответ на конкретную операционную боль: огромные Hive-таблицы, на которых перечисленная выше проблема listStatus и хрупкость directory-based партиционирования делали обычную эксплуатацию мучительной на масштабе тысяч ежедневных job'ов. Netflix с самого начала использовал внутри себя несколько вычислительных движков одновременно (Spark, Presto, позже Flink) - и именно поэтому ключевым архитектурным требованием стала не «глубокая интеграция с одним движком», а формальная, движок-независимая спецификация формата метаданных, опубликованная как открытый документ, который любой движок может реализовать самостоятельно, без зависимости от конкретной Java-библиотеки одного производителя.

Это решение оказалось стратегически верным: проект быстро получил весомый вклад от Apple, Adobe, AWS, а его создатель Райан Блю позже основал компанию Tabular, целиком построенную вокруг идеи Iceberg как универсального, движок-независимого стандарта - компанию, которую в 2024 году приобрела... Databricks, прямой конкурент в этом же сравнении, что само по себе наглядно показывает, насколько серьёзно рынок воспринял растущее доминирование Iceberg как открытого стандарта (подробнее - в разделе про экосистему интеграций этого урока). Сегодня Iceberg развивается как проект Apache Software Foundation, без единственного коммерческого владельца спецификации.

Apache Hudi: ДНК Uber - инкрементальная обработка и низкая задержка стриминга¶

Apache Hudi родился в Uber в 2016 году под максимально конкретную операционную задачу: данные о поездках непрерывно обновляются (статус поездки, итоговая стоимость, рейтинг) уже после первоначальной записи, и объём таких точечных обновлений на масштабе сотен миллионов поездок в день был неподъёмен для классического Hive Data Lake, единственным инструментом изменения данных в котором было полное переписывание партиции. Hudi с первого дня проектировался вокруг одной центральной задачи - сделать UPSERT дешёвым и быстрым на огромном масштабе, а не вокруг задачи аналитического чтения, которая для Uber была вторичной по отношению к необходимости постоянно обновлять огромный, непрерывно растущий датасет почти в реальном времени.

Эта изначальная сфокусированность на upsert-нагрузке и инкрементальной обработке объясняет самую узнаваемую отличительную черту Hudi относительно двух других форматов - собственный индексный слой (раздел про data skipping этого урока), позволяющий находить местоположение конкретной записи по ключу без полного сканирования метаданных, и историческое первенство в области инкрементальных запросов как первоклассной возможности формата, а не надстройки. Hudi, как и Iceberg, развивается как проект Apache Software Foundation.

Диаграмма фиксирует главный тезис раздела в сжатом виде: три происхождения - три разных доминирующих требования - три разных набора архитектурных компромиссов, которые будут конкретно и детально разобраны в следующих разделах урока. Важно держать эту таблицу происхождения в голове как объяснительную рамку: когда далее в уроке Hudi окажется сильнее в индексации, а Iceberg - в межплатформенной совместимости, это не случайность и не результат того, что одна команда «постаралась лучше» другой, а прямое, предсказуемое следствие изначального профиля нагрузки, под который каждый формат был спроектирован с первого дня.

Битва метаданных: дерево манифестов против линейного лога против таймлайна¶

Самое глубокое и самое практически значимое архитектурное различие между тремя форматами - это то, как именно каждый из них физически структурирует слой метаданных, описанный во вступительном разделе как общая для всех идея. Это не косметическая деталь: от конкретной структуры метаданных напрямую зависит механика атомарного коммита, цена планирования запроса и, как будет показано в разделе про эксплуатационную сложность, конкретная форма операционного риска при обслуживании таблицы.

Iceberg: дерево манифестов - краткое напоминание¶

Второй и третий уроки модуля разобрали архитектуру Iceberg исчерпывающе подробно, поэтому здесь - только сжатое напоминание для контраста с двумя другими форматами. Состояние таблицы описывается деревом из четырёх уровней: metadata.json (корень, содержит указатель current-snapshot-id и список всех снапшотов), Manifest List (снимок конкретного коммита - перечень манифестов с partition-level статистикой для pruning), Manifest File (точный список конкретных data- и delete-файлов с их собственной статистикой), и сами файлы данных. Атомарный коммит - это запись новой версии metadata.json и переключение указателя в Catalog одной операцией compare-and-swap, как было детально показано во втором уроке (Write-and-Commit Path, Stage 3).

Главное архитектурное свойство этой структуры - изоляция снимков через независимые поддеревья: каждый снапшот ссылается на свой Manifest List, но манифесты, не затронутые конкретным коммитом, могут быть переиспользованы несколькими подряд идущими снапшотами без копирования - дерево растёт инкрементально, а не как полностью независимая копия на каждый коммит.

Delta Lake: линейный JSON-лог транзакций с периодическими checkpoint'ами¶

Delta Lake устроен принципиально иначе - не как дерево, а как строго последовательный, линейный журнал транзакций, физически хранящийся в скрытой поддиректории _delta_log/ рядом с данными таблицы. Каждый коммит - это новый JSON-файл с строго инкрементирующимся именем, дополненным нулями до 20 знаков: 00000000000000000000.json, 00000000000000000001.json, 00000000000000000002.json и так далее. Каждый такой файл содержит последовательность action-записей JSON-объектов нескольких типов: add (файл добавлен в таблицу этим коммитом), remove (файл логически удалён из таблицы, физически может остаться на диске до VACUUM), metaData (изменения схемы или свойств таблицы), protocol (минимальная требуемая версия читателя/писателя) и commitInfo (метаданные операции - кто, когда, какой именно SQL-оператор).

Чтобы прочитать таблицу, движок должен знать полное текущее состояние - то есть теоретически прочитать и применить по очереди все JSON-файлы от версии 0 до самой последней. Это явно нежизнеспособно для таблицы с тысячами коммитов, и именно для решения этой проблемы Delta периодически (по умолчанию каждые 10 коммитов, настраивается через delta.checkpointInterval) материализует checkpoint - Parquet-файл, содержащий уже полностью «свёрнутое» состояние таблицы на конкретную версию (то есть результат применения всех action от начала истории до этой версии), так что читателю достаточно прочитать последний checkpoint и лишь те немногие JSON-файлы транзакций, что были закоммичены после него, а не всю историю с нуля.

Диаграмма показывает ключевую механику чекпоинтов: вместо того чтобы читать все 11 JSON-файлов от версии 0 до версии 10, читатель загружает один компактный Parquet-чекпоинт, материализованный на версии 9 (содержащий результат применения всех предыдущих action), и применяет к нему только один дополнительный JSON-файл версии 10 - экономия, концептуально аналогичная тому, зачем Iceberg периодически выполняет rewrite_manifests (второй урок модуля): без этого механизма стоимость восстановления текущего состояния росла бы линейно с полным числом исторических коммитов, а не оставалась почти постоянной.

Атомарность коммита в Delta достигается через атомарную операцию «создать файл с конкретным именем, только если он ещё не существует» (put-if-absent) в хранилище метаданных. На классическом HDFS эта примитива была изначально нативной, но на объектном хранилище типа S3 её историческая реализация требовала отдельного механизма координации для защиты от состояния гонки между несколькими кластерами, пишущими в одну и ту же таблицу одновременно (например, отдельного сервиса блокировок на DynamoDB в ранних версиях, или специального commit-координатора в современных версиях Delta) - деталь, прямо противопоставленная тому, как Iceberg и Hudi решают эту же задачу через сам Catalog (раздел про эксплуатационную сложность вернётся к этому нюансу).

Hudi: Timeline как явный журнал типизированных операций¶

Hudi выбирает третий, не похожий ни на дерево, ни на простой линейный лог Delta подход: сердце таблицы - это Timeline, явная, упорядоченная по времени последовательность Instant (мгновенных событий), каждое из которых хранится как небольшой файл-метка в скрытой директории .hoodie/. В отличие от плоского, универсального по форме JSON action из Delta, каждый Instant в Hudi явно типизирован по действию (COMMIT - обычная запись в Copy-on-Write таблицу, DELTA_COMMIT - запись в Merge-on-Read таблицу, добавляющая log-файлы, CLEAN - удаление устаревших версий файлов, COMPACTION - слияние log-файлов в новые базовые файлы, ROLLBACK - откат неудачного коммита, SAVEPOINT - явная защита конкретного коммита от очистки) и по состоянию (REQUESTED - операция запланирована, INFLIGHT - выполняется прямо сейчас, COMPLETED - успешно завершена).

Эта явная типизация - не просто эстетическое отличие. Она означает, что сама структура метаданных Hudi знает, что именно произошло на каждом шаге истории таблицы (обычная запись, компакция, очистка), тогда как у Delta эта информация существует лишь как один из многих текстовых атрибутов внутри обобщённого commitInfo, а у Iceberg - выводится из факта появления нового снапшота с определённой операцией в его метаданных (append, overwrite, delete, replace - поле operation в summary снапшота, упомянутое во втором уроке). Практическое следствие: инструментам обслуживания и мониторинга Hudi не нужно интерпретировать содержимое коммита, чтобы понять его природу - тип Instant уже несёт эту информацию явно в самой структуре Timeline.

Сводное сравнение трёх архитектур метаданных¶

Парадигмы обновления данных: Copy-on-Write и Merge-on-Read в трёх реализациях¶

Шестой и седьмой уроки модуля разобрали Copy-on-Write и Merge-on-Read для Iceberg на уровне формата конкретных файлов - position delete и equality delete. Этот раздел расширяет ту же концептуальную рамку (запись новых версий строк целиком против записи только описания изменения) на Delta Lake и Hudi, показывая, что у каждого формата - своя, физически отличная реализация одной и той же идеи, и что не все три формата предлагают эквивалентный набор возможностей.

Напоминание: Iceberg CoW и MoR¶

Под Copy-on-Write Iceberg реализует UPDATE/DELETE/MERGE INTO через полное перечитывание затронутых файлов и запись их новых версий (шестой урок) - простое и быстрое чтение, но Write Amplification, растущая с числом затронутых файлов. Под Merge-on-Read (седьмой урок) вместо переписывания данных создаются delete-файлы двух видов: position delete (адресует конкретную строку по координатам файл+offset, дешёвая запись, умеренная стоимость merge при чтении) и equality delete (адресует строки по значению ключа без знания их точных координат, самая дешёвая запись - blind write без чтения существующих данных, но самая дорогая стоимость merge при чтении, растущая с числом применимых delete-файлов независимо от объёма данных). Выбор режима управляется table property write.update.mode/write.delete.mode/write.merge.mode, как было показано в восьмом уроке.

Delta Lake: Deletion Vectors как единственная форма Merge-on-Read¶

Исторически Delta Lake поддерживал только Copy-on-Write - любой UPDATE/DELETE/MERGE переписывал затронутые файлы целиком, без какого-либо аналога Merge-on-Read. Это изменилось с появлением Deletion Vectors (доступны начиная с Delta Lake 2.3, продакшен-зрелость и широкая поддержка движков - с версии 3.0, включаются через delta.enableDeletionVectors = true): компактного битового вектора (физически - закодированный в формате RoaringBitmap side-файл), который помечает конкретные позиции строк внутри существующего Parquet-файла как логически удалённые, без переписывания самого файла.

Это - прямой структурный аналог position delete Iceberg: оба механизма адресуют строки по физической позиции внутри конкретного файла данных, а не по значению ключа. Важное отличие - в форме хранения: Iceberg материализует position delete как отдельный Parquet/Avro-файл со своей записью в манифесте, тогда как Delta Deletion Vector - это один битовый файл на одну Parquet-таблицу, генерируемый компактнее, поскольку битовая карта намного эффективнее по объёму, чем построчная запись пар (файл, offset) в отдельном Parquet-файле delete-записей.

Критическое ограничение, прямо аналогичное архитектурному различию position и equality delete у Iceberg: Deletion Vector умеет помечать строку как удалённую, но не умеет описывать изменение значения строки. Поэтому DELETE под Deletion Vectors действительно становится Merge-on-Read операцией (битовая карта вместо переписывания файла), но UPDATE изменяющий значения колонок (а не просто удаляющий строку), по-прежнему физически переписывает затронутые строки - Delta Lake выполняет это как комбинацию: помечает старые версии строк удалёнными через Deletion Vector у исходного файла и записывает новые значения как новые строки в новый файл, что является гибридом, а не чистым Merge-on-Read в духе равенственного delete Iceberg. У Delta Lake нет прямого структурного аналога equality delete - blind write без необходимости вообще прочитать существующие данные перед удалением, доступного у Iceberg именно благодаря equality delete.

Hudi: log-файлы и слияние записей при чтении¶

Hudi выбирает таблично-уровневое, а не операционно-уровневое разделение CoW и MoR: при создании таблицы инженер явно указывает её тип - COPY_ON_WRITE или MERGE_ON_READ - и этот выбор определяет физическую структуру файлов таблицы на всё время её существования (хотя начиная с относительно новых версий Hudi появилась возможность мигрировать тип существующей таблицы через отдельную команду, это - тяжёлая административная операция, а не лёгкий переключатель на уровне отдельного MERGE, как у Iceberg).

Для MERGE_ON_READ-таблицы каждая партиция (точнее, каждая File Group - аналог File Group из десятого урока модуля, но как постоянной, а не временной структуры компакции) состоит из одного базового Parquet-файла и серии log-файлов (.log), физически закодированных как последовательность HoodieLogBlock - блоков, содержащих полные Avro- или Parquet-сериализованные записи новых и изменённых строк, дописываемых последовательно при каждой новой инкрементальной записи (Instant с типом DELTA_COMMIT). При чтении читатель должен слить базовый файл с применимыми log-блоками по значению ключа записи - то есть, в отличие от position delete Iceberg/Delta, слияние Hudi всегда работает на уровне полноценных записей с ключом, концептуально ближе к equality-механизму Iceberg, но без раздельных типов «удаление» и «изменение значения»: один и тот же log-блок может одновременно нести и новые, и изменённые, и помеченные на удаление (через специальный системный флаг _hoodie_is_deleted) записи.

Диаграмма наглядно показывает асимметрию трёх реализаций. У Iceberg - два раздельных, специализированных типа delete-файла, каждый со своим, явно описанным во седьмом уроке профилем стоимости записи и чтения. У Delta Lake - один механизм для чистого удаления (Deletion Vector, дёшево) и отдельный, по сути CoW-путь для изменения значений (дорого, как и раньше). У Hudi - один универсальный механизм log-файлов, способный нести любой тип изменения (вставка, обновление значения, удаление) в одной и той же физической структуре, что упрощает модель данных, но не разделяет стоимость разных видов изменений так явно, как это делает Iceberg.

Read Amplification против Write Amplification: единый компромисс под разными именами¶

Формальная модель стоимости из седьмого урока - чем дешевле запись (меньше Write Amplification), тем дороже становится последующее чтение до момента компакции (растущий Read Penalty) - применима к Delta и Hudi без изменений, только с другими именами процедур, устраняющих накопленный долг. Компакция Deletion Vector у Delta (физическое применение битовых карт и переписывание файлов) выполняется как часть OPTIMIZE, концептуальный аналог rewrite_data_files/rewrite_position_delete_files Iceberg (десятый урок). Компакция log-файлов у Hudi - явный Instant типа COMPACTION в Timeline, сливающий накопленные log-блоки в новый базовый файл, причём, в отличие от обоих других форматов, эта компакция исторически воспринимается как встроенная, регулярно планируемая часть основного пайплайна записи (раздел про streaming этого урока вернётся к этому), а не как отдельная, изолированная maintenance-задача, запускаемая по собственному, независимому расписанию.

Продвинутый Data Skipping: партиционирование и индексация¶

Способность пропускать ненужные файлы без их физического чтения - центральная тема третьего и четвёртого уроков модуля для Iceberg. Этот раздел показывает, что три формата решают задачу «найти нужные строки без полного сканирования» принципиально разными механизмами, и что именно здесь лежит самое технически глубокое отличие Hudi от двух остальных.

Iceberg: Hidden Partitioning и Partition Evolution - напоминание¶

Четвёртый урок модуля показал, что партиционные значения в Iceberg вычисляются движком через partition transform (identity, year/month/day/hour, bucket(N, col), truncate(W, col)) и хранятся в метаданных, а не кодируются буквально в SQL-запросе аналитика - Hidden Partitioning. Пятый урок показал, что схему партиционирования можно изменить (ADD/DROP/REPLACE PARTITION FIELD) без переписывания уже существующих данных, поскольку каждый манифест хранит указатель на ту спецификацию партиционирования, что была актуальна в момент его записи (Partition Evolution, Split-Query Planning).

Delta Lake: Generated Columns и жёсткая физическая привязка¶

Делta Lake традиционно требует, чтобы партиционная колонка существовала как обычная колонка таблицы, физически кодируемая в путях директорий в стиле классического Hive (/event_date=2025-06-20/) - то есть наследует именно ту физическую модель, от которой Iceberg явно отошёл через Hidden Partitioning. Чтобы партиционировать по производному значению (например, по дате, извлечённой из timestamp-колонки), Delta предлагает Generated Columns - объявление вида event_date DATE GENERATED ALWAYS AS (CAST(event_ts AS DATE)), физически материализующее значение этой колонки при каждой записи и затем партиционирующее таблицу по ней как по обычной колонке.

-- Generated Column в Delta Lake: значение вычисляется автоматически
-- при каждой записи, но физически материализуется и партиционирует
-- директорию ровно как обычное Hive-style партиционирование
CREATE TABLE delta.`s3a://lakehouse/warehouse/orders_delta` (
  order_id BIGINT,
  customer_id BIGINT,
  order_ts TIMESTAMP,
  order_date DATE GENERATED ALWAYS AS (CAST(order_ts AS DATE)),
  amount DOUBLE
)
USING DELTA
PARTITIONED BY (order_date)

Ключевое инженерное следствие этого подхода - то, что партиционная схема Delta-таблицы физически зафиксирована в момент создания таблицы точно так же, как и в классическом Hive: изменение схемы партиционирования (например, переход от партиционирования по дню к партиционированию по часу) требует полного переписывания всего исторического датасета, ровно той болезненной миграции, которую пятый урок модуля показал как устранённую в Iceberg средствами Partition Evolution. Более новая возможность Databricks - Liquid Clustering (CLUSTER BY (col1, col2) вместо PARTITIONED BY) - частично закрывает этот разрыв, позволяя менять колонки кластеризации без переписывания истории, но эта возможность на момент написания урока зрелее и полнее всего реализована именно в управляемом Databricks Runtime, а не в открытой версии Delta Lake (нюанс, прямо относящийся к разделу про экосистему и vendor lock-in этого урока).

Hudi: индексный слой - главное технологическое отличие формата¶

Здесь Hudi предлагает нечто, чего попросту не существует ни у Iceberg, ни у Delta Lake в сопоставимой форме: явный, физически материализованный индекс, отвечающий на вопрос «в каком именно файле находится строка с этим ключом» без необходимости даже заглядывать в статистику метаданных файлов, не говоря об их полном сканировании. Это прямое инженерное следствие происхождения Hudi (Uber, раздел про философию дизайна этого урока) - формат, спроектированный вокруг частого точечного UPSERT, обязан уметь находить «куда положить эту запись» максимально дёшево, и именно для этого был построен отдельный индексный слой, на порядок более развитый, чем у конкурентов.

• Bloom Index (режим по умолчанию) - для каждого файла данных хранится компактный Bloom-фильтр - вероятностная структура, отвечающая на вопрос «может ли этот ключ присутствовать в этом файле» с гарантированным отсутствием false negative, но с возможным (настраиваемым по вероятности) false positive. Поиск по индексу ограничен партицией записи - предполагается, что движок заранее знает, в какой партиции искать ключ.

• Simple Index - прямое join-сравнение входящих ключей с уже существующими ключами через обычное Spark-соединение, без вероятностной структуры; медленнее Bloom Index, но даёт точный результат без false positive, требующих дополнительной проверки.

• Global Bloom / Global Simple Index - те же два механизма, но действующие по всей таблице, а не только в пределах целевой партиции записи - необходимо, когда партиция записи конкретного ключа может со временем меняться (например, партиционирование по статусу заказа, который может измениться) или когда движок заранее не знает целевую партицию входящей записи.

• Record-Level Index (RLI) - наиболее современный механизм (Hudi 0.14+): отдельная, постоянно поддерживаемая метаданная-таблица, явно хранящая отображение «ключ записи -> точный файл (File Group)», обновляемая при каждой записи. Это даёт точечный поиск без сканирования Bloom-фильтров и без вероятности false positive вообще - O(1) точечный lookup, ближайший по духу к индексу классической СУБД, а не к статистике файлов аналитического движка.

Диаграмма противопоставляет принципиально разные стратегии решения одной и той же задачи - найти, где лежит запись с данным ключом, перед UPSERT. У Iceberg и Delta Lake (восьмой урок модуля для Iceberg, раздел про CoW/MoR этого урока для Delta) ответ добывается универсальным механизмом - тем же MERGE INTO/join, что использовался бы для любой другой аналитической задачи, опирающимся на partition pruning и статистику файлов, но не на специализированную для точечного поиска структуру. У Hudi - выделенный, специально построенный под эту конкретную задачу индексный слой, дающий ответ существенно дешевле для таблиц с высокой частотой точечных обновлений по первичному ключу, ценой необходимости поддерживать и обслуживать сам индекс как дополнительную структуру.

Z-Order и Clustering: три похожих синтаксиса, разная зрелость¶

Десятый урок модуля детально разобрал Z-order компакцию Iceberg (CALL ... rewrite_data_files(strategy => 'zorder', ...)) как способ получить умеренную селективность сразу по нескольким колонкам фильтрации. Delta Lake предлагает синтаксически похожую, давно стабильную возможность - OPTIMIZE table ZORDER BY (col1, col2), доступную как в открытой версии Delta Lake, так и в Databricks Runtime. Hudi реализует ту же идею через отдельный тип Instant - CLUSTERING, с настраиваемой стратегией компоновки (включая z-order и кривую Гильберта), планируемый и выполняемый, как и компакция, либо синхронно, либо асинхронно отдельным сервисом.

Стриминг-возможности: CDC, чтение инкрементов и устойчивость к множеству мелких писателей¶

Все три формата поддерживают и потоковую запись, и потоковое чтение через Spark Structured Streaming, но зрелость, исходная мотивация и конкретный набор гарантий этих возможностей сильно различаются - что прямо следует из философии дизайна, разобранной в начале урока.

Change Data Feed Delta Lake¶

Delta Lake предлагает Change Data Feed (CDF) - механизм, включаемый свойством таблицы delta.enableChangeDataFeed = true, после чего каждая операция UPDATE/DELETE/MERGE дополнительно материализует компактную запись об изменении в скрытую структуру _change_data/. Прочитать поток изменений можно как обычным batch-запросом за диапазон версий, так и потоково:

# batch-чтение изменений между двумя версиями Delta-таблицы
changes_df = (
    spark.read.format("delta")
    .option("readChangeFeed", "true")
    .option("startingVersion", 10)
    .option("endingVersion", 20)
    .table("orders_delta")
)

# каждая строка дополнена тремя системными колонками:
# _change_type:      insert | update_preimage | update_postimage | delete
# _commit_version:   номер версии Delta-таблицы, в которой произошло изменение
# _commit_timestamp: время коммита этой версии
changes_df.select("order_id", "_change_type", "_commit_version").show()

Важная деталь: для UPDATE CDF материализует две строки - update_preimage (значение строки до изменения) и update_postimage (значение строки после изменения) - что даёт downstream-потребителю полную картину перехода значения, а не только конечный результат, востребованную, например, для построения SCD Type 2 в потребляющем пайплайне (паттерн, разобранный в девятом модуле курса).

Changelog Reads Iceberg¶

Iceberg предлагает структурно аналогичную, но более позднюю по времени появления возможность - Changelog Reads (через TableScan-API изменений или процедуру spark_catalog.system.create_changelog_view), также читающую изменения между двумя снапшотами и также дополняющую результат системной колонкой типа операции (INSERT/UPDATE_BEFORE/UPDATE_AFTER/DELETE). Принципиальное отличие в реализации - там, где CDF Delta требует заранее включённого табличного свойства, материализующего отдельные change-файлы при каждой записи, Changelog Reads Iceberg способны вычислить изменения между снапшотами задним числом, сравнивая содержимое снапшотов через уже существующий механизм Time Travel (девятый урок модуля) - то есть не требуют заранее предсказывать потребность в CDC и включать специальный режим записи.

Incremental Queries Hudi - историческое первенство¶

Среди трёх форматов именно Hudi реализовал инкрементальные запросы первым и сделал их частью изначального дизайна, а не более поздней надстройкой - прямое следствие происхождения из Uber (раздел про философию дизайна). Incremental Query в Hudi работает непосредственно с Timeline, а не с парой явно выбираемых снапшотов:

# Incremental Query Hudi: всё, что произошло после конкретного Instant
incremental_df = (
    spark.read.format("hudi")
    .option("hoodie.datasource.query.type", "incremental")
    .option("hoodie.datasource.read.begin.instanttime", "20250601120000")
    .option("hoodie.datasource.read.end.instanttime", "20250601180000")
    .load("s3a://lakehouse/warehouse/orders_hudi")
)

Принципиальное отличие от CDF и Changelog Reads - Hudi Incremental Query изначально проектировался как основной, а не вспомогательный режим чтения таблицы для построения каскадных пайплайнов (datalake-таблица A инкрементально питает построение производной таблицы B), а не специально как инструмент для внешней CDC-интеграции - то есть он глубже встроен в типичный паттерн использования формата, чем аналогичные возможности у конкурентов, появившиеся позже и более явно ориентированные на экспорт изменений во внешние системы.

Устойчивость к множеству мелких потоковых писателей¶

Раздел про эксплуатационную сложность десятого урока модуля показал, что частые micro-batch коммиты Structured Streaming быстро порождают огромное количество мелких файлов, требующих последующей компакции. Здесь три формата принципиально расходятся в философии решения этой проблемы, и расхождение прямо следует из изначального профиля нагрузки каждого:

• Iceberg и Delta Lake - реактивный подход: мелкие файлы пишутся как есть, проблема устраняется отдельной, более редкой maintenance-процедурой (rewrite_data_files у Iceberg, OPTIMIZE у Delta), запускаемой по независимому расписанию, асинхронно от потока записи.

• Hudi - проактивный подход прямо во время записи: настройка hoodie.parquet.small.file.limit (порог в байтах, ниже которого файл считается «маленьким») заставляет писатель Hudi искать существующие маленькие файлы текущей партиции и дописывать новые записи в них, а не создавать новый файл при каждом micro-batch коммите - то есть Hudi пытается предотвратить накопление проблемы непосредственно в момент записи, а не откладывать её устранение на потом.

Это различие напрямую объясняет, почему Hudi часто выбирают именно для нагрузок с очень частыми, маленькими по объёму потоковыми коммитами (секунды-минуты между записями), а Iceberg и Delta Lake комфортнее чувствуют себя при более редких, крупных по объёму коммитах (минуты-часы) - наблюдение, прямо использованное далее в сводной матрице по бизнес-кейсам этого урока.

Свобода от вендора: экосистема интеграций и каталоги¶

Раздел про философию дизайна в начале урока показал, что независимость от конкретного вычислительного движка была явной целью Iceberg с первого дня, тогда как Delta Lake исторически делал противоположную ставку - на глубину интеграции с одним движком. Этот раздел доводит то наблюдение до конкретных, практически значимых механизмов: какие движки на самом деле умеют читать и писать каждый формат, и какую архитектуру каталогов каждый из них предполагает.

Матрица поддержки движков¶

Эта таблица - не статичный факт, а отражение исторической динамики: ещё несколько лет назад Delta Lake был доступен по сути только из Spark, а Iceberg и Hudi предлагали более широкую, но неравномерную поддержку нескольких движков с первого дня. Сегодня разрыв заметно сузился (Delta Kernel дал множеству движков возможность читать Delta без полной Java-библиотеки Databricks), но направление асимметрии - где каждый формат исторически силён, а где догоняет - всё ещё прямо прослеживается до изначальной философии дизайна, разобранной в начале урока.

REST Catalog: каталог как переносимый, движок-независимый сервис¶

Первый урок модуля уже показал два варианта подключения каталога Iceberg - классический Hive Metastore (type = hive) и более новый, спецификационный REST Catalog (catalog-impl = org.apache.iceberg.rest.RESTCatalog, uri = http://iceberg-rest:8181). Этот раздел объясняет, зачем REST Catalog появился и почему он стал стратегически значимым именно для вопроса независимости от вендора.

REST Catalog - это стандартизированный HTTP-API (опубликованный как часть формальной спецификации Iceberg, включая OpenAPI-описание), который любой каталог-провайдер может реализовать самостоятельно как простой stateless-сервис поверх собственного хранилища состояния, и который любой движок может вызывать одинаковым образом, не зная деталей реализации конкретного провайдера. Это переносит зависимость каталога из плоскости «у вас обязательно должен быть установлен и доступен Hive Metastore, JDBC-сервер или специфичный для AWS сервис Glue» в плоскость «любой каталог, говорящий по REST-протоколу спецификации Iceberg, взаимозаменяем».

На диаграмме видно ключевое свойство архитектуры: любой из трёх движков обращается к каталогу через один и тот же HTTP-протокол, не зная, какая конкретно реализация стоит за ним - переключение с Project Nessie на Snowflake Polaris или на самостоятельно развёрнутый Apache Gravitino требует изменения только URI подключения, а не миграции данных или перезаписи запросов. Несколько реальных реализаций REST Catalog заслуживают отдельного упоминания: Project Nessie добавляет git-подобную семантику веток и коммитов поверх каталога Iceberg-таблиц; Snowflake Polaris и Tabular (компания создателя Iceberg, Райана Блю) предлагали управляемые REST Catalog как сервис; AWS Glue добавил REST-совместимый режим поверх уже существующего сервиса; Apache Gravitino - более новый проект, претендующий на роль универсального федеративного каталога не только для Iceberg, а для нескольких форматов сразу.

Показательная деталь индустрии: в 2024 году Databricks приобрела Tabular - компанию-создателя Iceberg, изначально построенную как чисто-Iceberg бизнес. Это можно прочитать двояко - либо как сигнал того, что открытый Iceberg-стандарт стал слишком значимым, чтобы конкурент мог его игнорировать, либо как намерение влиять на курс развития формата изнутри. Для инженерного решения это не имеет прямого значения - открытая спецификация Iceberg как формат файлов и протокол REST Catalog остаются открытыми независимо от того, кто владеет конкретной коммерческой компанией вокруг них - но сама сделка хорошо иллюстрирует, насколько серьёзно рынок воспринимает вопрос открытости формата, разобранный в этом разделе.

Delta UniForm: defensive-стратегия совместимости¶

Ответом Databricks на растущее давление в сторону Iceberg как межплатформенного стандарта стала возможность UniForm (Universal Format) - механизм, при включении которого (delta.universalFormat.enabledFormats = 'iceberg') Delta Lake при каждой записи дополнительно генерирует Iceberg-совместимые метаданные (манифесты и metadata.json), описывающие те же самые, физически уже существующие Parquet-файлы, оставляя нативный _delta_log основным источником истины.

Стоит честно назвать UniForm тем, чем он является с точки зрения рыночной стратегии - защитным шагом: вместо того чтобы рисковать потерей пользователей, нуждающихся в Iceberg-совместимости с другими движками, Databricks предлагает им остаться на родном Delta Lake, получая Iceberg-совместимость «бесплатно» как побочный, генерируемый артефакт. Инженерный нюанс, о котором важно знать: UniForm генерирует Iceberg-метаданные с определённой задержкой относительно Delta-коммита (не строго синхронно), и не каждая продвинутая фича Delta Lake (например, Deletion Vectors, разобранные в разделе про CoW/MoR) имеет корректную, полностью эквивалентную Iceberg-проекцию - то есть UniForm даёт совместимость для типового сценария чтения, но не гарантирует полную функциональную эквивалентность для самых новых возможностей формата.

Эксплуатационная сложность и сервисные операции¶

Десятый урок модуля подробно разобрал три процедуры обслуживания Iceberg-таблицы (rewrite_data_files, expire_snapshots, remove_orphan_files) и показал на конкретном производственном инциденте, что неправильно настроенный retention этих процедур способен сломать долго выполняющийся запрос гонкой FileNotFoundException. Этот раздел переносит ту же аналитическую рамку на Delta Lake и Hudi - и показывает, что природа операционной нагрузки у всех трёх форматов структурно похожа, но конкретные инструменты, пороги и риски отличаются.

Сопоставление процедур обслуживания¶

Главный практический вывод из этой таблицы - объём и природа операционной нагрузки сопоставимы у всех трёх форматов: ни один из них не избавляет инженера от необходимости регулярно запускать аналог компакции и аналог очистки устаревших файлов. Разница - не в том, нужно ли обслуживание вообще, а в том, насколько явно оно интегрировано в основной пайплайн записи (выученное в разделе про устойчивость к малым файлам наблюдение про Hudi применимо и здесь) и насколько единообразен интерфейс этих процедур.

Тот же класс гонки FileNotFoundException - у всех трёх¶

Производственный инцидент десятого урока (слишком агрессивный retain_last в expire_snapshots, оборвавший снапшот, на который ещё опирался долго выполняющийся аналитический запрос) - не специфичная для Iceberg уязвимость, а структурное следствие самой идеи версионируемого метаданного слоя с раздельной операцией очистки. Тот же класс риска присутствует у конкурентов почти без изменений:

• Delta Lake - VACUUM table RETAIN 168 HOURS физически удаляет файлы данных, отсутствующие в истории логов новее указанного порога. Если аналитический запрос, открытый через Time Travel (VERSION AS OF) на старую версию, выполняется дольше, чем установленный retention, VACUUM, запущенный параллельно, удалит файлы, на которые этот запрос всё ещё ссылается - тот же сценарий гонки, что и у Iceberg, только под другим именем команды. По умолчанию Delta Lake требует retention не короче 7 дней именно как защиту от этого риска (можно отключить флагом spark.databricks.delta.retentionDurationCheck.enabled = false, что является явным, осознанным шагом повышения риска).

• Hudi - CLEAN Instant удаляет старые версии File Slice сверх настроенной политики удержания (hoodie.cleaner.commits.retained либо политика по числу часов). Запрос, открытый через Incremental Query или Time Travel-эквивалент Hudi на старый Instant, удалённый прошедшим CLEAN, столкнётся со структурно тем же отказом.

Этот параллелизм - важный аргумент против заблуждения «у Iceberg плохая инженерия обслуживания, у конкурентов лучше»: риск - неотъемлемое следствие самой архитектурной идеи версионируемых метаданных с раздельной garbage collection, а не недостаток конкретной реализации. Правильный ответ для всех трёх форматов одинаков по духу - согласовать retention-период очистки с реалистичной максимальной длительностью долгих запросов и Time Travel-сценариев в конкретной организации, что и было итоговой рекомендацией десятого урока.

Память и риск OOM при тяжёлом MERGE¶

Восьмой урок модуля показал, что MERGE INTO у Iceberg реализован как join между исходными и целевыми данными, и что неравномерное распределение совпадающих ключей (data skew) способно перегрузить память executor'ов на стороне, обрабатывающей переполненные партиции. Этот риск без изменений переносится на Delta Lake, чей MERGE INTO реализован тем же join-based способом на том же движке Spark SQL.

Hudi сдвигает источник нагрузки на память в другое место: вместо join всего входящего батча с целевыми данными, Hudi использует свой индексный слой (раздел про data skipping этого урока) для тэггирования - определения, к какому File Group относится каждая входящая запись, прежде чем выполнить фактическую запись. Сам процесс тэггирования при использовании Bloom-индекса не требует join со всей целевой таблицей, но удержание в памяти исполнителя самих Bloom-фильтров (особенно при Global Bloom Index, покрывающем все партиции таблицы сразу) и при работе с очень большим числом File Group создаёт собственный, отдельный профиль нагрузки на память - не тождественный classic join skew, но способный приводить к OOM при недостаточно тщательно подобранной конфигурации индекса для масштаба конкретной таблицы.

Сводная матрица: выбор формата по бизнес-кейсам¶

Восемь разделов выше дали детальную, инженерно обоснованную картину различий по каждому отдельному измерению. Этот раздел сводит их в практическое решающее правило для трёх характерных, часто встречающихся профилей задач - намеренно более глубоких и обоснованных, чем простая таблица «фича есть / фичи нет» из поверхностного сравнения форматов, которую можно найти в любой вводной статье.

Кейс А: корпоративное DWH на нескольких движках, BI-нагрузка¶

Профиль: компания строит классическое корпоративное хранилище данных, к которому обращаются несколько разных инструментов - Spark для ETL, Trino для интерактивных BI-запросов (Tableau, Metabase, Superset), возможно ClickHouse для дополнительной аналитики. Запись происходит регулярными батчами (ежечасно или ежедневно), а не потоком с задержкой в секунды. Команда явно избегает привязки к одному коммерческому движку и хочет сохранить свободу выбора движка чтения на годы вперёд.

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

Кейс Б: real-time стриминг с задержкой до пяти минут, тяжёлый UPSERT¶

Профиль: данные поступают непрерывным потоком через Kafka/Debezium (CDC из транзакционной СУБД, разобранный в одиннадцатом модуле курса), требование к сквозной задержке - не более пяти минут от события в источнике до доступности в аналитической таблице, а доля операций обновления существующих строк (а не только вставки новых) составляет значительную часть потока.

Рекомендация: Apache Hudi. Обоснование: раздел про индексацию показал, что именно Hudi обладает специализированным индексным слоем (Bloom, RLI), дающим заметно более дешёвый точечный UPSERT по первичному ключу, чем универсальный join-based MERGE INTO двух конкурентов; раздел про streaming показал, что Hudi - единственный из трёх форматов, проактивно решающий проблему множества мелких файлов прямо во время записи (small.file.limit), что критично именно при высокой частоте micro-batch коммитов; историческое первенство и глубина встраивания Incremental Query в основной паттерн использования формата снижает архитектурный риск для каскадных, инкрементально питающих друг друга стриминговых пайплайнов.

Кейс В: стек, привязанный к Databricks как managed-платформе¶

Профиль: компания осознанно выбрала Databricks как основную платформу обработки данных (не вопрос «избежать вендора», а наоборот - осознанная коммерческая ставка на managed-сервис с его SLA, поддержкой и инструментарием), команда работает почти исключительно через Spark/Databricks Notebooks и SQL Warehouses, не планирует подключать Trino, Flink или ClickHouse к тем же таблицам в обозримом будущем.

Рекомендация: Delta Lake, и конкретно - использование его в составе самого Databricks Runtime, а не открытой автономной версии. Обоснование: раздел про философию дизайна показал, что глубочайшая интеграция со Spark и, в частности, с коммерческим движком исполнения Photon - центральное, изначальное конкурентное преимущество Delta Lake; раздел про экосистему показал, что самые продвинутые возможности (Liquid Clustering) зрелее и полнее всего реализованы именно в управляемом Databricks Runtime; раздел про data skipping показал, что Generated Columns и физическая жёсткость партиционирования Delta Lake - меньшая практическая проблема, если организация в принципе не планирует множественные независимые движки чтения, ради которых имела бы смысл инвестиция в гибкость Partition Evolution Iceberg.

Сводная таблица решающих факторов¶

Важная методологическая оговорка: эти три кейса - типичные, но не исчерпывающие точки на спектре. Реальная организация может обнаружить себя на пересечении нескольких профилей (например, нужен и широкий многодвижковый доступ, и тяжёлый UPSERT) - и именно для таких смешанных случаев настоятельно рекомендуется не угадывать ответ по интуиции, а воспроизвести измерения практического демо-блока этого урока на собственном, реалистичном по объёму и структуре датасете, прежде чем фиксировать архитектурное решение, которое окажется дорогим для пересмотра позже.

Практический демо-блок: бенчмарк UPSERT на одинаковом датасете¶

Все рассуждения выше опираются на задокументированные архитектурные различия, но окончательное решение для конкретной нагрузки заслуживает собственного измерения, а не только теоретического вывода. Этот раздел воспроизводит идентичный сценарий UPSERT на одном и том же датасете в трёх форматах внутри полностью самостоятельно хостящегося окружения - в соответствии с принципом курса о работе только с self-hosted инфраструктурой, без выгрузки данных в управляемое облако.

Кейс 0: окружение - Spark, MinIO и три набора пакетов¶

Лаборатория поднимается локально через Docker Compose - тот же minio сервис, что использовался в первом уроке модуля для Iceberg, и Spark с тремя независимыми наборами пакетов, поскольку Iceberg, Delta Lake и Hudi конфигурируются как взаимоисключающие расширения одной и той же SparkSession (одновременное подключение всех трёх пакетов в одну сессию технически возможно, но усложняет диагностику конфликтов классов - в лаборатории три формата запускаются тремя отдельными запусками spark-submit).

# docker-compose.yml - минимальное self-hosted окружение лаборатории
services:
  minio:
    image: minio/minio:latest
    ports:
      - "9000:9000"
      - "9001:9001"
    environment:
      MINIO_ROOT_USER: minioadmin
      MINIO_ROOT_PASSWORD: minioadmin
    command: server /data --console-address ":9001"

  spark:
    image: bitnami/spark:3.5.0
    depends_on:
      - minio
    volumes:
      - ./lab:/opt/lab

# requirements.txt лаборатории - три формата требуют разные пары pyspark/коннектор-версий,
# но 3.5.0 - общий знаменатель, совместимый со всеми тремя одновременно
pyspark==3.5.0
delta-spark==3.1.0

# session_iceberg.py - SparkSession для запусков с Apache Iceberg
from pyspark.sql import SparkSession

spark = (
    SparkSession.builder
    .appName("format-benchmark-iceberg")
    .config("spark.jars.packages",
            "org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.5.2,"
            "org.apache.iceberg:iceberg-aws-bundle:1.5.2")
    .config("spark.sql.extensions", "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions")
    .config("spark.sql.catalog.lakehouse", "org.apache.iceberg.spark.SparkCatalog")
    .config("spark.sql.catalog.lakehouse.catalog-impl", "org.apache.iceberg.rest.RESTCatalog")
    .config("spark.sql.catalog.lakehouse.uri", "http://iceberg-rest:8181")
    .config("spark.sql.catalog.lakehouse.warehouse", "s3a://lakehouse/warehouse")
    .config("spark.sql.catalog.lakehouse.io-impl", "org.apache.iceberg.aws.s3.S3FileIO")
    .config("spark.sql.catalog.lakehouse.s3.endpoint", "http://minio:9000")
    .config("spark.hadoop.fs.s3a.access.key", "minioadmin")
    .config("spark.hadoop.fs.s3a.secret.key", "minioadmin")
    .getOrCreate()
)

# session_delta.py - SparkSession для запусков с Delta Lake
from pyspark.sql import SparkSession

spark = (
    SparkSession.builder
    .appName("format-benchmark-delta")
    .config("spark.jars.packages", "io.delta:delta-spark_2.12:3.1.0")
    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension")
    .config("spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog")
    .config("spark.hadoop.fs.s3a.endpoint", "http://minio:9000")
    .config("spark.hadoop.fs.s3a.access.key", "minioadmin")
    .config("spark.hadoop.fs.s3a.secret.key", "minioadmin")
    .config("spark.hadoop.fs.s3a.path.style.access", "true")
    .getOrCreate()
)

# session_hudi.py - SparkSession для запусков с Apache Hudi
from pyspark.sql import SparkSession

spark = (
    SparkSession.builder
    .appName("format-benchmark-hudi")
    .config("spark.jars.packages", "org.apache.hudi:hudi-spark3.5-bundle_2.12:0.15.0")
    .config("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
    .config("spark.sql.extensions", "org.apache.spark.sql.hudi.HoodieSparkSessionExtension")
    .config("spark.hadoop.fs.s3a.endpoint", "http://minio:9000")
    .config("spark.hadoop.fs.s3a.access.key", "minioadmin")
    .config("spark.hadoop.fs.s3a.secret.key", "minioadmin")
    .config("spark.hadoop.fs.s3a.path.style.access", "true")
    .getOrCreate()
)

Кейс 1: одинаковый исходный датасет и первоначальная запись¶

Чтобы сравнение было честным, все три запуска используют один и тот же сгенерированный датасет - 10 миллионов строк заказов с равномерным распределением по 365 партициям (один день), записанный сначала как обычный append без единого UPSERT, для измерения базовой стоимости первоначальной загрузки.

from pyspark.sql import functions as F

def generate_orders(spark, n_rows: int = 10_000_000):
    return (
        spark.range(0, n_rows)
        .withColumn("order_id", F.col("id"))
        .withColumn("customer_id", (F.col("id") % 500_000))
        .withColumn(
            "order_ts",
            F.expr("timestamp_seconds(1700000000 + (id % 31536000))"),
        )
        .withColumn("order_date", F.to_date("order_ts"))
        .withColumn("amount", F.round(F.rand() * 1000, 2))
        .withColumn("status", F.lit("CREATED"))
        .drop("id")
    )

orders_df = generate_orders(spark)

# запись в Iceberg
orders_df.writeTo("lakehouse.benchmark.orders_iceberg") \
    .partitionedBy("order_date").createOrReplace()

# запись в Delta Lake (path-based таблица в отдельном подпути)
orders_df.write.format("delta").partitionBy("order_date") \
    .save("s3a://lakehouse/warehouse/benchmark/orders_delta")

# запись в Hudi (path-based таблица в отдельном подпути, COW по умолчанию)
orders_df.write.format("hudi") \
    .option("hoodie.table.name", "orders_hudi") \
    .option("hoodie.datasource.write.recordkey.field", "order_id") \
    .option("hoodie.datasource.write.partitionpath.field", "order_date") \
    .option("hoodie.datasource.write.precombine.field", "order_ts") \
    .mode("overwrite") \
    .save("s3a://lakehouse/warehouse/benchmark/orders_hudi")

Кейс 2: идентичный UPSERT-сценарий на 5% строк¶

Сценарий, имитирующий типичный поток CDC-обновлений: 5% случайно выбранных заказов меняют status на SHIPPED и получают новый amount, плюс добавляется 1% совершенно новых строк - то есть один и тот же updates_df используется во всех трёх запусках без каких-либо изменений между ними.

existing_ids = orders_df.select("order_id").sample(0.05).withColumn(
    "amount", F.round(F.rand() * 1000, 2)
).withColumn("status", F.lit("SHIPPED"))

new_rows = generate_orders(spark, 100_000).withColumn(
    "order_id", F.col("order_id") + 10_000_000
)

updates_df = existing_ids.unionByName(new_rows, allowMissingColumns=True)

-- Iceberg: MERGE INTO (восьмой урок модуля)
MERGE INTO lakehouse.benchmark.orders_iceberg t
USING updates_view s
ON t.order_id = s.order_id
WHEN MATCHED THEN UPDATE SET t.status = s.status, t.amount = s.amount
WHEN NOT MATCHED THEN INSERT *

# Delta Lake: MERGE INTO через DeltaTable API
from delta.tables import DeltaTable

delta_table = DeltaTable.forPath(spark, "s3a://lakehouse/warehouse/benchmark/orders_delta")
(
    delta_table.alias("t")
    .merge(updates_df.alias("s"), "t.order_id = s.order_id")
    .whenMatchedUpdate(set={"status": "s.status", "amount": "s.amount"})
    .whenNotMatchedInsertAll()
    .execute()
)

# Hudi: запись с тем же DataFrame API - UPSERT определяется опцией
# OPERATION_OPT_KEY, а не отдельным синтаксисом MERGE
updates_df.write.format("hudi") \
    .option("hoodie.table.name", "orders_hudi") \
    .option("hoodie.datasource.write.operation", "upsert") \
    .option("hoodie.datasource.write.recordkey.field", "order_id") \
    .option("hoodie.datasource.write.partitionpath.field", "order_date") \
    .option("hoodie.datasource.write.precombine.field", "order_ts") \
    .mode("append") \
    .save("s3a://lakehouse/warehouse/benchmark/orders_hudi")

Кейс 3: измерение - время записи, размер на диске, время планирования чтения¶

Единая измерительная обвязка засекает время каждой операции и опрашивает MinIO на итоговый объём занятого пространства до и после UPSERT-сценария, а также измеряет время простого count()-запроса с фильтром по партиции - то есть planning time, аналогично методике десятого урока модуля.

import time

def measure(label, fn):
    start = time.perf_counter()
    result = fn()
    elapsed = time.perf_counter() - start
    print(f"{label}: {elapsed:.2f} сек")
    return result, elapsed

# пример для Iceberg-запуска - идентичная обвязка применяется к Delta- и Hudi-сценариям
_, t_write = measure("Iceberg UPSERT", lambda: spark.sql("""
    MERGE INTO lakehouse.benchmark.orders_iceberg t
    USING updates_view s ON t.order_id = s.order_id
    WHEN MATCHED THEN UPDATE SET t.status = s.status, t.amount = s.amount
    WHEN NOT MATCHED THEN INSERT *
"""))

_, t_count = measure("Iceberg COUNT с partition pruning", lambda: spark.sql("""
    SELECT count(*) FROM lakehouse.benchmark.orders_iceberg
    WHERE order_date = DATE'2024-06-15'
""").collect())

Ожидаемая, типичная по характеру (но не приводимая здесь как точные числа - они зависят от конкретного железа и должны быть измерены лично на собственном окружении) картина результатов соответствует архитектурным выводам предыдущих разделов: Hudi демонстрирует наименьшее время записи UPSERT благодаря индексному слою, избегающему полного join со всей таблицей; Iceberg и Delta Lake показывают сопоставимое между собой время записи (оба реализуют MERGE как join) с небольшим преимуществом у того, чей Catalog ближе физически к Spark-кластеру лаборатории; planning time простого COUNT с partition pruning у всех трёх форматов на этом масштабе различается слабо до накопления значительной истории - расхождение становится заметным только после нескольких десятков циклов UPSERT, что проверяется в следующем кейсе.

Кейс 4: эффект компакции после серии из 20 циклов UPSERT¶

Повторение Кейса 2 двадцать раз подряд (симуляция продолжительной работы потока CDC) накапливает delete-структуры (position delete у Iceberg, Deletion Vectors у Delta, log-файлы у Hudi) и измеримо замедляет планирование запроса - именно тот Read Amplification эффект, разобранный в седьмом уроке модуля для Iceberg и обобщённый на три формата в разделе про CoW/MoR этого урока. Запуск соответствующей процедуры компакции для каждого формата восстанавливает скорость чтения:

# Iceberg: rewrite_data_files (десятый урок модуля)
spark.sql("CALL lakehouse.system.rewrite_data_files(table => 'benchmark.orders_iceberg')")

# Delta Lake: OPTIMIZE
spark.sql("OPTIMIZE delta.`s3a://lakehouse/warehouse/benchmark/orders_delta`")

# Hudi: явный запуск компакции через отдельную процедуру (для MoR-таблиц;
# при COW-таблице, как в этой лаборатории, базовые файлы переписываются
# уже при каждом upsert, поэтому здесь демонстрируется CLUSTERING - аналог Z-order)
spark.sql("""
    CALL run_clustering(table => 'orders_hudi')
""")

Сравнение planning time запроса COUNT с фильтром по партиции до и после запуска соответствующей процедуры компакции для каждого формата - именно тот измеримый эффект, который должен быть зафиксирован при доведении лаборатории до конца на собственном железе и положен в основу любого окончательного решения по выбору формата, дополняющего теоретическую сводную матрицу предыдущего раздела конкретными числами для собственной, реальной нагрузки.

Производственный кейс: миграция с Databricks-only возможностей на self-hosted Trino¶

Команда среднего размера два года строила аналитическую платформу целиком на Databricks: Delta Lake как формат хранения, Databricks SQL Warehouses как движок BI-запросов, Photon как движок исполнения, Liquid Clustering как основной механизм организации крупных таблиц фактов. Решение принималось осознанно и на тот момент было разумным - команда была маленькой, Databricks Runtime давал managed-инфраструктуру без необходимости держать отдельную DevOps-функцию, а скорость выхода в продакшен была приоритетнее архитектурной независимости.

Спустя два года компания выросла, объём данных вырос на порядок, а счета за Databricks compute стали ощутимой статьёй бюджета. Финансовое руководство поставило задачу: перенести слой BI-запросов на self-hosted Trino-кластер поверх того же MinIO-хранилища, оставив Databricks только для ETL-нагрузки, и тем самым сократить расходы на дорогой managed SQL Warehouse compute. На бумаге перенос выглядел простым - Trino умеет читать Delta-таблицы напрямую через delta коннектор, формат файлов на диске не меняется, миграция данных не нужна.

Реальность оказалась болезненнее. Самые крупные и часто используемые таблицы фактов компании были организованы через Liquid Clustering (CLUSTER BY (customer_id, event_date)) - а Trino-коннектор Delta Lake на тот момент умел читать сами данные, но не умел интерпретировать кластеризационные метаданные Liquid Clustering для эффективного data skipping: запросы, ранее использовавшие clustering-метаданные для pruning внутри Databricks SQL Warehouse, при выполнении через Trino деградировали до полного скана партиции. Параллельно обнаружилось, что часть таблиц использовала Deletion Vectors, корректно читаемые Trino, но требующие более новой версии коннектора, чем та, что была включена в текущий релиз используемого Trino - то есть само обновление инфраструктуры стало предпосылкой миграции, а не нейтральным фактом.

Командe пришлось выбирать между тремя путями: (а) переписать схему кластеризации крупных таблиц на классическое PARTITIONED BY ради совместимости с Trino, теряя часть преимуществ Liquid Clustering и требуя полного переписывания исторических данных; (б) задержать миграцию до выхода более новой версии Trino с полной поддержкой нужных возможностей Delta, рискуя финансовым давлением со стороны руководства; (в) пересмотреть стратегию формата для новых таблиц в пользу Iceberg, сохранив существующие Delta-таблицы как технический долг с явным планом постепенной миграции. Команда выбрала комбинацию (б) и (в) - частично отложила миграцию самых проблемных таблиц, и одновременно зафиксировала Apache Iceberg как формат по умолчанию для всех новых таблиц, специально из-за того самого свойства - равномерной многодвижковой поддержки, разобранного в разделе про экосистему этого урока - которое два года назад не было приоритетом, но оказалось критичным при первой же попытке выйти за рамки единственного движка.

Урок этого кейса - не в том, что Delta Lake был неправильным выбором два года назад (для маленькой команды, полностью живущей внутри Databricks, это было обоснованным решением, ровно как и описано в Кейсе В сводной матрицы этого урока). Урок в том, что самые продвинутые, самые удобные возможности конкретной платформы часто оказываются именно той частью формата, которая хуже всего переносится за пределы родного движка - и осознанная ставка на глубокую интеграцию с одним вендором (раздел про философию дизайна) обязана сопровождаться явным признанием соответствующего риска заранее, на этапе выбора архитектуры, а не постфактум, на этапе попытки от него уйти.

Типичные заблуждения¶

«Iceberg, Delta Lake и Hudi - в целом одно и то же, разница только в синтаксисе команд» - неверно, и это, возможно, самое опасное заблуждение всего урока. Раздел про битву метаданных явно показал: дерево манифестов, линейный JSON-лог с чекпоинтами и типизированный Timeline - три физически разные структуры с разными гарантиями консистентности, разной стоимостью восстановления состояния и разной моделью атомарности коммита. Различия проявляются не в синтаксисе, а в конкретном поведении под нагрузкой - именно то, что измеряет практический демо-блок этого урока.

«Раз Hudi сильнее в индексации, он автоматически лучший формат для любой задачи» - неточно. Сводная матрица этого урока явно показала, что превосходство Hudi в точечном UPSERT относится к конкретному профилю нагрузки (Кейс Б) и не означает преимущества в сценариях, где приоритет - многодвижковая аналитическая совместимость (Кейс А) или глубокая интеграция с managed-платформой (Кейс В). Выбор формата - это выбор под конкретный профиль нагрузки, а не поиск универсально «лучшего» технического решения.

«Delta UniForm и Iceberg REST Catalog решают одну и ту же задачу совместимости» - неверно. Раздел про экосистему интеграций явно разграничил эти механизмы: REST Catalog - это протокол доступа к уже единому формату метаданных, не предполагающий генерации параллельной, дублирующей структуры. UniForm, напротив, генерирует вторую, отдельную проекцию метаданных (Iceberg-совместимую) рядом с основной (Delta), с задержкой и без полной гарантии эквивалентности для самых новых возможностей формата - это принципиально иной, более слабый по гарантиям механизм совместимости.

«CoW и MoR в Iceberg, Delta и Hudi - идентичные механизмы под разными именами» - неверно. Раздел про парадигмы обновления данных явно показал структурные различия: Iceberg разделяет position и equality delete как два специализированных механизма с разным профилем стоимости; Delta Deletion Vectors умеют только помечать удаление, не умеют менять значения «бесплатно»; Hudi использует один универсальный log-файловый механизм, способный нести любой тип изменения. Перенос мысленной модели одного формата на другой без проверки этих различий - источник неверных ожиданий по производительности.

«Раз формат поддерживает MERGE INTO / UPSERT, дешевизна операции гарантирована независимо от масштаба таблицы» - опасное заблуждение. Раздел про эксплуатационную сложность явно показал, что у Iceberg и Delta Lake MERGE - join-based операция, чувствительная к data skew и общему объёму целевой таблицы, а у Hudi даже специализированный индексный слой требует тщательной настройки (выбор типа индекса, объём памяти под Bloom-фильтры) для сохранения дешевизны на большом масштабе - ни один из трёх форматов не даёт такой гарантии «бесплатно», без осознанной настройки.

«Открытый формат файлов автоматически означает отсутствие vendor lock-in» - неточно, и именно это показал производственный кейс этого урока. Формат файлов на диске (Parquet) был открытым у всех трёх рассматриваемых решений с самого начала, но это не помешало команде в кейсе столкнуться с реальным lock-in через продвинутые возможности конкретного движка (Liquid Clustering), не переносимые на альтернативный движок чтения. Открытость файла данных - необходимое, но не достаточное условие реальной переносимости.

«Зрелость многодвижковой поддержки формата - статичный, неизменный факт, который не стоит перепроверять» - неверно. Раздел про экосистему явно отметил, что разрыв между форматами по этому критерию исторически сужался (Delta Kernel дал многим движкам доступ к Delta без полной Java-библиотеки), а ситуация продолжает меняться - решение, принятое на основе таблицы поддержки движков из этого урока, должно быть перепроверено на актуальность непосредственно перед архитектурным решением, а не принято на веру как нечто навсегда зафиксированное.

Производственный чек-лист¶

• Выбор формата зафиксирован письменно с явным указанием доминирующего критерия (многодвижковая совместимость / частота и стоимость UPSERT / глубина интеграции с managed-платформой) из сводной матрицы этого урока, а не выбран по принципу «у конкурентов так принято» или «выбрали то, что знали раньше».

• Перед окончательным решением воспроизведён практический бенчмарк этого урока (или его аналог) на собственном, реалистичном по объёму и структуре датасете, а не только на основе теоретического сравнения архитектур - конкретные числа на конкретном железе и конкретном паттерне нагрузки часто меняют интуитивный вывод.

• Если выбор сделан в пользу глубокой интеграции с одним вендором (Databricks/Delta Lake), риск миграции на другой движок чтения признан явно и заранее, с письменной оценкой того, какие именно продвинутые возможности (Liquid Clustering, Photon-специфичные оптимизации) могут не перенестись на альтернативный движок - по образцу производственного кейса этого урока.

• Retention-период всех процедур обслуживания (VACUUM / expire_snapshots / CLEAN) согласован с максимальной ожидаемой длительностью долгих запросов и Time Travel-сценариев в организации, независимо от выбранного формата - разобранный в этом и десятом уроках класс гонки FileNotFoundException присутствует у всех трёх форматов без исключения.

• При выборе Hudi для тяжёлой UPSERT-нагрузки явно подобран и протестирован тип индекса (Bloom / Simple / Global Bloom / Record-Level Index) под фактический паттерн распределения ключей и партиций конкретной таблицы, а не оставлен по умолчанию без проверки на реалистичном объёме.

• При выборе Delta Lake вне управляемого Databricks Runtime явно проверена фактическая поддержка нужных возможностей (Deletion Vectors, Liquid Clustering) в используемой версии стороннего движка чтения (Trino, Flink), а не предполагается «по умолчанию работает», поскольку зрелость этой поддержки исторически отставала от нативной Spark-реализации.

• Решение пересматривается не реже раза в год с учётом изменившейся зрелости многодвижковой поддержки, новых возможностей (Liquid Clustering, Record-Level Index, Changelog Reads) и изменившегося профиля нагрузки самой организации - архитектурное решение, верное два года назад, не гарантированно остаётся верным сегодня, что и показал производственный кейс этого урока.

Мостик к следующим урокам¶

Этот урок завершил весь десятый модуль курса, дав сравнительную, инженерно обоснованную картину трёх конкурирующих реализаций общей идеи Open Table Format, выросшей из проблем классического Hive Data Lake, разобранных в первом разделе. Десятый модуль исчерпывающе закрыл тему table format как таковую - архитектуру, парадигмы обновления, индексацию, стриминг, экосистему, эксплуатацию и итоговый выбор. Следующий, одиннадцатый модуль курса («PostgreSQL») переключает внимание с устройства самого озера данных на источник, из которого данные в это озеро попадают.

• JDBC Connector и Parallel JDBC Read одиннадцатого модуля напрямую продолжат тему параллельного, партиционированного чтения большого источника, уже знакомую по работе с object storage в пятом модуле курса - только на этот раз источником будет не файловая система, а транзакционная СУБД, и партиционирование чтения придётся проектировать вручную через numPartitions/partitionColumn/lowerBound/upperBound, а не получать «бесплатно» через Hidden Partitioning, как в Iceberg.

• PostgreSQL WAL и Debezium CDC одиннадцатого модуля дадут источник тех самых потоков изменений, чтение и применение которых через MERGE INTO/CDF/Changelog Reads/Incremental Query разбирал раздел про стриминг этого урока - то есть одиннадцатый модуль покажет, откуда берётся CDC-поток, который десятый модуль учил эффективно принимать и материализовывать в виде Lakehouse-таблицы.

• CDC Events одиннадцатого модуля - формат сообщений об изменениях (before/after/op), генерируемых Debezium из PostgreSQL WAL - структурно близкий родственник системных колонок _change_type/update_preimage/update_postimage Delta CDF и INSERT/UPDATE_BEFORE/UPDATE_AFTER/DELETE Iceberg Changelog Reads, разобранных в разделе про streaming этого урока: понимание одной из этих двух нотаций существенно облегчает понимание другой, поскольку обе кодируют одну и ту же концепцию «строка плюс тип произошедшего с ней изменения», только на разных уровнях технологического стека - на уровне исходной СУБД против уровня целевого Lakehouse-формата.

Домашнее задание¶

1. Разверните локальное self-hosted окружение лаборатории этого урока (Docker Compose с MinIO и тремя SparkSession-конфигурациями) и воспроизведите Кейсы 0-2 практического демо-блока полностью: сгенерируйте 10 миллионов строк, запишите их во все три формата, выполните идентичный UPSERT-сценарий и зафиксируйте письменно время записи для каждого формата на вашем железе.

2. Повторите Кейс 2 двадцать раз подряд без единого запуска компакции, замерьте planning time запроса COUNT с фильтром по партиции после каждых пяти циклов и постройте график деградации для всех трёх форматов. Письменно объясните разницу в форме графика (если она есть) через материал раздела про CoW/MoR этого урока.

3. Реализуйте на одной и той же Hudi-таблице четыре типа индекса (Bloom, Simple, Global Bloom, Record-Level Index) по очереди, выполните идентичный UPSERT-сценарий Кейса 2 для каждого, и письменно сравните не только время выполнения, но и потребление памяти executor'ов (через Spark UI) - свяжите результат с материалом раздела про data skipping этого урока про разный профиль нагрузки на память у разных типов индекса.

4. Включите Deletion Vectors на тестовой Delta-таблице (delta.enableDeletionVectors = true), выполните чистый DELETE без изменения значений и отдельно UPDATE, изменяющий значения существующих строк. Через DESCRIBE HISTORY и прямой просмотр содержимого _delta_log/ подтвердите эмпирически утверждение раздела про CoW/MoR этого урока: DELETE действительно создаёт только Deletion Vector, тогда как UPDATE создаёт новые файлы данных.

5. Включите Delta Change Data Feed на тестовой таблице, выполните серию операций INSERT/UPDATE/DELETE, и прочитайте получившийся поток изменений через readChangeFeed. Письменно сопоставьте каждую строку результата (_change_type) с конкретной выполненной SQL-операцией и объясните, почему для UPDATE появляются ровно две строки, а не одна.

6. Настройте Iceberg REST Catalog локально (используя любую открытую реализацию, например Project Nessie в self-hosted режиме) и подключитесь к нему из двух разных движков - Spark и Trino (оба self-hosted) - к одной и той же Iceberg-таблице. Письменно зафиксируйте, какие именно шаги конфигурации потребовались для каждого движка и подтвердите, что оба видят идентичное, согласованное состояние таблицы сразу после коммита из одного из них.

7. Включите Delta UniForm (delta.universalFormat.enabledFormats = 'iceberg') на тестовой таблице, прочитайте сгенерированную Iceberg-проекцию метаданных через Iceberg-движок (Spark с Iceberg-каталогом, направленным на тот же путь), и письменно зафиксируйте, появляется ли задержка между Delta-коммитом и появлением соответствующей Iceberg-метаданной, и совпадает ли результат SELECT через оба пути для таблицы без Deletion Vectors и с ними включёнными.

8. Спроектируйте и письменно обоснуйте выбор формата для гипотетического сценария, не покрытого ровно ни одним из трёх кейсов сводной матрицы этого урока: компания строит ML feature store с требованием к point-in-time correctness (Time Travel необходим), читает данные и из Spark (обучение модели), и из Python-сервиса напрямую через pyarrow/pandas (онлайн-инференс с низкой задержкой), при умеренной частоте обновления признаков (раз в час). Обоснуйте выбор через материал минимум четырёх разделов этого урока.

9. Воспроизведите упрощённую версию производственного кейса этого урока: создайте Delta-таблицу с Liquid Clustering (либо, если недоступно в вашей версии Delta Lake, смоделируйте эквивалентную ситуацию через OPTIMIZE ZORDER BY, зафиксировав ограничение), прочитайте её через self-hosted Trino, и письменно зафиксируйте, какие конкретно метаданные кластеризации видны или не видны движку чтения относительно того, что видит нативный Spark/Delta путь.

10. Напишите сравнительную таблицу (минимум 15 строк) самостоятельно, без обращения к материалу урока, перечисляющую ключевые архитектурные различия Iceberg/Delta Lake/Hudi по всем измерениям, разобранным в уроке (метаданные, CoW/MoR, индексация, streaming, экосистема, эксплуатация), а затем сравните получившуюся таблицу с материалом урока и письменно отметьте, какие пункты вы упустили или сформулировали неточно - это - проверка того, что теоретическое понимание действительно усвоено, а не просто прочитано.

Полная картина: три формата, одна задача, разные компромиссы¶

Завершая урок и весь десятый модуль курса, соберём весь материал в единую диаграмму - от общего происхождения проблемы (классический Data Lake, разобранный в первом разделе) до конкретного, обоснованного выбора одного из трёх форматов под конкретный профиль нагрузки.

Диаграмма читается сверху вниз ровно в том порядке, в котором строился весь урок. Общая проблема классического Data Lake (PROBLEM) рождает одну общую архитектурную идею (IDEA) - версионируемый слой метаданных. От этой общей точки расходятся три самостоятельные ветки, каждая начинающаяся с происхождения (раздел про философию дизайна) и последовательно проходящая через метаданные, парадигму обновления, индексацию/партиционирование и streaming-возможности - ровно те разделы 3-6 урока, которые были разобраны для каждого формата отдельно. Три ветки сходятся обратно в MATRIX - сводную матрицу по бизнес-кейсам, которая, в свою очередь, не является конечной точкой, а ведёт к DECISION - обоснованному выбору, подтверждённому собственным практическим бенчмарком, а не принятому на основании одной только теории.

Итоги¶

Iceberg, Delta Lake и Hudi решают одну и ту же базовую задачу - перенос списка файлов таблицы в версионируемый слой метаданных - но делают это тремя физически разными способами, унаследованными от трёх разных компаний с трёх разных доминирующих профилей нагрузки. Delta Lake - ставка Databricks на глубину интеграции с одним движком; Iceberg - ставка Netflix на формальную, движок-независимую спецификацию; Hudi - ставка Uber на дешёвый UPSERT и низкую задержку потоковой обработки. Понимание этого происхождения объясняет архитектурные приоритеты каждого формата лучше, чем любое заучивание отдельных фич.

Слой метаданных физически устроен по-разному у всех трёх: дерево манифестов у Iceberg, линейный JSON-лог с Parquet-чекпоинтами у Delta Lake, типизированный Timeline с явными Instant у Hudi. Эти структуры дают сопоставимые гарантии (атомарный коммит, версионная история), но с разной механикой восстановления текущего состояния и разной формой явной типизации произошедших операций.

Copy-on-Write и Merge-on-Read - общая концептуальная рамка для всех трёх форматов, но конкретная реализация Merge-on-Read у каждого асимметрична. Iceberg разделяет position и equality delete как два специализированных механизма; Delta Deletion Vectors дёшево удаляют, но дорого изменяют значения; Hudi использует один универсальный log-файловый механизм, способный нести любой тип изменения в единой структуре.

Индексация - точка наибольшей технической дифференциации: только Hudi предлагает выделенный индексный слой (Bloom, Simple, Global Bloom, Record-Level Index), дающий O(1) точечный поиск по ключу без полного сканирования метаданных. Iceberg и Delta Lake решают ту же задачу универсальным join-based механизмом MERGE INTO, опирающимся на partition pruning и статистику файлов, а не на специализированную структуру.

Streaming-возможности трёх форматов различаются и зрелостью, и философией: Hudi Incremental Query - историческое первенство и центральный, а не вспомогательный режим использования формата, тогда как Delta CDF и Iceberg Changelog Reads появились позже как более явно ориентированные на экспорт изменений во внешние системы возможности. Устойчивость к множеству мелких потоковых писателей также различается философски - проактивная защита Hudi во время записи против реактивной компакции постфактум у двух конкурентов.

Свобода от вендора - не бинарное свойство, а спектр: REST Catalog Iceberg даёт переносимость каталога как протокола, Delta UniForm даёт защитную, неполную по гарантиям проекцию метаданных, а открытость самого файла Parquet есть у всех трёх, но не гарантирует переносимости продвинутых, движок-специфичных возможностей, что прямо подтвердил производственный кейс этого урока с миграцией Liquid Clustering-таблиц на Trino.

Эксплуатационная сложность сопоставима у всех трёх форматов по объёму, но не по форме: каждый требует аналога компакции и аналога очистки устаревших файлов, и каждый несёт структурно тот же класс риска гонки FileNotFoundException между обслуживанием и активными читателями/писателями, разобранный для Iceberg в десятом уроке модуля и обобщённый здесь на Delta VACUUM и Hudi CLEAN.

Окончательный выбор формата должен определяться доминирующим профилем нагрузки конкретной организации - многодвижковая аналитика, тяжёлый потоковый UPSERT или глубокая привязка к managed-платформе - а не общими впечатлениями о «популярности» или «новизне» формата, и должен быть подтверждён практическим бенчмарком на собственном, реалистичном датасете, а не принят исключительно на основании теоретического сравнения архитектур.

Краткий глоссарий терминов урока¶

• Open Table Format - класс форматов хранения табличных данных, переносящих список файлов таблицы в явный, версионируемый слой метаданных поверх объектного хранилища, обеспечивающий ACID-гарантии без выделенной СУБД; общее понятие, под которое подпадают Iceberg, Delta Lake и Hudi.

• Metadata-based table - принцип, при котором движок узнаёт точный список файлов таблицы из явных метаданных, а не через листинг файловой системы - центральная идея, отличающая все три формата от классического Hive Data Lake.

• _delta_log - скрытая директория Delta Lake, хранящая последовательность JSON-файлов транзакций (action) и периодические Parquet-чекпоинты, описывающие полную историю изменений таблицы.

• Action (Delta) - типизированная запись внутри JSON-файла транзакции Delta Lake (add, remove, metaData, protocol, commitInfo), описывающая одно элементарное изменение состояния таблицы.

• Checkpoint (Delta) - периодически материализуемый Parquet-файл, содержащий свёрнутое состояние таблицы на конкретную версию, избавляющий читателя от необходимости применять всю историю транзакций с нуля.

• Timeline (Hudi) - упорядоченная по времени последовательность Instant, хранящаяся в директории .hoodie/, фиксирующая всю историю операций над Hudi-таблицей с явной типизацией каждого события.

• Instant (Hudi) - единица Timeline, описывающая одно событие конкретного типа (COMMIT, DELTA_COMMIT, CLEAN, COMPACTION, ROLLBACK, SAVEPOINT, CLUSTERING) в одном из состояний (REQUESTED, INFLIGHT, COMPLETED).

• Deletion Vector - механизм Delta Lake, физически реализованный как side-файл с битовой картой (RoaringBitmap), помечающий позиции логически удалённых строк внутри существующего Parquet-файла без его переписывания.

• HoodieLogBlock - физическая единица log-файла Hudi, содержащая Avro- или Parquet-сериализованные новые, изменённые или помеченные на удаление записи, сливаемые с базовым файлом при чтении по значению ключа.

• Generated Column - объявление колонки Delta Lake, значение которой вычисляется автоматически из других колонок при каждой записи и физически материализуется, часто используемое как партиционная колонка.

• Liquid Clustering - возможность Delta Lake (преимущественно Databricks Runtime), позволяющая указать колонки кластеризации (CLUSTER BY) без физической привязки к директориям и без необходимости переписывать историю при их изменении.

• Bloom Index / Record-Level Index (RLI) - механизмы индексного слоя Hudi: Bloom Index - вероятностная структура для проверки возможного присутствия ключа в файле; Record-Level Index - точная метаданная-таблица, дающая O(1) точечный поиск файла по ключу записи без вероятности false positive.

• Change Data Feed (CDF) - механизм Delta Lake, материализующий поток изменений таблицы с системными колонками _change_type/_commit_version/_commit_timestamp, читаемый как batch- или потоковым запросом.

• Changelog Reads - аналогичная CDF возможность Iceberg, вычисляющая поток изменений между двумя снапшотами через сравнение их содержимого, не требующая заранее включённого специального режима записи.

• Incremental Query - исторически первый и наиболее глубоко встроенный в основной паттерн использования Hudi механизм чтения всех изменений, произошедших между двумя точками Timeline.

• REST Catalog - стандартизированный, опубликованный как часть спецификации Iceberg HTTP-протокол доступа к каталогу таблиц, позволяющий взаимозаменять конкретные реализации каталога (Nessie, Polaris, Glue REST, Gravitino) без изменения кода движков-потребителей.

• Delta UniForm - механизм Delta Lake, дополнительно генерирующий Iceberg-совместимые метаданные поверх тех же физических Parquet-файлов, оставляя _delta_log основным источником истины.

• Vendor lock-in - зависимость архитектурного решения от продвинутых, специфичных для конкретного движка или платформы возможностей формата, затрудняющая последующую миграцию на альтернативный движок без потери функциональности или производительности.