Data Lake, Data Warehouse и Lakehouse: в чём разница
Основы3 минРедакция Innovialabs
Коротко
Data Warehouse хранит очищенные структурированные данные для отчётов, Data Lake — любые сырые данные дёшево и в исходном виде, а Lakehouse добавляет к озеру таблицы и транзакции как в хранилище. Небольшой компании часто хватает обычной базы и BI-инструмента.
Коротко о трёх подходах
- Data Warehouse (хранилище данных) — структурированные таблицы с заранее заданной схемой. Данные очищены и согласованы, по ним быстро строятся отчёты на SQL.
- Data Lake (озеро данных) — дешёвое объектное хранилище (S3, Google Cloud Storage, Azure Data Lake Storage), куда складывают всё подряд в исходном виде: выгрузки баз, логи, JSON из API, файлы, изображения. Схема применяется при чтении.
- Lakehouse — озеро данных плюс открытый табличный формат (Delta Lake, Apache Iceberg, Apache Hudi), который даёт файлам в озере транзакции, версии и схему. Идея — получить дешевизну озера и надёжность хранилища в одной системе.
Сравнение
| Параметр | Data Warehouse | Data Lake | Lakehouse |
|---|---|---|---|
| Структура | Строгая схема при записи | Любые форматы, схема при чтении | Таблицы поверх файлов в озере |
| Типы данных | Таблицы | Таблицы, логи, JSON, тексты, медиа | Все, но аналитика в основном по таблицам |
| Стоимость хранения | Выше, оплата часто связана с вычислениями | Низкая, объектное хранилище | Низкая, как у озера |
| Основные пользователи | Аналитики, BI, руководство | Data-инженеры, data scientists | И аналитики, и инженеры, и ML-команды |
| Типовые задачи | Отчёты, дашборды, финансовые метрики | Архив сырых данных, ML, обработка логов | BI и ML на одних данных без копирования |
| Примеры | BigQuery, Snowflake, ClickHouse | S3, GCS, ADLS | Databricks, Iceberg-таблицы в разных движках |
| Главный риск | Дороговизна при росте объёмов и сырых данных | «Болото данных» без каталога и владельцев | Сложность внедрения и поддержки |
Когда что подходит
Хранилище — если главные потребители данных — отчёты и дашборды, источники в основном табличные (CRM, учёт, база сайта), а команде важны простой SQL и предсказуемые цифры.
Озеро — если много неструктурированных или полуструктурированных данных: логи, события, файлы, тексты; нужно дёшево хранить всё «на будущее»; есть задачи машинного обучения.
Lakehouse — если данных уже много и они разнородные, а держать и озеро, и хранилище с копированием между ними стало дорого и сложно. Это решение для зрелой команды данных, а не стартовая точка.
На практике часто встречается связка: сырые данные лежат в озере, очищенная часть загружается в хранилище для BI.
Типичные ошибки
- Озеро без порядка. Файлы складываются без описания, владельцев и сроков хранения. Через год никто не понимает, что в них лежит, и озеро превращается в «болото».
- Выбор по моде. Lakehouse внедряют там, где хватило бы одной аналитической базы.
- Отсутствие единых определений. Архитектура не спасает, если «выручка» в разных отчётах считается по-разному.
- Персональные данные без контроля. В сырых выгрузках легко оказываются телефоны и паспортные данные, к которым открыт слишком широкий доступ.
Когда не нужно ничего из этого
Небольшой или средней компании зачастую рано строить отдельную архитектуру данных. Признаки:
- источников данных немного, например CRM, учётная система и сайт;
- объём помещается в обычную базу, а запросы к ней работают быстро;
- отчёты нужны раз в день или неделю, а не в реальном времени;
- нет задач машинного обучения и больших потоков событий.
Что делать вместо этого:
- Настроить реплику рабочей базы или отдельную схему для аналитики в PostgreSQL.
- Подключить BI-инструмент (Metabase, Looker Studio, Power BI) к этой реплике.
- Описать 5–10 ключевых метрик и их определения.
- Пересмотреть решение, когда запросы начнут тормозить или появятся новые источники.