Storage: куда складываем данные

После ingestion данные должны где-то жить. У этой работы есть несколько кардинально разных вариантов, и они часто сосуществуют в одной компании.

В этом уроке — обзор четырёх главных типов storage: OLTP DB, DWH, Data Lake, Lakehouse. Подробности — в модулях M04-M06 и M13.

Четыре главных варианта

OLTP БД: не для аналитики

OLTP (Online Transaction Processing) — это БД приложения. Postgres, MySQL — типичные представители.

Они оптимизированы под:

• Маленькие транзакции — обновить заказ, добавить пользователя.
• Низкую latency — операция должна занять миллисекунды.
• Конкурентный доступ — тысячи пользователей одновременно.
• ACID-гарантии — строгая консистентность.

Они не оптимизированы под аналитику:

• Большие сканы (SELECT * FROM orders WHERE date >= '2025-01-01') тормозят.
• Агрегации (SUM, AVG, GROUP BY по миллионам строк) пожирают CPU.
• Тяжёлые джоины конкурируют за ресурсы с production-нагрузкой.

Data Warehouse (DWH)

DWH — это специализированное хранилище под аналитику.

Ключевые свойства

• Колоночное хранение — данные хранятся не построчно, а поколоночно. Скан только нужных колонок — быстрее на 10-100x для аналитики.
• MPP (Massively Parallel Processing) — запрос делится на сотни parallel воркеров.
• Compute и storage разделены (Snowflake, BigQuery) — можешь поднять больше compute на пиках без перетряхивания данных.
• Schema-on-write — данные структурированы при загрузке.
• SQL-first — главный интерфейс.

Лидеры рынка

Углубление по DWH-моделям — модуль 06-data-warehousing.

Data Lake

Data Lake — это файловое хранилище в облаке, где любые данные живут в любом формате.

Зачем

OLTP-БД и DWH принимают только структурированные данные. А что делать с:

• логами приложения (JSON, неструктурированными);
• картинками, PDF, видео;
• сырыми JSON от API, до того как ты решил их схему;
• петабайтами клик-стрима, где затраты на DWH-хранение убийственные.

Ответ: Data Lake. Объектное хранилище (S3, GCS, Azure Blob) с schema-on-read: схему применяешь при чтении, а не при записи.

Свойства

• Storage-only — это просто файлы. Compute — отдельно (Spark, Athena, Presto, DuckDB).
• Schema-on-read — данные пишутся как есть, schema применяется при чтении.
• Дёшево — $0.023 / GB / месяц в S3 vs$20+ / TB / месяц в DWH.
• Любые форматы — Parquet, JSON, CSV, Avro, картинки, что угодно.

Минусы

• Хаос без процессов — превращается в «data swamp» (болото). Никто не знает, какие данные актуальны, как использовать.
• Нет ACID — обновить одну строку в файле невозможно. Только переписать файл целиком.
• Performance — медленнее DWH на чистых аналитических запросах (если нет правильной партиционирования).

Когда нужен Lake

• Объёмы > 10TB, бюджет ограничен.
• Сырые данные перед моделированием (raw landing zone).
• Неструктурированные данные.
• ML / DS — им нужны сырые данные.

Подробнее — модуль 13-data-lakes-lakehouse.

Lakehouse — гибрид

В 2018-2020 появился новый класс: Lakehouse. Идея: «храним в S3, как Lake, но сверху — слой метаданных, который даёт ACID и SQL, как DWH».

Что даёт Lakehouse

• ACID на файлах (через metadata).
• Schema evolution — добавить колонку без перезаписи.
• Time travel — посмотреть «какая была версия таблицы вчера».
• Vendor-agnostic — Iceberg-таблицу читает и Snowflake, и Databricks, и DuckDB.

Игроки

• Apache Iceberg (Netflix-родной) — лидер по open-формату.
• Delta Lake (Databricks) — глубоко интегрирован в Databricks.
• Apache Hudi (Uber) — лучший для CDC use cases.

Слои в DWH/Lakehouse

Внутри DWH данные обычно разложены слоями:

Bronze (Raw)

«Так как пришло». Без изменений. Зачем — traceability: если что-то пошло не так в Gold, можешь пересчитать из Bronze. Сохраняет историю.

Silver (Staging)

Лёгкие трансформации:

• кастинг типов (order_total из строки в decimal);
• переименование колонок к корпоративному стандарту;
• фильтрация мусора (test records);
• разделение JSON-полей на колонки.

Одна модель в Silver = одна таблица из источника. Без join’ов.

Gold (Marts)

Финальные модели для бизнеса:

• star schema (fact + dimensions);
• агрегации (выручка по дню, неделя, месяц);
• бизнес-метрики (CAC, LTV, retention).

Здесь join’ы, агрегации, всё что нужно для дашбордов.

Когда что использовать

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

• OLTP (Postgres) — production-БД приложения.
• DWH (Snowflake) — основной аналитический слой.
• Lake (S3) — сырые landing zone и хранение ML-фич.

Это нормально. Большие компании двигаются в сторону lakehouse, объединяя DWH и Lake в одно.

Реальный пример

E-commerce на 500 человек, 2026 год:

PRODUCTION                      ANALYTICS
Postgres ───────► Fivetran ───► Snowflake (DWH)
                                ├─ RAW         (Bronze)
                                ├─ STAGING     (Silver)
                                └─ MARTS       (Gold)

S3 (Data Lake)
├─ raw/events/         <- логи фронтенда (клики)
├─ raw/snapshots/      <- ежедневные снапшоты для recovery
└─ ml_features/        <- сырые фичи для DS

Iceberg-таблицы поверх S3 ─── читает Snowflake и Spark

DE отвечает за все три хранилища.

Попробуй сам

1. Подумай: твоя компания (или воображаемая). Какие у вас источники, какие данные в OLTP, что бы вы положили в Lake, что в DWH? Нарисуй на бумаге.
2. Создай free-tier аккаунт в Snowflake (или Google BigQuery). Загрузи туда любой CSV (например, Sample data). Напиши SELECT COUNT(*). Это твой первый DWH.