Летом в рамках стрима «Разговоры на Архитекторском» состоялась беседа с Вадимом Беловым, руководителем системной разработки больших данных в X5. Основной темой стали эволюция платформ данных, переход от классических архитектур к концепции `Lakehouse` и практические аспекты такой миграции. Ниже представлен синтез ключевых идей и выводов этой встречи.

https://t.me/analyticsfromzero/201

1. Предел «классической» архитектуры

В начале пути многие компании, включая X5, строили свои платформы на стеке проверенных, но разрозненных технологий: `Hadoop` для хранения больших объемов данных, `Greenplum` как мощная MPP-база для аналитики и `ClickHouse` для быстрых витрин. Такая архитектура работала, но со временем достигла своего предела.

По словам Вадима, точка невозврата наступает не столько из-за роста объема данных, сколько из-за роста разнообразия нагрузок и требований бизнеса.

Основные болевые точки «классического зоопарка»:

• Сложность и дублирование: Данные приходилось постоянно перемещать между системами. Например, выгрузить данные в `Hadoop`, оттуда переложить в `Greenplum` для расчетов, а затем, возможно, вернуть обратно для ML-моделей на `Spark`. Каждое такое перемещение создает `staging`-слои и дубликаты данных.
• Высокий TCO (Total Cost of Ownership): Поддержка нескольких разнородных систем с разными компетенциями, процессами релиза и типами оборудования обходится дорого.
• Узкие горлышки: Централизованные команды и системы не успевают отвечать на растущие запросы бизнеса, требующего большей скорости и гибкости (`time-to-market`).
• Технологические ограничения: Каждая система хороша для своей ниши, но имеет ограничения. Например, `Greenplum` — мощная реляционная СУБД, но из неё сложно отдавать данные для нереляционных задач, связанных с машинным обучением.

2. Lakehouse как эволюционное решение

Переход к `Lakehouse` — это не революция, а эволюция, попытка объединить лучшие черты двух миров:

• `Data Lake`: Дешевое хранение огромных объемов данных любого формата.
• `Data Warehouse`: Структурированность, надежность, транзакционность (`ACID`) и гарантия консистентности данных.

Ключевым моментом, сделавшим эту концепцию возможной, стало появление открытых транзакционных форматов таблиц, таких как `Apache Iceberg` и `Delta Lake`. Именно они позволили реализовать `ACID`-транзакции поверх файловых хранилищ вроде `S3`.

Центральная архитектурная идея `Lakehouse` — разделение хранения (`storage`) и вычислений (`compute`). Это дает модульность и гибкость: можно независимо масштабировать хранилище и вычислительные ресурсы, а также подменять компоненты стека без кардинальной перестройки всей системы.

3. Преимущества и новые возможности

Архитектура `Lakehouse` открывает ряд значительных преимуществ:

• Унификация и сокращение дублирования: Данные хранятся в одном месте в открытом формате, а различные движки (`Trino`, `Spark` и др.) могут работать с ними напрямую, без необходимости копирования. Это снижает затраты на хранение и упрощает пайплайны.
• Упрощение разработки: Благодаря поддержке `ACID` и возможности выполнять `UPDATE`/`DELETE`/`MERGE` операции, дата-инженеры могут работать с `Lakehouse` как с обычной реляционной базой данных, что снижает порог входа и упрощает поддержку.
• Гибкость и снижение рисков: Модульная архитектура позволяет легко заменять компоненты. Если вычислительный движок перестал устраивать, его можно поменять, не затрагивая данные. Это снижает зависимость от одного вендора или технологии.
• Новые бизнес-сценарии: Появляется возможность строить аналитические контуры, близкие к реальному времени. Используя технологии `CDC` (Change Data Capture), например, с помощью `Debezium`, можно с секундной задержкой реплицировать изменения из операционных баз прямо в `Lakehouse` и немедленно делать их доступными для аналитики.

4. Практика реализации и вызовы

В X5 в качестве основного SQL-движка для `Lakehouse` выбрали `Trino`, а для сложных обработок — `Spark`. Форматом хранения стал `Apache Iceberg`. Вадим отметил, что перенос логики с `Greenplum` на `Trino` оказался относительно простым, так как оба решения являются MPP-системами. Продвинутые возможности современных движков, такие как динамические фильтры в `Trino`, позволяют значительно ускорять запросы за счет сокращения объема данных, читаемых из хранилища cedrusdata.ru, habr.com.

Однако переход не лишен сложностей:

• Data Governance:** Как управлять правами доступа, когда к одним и тем же данным могут подключаться разные движки (`Trino`, `Spark`)? Классические инструменты, вроде `Ranger`, не всегда подходят. Решением видится развитие «умных» каталогов данных (например, `Gravitino`), которые станут единой точкой для управления политиками безопасности и метаданными. (пс: хватит уже откапывать этот Ranger \ ставьте сразу OPAL :) )
• Производительность:** Критически важными становятся производительность сети между `storage` и `compute`, а также возможности самого объектного хранилища (`S3-compatible`) выдерживать высокую нагрузку на чтение метаданных и мелких файлов.
• Зрелость Open Source:** Многие компоненты активно развиваются, что означает частые обновления, новые возможности, но и потенциальные баги. Это требует выстраивания собственных процессов R&D и тщательного тестирования.

5. Советы для бизнеса и архитекторов

Для тех, кто рассматривает переход на `Lakehouse`, Вадим Белов дал несколько ключевых советов:

1. Проводите R&D: Не принимайте решение на основе маркетинговых материалов. Проведите исследование на собственных данных и задачах.
2. Начинайте с пилота: Используйте облачные платформы для быстрого развертывания пилотного проекта. Это позволит оценить технологию, посчитать экономику и выключить кластер, когда он не нужен, сэкономив деньги.
3. Не трогайте `business-critical`: Не начинайте миграцию с самых критичных систем. Выберите область, где есть право на ошибку, чтобы команда могла адаптироваться к новым технологиям.
4. Обосновывайте деньгами: Для бизнеса главным аргументом будет экономическая эффективность: снижение TCO за счет унификации стека, отсутствия дублирования данных и более быстрого `time-to-market` для новых продуктов.

Итог встречи

Концепция `Lakehouse` — это не просто очередная модная технология, а логичный эволюционный шаг в развитии платформ данных. Она отвечает на главные вызовы современных DWH: разнообразие нагрузок, требование к скорости и высокую стоимость поддержки разрозненных систем.

Переход на `Lakehouse` позволяет создать более гибкую, масштабируемую и экономически эффективную архитектуру за счет разделения хранения и вычислений, а также использования открытых форматов. Однако этот путь требует зрелого подхода, инвестиций в R&D и решения новых вызовов, в первую очередь в области `Data Governance`.

Взгляд в будущее направлен на `Streaming Lakehouse`, где граница между batch- и stream-обработкой стирается, и на развитие «умных» каталогов данных, которые станут мозгом всей платформы, управляя не только метаданными, но и безопасностью, качеством и контрактами данных.

О некоторых Streaming Хаусах я уже писал ранее.

Скоро будет еще встреча

13 ноября проведут вторую серию «Разговоров на архитекторском» и в этот раз коснемся индустриальных ML платформ.

Эксперт – руководитель разработки и ML OPS в крупной технологичной компании, которую вы все знаете.

Темы:

1️⃣Платформа инференса в 2025 году. Как построить и как грамотно утилизировать большой парк современных GPU
2️⃣Классический ML и трансформерный ИИ. Может ли существовать одно без другого.
3️⃣Если ты стажер или джун и хочешь в ML, на что тебе стоит обратить внимание и что изучить

@analyticsfromzero