Типы данных и эволюция схемы

Эволюция схемы в Iceberg — одна из тех функций, после знакомства с которыми вы удивитесь, как вообще жили без неё.

Представьте сценарий: маркетологам нужно переименовать колонку. В старом мире это означало согласование простоя, координацию между командами, перезагрузку таблицы, обновление всех запросов и прочие радости. Ужас.

А если нужно удалить колонку? Внезапно вы сталкиваетесь со сдвигами позиций, сломанными запросами, костылями. Iceberg решает эти проблемы элегантно.

Типы данных в Iceberg

Прежде чем говорить об эволюции схемы, давайте посмотрим, какие типы данных вообще есть в Iceberg.

Базовые типы

Обычные подозреваемые: boolean, int, long, float, double, decimal, string, binary. Есть timestamp (без временной зоны) и timestamp with time zone. А ещё структуры, списки и карты — комплексные типы для моделирования сложных доменных объектов.

Новинки версии 3

Iceberg версии 3 принёс три важных дополнения:

1. Variant — тип для полуструктурированных данных (например, JSON‑колонка). Раньше у вас было два плохих варианта: расплющить всё в широкую таблицу с кучей NULL или хранить как строку, жертвуя производительностью запросов. Variant кодирует вложенные данные в эффективный бинарный формат, сохраняя гибкость схемы и позволяя движку push‑down фильтры.

2. Нативные геопространственные типы (geometry, geography) — для работы с полигонами, точками, линиями. Если вы не работаете с гео‑данными, можете пропустить. Если работаете — это огромное облегчение: больше никаких костыльных преобразований структур.

3. Таймстампы с наносекундной точностью — для высокочастотных событийных данных (телеметрия, устройства с GPS). Теперь можно хранить время события с точностью до наносекунды прямо в таблице.

Эти типы — не просто «приятные плюшки». Они открывают целые классы use‑cases, которые раньше были слишком сложны для реализации в data lake.

Безопасные изменения схемы

Iceberg покрывает базовые типы, но что происходит, когда схема должна измениться? Мир меняется, бизнес адаптируется — колонки переименовываются, появляются новые поля, старые исчезают, типы данных расширяются.

Поддерживаемые виды эволюции схемы в Iceberg:

• Добавление колонок
• Удаление колонок
• Переименование колонок
• Расширение типов (widening)
• Изменение порядка колонок (для читаемости)
• Эволюция комплексных типов (структур, массивов, карт)

Все эти изменения мгновенны — это всего лишь изменения метаданных. Ни один файл данных не перезаписывается.

Магия column ID

Iceberg отслеживает каждую колонку по уникальному ID, а не по позиции или имени. Это делает изменения схемы безопасными:

• Если вы удаляете колонку, ничего никуда не сдвигается.
• Если переименовываете колонку, старые файлы данных по‑прежнему читаются корректно, потому что они ссылаются на ID колонки. Вы меняете лишь метаданные — имя, соответствующее этому ID.

В результате все старые файлы данных остаются читаемыми с новой схемой. Обратная совместимость встроена на уровне базы.

Конечно, на уровне приложений что‑то может сломаться — но база данных безопасна.

Пример: таблица user events

У нас есть базовая таблица user_events с тремя колонками: event_id, user_id, event_type. Несколько недель спустя маркетинг хочет отслеживать тип устройства и версию браузера.

Добавляем колонки:

alter table user_events add colums (    device_type STRING,    browser_version STRING);

Новые записи приходят с этими колонками, старые записи получают null для новых полей. Всё работает.

Ещё через некоторое время маркетинг понимает, что browser_version не очень полезен. Удаляем колонку:

alter table user_events drop column browser_version;

Колонка исчезает из запросов, но данные остаются в хранилище. Вы можете откатиться во времени (time travel) к снапшоту, где колонка ещё существовала, и увидеть её.

Переименование колонки

Кто‑то решает, что event_type недостаточно описательно, и хочет переименовать его в action_category:

alter table user_events rename column event_type to action_category;

Ни один файл данных не тронут — только метаданные. Исторические данные остаются доступными, запросы работают.

Важный нюанс: Iceberg не координирует rollout. После переименования все запросы должны использовать новое имя сразу. Нет «периода благодати», когда работают оба имени. Вам всё равно нужно согласовать изменение с приложениями, дашбордами, ETL‑пайплайнами.

Расширение типов (widening)

Допустим, user_id был определён как INT, а теперь у вас больше 4,2 миллиарда пользователей (поздравляем!). Вы можете расширить тип до BIGINT:

alter table user_events alter column user_id type BIGINT;

Старые данные остаются на диске как 32‑битные целые, но при чтении Iceberg автоматически приводит их к более широкому типу. Безопасное расширение работает для INT → BIGINT, FLOAT → DOUBLE, увеличения точности DECIMAL.

Изменение порядка колонок

Если describe table и select * становятся неудобными из‑за накопившихся изменений схемы, вы можете переупорядочить колонки:

alter table user_events alter column action_category after event_id;

Это тоже всего лишь изменение метаданных — файлы данных не затрагиваются.

Эволюция комплексных типов

Допустим, у вас есть структура user_preferences с полями email_notifications и color_theme. Позже вы хотите добавить mobile_notifications и language_preference. Синтаксис зависит от движка, но на уровне API Iceberg это поддерживается:

alter table user_eventsadd column user_preferences.mobile_notifications BOOLEAN,add column user_preferences.language_preference STRING;

Существующие данные получат null для новых полей — всё продолжает работать.

Дисциплина и руководство (governance)

Гибкость требует дисциплины. Изменения схемы настолько просты на уровне базы, что остальную систему легко испортить.

• Тестируйте изменения перед rollout.
• Координируйтесь с командами, которые используют таблицу.
• Обновляйте пайплайны, дашборды, приложения.

Iceberg берёт на себя техническую сложность на уровне данных — вы берёте на себя руководство. Сделайте это правильно, и эволюция схемы станет одним из ваших самых мощных инструментов.

Схема — как живой организм. Она растёт, меняется, иногда теряет лишнее. Iceberg — это система контроля версий для вашей схемы, которая гарантирует, что ни одно изменение не убьёт историю.

Что дальше? Практикуемся! В следующем упражнении Эволюция схемы на практике вы примените все изученные операции к реальной таблице.

→ Вперёд к упражнению

← Назад к обновлениям и удалениям