Какая архитектура лучше соответствует бизнес‑целям, когда стоит выбрать проверенный DWH, а в каких случаях бизнесу нужна гибкость Lakehouse — разбираемся в статье.
Аналитика данных давно вышла за рамки квартальной отчётности: бизнесу нужна свежая информация, быстрые ответы на вопросы и современные технологии. И всё это — на одних и тех же данных. Сложность в том, что они разъезжаются по разным углам: транзакционным таблицам, логам, файлам, потокам событий. От того, как устроен аналитический контур, зависит, получит аналитик ответ за минуту или за две недели.
Исторически задачу решали двумя способами:
Lakehouse объединяет оба подхода: дешёвое объектное хранилище и открытые форматы озера плюс транзакционность, схема и производительность хранилища.
В статье разбираем, чем DWH, Data Lake и Lakehouse отличаются с точки зрения аналитических сценариев и как выбрать архитектуру под свои задачи — от регламентной отчётности до машинного обучения.
Данных в корпорациях становится всё больше, разнообразие их форматов тоже растёт: от классических реляционных таблиц до полуструктурированных JSON, логов, потоковых событий и полностью неструктурированного контента — сканов документов или данных телеметрии. При этом, по итогам исследования консалтинговой компании HFS Research, 85% руководителей крупных международных организаций считают, что данные — это фундамент для развития бизнеса.
Data Warehouse (DWH) — это централизованное хранилище данных, которое собирает, очищает и хранит их из разных источников (CRM, ERP, 1С, логов) в структурированном виде, готовом для анализов и отчётов. Он позволяет объединить разнородные данные в едином пространстве, а также повысить качество и скорость доступа к ним. Такой метод подходит, когда бизнесу нужны единые показатели, формализованные правила расчёта и стабильная работа аналитических нагрузок.
DWH ориентирован на работу с большими объёмами структурированных данных и помогает выполнять аналитические запросы с высокой скоростью. Он решает три ключевые задачи:
Ключевая идея DWH
Интеграция данных из различных источников в единую структуру, что делает их незаменимым инструментом для бизнес-аналитики. При DWH-подходе у компании есть корпоративное хранилище, в котором данные из разных систем собираются, очищаются, приводятся к единой структуре и подготавливаются для аналитики. Такие хранилища создаются на основе колоночно-ориентированных СУБД или СУБД, построенных на архитектурном шаблоне MPP (Massively Parallel Processing).
Change Data Capture — технология захвата изменений данных в реальном времени из логов транзакций источника.
Типовая архитектура DWH включает:
Многоуровневая архитектура DWH — залог надёжной аналитики. Каждый слой решает свою задачу: от фиксации сырых изменений в операционных системах до готовых витрин, на базе которых строятся отчёты и принимаются решения. Благодаря этому бизнес получает единую и проверяемую версию данных: метрики считаются одинаково во всех подразделениях, а любые расхождения можно отследить по цепочке преобразований. В итоге аналитика становится релевантной, а бизнес-решения — обоснованными.
DWH помогает бизнесу опираться на единую информацию, снижать расхождения в отчётности и быстрее принимать решения. Ниже разберём ключевые преимущества и недостатки подхода DWH.
DWH собирает данные из операционных систем, логов, внешних API и других источников, приводит их к единому формату и хранит в согласованной модели. Это решает проблему «разных версий правды» в компании.
DWH спроектирован под аналитические запросы. Он обеспечивает их скорость и одновременную работу множества аналитиков.
Важно
Производительность сильно зависит от качества модели данных и настройки партиционирования. Даже самый быстрый DWH будет медленным при плохой схеме и отсутствии статистики.
С помощью DWH можно наращивать ёмкость и вычислительные мощности по мере роста данных и числа пользователей, а также менять архитектуру под новые типы задач: классическую аналитику, ML‑фичи, потоковые данные.
В классическом DWH (Greenplum®, VERTICA, Teradata, Redshift первых поколений) вычислительные ресурсы (CPU, RAM) и дисковое пространство физически находятся на одних и тех же серверах и масштабируются только вместе. Нельзя увеличить объём данных, не добавив при этом ещё и вычислительные мощности. И наоборот. При этом придётся переплачивать за ненужные ресурсы.
Дорогие лицензии (Oracle®, Teradata, SAP HANA®), мощное оборудование, затраты на администрирование и поддержку. Для среднего бизнеса бюджет на DWH может составлять миллионы рублей в год. Вопрос об оправдании высоких затрат возникает регулярно.
Любые изменения в источниках требуют перестройки модели данных — это замедляет адаптацию к новым задачам. К примеру, если через полгода в CRM появилось новое поле или изменился формат данных, нужно менять схему DWH, переписывать ETL, перегружать историю. Это недели работы.
DWH отлично работает с табличными данными (заказами, клиентами, платежами), но ограничен в поддержке неструктурированных форматов: текстов, JSON, логов, изображений и видео. Их приходится сложно парсить и преобразовывать, это дорого и долго. В результате аналитики не видят полной картины, а бизнес теряет важные инсайты, например о тональности отзывов или поведении пользователей.
Для обучения моделей данные выгружают из DWH в отдельные системы, очищают (в Python® или Spark™) и обучают модель. Затем результаты загружают обратно. Это создаёт дублирование и задержки: ML‑инженеры тратят время на перенос данных, а не на работу с моделями.
DWH обеспечивает единую версию показателей и точные управленческие отчёты по продажам, финансам, закупкам, поэтому его применяют во многих отраслях. Некоторые примеры отраслевого использования DWH:
От Data Lake (озеро данных) подход берёт гибкость (хранение любых данных в сыром виде), а от DWH — производительность (структурированные запросы, ACID-транзакции, поддержка BI). Это единое пространство, где можно хранить сырые данные и сразу строить на них отчёты, модели машинного обучения или потоковую аналитику, не дублируя инфраструктуру.
Согласно аналитике Global Market Insights Inc., мировой рынок Lakehouse вырастет с 14,2 млрд долларов в 2025 году до 105,9 млрд долларов в 2034 году при темпе роста 25% в год. Так, за счёт своей универсальности, подход Lakehouse помогает компаниям экономить на хранении и обработке данных.
Типовая Lakehouse‑архитектура в Yandex Cloud включает:
Lakehouse помогает быстрее запускать аналитику, новые продукты и услуги, не дублировать данные между системами, независимо масштабировать хранение и вычисления, а также управлять затратами на платформу.
Подход позволяет работать с данными любого формата и анализировать их без переключения между разными хранилищами. Это решает проблему «болота данных» (Data Swamp), часто встречающуюся в неструктурированных Data Lake, и при этом сохраняет транзакционные возможности, характерные для DWH.
Объектное хранилище масштабируется до петабайтов без ограничений, а вычислительные мощности (Spark, Trino) добавляются независимо. Lakehouse помогает быстрее запускать аналитику, работать с растущими объёмами данных и управлять затратами на платформу.
Используются открытые форматы (Apache Parquet™, ORC, Apache Avro™) поверх объектного хранилища. Это значительно дешевле проприетарных DWH.
BI-отчёты и обучение моделей работают с одним и тем же набором данных, без выгрузки и дублирования.
Есть доступ к любой версии данных за любой момент времени — это упрощает аудит и отладку.
Несмотря на значительные преимущества, у Lakehouse-подхода также есть ограничения и недостатки.
Придётся нанять или обучить инженеров, которые умеют работать со Spark, Iceberg™ и объектными хранилищами — на рынке таких меньше, чем DBA. Ещё один способ решить это — привлечь экспертного партнёра с практическим опытом во внедрении Lakehouse-подхода.
Дашборды в реальном времени могут тормозить, если данные не оптимизированы. Для миллисекундных ответов Lakehouse-архитектура часто дополняется быстрыми витринами данных — например, на базе ClickHouse или Greenplum, которые встраиваются как часть Lakehouse.
При обновлении одного из компонентов стека (Spark, Iceberg, Apache Hudi™, Trino) нет гарантии, что новая версия будет совместима с текущими версиями остальных компонентов.
Обновление Spark может сломать интеграцию с Iceberg, а новая версия Iceberg — потребовать обновления Spark или Apache Hive™ Metastore. Поскольку каждый компонент развивается независимо и нет единого вендора, который отвечает за совместимость всего стека, команда тратит время на тестирование сочетаний версий и решение конфликтов. В коммерческом DWH эта проблема решается производителем — вы обновляете систему целиком, и совместимость гарантирована. В Lakehouse это ложится на плечи команды.
ACID — атомарный коммит одной таблицы, а не транзакции СУБД: обновить две таблицы атомарно или открыть BEGIN…COMMIT из сессии нельзя. ACID требует обслуживания: без регулярной компакции и чистки снапшотов таблица деградирует.
Lakehouse подходит для прогнозирования, сегментации и построения рекомендательных систем. Он может объединять все типы данных:
При этом для Lakehouse не важно, каким способом эти данные доставляются: пакетно, потоково или через CDC.
Классические OLAP/MPP-хранилища сложнее и дороже масштабировать, а хранение и вычисления связаны. Lakehouse на объектном хранилище разделяет их и масштабируется до петабайтов, добавляя вычисления независимо от объёма данных.
Lakehouse применяют в различных отраслях:
Выбор между Data Warehouse и Lakehouse влияет на то, как компания хранит данные, насколько быстро она может принимать решения, сколько денег тратит на анализ и насколько легко может менять способы такой аналитики.
В таблице ниже мы собрали ключевые различия этих подходов по важным для бизнеса критериям. Сравнение поможет определить, какой подход лучше закрывает текущие и перспективные задачи компании:
|
Параметр |
DWH |
Lakehouse |
|
Стоимость хранения |
Высокая (проприетарные форматы), хранение связано с вычислениями |
Дешёвое объектное хранилище |
|
Масштабирование |
Горизонтальное, менее эластично |
Горизонтальное, эластичное |
|
Типы данных |
Только структурированные |
Структурированные и неструктурированные: JSON, видео + аудио (кроме табличных форматов) |
|
ACID |
Нативная |
Частично (через Iceberg, Delta Lake, Hudi) |
|
Производительность для аналитики (OLAP) |
Очень высокая для сложных SQL-запросов, агрегаций. Оптимизирована под BI и регулярную отчётность |
Высокая, но сильно зависит от качества метаданных, статистики и партиционирования |
|
Поддержка ML и Data Science |
Для ML часто требуется выгрузка в отдельный контур |
Нативная поддержка: ML-команды работают напрямую с сырыми и промежуточными слоями |
|
Риски и сложности |
Жёсткая структура усложняет адаптацию к новым источникам. Риск узких мест при росте объёмов. Высокая стоимость хранения больших массивов сырых данных |
Риск превращения в Data Swamp (информационное болото) без строгих правил. Требует высокой зрелости команды (метаданные, каталоги, контроль качества) |
При выборе между DWH или Lakehouse важно учитывать множество разных факторов, которые могут повлиять на то, насколько хорошо будет работать система хранения данных. Как правило, решающий фактор — это характер данных и зрелость процессов работы с ними.
Если преобладают структурированные данные, чаще выбирают DWH. Если значительную часть составляют неструктурированные данные — Lakehouse.
Если у вас только структурированные данные, а объёмы до 100 ТБ и влезают в один кластер — DWH будет проще и быстрее. Если данных много (сотни терабайт и выше), есть неструктурированные данные (логи, тексты, видео) или вы планируете строить ML-модели — Lakehouse даёт гибкость и экономию за счёт единого хранения всех типов данных, включая структурированные.
Не менее значимы такие параметры, как удобство работы в облачной среде, способность системы поддерживать разнообразные форматы данных и стоимость хранения информации на один терабайт.
|
У вас только структурированные данные: таблицы, Excel, SQL-базы |
→ DWH |
|
Есть неструктурированные данные: тексты, логи, JSON, аудио, видео, изображения |
→ Lakehouse |
|
У вас и то и другое в равной степени |
→ Lakehouse |
|
Ваша основная задача — BI-отчёты и дашборды: SQL-запросы, быстрые агрегации |
→ DWH |
|
Вы планируете обучать ML-модели на тех же данных, что и аналитика |
→ Lakehouse |
|
Вам нужна сквозная аналитика и ML на одной платформе |
→ Lakehouse |
|
У вас жёсткая схема данных, которая не меняется годами |
→ DWH |
|
Ваша схема данных часто меняется: приходят новые источники, поля появляются и исчезают |
→ Lakehouse |
|
Вам нужно хранить сырые данные как есть и применять схему при чтении |
→ Lakehouse |
|
У вас есть бюджет на проприетарные лицензии (Oracle, Teradata, Snowflake) |
→ DWH |
|
Вы хотите экономить на хранении (объектное хранилище, открытые форматы) |
→ Lakehouse |
|
В вашей команде есть инженеры данных, готовые работать со Spark, Delta Lake и Iceberg |
→ Lakehouse |
|
Ваша команда привыкла к классическим SQL-инструментам |
→ DWH |
|
Вам нужны миллисекундные задержки на сложных SQL-запросах |
→ DWH |
|
Вы готовы ждать ради гибкости и дешёвого хранения |
→ Lakehouse |
Итоговое решение зависит от распределения выборов: если чаще выбирали DWH — подойдёт классическое хранилище данных. А если Lakehouse — единая платформа для аналитики и ML. Если голоса разделились поровну, то оптимальный вариант — гибрид: DWH для критичных отчётов и Lakehouse для работы с сырыми данными и ML.
Гибридный путь — совмещение DWH и Lakehouse — позволяет взять лучшее от обоих миров: надёжность и предсказуемость DWH, а гибкость и масштаб — от Lakehouse.
Существует три главных паттерна для реализации гибридного подхода.
Lakehouse хранит сырые данные, промежуточные слои и экспериментальные модели. DWH забирает оттуда уже проверенные, согласованные данные и формирует финальные витрины для BI и отчётности.
Так можно не дублировать всю сырую историю в DWH, но дать бизнесу гарантированно качественные метрики.
Плюсы:
Минусы:
Основная нагрузка переносится в Lakehouse (BI, ML, эксперименты). В DWH выносят только самые критичные, регламентированные отчёты и витрины, где нужны жёсткие SLA по времени отклика и стабильности.
Такую схему выбирают, когда хочется двигаться к единой платформе, но нельзя рисковать ключевыми отчётами (финансы, налоги).
Плюсы:
Минусы:
При такой схеме все витрины и BI‑отчётность живут в DWH. Lakehouse используют как «песочницу» для Data Science, экспериментов с новыми источниками и как архив старых данных, которые редко запрашивают.
Такая реализация имеет смысл, если компания уже сильно вложилась в DWH и хочет добавить гибкость для ML и новых типов данных.
Плюсы:
Минусы:
Сервисы Yandex Cloud помогают в работе с DWH и Lakehouse в облаке, предоставляя инструменты для полного цикла обработки данных: от сбора и хранения до анализа и визуализации.
Для DWH сервисы Yandex Cloud позволяют:
Пример применения подхода Lakehouse — опыт сети ресторанов ROSTIC’S по построению платформы данных на базе Greenplum и ClickHouse в Yandex Cloud. IT‑команда «Юнирест» пересмотрела архитектуру при миграции в облако: входящие данные теперь «стекаются» в озеро данных на базе Yandex Object Storage с механизмом Change Data Capture.
В итоге Lakehouse позволил ROSTIC’S объединить дешёвое хранение сырых данных с быстрой аналитикой, автоматизировать создание отчётов и ускорить время выхода на рынок новых функций без найма дополнительных разработчиков.
Классическое DWH-хранилище данных остаётся надёжным выбором для структурированной аналитики, где важны скорость запросов и жёсткая схема. Lakehouse открывает новые возможности там, где нужна гибкость, работа с неструктурированными данными и бесшовная интеграция с ML-нагрузками.
Если ваш бизнес строится вокруг стандартных BI-отчётов на структурированных данных — DWH будет проще, дешевле и быстрее во внедрении. Если вы работаете с разнородными данными, планируете внедрять машинное обучение или хотите хранить сырые данные «на вырост» — Lakehouse даст нужную гибкость без жёсткой привязки к схеме данных.
В этой статье: