Iceberg или Delta Lake: выбор таблиц для озера решается по двум проверкам: сохраняет ли формат идентичность поля при переименовании столбца и остаются ли на диске файлы, нужные для чтения старой версии. Iceberg связывает столбцы с уникальными ID, Delta Lake хранит column mapping поверх Parquet. Ниже — учебная таблица orders, матрица двух сценариев и порядок проверки.
Table format поверх файлов данных
Table format — это слой метаданных поверх обычных файлов данных. Parquet хранит строки и колонки внутри одного файла. Table format добавляет к набору таких файлов журнал: какие файлы входят в текущую версию таблицы, как называются столбцы, какие снимки состояния существовали раньше. Документация Delta Lake описывает свой формат как слой обработки данных поверх существующих озёр, включая S3, ADLS, GCS и HDFS. Это значит, что файлы Parquet остаются на месте, а формат надстраивает над ними транзакционный журнал и правила чтения.
Практическое следствие: один и тот же набор Parquet-файлов можно читать как обычную папку или как таблицу с историей. Разница проявляется в момент изменений. Обычная папка не знает, какой файл заменил какой. Table format знает, потому что ведёт журнал версий.
В учебном примере таблица orders живёт в двух версиях. Версия 0 содержит строку id1 с amount 100 и строку id2 с amount 50. Версия 1 исправляет id2 до 70. Текущее чтение даёт сумму 170, чтение версии 0 даёт сумму 150. Это ручная арифметика на бумаге, она задаёт эталон, с которым сверяются оба сценария. Никакие движки для получения этих чисел не запускались.
Разделение слоёв важно для выбора. Формат отвечает за метаданные и историю. Движок отвечает за то, как он эти метаданные читает. Ошибка новичка — выбирать формат по названию движка, который стоит в проекте сегодня, и забывать, что завтра к тем же файлам подключится второй движок со своими требованиями к протоколу.
Идентичность полей и metadata rename
Переименование столбца — первая проверка, где форматы расходятся по механике. Документация Apache Iceberg указывает, что проект использует уникальные ID для отслеживания каждого столбца таблицы. Имя столбца становится ярлыком, а идентичность держится на ID. Переименование меняет ярлык, ID остаётся прежним, и старые файлы продолжают сопоставляться с тем же полем.
Delta Lake решает ту же задачу через column mapping. Документация Delta Lake описывает разделение физического имени в Parquet и логического имени столбца. При включённом режиме name переименование столбца меняет логическое имя, а физические данные в файлах остаются нетронутыми. Переписывания Parquet не происходит.
Обе механики дают схожий результат на уровне файлов. Различие лежит в требованиях к читателю и писателю. Iceberg опирается на ID, которые прописаны в его собственных метаданных. Delta Lake требует, чтобы читатель и писатель умели работать с column mapping, а это задаётся версиями протокола.
Для учебного сценария это означает следующее. Переименование amount в amount_total без переписывания файлов проходит в обоих форматах при выполнении требований протокола. Проверка идентичности поля в Iceberg идёт по ID. Проверка в Delta Lake идёт по режиму name и версиям протокола. Дальше начинается вторая проверка — сохранение старой версии, и там решает уже не переименование, а политика хранения файлов.
Delta column mapping и требования протокола
Column mapping в Delta Lake включается не свободно. Документация Delta Lake называет два условия: версия читателя 2 или выше и версия писателя 5 или выше. Режим name задаёт способ сопоставления логических имён с физическими. Без выполнения этих условий переименование столбца с сохранением старых файлов не проходит.
В учебном сценарии карточка текущего читателя заявлена с protocol 1. Это намеренно введённый отрицательный учебный пример. Реальный продукт здесь не назван. При таком читателе изменение BLOCK: формат не может гарантировать, что читатель правильно сопоставит переименованное поле со старыми файлами. Требования 2 и 5 взяты из текущей документации Delta Lake по column mapping. Условие protocol 1 вымышлено для обучения.
Порядок проверки для Delta Lake выглядит так:
- Посмотреть минимальную версию читателя таблицы.
- Посмотреть минимальную версию писателя таблицы.
- Убедиться, что включён режим name.
- Только после этого планировать переименование без переписывания файлов.
Команда DESCRIBE DETAIL в документации Delta Lake возвращает среди прочего minReaderVersion и minWriterVersion. Это те самые числа, которые нужно сверить с требованиями column mapping до изменения схемы. Если читатель заявлен ниже требуемой версии, переименование блокируется ещё при планировании.
Отдельно стоит помнить про ограничения. Документация Delta Lake отмечает, что column mapping взаимодействует с change data feed и потоковыми сценариями, и что переименование без переписывания Parquet не означает нулевого влияния на всех потребителей таблицы. Читатель должен поддерживать протокол таблицы и column mapping; чтение отдельных Parquet-файлов не заменяет корректное чтение Delta-таблицы.
Snapshot и history: какие файлы нужны
История таблицы и файлы данных — две разные сущности. Журнал хранит записи о версиях. Файлы данных лежат в хранилище. Чтение старой версии требует и записи в журнале, и физических файлов, на которые эта запись ссылается.
Документация Delta Lake описывает команду history, которая возвращает операции, пользователя, время и метрики по каждой записи. По умолчанию история таблицы хранится 30 дней. Команда RESTORE возвращает таблицу к более раннему состоянию по версии или по времени. Но RESTORE опирается на те же файлы: если файл удалён из хранилища, восстановление к версии, которая на него ссылалась, невозможно.
Здесь вступает VACUUM. Документация Delta Lake описывает VACUUM как команду, удаляющую файлы, на которые больше не ссылается таблица и которые старше порога хранения. Порог по умолчанию — 7 дней. Официальный блог Delta Lake формулирует прямо: если VACUUM удалит файл, от которого зависит версия таблицы, вернуться к этой версии через time travel не получится.
Iceberg работает по схожей логике, но своими командами. Документация Apache Iceberg указывает, что истечение старых снимков удаляет их из метаданных, и после этого они недоступны для запросов time travel. Файлы, которые делятся с сохранёнными снимками, остаются на месте. Удаляются только те, что больше не нужны ни одному живому снимку.
Разница в алгоритмах важна. VACUUM в Delta Lake удаляет файлы, не упомянутые в текущем состоянии таблицы и вышедшие за порог хранения. Истечение снимков в Iceberg удаляет устаревшие снимки из метаданных и связанные с ними файлы согласно политике. Обе операции необратимы для старого чтения. Наличие записи в журнале не заменяет наличие файла на диске.
Заполненная матрица двух сценариев
Матрица ниже — результат учебного ревью; движки не запускались. Она показывает, как два сценария раскладываются по форматам при заданных условиях.
| Сценарий | Iceberg | Delta Lake |
|---|---|---|
| Переименовать amount в amount_total без переписывания файлов | Проходит: поле сопоставляется по уникальному ID | Проходит при reader ≥ 2, writer ≥ 5, режим name |
| Тот же сценарий при читателе protocol 1 | Числа Delta-протокола неприменимы; нужен совместимый Iceberg-reader | BLOCK: читатель не поддерживает требуемый Delta-протокол |
| Прочитать версию 0 с суммой 150 | Нужен сохранённый снимок версии 0 и его файлы | Нужна запись версии 0 в журнале и её файлы |
| После истечения снимков в Iceberg | Снимок удалён из метаданных, time travel к нему недоступен | Не применимо |
| После VACUUM в Delta Lake | Не применимо | Файлы вне порога удалены, time travel к зависимым версиям недоступен |
| Наличие записи в истории | Для сохранённого снимка нужны его метаданные и файлы; expiration сохраняет файлы живых снимков | Запись есть, файлы могут быть удалены VACUUM |
Учебное значение reader protocol 1 относится только к Delta Lake. В Iceberg истечение снимков не удаляет файлы, нужные оставшимся доступным снимкам.
Из матрицы видно, что выбор формата для этих двух сценариев упирается в две вещи: версии протокола у потребителей Delta Lake и политику хранения файлов в обоих форматах. В Iceberg идентичность поля при переименовании держится на ID в метаданных; совместимость движка с форматом таблицы проверяют отдельно. Delta Lake требует явной сверки версий до изменения схемы.
Общего победителя по скорости, стоимости или совместимости движков матрица не объявляет. Она отвечает только на два поставленных вопроса.
Учебные суммы 150 и 170 и границы time travel
Вернёмся к числам. Версия 0 таблицы orders даёт сумму 150: 100 плюс 50. Версия 1 даёт сумму 170: 100 плюс 70. Это эталоны для проверки, что чтение попадает в нужную версию. Если после операции чтение версии 0 возвращает 170, значит читатель видит текущее состояние вместо исторического.
Границы time travel задаются не форматом как таковым, а политикой хранения. В Delta Lake порог VACUUM по умолчанию 7 дней, история таблицы по умолчанию 30 дней. Эти два числа независимы: журнал может хранить записи дольше, чем живут файлы данных. В Iceberg срок жизни снимков задаётся политикой истечения, и после истечения снимок пропадает из метаданных.
Практический порядок проверки перед тем, как полагаться на time travel:
- Зафиксировать, к какой версии нужно вернуться и какая сумма ей соответствует.
- Проверить, что запись этой версии есть в журнале.
- Проверить, что файлы этой версии не попали под VACUUM или истечение снимков.
- Сверить порог хранения файлов с требуемым горизонтом чтения.
Если после retention-операции нужна версия 0 с суммой 150, а её файлы удалены, операция блокируется в учебном сценарии. Это правило учебного сценария; операция не выполнялась. Наличие записи в истории не спасает: журнал ссылается на файл, файла нет.
Отсюда практический вывод для выбора. Если горизонт исторического чтения короткий и совпадает с порогом очистки, оба формата подходят. Если горизонт длинный, порог хранения файлов нужно поднимать отдельно от срока жизни журнала, и делать это до первой очистки.
Частые вопросы
Iceberg или Delta Lake: что выбрать для нового озера?
Выбор идёт по двум проверкам: как формат держит идентичность поля при переименовании и как политика хранения файлов соотносится с нужным горизонтом чтения. Iceberg связывает столбцы с уникальными ID. Delta Lake требует сверки версий читателя и писателя для column mapping. Оба формата работают поверх Parquet-файлов в S3, ADLS, GCS и HDFS.
Чем Iceberg отличается от Delta Lake при переименовании столбца?
Iceberg сопоставляет поле по уникальному ID, поэтому переименование меняет ярлык, а идентичность сохраняется. Delta Lake использует column mapping с режимом name и требует версию читателя 2 или выше и версию писателя 5 или выше. При выполнении этих условий переписывания Parquet не происходит в обоих форматах.
Почему time travel перестаёт работать после очистки?
Чтение старой версии требует и записи в журнале, и физических файлов. VACUUM в Delta Lake удаляет файлы вне порога хранения, и зависимые версии становятся недоступны. Истечение снимков в Iceberg удаляет устаревшие снимки из метаданных, и они пропадают из time travel. Запись в истории сама по себе файлы не возвращает.
Что такое column mapping в Delta Lake?
Это механизм разделения физического имени столбца в Parquet и логического имени в таблице. Он позволяет переименовывать и удалять столбцы без переписывания файлов данных. Для включения нужны версия читателя 2 или выше, версия писателя 5 или выше и режим name. Проверить текущие версии можно командой DESCRIBE DETAIL.
Как проверить, что чтение попадает в нужную версию таблицы?
Задать эталонную сумму для каждой версии. В учебном примере версия 0 даёт 150, версия 1 даёт 170. Если чтение версии 0 возвращает 170, читатель видит текущее состояние. Перед проверкой убедитесь, что файлы нужной версии не удалены очисткой и порог хранения покрывает требуемый горизонт.