Эволюция схем в Table Formats

В уроке 01 мы разобрали, что Parquet и ORC сами по себе поддерживают только базовую эволюцию: добавление колонок в конец. Переименование, удаление, изменение порядка — невозможны без перезаписи файлов.

Table formats (Delta Lake, Iceberg, Hudi, Paimon) решают эту проблему: они добавляют metadata layer поверх Parquet/ORC, который отслеживает колонки не по позиции, а по ID или имени, и позволяет менять схему без rewrite данных.

Каждый формат решает эту задачу по-разному. Iceberg — наиболее мощный (ID-based tracking, partition evolution). Delta Lake — фокус на enforcement и type widening. Hudi — минимальная эволюция. Paimon — streaming-first подход.

Delta Lake: Schema Enforcement + Evolution

Delta Lake различает два режима:

Schema Enforcement (по умолчанию)

Schema enforcement — это строгая проверка: каждая write-операция должна точно соответствовать текущей схеме таблицы. Если schema не совпадает — write отклоняется:

# Текущая схема: id: int, name: string, email: string
# Попытка записать: id: int, name: string, phone: string
# → AnalysisException: phone не существует в схеме таблицы
df_with_phone.write.format("delta").mode("append").save("/data/users")

Enforcement защищает от случайного добавления “мусорных” колонок. Это schema-on-write: ошибка обнаруживается в момент записи, а не при чтении.

Schema Evolution (opt-in)

Чтобы разрешить эволюцию, нужно явно включить mergeSchema:

# Добавление новой колонки phone
df_with_phone.write.format("delta") \
 .mode("append") \
 .option("mergeSchema", "true") \
 .save("/data/users")

Поддерживаемые операции

Type Widening

Delta Lake поддерживает безопасное расширение типов без rewrite:

-- Включить type widening для таблицы
ALTER TABLE users SET TBLPROPERTIES ('delta.enableTypeWidening' = 'true');

-- Теперь можно менять тип
ALTER TABLE users ALTER COLUMN age TYPE BIGINT; -- int → bigint

Безопасные widening-пути: byte → short → int → long, float → double, date → timestampNTZ.

Apache Iceberg: ID-based Column Tracking

Iceberg — наиболее мощный формат с точки зрения schema evolution. Ключевое отличие: каждая колонка имеет уникальный integer ID, который никогда не переиспользуется.

Как работает ID-based tracking

Все операции Iceberg

Iceberg поддерживает полный набор schema evolution операций — без rewrite данных:

Partition Evolution

Уникальная фича Iceberg — partition evolution: можно менять partition scheme без rewrite:

-- Начали с партиционирования по дням
ALTER TABLE events ADD PARTITION FIELD day(event_time);

-- Через год: данных слишком много, меняем на часы
ALTER TABLE events REPLACE PARTITION FIELD day(event_time) WITH hour(event_time);

Iceberg хранит partition spec per-snapshot. Старые файлы остаются в дневных партициях, новые — в часовых. При query planning Iceberg использует оба spec для partition pruning.

Iceberg Spec v3

Spec v3 (стабилизирован в 2025) добавляет:

• Row-level lineage: отслеживание происхождения строк
• Multi-argument transforms: composite partition transforms
• Default values: значения по умолчанию для новых колонок (ранее всегда NULL)
• Variant type: semi-structured данные (JSON-like) с типизацией

Apache Hudi: Ограниченная эволюция

Hudi исторически фокусировался на upsert/incremental processing, а не на schema evolution. Возможности эволюции ограничены:

Apache Paimon: Streaming-first эволюция

Apache Paimon — table format, оптимизированный для streaming use cases (Flink-native).

Schema evolution в Paimon:

Paimon использует schema ID для версионирования — каждый data file ссылается на конкретную версию schema. При чтении файлов с другой schema version — Paimon выполняет schema reconciliation (аналогично Avro ResolvingDecoder, но на уровне колоночных файлов).

Streaming-first особенность: Paimon поддерживает schema evolution в streaming write через Flink CDC:

-- Flink SQL: автоматическая синхронизация schema из MySQL CDC
CREATE TABLE paimon_users WITH (
 'merge-engine' = 'deduplicate'
) AS TABLE mysql_users;
-- Если в MySQL добавляется колонка — Paimon автоматически обновляет schema

Сравнительная матрица: Table Format Evolution

Ключевой архитектурный паттерн: ID vs Position vs Name

Различия в schema evolution между table formats сводятся к фундаментальному вопросу: как формат идентифицирует колонки.

Этот паттерн мы уже видели в уроке 01: Avro использует имена (+ aliases), Protobuf — числовые ID, Parquet/ORC — позиции. Table formats повторяют ту же историю на уровне metadata layer.

Практические рекомендации

Для новых проектов

1. Если schema evolution критична (аналитический data lake с частыми изменениями) → Iceberg. ID-based tracking + partition evolution = минимальные ограничения.
2. Если Spark/Databricks — основной движок → Delta Lake. Включите column mapping mode (name) сразу при создании таблицы — переключить позже нельзя без миграции.
3. Если streaming-first (Flink CDC) → Paimon. Автоматическая синхронизация schema из upstream sources.
4. Если уже на Hudi → планируйте schema changes как add-only. Rename/drop — через создание view или materialized table.

Миграция между форматами

Delta Lake, Iceberg и Hudi хранят данные в одних и тех же Parquet файлах. Разница — в metadata. Это позволяет:

• UniForm (Delta Lake): генерирует Iceberg metadata поверх Delta Parquet файлов
• Apache XTable (incubating): конвертирует metadata между Delta ↔ Iceberg ↔ Hudi
• Одни и те же Parquet файлы — три разных metadata view

Итоги

Schema evolution в table formats — это metadata layer поверх Parquet/ORC, который снимает ограничения нижележащих форматов:

• Iceberg — наиболее мощный: ID-based tracking, полный набор операций (add/drop/rename/reorder), partition evolution, spec v3
• Delta Lake — schema enforcement по умолчанию (защита от случайных изменений) + evolution через mergeSchema/column mapping, type widening
• Hudi — минимальная эволюция (add columns), фокус на upsert/incremental, не на schema changes
• Paimon — streaming-first: автоматическая синхронизация schema из CDC sources, add/drop/rename

Ключевой architectural insight: способ идентификации колонок (ID vs name vs position) определяет все возможности эволюции — как на уровне serialization formats, так и на уровне table formats.