Собесов

DataLearn DE-101: Data Warehouse vs Data Lake — когда что выбирать

Кейсы и метрикиАрхитектура данныхЛёгкаяJunior

Условие

В курсе DE-101 Дмитрия Аношина первый модуль посвящён базовым понятиям. Один из контрольных вопросов: «Объясните разницу между Data Warehouse (DWH), Data Lake и Data Lakehouse. Когда вы будете рекомендовать заказчику каждый из подходов?»

Дополнительно: компания пришла с задачей — у неё есть OLTP-база PostgreSQL с заказами (≈ 5 ГБ/мес), CSV-логи приложения (≈ 100 ГБ/мес) и видео из CRM (≈ 1 ТБ/мес). Аналитики хотят строить отчёты, дата-сайнтисты — обучать ML. Что бы вы предложили?

Решение

Подход

Главное — понимать, что DWH/Lake/Lakehouse решают разные задачи и в реальности часто сосуществуют.

Свойство Data Warehouse Data Lake Lakehouse
Структура строгая (schema-on-write) любая (schema-on-read) гибрид
Формат колонки (Parquet/проп.) сырые файлы (JSON/CSV/Parquet) open formats + ACID
Стоимость хранения высокая низкая средняя
Скорость аналитики очень быстрая медленная без оптимизации быстрая
Use case BI/отчёты ML/raw archive оба
Примеры Snowflake, BigQuery, Redshift S3/ADLS/GCS + Glue/Athena Databricks Delta, Iceberg, Hudi

Когда что выбирать

  • DWH: устоявшиеся бизнес-метрики, регулярные дашборды, SLA на запросы.
  • Lake: «ещё не знаем, что будем считать», много неструктурированных данных, ML-feature store.
  • Lakehouse: хочется и BI, и ML на одном источнике, бюджет ограничен.

Архитектура для кейса

PostgreSQL OLTP ──► CDC (Debezium) ──┐
                                      │
CSV-логи         ──► Airflow/Glue ────┼─► S3 (Bronze, raw) ──► S3 (Silver, cleaned)
                                      │                            │
Видео из CRM     ─────────────────────┘                            ▼
                                                         S3 (Gold, marts)
                                                              │
                                              ┌───────────────┴─────────┐
                                              ▼                         ▼
                                   Snowflake / BigQuery          Databricks
                                   (BI: Tableau, Power BI)       (ML, Spark)

Сырьё (Bronze) → очищенные (Silver) → витрины (Gold) — медальон-архитектура.

Подводные камни

  1. «Data Lake = свалка» — без каталога (Glue, Unity, Hive Metastore) и ACL быстро превращается в data swamp.
  2. Не считайте видео «данными для аналитики» — обычно архивируют в дешёвый storage class (Glacier) и индексируют отдельно.
  3. CDC vs nightly batch: CDC даёт near-real-time, но требует постоянного потребителя; для отчётов часто достаточно ночного полного снимка.
  4. DWH ≠ просто база: специализированные движки (column-store, MPP) дают на 10-100× выигрыш в OLAP-запросах vs Postgres.
  5. Партиционирование на S3: s3://bucket/table/dt=2026-05-26/ — обязательно для дешёвых сканов в Athena/Spectrum.
  6. Парадокс стоимости: «дешёвое» хранение в Lake становится дорогим, если каждый запрос сканирует ТБ.

Эталонный ответ

DWH — для BI и регулярной отчётности (структурированные данные, schema-on-write, быстрые OLAP-запросы). Data Lake — для дёшевого хранения сырья и ML (schema-on-read, любые форматы). Lakehouse — гибрид с ACID-таблицами поверх объектного хранилища (Delta, Iceberg).

Для кейса: Postgres → CDC → S3 Bronze; логи → Airflow → S3 Bronze; видео — отдельный архивный bucket. Над S3 строим Silver/Gold слои; для BI поднимаем Snowflake/BigQuery, для ML — Databricks или Spark over Iceberg.

Хочешь увидеть разбор?

Зарегистрируйся бесплатно — откроется развёрнутое решение этой задачи и ещё 4 на выбор.

Зарегистрироваться и увидеть разбор
Уже есть аккаунт? Войти