Внедрение архитектуры Lakehouse в компании из сегмента retail DIY: практический кейс
Архитектура Lakehouse становится всё более востребованной в крупном бизнесе, где требуется масштабируемость, экономичное хранение, открытая экосистема и независимость вычислений от данных. Рассматриваем кейс перехода крупной розничной сети DIY-формата к архитектуре Lakehouse. В статье подробно описаны проблемы старого решения, выбранный стек технологий, этапы реализации, организационные и технические решения, а также достигнутые результаты и планы развития.
Исходная инфраструктура и мотивация к изменениям
Компания эксплуатировала классическое хранилище данных на базе Greenplum с объемом более 600 ТБ, при этом дополнительный слой хранения составлял 1.5 ТБ в S3. Основные источники данных поступали в Kafka, где Flink обрабатывал потоковые события и сохранял их в S3 в формате Avro (слой raw). Далее Spark перекладывал данные в Parquet (слой ODS), откуда данные попадали в Greenplum. Greenplum выступал в роли централизованного DWH и был единственной точкой входа для всех аналитиков и сотрудников магазинов, имевших доступ к отчетности.
Основные ограничения старой архитектуры
- Связка хранения и вычислений в Greenplum ограничивала гибкость и масштабируемость.
- Требовалось заранее резервировать ресурсы, что приводило к перерасходу.
- Стоимость хранения была высокой.
- Любые изменения инфраструктуры затрагивали цепочку целиком.
- Масштабирование было ограничено shared-nothing архитектурой.
Цели и требования к новой платформе
Перед началом проектирования новой архитектуры были сформулированы следующие требования:
- Использование open source-решений без вендор-локов.
- Полное разделение хранения и вычислений.
- Поддержка облачной инфраструктуры с возможностью переноса между провайдерами.
- Низкий порог входа — необходима поддержка SQL и совместимость с BI-средами.
Выбранная архитектура
На основании сравнительного анализа технологий был выбран следующий стек:
- Trino в роли вычислительного движка. Обеспечивает поддержку ANSI SQL, активное сообщество, поддержку многих источников и высокую гибкость лицензирования.
- Apache Iceberg в качестве табличного формата. Рассматривались также Apache Hudi и Delta Lake, но Iceberg показал лучшую зрелость и стабильность.
- S3 в качестве слоя хранения данных.
- Hive Metastore (HMS) — в качестве каталога метаданных. Планируется миграция на Nessie для поддержки версионности и параллельной работы с ветками.
Организация вычислений
Для изоляции нагрузки и повышения стабильности архитектура Trino-кластеров была разделена на три сегмента:
- Ad hoc кластер — обслуживает BI-пользователей, интерактивные запросы и аналитику.
- ETL кластер — обрабатывает загрузки и обновление слоёв.
- DQ кластер — выполняет проверки качества данных, SLA и технические метрики.
Интеграция и доступ
- Аутентификация реализована через Keycloak в связке с Active Directory.
- Авторизация организована на базе file-based ACL.
- Права доступа и конфигурации кластеров управляются в рамках GitOps-подхода через ArgoCD и Vault.
Источник данных и ingestion
Сбор данных организован централизованно: за подключение источников отвечает сервисная служба, которая настраивает Debezium. Далее данные поступают в Kafka и автоматически обрабатываются платформой данных, попадая в слой raw в S3. Пользовательские команды не взаимодействуют напрямую с источниками.
Основные технологические ограничения и решения
Ограничения Trino
- Отсутствие временных таблиц, что осложняет перенос некоторых SQL-скриптов.
- Устаревшая реализация spill-файлов и ограниченные возможности конфигурации.
- Отсутствие прямого коннектора к Greenplum (доступ через master).
Проблемы с Iceberg
- Отсутствие поддержки мульти-транзакционности (неактуально для append-only сценариев).
- Ограничения на типы данных (особенно nullable списки и сложные структуры).
- Не используется сортировка, индексация — применяются только партиционирование и бакетирование.
Работа с S3
- Проблемы с большим количеством мелких файлов.
- Обслуживание и компактизация пока выполняются вручную.
- Планируется автоматизация процессов обслуживания и оптимизации Iceberg-таблиц.
Мониторинг и эксплуатация
Мониторинг производительности
- Метрики собираются с помощью JMX Exporter и передаются в Prometheus.
- Используется Prometheus Operator с выводом данных в VictoriaMetrics.
- Для визуализации используется Grafana.
- Готовые дашборды доступны в открытом доступе: grafana-trino-overview-preset
Мониторинг пользовательских запросов
- Базовая реализация Trino теряет историю при перезапуске.
- Решение — реализация Kafka Event Listener, который отслеживает события и пишет их в ClickHouse.
- Графики визуализируются в Grafana.
Управление инфраструктурой
Полный переход на GitOps обеспечен за счет:
- ArgoCD для автоматизированного развертывания кластеров и компонентов.
- Vault для управления секретами и переменными окружения.
- CI/CD пайплайны реализованы для автоматических откатов и обновлений кластеров.
Экономический и технический эффект
Экономия
- Хранение в S3 дешевле более чем в 10 раз по сравнению с Greenplum.
- Нет необходимости резервировать ресурсы заранее.
- Обеспечена независимость масштабирования хранения и вычислений.
- Поддержка Kubernetes упростила масштабирование и отказоустойчивость.
Производительность
- Обновление витрин и ETL-процессов ускорилось.
- BI-аналитики получили альтернативную точку доступа к данным.
- Запросы легко переносились с Greenplum на Trino благодаря поддержке ANSI SQL.
- Возможность использования одних и тех же данных несколькими вычислительными движками.
Планируемые шаги по развитию
- Переход с HMS на Nessie для поддержки управления версиями таблиц.
- Продуктивное внедрение SCD2-таблиц на базе Iceberg.
- Настройка автоскейлинга Trino-кластеров по метрикам.
- Автоматическое копирование данных из Iceberg в Greenplum для обратной совместимости.
- Внедрение процедур обслуживания Iceberg-таблиц (compaction, rewrite, vacuum).
Ответы на часто задаваемые вопросы
- Почему используется Avro на слое raw? — Команда имела опыт работы с этим форматом, он удовлетворял всем требованиям.
- Почему не используются индексы? — Достаточно партиционирования и бакетирования, сортировка эффекта не дала.
- Как обеспечивается отказоустойчивость? — На текущий момент все выполняется вручную, но координатор Trino еще ни разу не выходил из строя.
- Почему выбран HMS? — Требовалась совместимость с паркетом и Iceberg на старте, HMS закрыл задачу.
- Используется ли FTE (fault-tolerant execution)? — Не используется из-за потери в производительности. Предпочтение отдано ручному перезапуску задач.
- Как решается проблема с мелкими файлами в S3? — Пока вручную, планируется автоматизация.
- Рассматривался ли Paimon как каталог? — Пока нет, стратегия — итеративный подход к смене каталога.
Внедрение архитектуры Lakehouse на базе Trino, Iceberg и S3 продемонстрировало свою состоятельность в условиях крупной розничной сети с высоким объемом данных и разнообразием бизнес-задач. Ключевые преимущества:
- Отделение хранения от вычислений и, как следствие, гибкое масштабирование.
- Существенное снижение затрат на инфраструктуру.
- Универсальный доступ к данным для BI и аналитики.
- Поддержка open source-экосистемы и отказ от вендор-локов.
Проект доказал применимость архитектуры Lakehouse для компаний с высокой нагрузкой, разветвленной структурой и требованиями к гибкости данных. Полученные результаты, архитектурные решения и разработанные практики могут быть использованы в аналогичных проектах в ритейле, e-commerce, банковской сфере и промышленности.
