Data lake, warehouse и lakehouse

Урок сравнивает три типа хранилищ и помогает понять, что куда складывать.

Data warehouse — структурированное хранилище для аналитики со строгой схемой. Data lake — дешёвое хранилище сырых файлов любого формата. Lakehouse — гибрид: дешевизна озера плюс надёжность хранилища.

Три способа хранить данные

Хранилище (warehouse) — это база, заточенная под аналитические запросы: данные в ней структурированы, со схемой, и SELECT по миллиардам строк работает быстро. Примеры: Snowflake, BigQuery, ClickHouse.

Озеро (data lake) — это просто дешёвое объектное хранилище (S3, MinIO), куда складывают файлы как есть: логи, JSON, Parquet, картинки. Схемы нет — структуру навешивают при чтении.

Lakehouse — современная попытка взять лучшее от обоих: файлы лежат дёшево в озере, но поверх них есть таблицы со схемой, транзакциями и быстрыми запросами (форматы Delta Lake, Apache Iceberg).

Историческая логика проста. Сначала были только дорогие хранилища, и в них клали лишь тщательно подготовленные данные. Потом подешевело облачное хранение, и появились озёра — туда стали сваливать вообще всё. Но без схемы и транзакций озёра быстро превращались в хаос, поэтому индустрия пришла к lakehouse: дешёвое хранение плюс «таблицы» поверх файлов. Это не мода, а закономерный ответ на боль предыдущих поколений архитектур.

Schema-on-write против schema-on-read

Подход	Когда задаётся схема	Где
schema-on-write	при записи данных	warehouse
schema-on-read	при чтении данных	data lake

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

Как работает под капотом

Схему хранилища задают через CREATE TABLE с типами столбцов. Попытка вставить неверный тип ловится сразу. Соберём маленькое «хранилище» продаж и посчитаем витрину.

CREATE TABLE sales (
    id INTEGER PRIMARY KEY,
    product TEXT NOT NULL,
    amount INTEGER NOT NULL,
    region TEXT NOT NULL
);
INSERT INTO sales (product, amount, region) VALUES
    ('Книга', 300, 'Север'),
    ('Книга', 500, 'Юг'),
    ('Ручка', 50, 'Север'),
    ('Ручка', 90, 'Юг');

SELECT region, SUM(amount) AS revenue
FROM sales
GROUP BY region
ORDER BY revenue DESC;

Обратите внимание на NOT NULL в схеме: хранилище не даст вставить строку без региона или суммы. Это и есть schema-on-write в действии — правила качества встроены прямо в определение таблицы, и плохие данные физически не попадут внутрь. В озере такой защиты нет: туда можно записать что угодно, а проверять корректность придётся уже при чтении, своими руками.

Где что хранить

Сырые логи и выгрузки → озеро (дёшево, schema-on-read).
Готовые витрины для дашбордов → хранилище (быстро, схема).
Большие объёмы с потребностью в аналитике → lakehouse (компромисс).

Частые ошибки

Свалить всё в озеро и забыть. Без каталога и описаний озеро превращается в «болото данных» (data swamp), где никто ничего не находит.
Грузить сырьё прямо в дорогое хранилище. Это дорого и засоряет аналитическую базу; сырьё место в озере.
Считать lakehouse «волшебной таблеткой». Это инженерный компромисс, а не замена пониманию данных.

Итог

Warehouse — структурированное хранилище для быстрой аналитики (schema-on-write).
Data lake — дешёвое хранение сырья любого формата (schema-on-read).
Lakehouse — гибрид, сочетающий дешевизну озера и надёжность хранилища.