Миграция с монолитного Greenplum на Lakehouse-архитектуру с Iceberg и S3: опыт страховой компании

Многие крупные компании, особенно в финансовом и страховом секторе, пришли к точке, когда классическая архитектура корпоративного хранилища данных (DWH) перестаёт удовлетворять требованиям бизнеса. Рост объёмов данных, усложнение аналитических сценариев, появление новых источников и потребность в более гибком масштабировании делают монолитные системы узким местом.

В нашем случае речь идёт о страховой компании, которая за четыре года эксплуатации накопила 50–70 ТБ данных в Greenplum, обрабатывала потоки из MongoDB, Kafka и классических реляционных СУБД, но столкнулась с типичными ограничениями монолитного подхода.

Проблемы старой системы (Greenplum DWH)

1. Высокая стоимость владения
Greenplum — мощная MPP-платформа, но лицензии и аппаратное обеспечение требовали значительных вложений. Дополнительные расходы появлялись при расширении кластера.

2. Ограниченное масштабирование
Масштабирование «вширь» было ограничено как технически (увеличение количества сегментов и перераспределение данных), так и экономически.

3. Ограниченная гибкость для аналитиков
Работа с неструктурированными источниками (JSON из MongoDB, потоковые события из Kafka) требовала промежуточных ETL-преобразований, замедляя доставку данных в витрины.

4. Гетерогенная среда
В одном DWH приходилось хранить как структурированные таблицы, так и полуструктурированные документы. Конфликты типов и сложные конверсии приводили к росту ETL-кода.

Выбор новой архитектуры

После анализа было определено несколько ключевых требований:

Разделение storage и compute для независимого масштабирования.
Open Source стек для снижения зависимости от вендоров.
Снижение TCO с полной окупаемостью проекта к 2025 году.
Поддержка гибридных сценариев: возможность работы с данными как в классическом BI, так и в data science.

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

Хранилище: S3 (Яндекс.Облако) + Apache Iceberg
Вычисления: Trino (основной), Greenplum (для легаси-витрин)
Оркестрация: Dagster + dbt
Каталог метаданных: OpenMetadata

Реализация миграции

1. Перенос данных

Переезд выполнялся по схеме:

Полная загрузка исторических данных через Airflow.
Самая крупная таблица — 60 ГБ, переносилась батчами.
Основной объём — инкрементально (T+1) через DAG'и Dagster.

Особенности:

Iceberg позволил хранить данные в Parquet, что дало прирост в скорости выборки на 15–20% по сравнению с Greenplum.
Исторические срезы: еженедельные снапшоты и архив глубиной 6 месяцев.

2. Модель слоёв

Слои данных были организованы по классической схеме:

Raw → ODS → DDS → Витрины

Raw — минимальные преобразования, хранение в исходном формате.
ODS — очищенные и нормализованные данные.
DDS — агрегаты и бизнес-логика.
Витрины — подготовленные наборы для BI.

3. Интеграции

MongoDB: CDC через Debezium → Kafka → Greenplum (PXF).
Trino: нативные коннекторы к S3 и JDBC-источникам.

Проблемы и их решения

1. Деградация JOIN-ов
В не-OLAP сценариях (много мелких запросов) время выполнения увеличивалось до 27%.
Решение: для мелких джойнов — материализованные представления в Iceberg с частичной денормализацией.

2. Кастомные типы данных
В Greenplum существовали собственные типы (например, money, interval), которые не маппились напрямую в Parquet.
Решение: преобразование на ETL-уровне в универсальные типы (decimal, string).

3. Хранимые процедуры
Вся логика витрин на PL/pgSQL стала непереносимой.
Решение: переписывание витрин на dbt-моделях, часть логики — в Python UDF для Trino.

4. Безопасность
Iceberg сам по себе не управляет доступом, поэтому контроль был реализован через Trino + Keycloak с политиками на уровне каталогов и таблиц.

Результаты

Экономия: хранение в S3 оказалось в 10+ раз дешевле, чем в Greenplum.
Гибкость: Trino и Greenplum одновременно работают с одними и теми же наборами данных.
Масштабируемость: вычислительные кластеры Trino в Kubernetes можно поднимать под конкретную нагрузку.

Планы развития

Переход с Hive Metastore на Project Nessie для поддержки ветвления данных.
Постепенный отказ от 3NF в пользу Data Vault.
Автоматическое масштабирование Trino по метрикам нагрузки.

Часто задаваемые вопросы

Q: Как настраивали информационную безопасность?
A: На уровне Trino с Keycloak и политиками доступа, плюс IAM-роли в S3.

Q: Как решали проблему несовместимых типов?
A: Преобразования на ETL-уровне, MongoDB оставили в легаси-зоне.

Q: Почему выбрали Parquet, а не ORC?
A: В тестах Parquet показал лучшее время чтения на наших типах запросов.

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

Ошибки, которых стоит избежать

Неполная инвентаризация хранимой логики — перенос процедур и функций может занять больше времени, чем сам перенос данных.
Слепое копирование партиционирования из старой системы — Iceberg имеет свои оптимальные стратегии.
Отсутствие мониторинга метаданных — без него Iceberg-таблицы могут быстро «разрастись» в количестве файлов.

Рекомендации

Перед миграцией провести пилот на одном бизнес-домене, чтобы отработать пайплайны.
Не переносить «мусорные» данные — миграция хороший повод навести порядок.
Инвестировать время в автоматизацию CI/CD для моделей dbt.

1. Архитектурная схема Lakehouse-стека

                 Источники данных

 ┌───────────────────────────────────────────────────────┐
 │  MongoDB  │  Kafka  │  PostgreSQL / Oracle  │  API    │
 └───────────┴─────────┴───────────────────────┴─────────┘
                         │
                         ▼
             (CDC / Batch / API загрузка)
                         │
                ┌───────────────────┐
                │     Оркестрация   │
                │ Dagster + dbt     │
                └───────────────────┘
                         │
                         ▼
                ┌───────────────────┐
                │       RAW         │  - исходные данные
                │  S3 + Iceberg     │
                └───────────────────┘
                         │
                         ▼
                ┌───────────────────┐
                │       ODS         │  - очищенные/нормализованные
                │  S3 + Iceberg     │
                └───────────────────┘
                         │
                         ▼
                ┌───────────────────┐
                │       DDS         │  - бизнес-агрегаты
                │  S3 + Iceberg     │
                └───────────────────┘
                         │
                         ▼
                ┌───────────────────┐
                │     Витрины       │  - BI-ready data
                │  S3 + Iceberg     │
                └───────────────────┘
                         │
          ┌────────────────────────────────────┐
          │      Движки вычислений             │
          │  Trino (ad-hoc / BI)               │
          │  Greenplum (legacy OLAP)           │
          └────────────────────────────────────┘
                         │
                         ▼
        ┌──────────────────────────────────────────┐
        │                 BI / ML                  │
        │ Power BI │ Superset │ Jupyter │ AutoML   │
        └──────────────────────────────────────────┘

Ключевые моменты:

Iceberg хранит данные в S3 в формате Parquet, поддерживая снапшоты и инкрементальные апдейты.
Trino — основной compute-движок для аналитических запросов, работает через коннектор Iceberg напрямую с S3.
Greenplum остаётся как временный «мост» для старых витрин и привычных отчётов.
Dagster управляет пайплайнами, dbt отвечает за SQL-трансформации.
OpenMetadata регистрирует схемы, lineage, владельцев данных.

2. Сравнение производительности: Trino+Iceberg vs Greenplum

Методология тестирования

Для честного сравнения использовали:

Набор тестовых запросов: mix OLAP и OLTP-подобных (50/50).
Датасеты: 1, 5, 10 и 50 ТБ (скейлинг данных методом data generator + исторические снапшоты).
Запросы:
- сложные агрегаты с многоуровневым GROUP BY
- джойны на 2–4 таблицы
- window-функции (row_number, lag)
- выборка по партициям + фильтры
Среда:
Greenplum 6.21 на bare metal (20 сегментов, 512 ГБ RAM)
Trino 441 на Kubernetes (8 worker-нод, по 64 ГБ RAM)

Результаты теста

Тип запроса	Greenplum (с)	Trino+Iceberg (с)	Комментарий
Простой агрегат (1ТБ)	42	35	Trino быстрее на 17% за счёт колоночного формата Parquet
JOIN 2x1B rows (1ТБ)	61	52	Выигрыш Trino в IO и планировщике
JOIN 4x1B rows (10ТБ)	310	360	GP выигрывает за счёт MPP-архитектуры в heavy join
Window + фильтр (1ТБ)	95	81	Trino выигрывает на партиционированных данных
Random access (OLTP-like)	0.05	0.12	GP быстрее из-за row-based хранения
Массовое чтение без фильтров	540	480	Trino быстрее при полном скане

Вывод:

Trino+Iceberg выигрывает на аналитических батчевых запросах с предикатами и агрегациями.
Greenplum всё ещё сильнее в очень тяжёлых джойнах и точечных OLTP-запросах.
В реальной эксплуатации бизнес-отчёты (витрины DDS) стали выполняться на 20–40% быстрее.

3. Практический опыт и советы

Не копировать физическую модель из Greenplum в Iceberg
Iceberg оптимальнее при партиционировании по датам/категориям, а не по surrogate-ключам.
Следить за количеством мелких файлов
Trino чувствителен к большому числу мелких Parquet-файлов. Помогает компакция в ETL.
Кеширование в Trino
Для часто запрашиваемых витрин стоит включать result caching или precomputed aggregates.
Iceberg snapshots housekeeping
Без регулярного expire_snapshots и remove_orphan_files S3-стоимость начнёт расти.
Метрики в Kubernetes
Автоскейлинг Trino лучше настраивать по CPU+IO wait, а не только по запросам.