Системы, построенные на принципах MPP-архитектуры, демонстрируют признаки исчерпания потенциала:

  • масштабирование вычислительных ресурсов и хранилищ происходит совместно, что ведет к неоптимальному росту TCO;
  • жесткая схема данных ограничивает гибкость при работе с полуструктурированной информацией;
  • время подготовки новых витрин измеряется неделями, тогда как бизнес ожидает результаты за часы.
Виталий Ранн
Руководитель направления стратегии и позиционирования Data-сервисов
Cloud.ru

Параллельно попытки решить задачу через развертывание Data Lake на базе Hadoop/HDFS часто приводят к обратному эффекту: без строгой архитектуры, метаданных и гарантий консистентности такие хранилища трансформируются в «болота данных», где сложно обеспечить качество, воспроизводимость и безопасный доступ. Возникает парадокс: DWH не справляется с разнообразием данных, а Data Lake — с надежностью и SQL-аналитикой.

Радует, что архитектура данных постоянно эволюционирует. Первые проприетарные корпоративные хранилища данных строились в 1990-х на реляционных СУБД с вертикальным масштабированием. Появление MPP-архитектур (Greenplum и Vertica) в те годы стало прорывом: shared-nothing подход позволил горизонтально масштабировать кластеры и обрабатывать терабайты структурированных данных. Однако у этой модели проявились системные ограничения.

Затем в 2010-х появление Hadoop Stack и экосистем Big Data дало ответ на вызов разнообразия данных: идея «храни всё, обрабатывай потом» подтвердила существование парадигмы ELT (extract-load-transform) и позволила накапливать сырые логи, JSON, изображения и другие неструктурированные форматы в доступном распределенном хранилище (HDFS) без предварительной обработки.

Однако на практике отсутствие транзакционности, слабые гарантии качества и сложность SQL-интерфейсов Hive привели к появлению «болот данных»: информация накапливалась и ее ценность оставалась трудноизвлекаемой. Data Lake решил проблему хранения, но не проблему надежного потребления. Такую проблему можно наблюдать и по сей день, когда из больших терабайтных хранилищ используется только 10% данных.

В 2020-х случился синтез: LakeHouse объединил надежность и SQL-стандарт DWH с гибкостью и экономичностью Data Lake. Ключевыми инновациями стали: открытые табличные форматы, такие как Parquet/Iceberg, Avro, Delta Lake, поддержка ACID-транзакций поверх объектного хранилища и разделение слоев вычислений и хранения. Эти новшества позволили работать с данными любого типа, обеспечивать консистентность и возможность независимо масштабировать ресурсы. И это не замена предыдущих подходов, а их эволюционное развитие, отвечающее требованиям 2026 года: скорость, гибкость, масштабируемость каждого слоя и, конечно же, экономическая эффективность данных.

Переход к архитектуре Data LakeHouse позволяет синтезировать сильные стороны обоих подходов. Ключевые принципы —разделение слоев вычислений и хранения, использование открытых табличных форматов Parquet/Iceberg и поддержка транзакционности поверх объектного хранилища — обеспечивают гибкость схемы, независимое масштабирование ресурсов и единый источник данных для BI, Data Science и ML-пайплайнов.

Важно отметить, что LakeHouse — это не продукт, а архитектурный паттерн. Его реализация требует взвешенного выбора компонентов с учетом экспертизы команды, требований к SLA и регуляторных ограничений. В российской практике критичными становятся пять факторов:

  • наличие локальной поддержки открытых (open source) решений;
  • совместимость с требованиями регуляторов 152-ФЗ;
  • обеспечение безопасности хранимых данных и доступов до хранилищ;
  • совместимость системы с уже принятым на рынке AI/LLM/ML-инструментарием;
  • возможность сертификации компонентов для госсектора и финтеха.

Миграция с классического DWH на LakeHouse эффективнее всего реализуется по паттерну Strangler Fig: параллельная работа legacy-системы и новой платформы, постепенный перенос витрин по доменам данных, A/B-тестирование запросов и контроль ключевых метрик (производительность, стоимость, время получения инсайта). При этом данные в открытых форматах Parquet/Iceberg остаются активом компании, что минимизирует риски зависимости от поставщика.

Для команд, которые стремятся сфокусироваться на бизнес-логике, а не на поддержке инфраструктуры, актуальны управляемые сервисы, реализующие паттерны LakeHouse. Такие решения предоставляют готовые интеграции SQL-движков, фреймворков обработки данных и объектного хранилища, обеспечивая SLA на доступность и снижая операционную нагрузку на ИТ-команды. При этом архитектура остается гибкой: данные в открытых форматах можно в любой момент перенести на другую платформу.

Отдельный блок вопросов касается интеграции AI/ML-сервисов. В текущих реалиях подготовка данных для обучения моделей, Feature Store и организация инференса в LakeHouse становятся частью единой экосистемы: один набор данных в Iceberg может использоваться для SQL-аналитики, ETL-пайплайнов и обучения моделей без копирования витрин и рассинхронизации.

Переход от монолитного DWH к Data LakeHouse — это не революция, а управляемая эволюция. Она требует дисциплины в проектировании, инвестиций в обучение команды и четкого понимания бизнес-приоритетов. Однако результат часто оправдывает усилия: снижение TCO на 40%, в среднем, ускорение получения инсайтов с недель до дней и создание масштабируемого фундамента для цифровой трансформации на базе data-driven подхода и AI-инициатив являются витальными для бизнеса. С учетом российской специфики такой подход позволяет не только решить архитектурные задачи, но и обеспечить долгосрочную устойчивость платформы данных.

Адаптация аналитической архитектуры — это не про технологии, а про компромиссы. Data LakeHouse предлагает компромисс, который дает больше свободы, чем любая монолитная альтернатива, сохраняя при этом контроль, безопасность и экономическую предсказуемость.

В качестве реализации архитектурного паттерна предлагаю протестировать облачную платформу Cloud.ru на базе управляемых сервисов. Среди возможностей: объектное хранилище с поддержкой открытых форматов (Parquet, Iceberg) и независимым масштабированием, а также сервисы аналитики на базе Trino, ArenadataDB и Spark. Оркестрация и AI/ML-инструментарий интегрированы в единый контур без дублирования витрин и рассинхронизации данных. Платформа обеспечивает гибкость архитектуры без зависимости от поставщика, снижает операционную нагрузку на ИТ и позволяет прогнозировать экономику владения. Также платформа соответствует требованиям регуляторов и задачам технологического суверенитета, опираясь на собственные разработки и открытые (open source) решения.