✨ Валентин Пановский — Миграция на Iceberg: как кролик съел зеленую сливу и не умер

Сложность: 1/3 (Интересная историческая справка в начале , нет сложного кода, в который необходимо вникнуть. Докладчик рассказывает понятным и доступным языком)

https://www.youtube.com/watch?v=YWD7WcfFfk8

Валентин Пановский поделился опытом миграции с монолитного Greenplum на разделенную Lakehouse-архитектуру с Iceberg в страховой компании.

🔍 Проблемы старой системы

Монолитная DWH на Greenplum:
Высокая стоимость (лицензии + оборудование)
Сложности с масштабированием
Ограниченная гибкость для аналитиков
Гетерогенная среда:
50-70 ТБ данных за 4 года
Разные источники: MongoDB, Kafka, классические БД
🚀 Выбор новой архитектуры

Требования:
✔️ Разделение storage/compute
✔️ Open Source решения
✔️ Снижение TCO (полная окупаемость к 2025)

Выбранный стек:

Хранение: S3 (Яндекс.Облако) + Iceberg
Compute: Trino (основной) + Greenplum (легаси)
Оркестрация: Dagster + dbt
Каталог: OpenMetadata
⚙️ Реализация

1️⃣ Миграция данных:

Таблицы переносились "в лоб" через Airflow. Самая большая таблица - до 60 ГБ).
Основной объем — инкрементально (T+1)
2️⃣ Слои данных:

Raw → ODS → DDS → Витрины
Исторические данные: срезы раз в неделю + архив (6 месяцев)
3️⃣ Интеграции:

MongoDB: CDC через Debezium → Kafka → Greenplum (PXF)
Trino: Нативные коннекторы (проще чем в GP)
🛠 Проблемы и решения

Деградация JOIN-ов: До 27% в не-OLAP сценариях
Кастомные типы данных: Обработка на ETL-уровне
Хранимые процедуры: Пришлось переписывать витрины
Безопасность: Реализована через Trino + Keycloak
📊 Результаты

✅ Экономия:

Снижение затрат на лицензии и оборудование
Хранение в 10+ раз дешевле
✅ Гибкость:

Разные движки (Trino/GP) работают с одними данными
Легкое масштабирование в Kubernetes
🔮 Планы

Переход с HMS на Nessie (branch-поддержка)
Внедрение Data Vault вместо 3NF
Автоскейлинг Trino на основе метрик

🤔 Ответы на вопросы

Q: Как настраивали ИБ?
A: Вопросы изоляции и безопасности решались на уровне trino через системы аутентификации и политик доступа.

Q: Как решали проблему неконсистентных типов?
A: На ETL-уровне. MongoDB оставили как есть (легаси)

Q: Почему Parquet, а не ORC?
A: Лучшая производительность в наших тестах

Q: FTE не пробовали?
A: Нет, проще перезапускать (макс. запрос — 45 мин)

Q: Используете ли динамическое партиционирование?
A: Пока в бэклоге

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