Архитектор Данных

✨ Пётр Гуринов и Сергей Куприков: Опыт внедрения 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, масштабируемость и экономия.

ArenaDay 2025

22 апреля доклад прочитать не получилось из-за срочных встреч. Лучшая в мире команда архитекторов данных подхватила и доклад, и непростую технологическую идею облачного DWH DR!

Основные тезисы доклада.

📈 По мере роста дата офиса ценность данных для бизнеса неизбежно растет. Растут и потери от простоя хранилища данных.

🔬 Greenplum и ArenadataDB - отличная база данных, терпимая ко многим типам отказа оборудования. Но это все еще одна СУБД, опирающаяся на один ЦОД. КХД все еще подверженно отказам.

☁️ Облако дает несколько инструментов для отказоустойчивости.

1️⃣ Первое, это бекап в s3. В инструмент Arenadata Backup Manager можно просто прописать эндпоинты и ключи облачного s3, и это будет работать.
2️⃣ Второе интереснее - это возможность поднять в облаке горячий резерв кластер. Причем, облако обладает гибким подходом к инфраструктуре и умеет на лету по API или по Terraform менять состав инфраструктуры. Одним небольшим скриптом можно массово растить или схлопывать в размере Виртуальные Машины.

Мы можем при основном кластере в 1000 ядер гринплама поднять в облаке DR площадку на 100 ядер и применять в нее все изменения с основного кластера раз в день или раз в час.

💎 В критическом случае отказа основного кластера или ЦОД мы приходим в облачный кластер и командуем ему расшириться до 1000 ядер для принятия нагрузки.
Платим же все это время за фактически потребленные ядро-часы.

🔬 Так с помощью технологий можно значительно повысить отказоустойчивость данных без кратного раздувания бюджета.

Выступаю на Arenaday 2025

Ровно через неделю, 22 апреля состоится большая ежегодная конференция Аренадата - ArenaDay 2025.

Совместно с архитекторами Аренадаты мы подготовили доклад об эффективном обеспечении отказоустойчивости кластеров ArenaDB.

Не так сложно организовать полноценную вторую площадку данных, имея x2-x3 бюджета основной. Но мы пошли дальше и предлагаем решение, которое использует механизмы облака для сокращения бюджета на DR. Причем даже этот резерв не будет бесполезно «греть воздух», а может быть переиспользован для задач аналитики и разработки.

Какие темы раскроем
⁃ Как перестать бояться отказов и начать использовать данные в реальных бизнес-процессах. И причем тут резервная площадка.
⁃ Что может предложить облако для отказоустойчивости данных
⁃ Как организовать ADB DR без кратного роста расходов на инфраструктуру данных
⁃ Как автоматизировать переключение между площадками с помощью сервисов облака
⁃ Как составить детальный DR-план, организовать DR-учения и не бояться отказов
⁃ Как переиспользовать вторую площадку для других задач: Dev/Test окружений, песочниц для разработчиков, сервинга данных для ML и LLM.

No system is safe. Даже самые крутые ЦОДы от ведущих мировых и российских компаний иногда падают. Даже самые безопасные системы ловят вирусов-шифровальщиков.

В мою бытность Head of Analytics меня не один и не два раза выручал тот факт, что у меня есть логический бекап данных в какой-то другой системе. Иметь рабочие механизмы данных в ситуации когда вся инфраструктура вашей компании испытывает проблемы - это гигантский бонус в вашу карму. Вы надежные, вам можно доверить серьезные бизнес-процессы.

22 апреля, вторник, Секция «Гибридное хранилище», 16:30

На день космонавтики

64 года назад мы достигли многого. Мы вывели человека за пределы его колыбели и нюхнули свободы взрослого мира.

Сейчас многие вслед за Илоном нашим Маском мыслями обращаются к Марсу. И воображают что слетать туда все равно что в соседний город. Но если задуматься о масштабах, то все окажется совсем по-другому.

Упражнение с глобусом

Если взять в руки школьный глобус с диаметром 30 см, на какой высоте летал Гагарин и какая высота орбиты МКС? 1 сантиметр. Это уже для нас Космос!

А Луна? Луна на расстоянии 9 метров. Это уже соседняя квартира.

А Марс? Порядка 5 километров! 3 автобусные остановки или час пешком.

Ближайшая потенциально обитаемая планета? Очень повезло, она в ближайшей же звездной системе - это Проксима Центавра B, на ней может быть жидкая вода. Расстояние? Да забудьте - там 900 тысяч километров!

Теперь представьте поход на 23 раза обогнуть экватор в то время, как мы нормально освоили только 1 сантиметр этого пространства! Эволюционно мы на уровне инфузорий, которые и путешествуют за свою жизнь на несколько сантиметров. Теперь Илон предлагает нам приложить титанические усилия для эволюции, ну, в простейшую гидру, которая может теоретически утопать на 5 км от места своего рождения и выжить. А до звезд все еще нужен разум и реактивный самолет.

Человеку трудно представить масштабы этих расстояний и стоящих задач.

Но. Давайте в этот день праздновать. У нас есть важное отличие от инфузорий, оно в том, что мы способны осмыслить внутри себя самый дальний поход. Мы способны измерить, оценить, подсчитать, составить план. Мы даже способны вообразить задачи на сотни поколений вперед, где давно уже не будет никаких нас.

Люди на каноэ

Когда-то на берегу Тихого океана люди спустили на воду каноэ из тростника и поплыли в неизвестность. Они не знали, сколько плыть, не знали, есть ли там вообще пригодная земля. Неизвестно, сколько их сгинуло. Но известно, что все, даже самые удаленные, острова в океане на пол-Глобуса оказались заселены.

У нас огромное преимущество перед людьми на каноэ. Мы точно знаем, куда и сколько нам лететь. Мы знаем, что именно там находится. Мы в куда более лучшем положении чем люди на каноэ.

Почему мы хотим покорить Космос? Да потому что он, Космос, есть!

Подлинная революция

Пока мы тут про лейкхаусы, в российском ИТ случилась настоящая революция.

1С научился хранить файлы в S3.

Отраслевые тесты для OLAP

Коллеги, поделитесь, какие вы используете тесты для изменения перформанса OLAP? Есть ли что-то кроме TPC-DS?

Есть у меня мой "авторский" на данных блокчейна Ethereum. Но к нему надо больше запросов написать как минимум и какой-то раннер прикрутить еще. Зато там данных много: Ehereum это около 6 ТБ данных транзакций, а Polygon 20 уже.

Хозяйке на заметку

Всем привет! 24 апреля в Москве в офисе Лемана Тех пройдет очередной митап по технологиям Trino и Apache Iceberg! Также будет доступна онлайн-трансляция.

В программе:
- Доклад от Лемана Тех про миграцию на Trino
- Доклад от Азбуки Вкуса про использование каталога Nessie
- Круглый стол про проблемы внедрения lakehouse с инженерами T-Банк, S7 Airlines, Лемана Тех и Кверифай Лабс

Регистрация по ссылке: https://cedrusdata.timepad.ru/event/3299844/

Хороший годный митап от коллег.

Аптаймы

Есть байка, что где-то у кого-то есть сервер с аптаймом 32 года. То есть не выключавшийся и не перезагружавшийся ни разу с 1993 года.

Интересно, есть ли ETL пайплайн, который работает ну хотя бы с 2015-го? 10 лет.

Рекорд, который я видел своими глазами, - 1100 успешных дневных запусков подряд. 3,5 года.

С огромной вероятностью, ни сервер, ни пайплайн в реальности никому не нужны и греют воздух бесполезно.

Спасибо всем, кто слушал онлайн и в зале.

Обсудим в комментах

3 сценария развития дата офиса и зачем нам DLH в каждом из них.

Все хорошо, мы развиваемся

Главный вызов - рост челенжа. Это только кажется, что при росте объема данных с 20 до 100 ТБ мы прирастаем всего в 5 раз. На самом деле у нас больше аналитиков, а это больше потоков нагрузки. Новые аналитики привносят новые датасеты, которые надо джойнить со старыми и проверять на качество.
Бизнес собрал все низковисящие фрукты и стал задавать сложные вопросы, а это рост сложности и перекрученности среднего запроса. А еще обязательно попросят обновлять данные не 1 раз в день, а максимум через 5 минут с прода они были.

Надо ли говорить, что старая MPP система может не справиться, а заливать все бюджетами может не получиться. Нужно технологическое решение, чтобы эффективно и без огромных бюджетов "съедать" все возрастающие требования.


Все плохо, мы экономим

Здесь главное - сохранить команду. Если инфраструктура не умеет сживаться в деньгах, то единственный способ сэкономить это увольнять. Не хочется стоять перед таким отсутствием выбора. Лучше если ваша система и расходы на нее умеет скалироваться вниз.


Все идет как идет

Если вы собрались на пенсию, то в целом можно ничего не делать. В другом случае риск попадания в застой существенный. И, как мы знаем, любой застой оканчивается плохо.

Плейлист хороших видео про Лейкхаусы

1.
Вебинар - Поднимаем Lakehouse на основе Trino.

Старался раскрыть мотивацию, зачем нужен лейкхаус и какая его ниша применения. Во второй половине - воркшоп, как сделать лейкхаус в облаке за 20 минут.

2.
Доклад от Димы Зуева на VK Data Meetup - Роль Trino в Т-Банке

Отличный рассказ о том, как изменилась практика применения движка Трино, с какими ограничениями столкнулась команда и как они их преодолели.

3.
Владимир Озеров о том как на самом деле работает Iceberg Catalog

Просто о сложном. Как оно работает.

Интересный вопрос от подпичика.

Мое мнение - тип хранилища не так важен. Может быть и HDFS, может быть и корпоративная SAN блочка.

Важнее - возможность разделить и независимо управлять сторажем и компьютом.

Важнее - мультисервисный доступ к данным. N кластеров Trino/Hive и K кластеров Spark могут читать и писать в один датасет. Это "лейковость".

Важнее - (квази)транзакционность и ACID-ность записи. Это "варехаусность".

Тип контейнеризации (k8s, nomad, yarn), формат данных (iceberg, parquet), набор сервисов (Trino или Impala, Kafka или Flink), тип хранилища (блочка, объектное, hdfs) - более гибкие вопросы.

Есть более удобные и менее удобные сервисы. В будущем появятся новые (замена Spark на что-то более легковесное?).

Ответ на вопрос - если в хадуп добавить S3 протокол и даже Iceberg Catalog туда посадить - нет это не будет DLH. Все равно в этой парадигме нельзя(трудно) сделать N отдельных кластеров компьюта, K отдельных метасторов и гибко ими управлять.