В чем разница DWH и Data Lake

Что проверяют

Понимаете ли вы, что разница не в объёме, а в том, когда данные получают схему и кто ими пользуется. Следом почти всегда спрашивают про lakehouse и о том, как построить хранилище сразу для аналитиков и для ML.

Как отвечать

Сравнивайте по нескольким осям:

• схема: DWH работает по схеме при записи (schema-on-write): данные чистят, типизируют и укладывают в модель заранее. Data Lake хранит сырьё как есть, а схему применяет при чтении (schema-on-read);
• данные: в DWH таблицы, смоделированные под анализ (звезда по Кимбаллу, Data Vault). В озере файлы в Parquet, ORC, JSON, CSV, логи, картинки;
• хранение и движки: DWH это колоночные распределённые системы вроде Greenplum, ClickHouse, Snowflake, BigQuery. Озеро это объектное хранилище S3 или HDFS и движки Spark, Trino, Hive поверх него;
• потребители: DWH кормит BI и отчёты, где нужны быстрые и согласованные SQL-запросы. Озеро нужно дата-сайентистам и ML: сырые события, признаки, обучающие выборки;
• цена: хранить в объектном хранилище дёшево, но без каталога и контроля качества озеро превращается в болото (data swamp), где никто не знает, какой файл актуален.

Дальше покажите современную картину. Граница размылась: табличные форматы Apache Iceberg, Delta Lake и Apache Hudi дают поверх файлов в S3 транзакции ACID, эволюцию схемы и чтение прошлых версий таблицы. Это и называют lakehouse. Типовая схема слоёв: сырой, очищенный и витрины (bronze, silver, gold), причём витрины часто всё равно лежат в DWH.

Где спотыкаются

Повторяют «в DWH ETL, в озере ELT». Современные хранилища активно работают по ELT: сырьё грузят в staging, а трансформации пишут на SQL в dbt внутри самого DWH.

Говорят, что озеро это просто место для неструктурированных данных. На практике большая часть озера это вполне структурированные Parquet-таблицы.

Противопоставляют их как «или-или». В реальных компаниях они живут вместе: озеро как дешёвый источник истины, DWH как быстрый слой для аналитики.