Корни проблемы

Представь крупный банк в 1985 году. У него уже 20 лет работают:

• Mainframe система обработки чеков (COBOL, IBM DB2).
• Кредитные операции (отдельная база, отдельная команда).
• Депозиты и сберегательные счета.
• Карточный процессинг.
• Корпоративные клиенты (отдельная подсистема).

И тут топ-менеджмент спрашивает: сколько мы заработали в прошлом квартале с клиентов в Сан-Франциско?

Кажется простой вопрос. Реальность: данные про клиентов лежат в трёх разных системах с разными ID. Транзакции — ещё в двух. Идентификатор “клиент Сан-Франциско” определяется по адресу, но адреса разные форматы в разных системах. Чтобы ответить, аналитику нужно неделями выгружать tape-ы, мерджить вручную, считать. К моменту, когда ответ готов — квартал уже закрыт.

Эта проблема породила понятие Data Warehouse. Идея: построить отдельную систему, которая аккумулирует данные из всех операционных источников, очищает их, унифицирует, и держит в форме, удобной для анализа.

Определение

Data Warehouse (DWH, хранилище данных) — это отдельная аналитическая база данных, в которую регулярно загружаются данные из операционных систем, очищаются, унифицируются и хранятся в виде, оптимизированном для отчётности и анализа.

Классическое определение Билла Инмона (1990): DWH должен быть:

1. Subject-oriented (предметно-ориентированный) — организован вокруг бизнес-сущностей (заказы, клиенты, продукты), а не операционных процессов.
2. Integrated (интегрированный) — данные из разных источников приведены к единому виду (одни ID, форматы, единицы).
3. Time-variant (исторический) — хранит данные за длительный период, отслеживает изменения во времени.
4. Non-volatile (неизменяемый) — данные не обновляются после загрузки, только добавляются.

Эти четыре свойства до сих пор определяют, что такое DWH.

Почему “отдельная” система — критично

В предыдущем модуле мы разбирали OLTP vs OLAP. DWH — это классический OLAP, физически отделённый от OLTP-систем. Зачем — три причины:

1. OLTP-системы не справляются с аналитической нагрузкой. Запрос “сумма продаж по всем филиалам за 5 лет” на live OLTP базе банка положит транзакционные системы. DWH — отдельный compute, отдельный storage, можно гонять тяжёлые запросы без риска.

2. Структура данных другая. OLTP-схема нормализованная, оптимизирована под точечные UPDATE. Аналитический запрос с 10 JOIN-ами по нормализованной схеме медленный. В DWH — денормализованная схема (star, snowflake) с большими wide-таблицами, оптимизированная под scans.

3. История нужна, OLTP её не хранит. В OLTP-базе статус заказа меняется на месте: pending -> paid -> shipped. История не остаётся. В DWH мы храним snapshot за каждый день (или event-stream изменений), чтобы потом анализировать “сколько заказов было в pending 6 месяцев назад”.

История: от mainframe к cloud

1980-е. Концепция начинает формироваться. Bill Inmon (IBM, потом независимый) пишет первые статьи. Идея — отдельная база для аналитики.

1990-е. Билл Инмон публикует “Building the Data Warehouse” (1992). Ральф Кимбалл предлагает альтернативный подход (dimensional modeling, 1996). Появляются специализированные продукты: Teradata, Oracle Data Warehouse, IBM Db2 Warehouse. Это эра on-premise mainframe-ов и больших инвестиций.

2000-е. Hadoop и MapReduce (2005-2010). Появляется идея “Data Lake” — хранить сырые данные в распределённой файловой системе, обрабатывать через MapReduce. Hadoop конкурирует с DWH, но в реальности используется параллельно.

2010-е. AWS Redshift (2012), Google BigQuery (2010), Snowflake (2014). DWH переезжает в облако. Отделение storage от compute (Snowflake) — революция, масштабирование становится эластичным. Цены падают, доступность растёт.

2020-е. Lakehouse-парадигма (Databricks Delta, Apache Iceberg) — объединение DWH и Data Lake. Snowflake, Databricks SQL, BigQuery становятся равноценными платформами. Появляется dbt — стандарт для transformation. Modern Data Stack.

2024-2026. AI-native DWH: Snowflake Cortex, BigQuery ML, Databricks AI — встроенная аналитика и ML прямо в DWH. Boundary между DWH и data platform размывается.

Что отличает DWH от обычной БД

Это самый частый вопрос джунов: “А чем DWH отличается от Postgres? Это же тоже база данных, тоже SQL”.

Главное отличие — роль в системе: OLTP-БД обслуживает приложение в real-time. DWH — это инфраструктура для бизнес-аналитики, исторических отчётов, ML.

Что заставляет компанию строить DWH

Не каждой компании нужен DWH. Триггеры, когда он становится необходим:

1. Множественные источники данных. Когда в компании несколько систем (CRM, ERP, маркетинговые тулы, billing), и аналитика требует объединения. Это самый частый триггер.

2. Серьёзные объёмы исторических данных. Когда нужно анализировать данные за 2+ года, и OLTP-системы их выкидывают.

3. Аналитика тормозит operations. Когда long-running запросы на OLTP-базе мешают live workload.

4. Появляется команда аналитиков. Когда есть 2+ людей, которые тратят день на ad-hoc SQL — пора давать им отдельную систему.

5. Регуляторика. Финансовые, медицинские, государственные требования — хранить и предоставлять данные за длительный период, в стандартной форме.

6. ML на исторических данных. Когда нужно тренировать модели на годах данных — ML data scientists хотят stable аналитический warehouse.

7. User-facing аналитика в продукте. Когда пользователю показываются его статистики, аналитики, отчёты — нужен low-latency OLAP под капотом.

Если ни одного триггера нет — DWH преждевременен. Многие стартапы прекрасно живут на Postgres + materialized views до серьёзного масштаба.

Реальный пример: e-commerce DWH

Возьмём типичный интернет-магазин. Источники данных:

• Backend Postgres — заказы, корзины, пользователи.
• Stripe — платежи, refunds.
• Mailchimp — email кампании, open rates.
• Google Analytics — события на сайте.
• Salesforce — корпоративные клиенты.
• Zendesk — тикеты поддержки.
• Internal logs — поведение в приложении.

Каждая система — это свой мир. Чтобы ответить на вопрос “сколько мы заработали с пользователей, которые открыли email кампанию ‘Black Friday’” — нужно объединить данные из Mailchimp + Postgres + Stripe.

DWH (например, Snowflake) делает это возможным:

1. Ingestion: Fivetran/Airbyte регулярно тянет данные из всех источников в raw слой Snowflake.
2. Transformation: dbt модели чистят данные, объединяют, создают unified customers, orders таблицы.
3. Mart: построены mart-таблицы (revenue per cohort, customer LTV, marketing attribution).
4. Consumption: Tableau/Looker подключены к mart, аналитики делают ad-hoc SQL.

Эта архитектура — стандарт Modern Data Stack 2026. Углубление в модуле 15 (cloud data platforms) и модуле 13 (dbt).

Чего DWH НЕ делает

Важно понимать ограничения:

• DWH не заменяет OLTP. Не подходит для transactional нагрузки, web backend.
• DWH не обрабатывает real-time события. Latency типичная — минуты или часы. Для sub-second — отдельный класс (ClickHouse, Druid, Pinot).
• DWH не делает ML training. Хранит features, но тренируется ML отдельно (Sagemaker, Vertex, Databricks ML).
• DWH не делает unstructured data. Изображения, видео, audio — это data lake, не DWH (хотя гибриды появляются).
• DWH не заменяет инструменты orchestration. Airflow/Prefect управляют pipeline, DWH — это storage+compute для аналитики.

DWH — это специализированная система, она хорошая в одной задаче (аналитика структурированных данных), всё остальное — рядом.

Терминология: DWH, EDW, ODS

В литературе можно встретить разные термины:

• DWH (Data Warehouse) — общий термин.
• EDW (Enterprise Data Warehouse) — единый центральный DWH компании. Это про organizational scope.
• ODS (Operational Data Store) — staging layer перед DWH, near-realtime копия OLTP без сложной обработки. Не классика DWH, скорее supporting infrastructure.
• Data Mart — domain-specific подмножество DWH (например, sales mart, marketing mart). Может физически жить внутри DWH или быть отдельной системой.
• Data Lake — хранилище сырых данных (Parquet/JSON на S3). Дополняет DWH, не заменяет.
• Lakehouse — гибрид DWH+Lake (Databricks, Iceberg).

В современной терминологии Snowflake/BigQuery называют просто DWH, без указания EDW. ODS почти исчез — заменён на staging layer в самом DWH через dbt.

Попробуй сам

1. Найди в своей компании (или в open project) data flow от OLTP до BI. Сколько систем-источников? Где живёт DWH? Какой ETL?
2. Попробуй построить mini DWH на DuckDB: возьми 2-3 разных CSV (orders, customers, products) с искусственными mismatching форматами (даты как DD/MM/YYYY vs YYYY-MM-DD, country names vs codes), напиши SQL-трансформации для приведения к единому виду.
3. Прочитай “Building the Data Warehouse” Билла Инмона (фрагменты) и “The Data Warehouse Toolkit” Ральфа Кимбалла (введение). Это two foundational books — увидишь, насколько концепции сохранились.
4. Изучи Snowflake free trial. Создай простую таблицу, загрузи 1 GB Parquet, выполни агрегационный запрос. Замерь — секунды vs Postgres минуты.