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

✨ Валентин Пановский — Миграция на 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 — сложный, но окупаемый процесс. Главные плюсы: гибкость, экономия и возможность использовать лучшие инструменты для разных задач.