✨ Пётр Гуринов и Сергей Куприков: Опыт внедрения Lakehouse в компании Лемана Тех. Ссылка на выступление: https://www.youtube.com/watch?v=r70FGQWdEvc&t=950s Сложность: 2/3 (Сложного кода в докладе нет, но требуется понимание архитектуры DWH/DLH) Кому будет интересно: - Вообще всем, кто как-то связан с построением хранилищ данных. DLH это новая реальность, в которую обязательно нужно погрузиться. --- Компания с масштабной инфраструктурой (600 TB в DWH, 1.5 TB в S3) перешла на Lakehouse-архитектуру. Рассказываем, как, зачем и с какими проблемами столкнулись. --- 🔍 Проблемы старой архитектуры - Greenplum (Shared Nothing): - Данные невозможно оторвать от compute - Ограниченная масштабируемость - Высокие затраты на хранение - Pipeline до внедрения DLH: ```Источники собираются в Kafka. Flink вычитывает данные, складывает их в S3 в формате avro (слой raw). Далее Spark трансфармирует данные в parquet, складывает данные в S3 (слой ods). Оттуда данные попадают в GP, который является единой точкой входа всех сотрудников компании (любой сотрудник магазина может запросить доступ к DWH). ``` --- 🚀 Переход на Lakehouse Требования к новой платформе: ✔️ Open Source ✔️ Разделение compute/storage ✔️ Cloud-ready/cloud agnostic ✔️ Низкий порог входа Выбранный стек: - Вычисления: Trino (поддержка ANSI SQL, активное комьюнити, лицензирование и гетерогенность источников) - Табличный формат: Iceberg (выбирали между Iceberg/Hudi/Delta Lake) - Хранение: S3 - Метаданные: HMS (планы на переход к Nessie для branch-поддержки) --- ⚙️ Реализация: - Кластеры Trino: - Ad hoc (пользователи/BI) - ETL (тех.учетки) - DQ (Data Quality) Интеграция: - Аутентификация через Keycloak + AD - Управление доступом: file-based ACL --- 🛠 Проблемы и решения Ограничения технологий: - Нет коннектора Trino → Greenplum (ходят через Master) - Iceberg: нет мультитранзакций, сложности с типами данных - Trino: нет временных таблиц, legacy spill-файлы 🛠 Мониторинг: - Мониторинг производительности с использованием Prometheus и Grafana. JMX Exporter снимает метрики и преобразует в формат Prometheus. Prometheus operator пушит их в VictoriaMetrics, которые визуализируются в Grafana. -Мониторинг пользовательских запросов из коробки имеет критическое ограничение: после рестарта вся история удаляется. Реализовали мониторинг с использованием Kafka event listener, оттуда пишем в CH и визуализируем в Grafana. Дашборды выложены в opensource: https://github.com/rugratko/grafana-trino-overview-preset - Кастомный сбор метрик запросов через Kafka → ClickHouse 🛠 Управление инфраструктурой: - GitOps + ArgoCD + Vault - Автоматические откаты --- 📊 Результаты ✅ Экономия: - Хранение дешевле в 10+ раз - Быстрое масштабирование в Kubernetes - Независимое масштабирование и отсутствие необходимости резервировать место заранее. ✅ Производительность: - Ускорение расчетов витрин - Легкий переход запросов с GP на Trino - Аналитики получают дополнительную точку входа для доступа к данным - Разные вычислительные движки могут использовать одни и те же данные. --- 🔮 Планы - Замена HMS на Nessie - Продуктивизация SCD2-таблиц - Автоскейлинг Trino на основе метрик - Копирование Iceberg-таблиц в Greenplum - Обслуживание (maintenance) Iceberg таблиц. Пока не актуально, так как сейчас данные append only --- 💡 Вывод: Lakehouse на базе Trino + Iceberg — гибкая альтернатива классическому DWH. Главные преимущества: разделение compute/storage, масштабируемость и экономия.