Три парадигмы хранения данных

В 2026 году у data engineer-а есть три основных архитектурных выбора для большого хранилища:

1. Data Warehouse (DWH) — Snowflake, BigQuery, Redshift. Структурированные данные, SQL-native, managed.
2. Data Lake — Parquet/JSON на S3, query через Athena/Spark. Сырые данные, дёшево, гибко.
3. Lakehouse — Iceberg/Delta поверх Parquet на S3, query через Databricks/Trino. Гибрид DWH+Lake.

Каждый возник из конкретной проблемы. В этом уроке разбираем, чем отличаются, как развивались, когда какой выбирать.

Data Warehouse: структурированный мир

Концепцию DWH мы разобрали в предыдущих уроках. Кратко рекапитуляция:

• Структурированные данные: tables, columns, types, schema.
• SQL-native: всё через SQL, оптимизирован для analytics.
• Managed cloud сервис: Snowflake/BigQuery/Redshift.
• Closed storage format: Snowflake хранит данные в своём internal формате, не доступен напрямую.
• Tight performance: оптимизирован под analytics — projection/predicate pushdown, columnar, MPP.
• Дорого: storage в DWH дороже data lake S3 в 10-50x.

Плюсы DWH:

• Простота: подключился, написал SQL, получил ответ.
• Производительность: secondary к чёткой specialization.
• Governance: RBAC, masking, lineage — first-class.
• Reliability: managed, никакого operating overhead.

Минусы DWH:

• Цена: на petabyte storage становится непомерно.
• Vendor lock-in: Snowflake данные не прочитать external tools.
• Не для unstructured (images, video, audio).
• ML training — не основной use case.

Data Lake: дикий запад

Data Lake появился около 2010 года как ответ на проблемы DWH:

• DWH дорогой на больших объёмах.
• DWH требует жёсткой схемы заранее — что если структура неизвестна?
• DWH плохо работает с raw, semi-structured (JSON, logs).
• ETL в DWH — это месяцы инженерной работы.

Идея: просто кладём всё в S3 как есть (Parquet, JSON, CSV, даже images), потом разбираемся, как обрабатывать. Это “schema-on-read” вместо “schema-on-write”.

Архитектура:

[Sources] -> [S3 Bucket: raw + cleaned Parquet] -> [Compute engines: Spark, Athena, Trino, DuckDB]

S3 хранит данные. Compute engines читают S3, обрабатывают, возвращают результат. Никакой managed-БД — только storage и compute, разные.

Плюсы Data Lake:

• Дёшево: S3 storage ~$23/TB/мес vs Snowflake$40+/TB/мес.
• Гибко: любые форматы, любая структура.
• Открыто: Parquet/JSON — open standards, любой engine читает.
• Scale: терабайты до петабайтов без проблем.
• Multi-workload: ML training рядом с SQL analytics.

Минусы Data Lake (классический):

• Нет ACID транзакций: одновременная запись + чтение — race conditions, partial reads.
• Нет schema evolution в proper sense: можно сломать downstream, если поменять формат.
• Performance — DIY: оптимизация (partitioning, file sizing, compaction) на тебе.
• Governance сложнее: ACL, lineage, masking — нет out-of-the-box.
• Data swamp: если не следить, lake превращается в свалку.

Классический Hadoop Data Lake (2010-2018) часто заканчивался “data swamp” — куча файлов, никто не знает что есть что. Это породило следующую парадигму.

Lakehouse: лучшее из двух миров

Около 2020 года появилась парадигма Lakehouse — попытка совместить:

• Дешёвый и гибкий storage data lake-а.
• ACID, schema, performance DWH.

Реализация: добавить table format layer поверх Parquet на S3. Это metadata layer, который превращает набор Parquet-файлов в полноценную ACID-таблицу.

Главные table formats:

• Apache Iceberg — open, от Netflix/Apple (2017). Самый mindshare-богатый.
• Delta Lake — open, от Databricks (2019). Native в Databricks SQL.
• Apache Hudi — open, от Uber (2017). Меньше mindshare, но активно используется.

Архитектура Lakehouse:

[Sources] -> [S3: Parquet files + Iceberg/Delta metadata]
                                                          \
            -> [Query engines: Databricks SQL, Trino, Snowflake, BigQuery, DuckDB] -> [BI/ML]

Iceberg/Delta хранит:

• Schema definition: какие колонки, какие типы.
• Transaction log: какие файлы относятся к какой версии таблицы.
• Statistics: min/max по колонкам для skipping.
• Partition spec: как партиционировано.

Это даёт:

• ACID транзакции: атомарные writes, isolation, no partial reads.
• Schema evolution: добавить колонку, переименовать — без переписывания файлов.
• Time travel: запрос к данным “как было N дней назад”.
• Partition evolution: можно изменить partitioning стратегию без переписывания.
• Performance: predicate pushdown, partition pruning, file-level statistics.

И всё это поверх обычных Parquet файлов на S3. Любой engine, понимающий формат, работает с теми же данными.

Плюсы Lakehouse:

• Cost data lake-а (cheap S3).
• Performance близок к DWH (для read-heavy analytics).
• Open formats — no vendor lock-in, multi-engine.
• ACID, schema evolution, time travel.
• Multi-workload: ML training рядом с SQL.
• Можно мигрировать engines (Databricks -> Trino -> Snowflake) без копирования данных.

Минусы Lakehouse:

• Сложнее в setup: нужно настроить table format, catalog (Glue/Hive Metastore/Polaris).
• Operating overhead больше DWH: нужно compaction, vacuum, partition management.
• Performance всё-таки чуть ниже native DWH формата (Snowflake’s closed storage чуть быстрее).
• Эволюционная сложность: features (clustering, hidden partitions) добавляются постепенно.

Сравнительная таблица

Эволюция: куда движется индустрия

2010-2018: Data Lake era. Hadoop, Spark, S3. Параллельно — классические DWH (Teradata, Oracle).

2018-2022: Cloud DWH era. Snowflake становится default. BigQuery растёт. Data Lake остаётся для big data специфики.

2022-2024: Lakehouse rise. Databricks/Iceberg/Delta набирают mindshare. Snowflake начинает поддерживать Iceberg (Polaris Catalog).

2024-2026: Convergence. Все DWH добавляют Iceberg/Delta support:

• Snowflake — Iceberg tables (managed and external).
• BigQuery — external Iceberg/Delta.
• Redshift — external Iceberg.
• Databricks — native Delta, Iceberg interop.

Границы размываются. Можно держать данные в Iceberg, query одним engine, переключиться на другой без миграции данных. Это направление, в котором идёт индустрия.

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

Чистый DWH (Snowflake/BigQuery/Redshift) — когда:

• Размер меньше 100 TB.
• Команда маленькая, важна simplicity.
• Pure SQL analytics, никакого ML training.
• Не хочется operating overhead.
• Регуляторика требует tight governance.

Чистый Data Lake (S3 + Spark/Athena) — когда:

• Сырые данные, structure неизвестна.
• ML training — primary workload.
• Cost-критичный — петабайты данных.
• Команда есть для operating.
• Mixed workloads (analytics + ML + streaming).

Lakehouse (Iceberg/Delta поверх S3) — когда:

• Modern data platform с нуля.
• Multi-engine стратегия (Databricks для ML, Trino для SQL).
• No vendor lock-in важен.
• Open standards стратегия.
• Mixed workloads.

В 2026 году Lakehouse — самый perspective выбор для new builds. DWH остаётся для simplicity, Data Lake — для специфических ML/big data nuances.

Реальная архитектура: гибрид

В крупных компаниях типичная архитектура — гибрид:

[Sources]
   ↓
[Raw Data Lake S3] — bronze layer, raw как есть, дёшево
   ↓
[Iceberg/Delta cleaned tables] — silver layer, ACID
   ↓
[DWH Snowflake/BigQuery for hot analytics] — gold marts
   ↓
[BI tools]

• Raw в data lake — дёшево, history.
• Iceberg/Delta для intermediate processing — ACID, multi-engine.
• DWH для frequent analytics — tight performance, simplicity.

Это realistic 2026 паттерн в Netflix, Airbnb, Uber. Не “DWH OR Lake OR Lakehouse” — а “DWH AND Lake AND Lakehouse”.

Реальные числа: 1 PB через 3 архитектуры

Гипотетическая стоимость хранения 1 PB:

Это очень approximate, реальные числа сильно зависят от workload patterns. Но общая идея: Lake/Lakehouse дешевле на чистом storage, DWH проще в operating.

Попробуй сам

1. Создай маленький Lakehouse setup: Iceberg/Delta tables в S3 (можно minio локально), query через DuckDB и Spark. Сравни experience с прямым Parquet.
2. Изучи Iceberg docs (https://iceberg.apache.org). Понимаешь снапшоты, manifests, partition evolution — это foundation современного storage.
3. Сравни три архитектуры на TPC-H: classic DWH (DuckDB как proxy для Snowflake), Data Lake (raw Parquet + DuckDB), Lakehouse (Iceberg + DuckDB). Замерь performance.
4. Спроектируй data platform для своей задачи. Какие данные где живут? Какие engines? Какие table formats?