9 апреля 2026 г.

Data Warehouse vs Database — разница для аналитика

Коротко

Database (база данных) — хранит текущие данные для приложений (OLTP). Data Warehouse (хранилище данных) — хранит исторические данные для аналитики (OLAP). База оптимизирована для быстрых INSERT/UPDATE одной строки. Хранилище — для быстрых SELECT по миллионам строк. Аналитик работает с обоими, но чаще с хранилищем. На собеседованиях спрашивают разницу OLTP/OLAP, ETL и архитектуру хранилища.

Быстрое сравнение

Критерий Database (OLTP) Data Warehouse (OLAP)
Назначение Операционные данные Аналитика и отчёты
Пользователи Приложение, бэкенд Аналитики, BI-инструменты
Запросы INSERT, UPDATE, DELETE SELECT (агрегации, JOIN)
Объём запроса 1–100 строк Миллионы строк
Схема Нормализованная (3NF) Денормализованная (звезда)
Данные Текущее состояние Исторические + текущие
Скорость записи Высокая Низкая (пакетная загрузка)
Скорость чтения Быстро для точечных Быстро для массовых
Примеры PostgreSQL, MySQL ClickHouse, BigQuery, Redshift

OLTP — Online Transaction Processing

OLTP-системы обслуживают приложения: регистрация пользователя, оформление заказа, обновление профиля.

-- Типичные OLTP-запросы (быстрые, точечные)
INSERT INTO orders (user_id, amount) VALUES (42, 5000);
SELECT * FROM users WHERE user_id = 42;
UPDATE orders SET status = 'shipped' WHERE order_id = 1001;

Характеристики:

  • Много мелких транзакций (тысячи/сек)
  • Каждая затрагивает 1–10 строк
  • Нормализованная схема (меньше дублирования, быстрее запись)
  • ACID-транзакции

Примеры: PostgreSQL, MySQL, Oracle, SQL Server.

OLAP — Online Analytical Processing

OLAP-системы обслуживают аналитиков: «какая выручка за квартал по категориям?», «какой retention по когортам?».

-- Типичные OLAP-запросы (тяжёлые, массовые)
SELECT
    DATE_TRUNC('month', order_date) AS month,
    category,
    SUM(amount) AS revenue,
    COUNT(DISTINCT user_id) AS buyers
FROM orders
JOIN products ON orders.product_id = products.product_id
WHERE order_date >= '2024-01-01'
GROUP BY 1, 2
ORDER BY month, revenue DESC;

Характеристики:

  • Мало запросов, но каждый сканирует миллионы строк
  • Денормализованная схема (меньше JOIN, быстрее чтение)
  • Колоночное хранение (сжатие, быстрая агрегация)
  • Данные загружаются пакетами (ETL)

Примеры: ClickHouse, BigQuery, Amazon Redshift, Snowflake, Vertica.

Архитектура хранилища

Источники данных → ETL → Data Warehouse → BI / Аналитика
   (PostgreSQL,        (ClickHouse,         (Tableau,
    API, CSV)           BigQuery)            Metabase)

ETL: Extract, Transform, Load

  1. Extract — извлечь данные из источников (БД, API, файлы)
  2. Transform — очистить, преобразовать, агрегировать
  3. Load — загрузить в хранилище

Инструменты: Apache Airflow, dbt, Fivetran, Airbyte. Подробнее — в гайде по ETL.

Звёздная схема (Star Schema)

              ┌─────────────┐
              │  dim_users   │
              │  user_id     │
              │  name        │
              │  city        │
              │  segment     │
              └──────┬───────┘
                     │
┌──────────────┐     │     ┌──────────────┐
│ dim_products │     │     │  dim_dates   │
│ product_id   ├─────┼─────┤  date_id     │
│ name         │     │     │  year        │
│ category     │     │     │  month       │
└──────────────┘     │     │  weekday     │
                     │     └──────────────┘
              ┌──────┴───────┐
              │ fact_orders  │
              │ order_id     │
              │ user_id  (FK)│
              │ product_id(FK)│
              │ date_id  (FK)│
              │ amount       │
              │ quantity     │
              └──────────────┘

Fact table (таблица фактов) — события и метрики (заказы, клики, платежи). Dimension tables (измерения) — справочники (пользователи, продукты, даты). Запрос: JOIN fact с нужными dimensions, GROUP BY dimension attributes.

Когда что используется

Аналитик работает с Database, когда:

  • Данных мало (< 10 млн строк)
  • Нет хранилища (стартап, маленькая команда)
  • Нужен ad hoc запрос к продовой БД (осторожно!)
  • PostgreSQL справляется с аналитическими запросами

Аналитик работает с Data Warehouse, когда:

  • Данных много (> 100 млн строк)
  • Нужны исторические данные и тренды
  • Множество источников (БД + API + логи)
  • Есть BI-дашборды с регулярным обновлением

PostgreSQL — одновременно OLTP и OLAP?

PostgreSQL может работать как мини-хранилище:

  • Поддерживает аналитические функции (оконные, CTE)
  • Materialized views для витрин
  • Партиционирование для больших таблиц
  • Расширения: TimescaleDB (time-series), Citus (distributed)

Но для 1+ млрд строк ClickHouse или BigQuery будут в 10–100× быстрее для аналитических запросов.

Современные тренды

Lakehouse — гибрид Data Lake + Data Warehouse. Хранит сырые данные (как Lake) с поддержкой SQL-запросов (как Warehouse). Примеры: Databricks, Delta Lake.

ELT вместо ETL — сначала загрузить сырые данные, потом трансформировать внутри хранилища (через dbt). Проще и гибче.

Real-time analytics — ClickHouse, Apache Druid, Materialize. Аналитика на данных с задержкой < 1 минуты вместо ежедневных ETL-пакетов.

Типичные ошибки

Аналитические запросы к продовой БД. Тяжёлый GROUP BY на 100 млн строк может замедлить приложение для пользователей. Используйте реплику или хранилище.

Нормализованная схема в хранилище. В OLTP нормализация — хорошо (быстрая запись). В OLAP — денормализация лучше (меньше JOIN, быстрее чтение).

Нет исторических данных. OLTP хранит текущее состояние. Если пользователь сменил город — старый город потерян. Хранилище фиксирует изменения (slowly changing dimensions).

Вопросы с собеседований

-- Чем OLTP отличается от OLAP? -- OLTP — операционные данные, много мелких транзакций, нормализованная схема. OLAP — аналитика, мало тяжёлых запросов по миллионам строк, денормализованная схема.

-- Что такое звёздная схема? -- Центральная fact table (метрики) окружена dimension tables (справочники). JOIN факта с измерениями. Оптимизирована для аналитических запросов.

-- Что такое ETL? -- Extract (извлечь данные), Transform (очистить, преобразовать), Load (загрузить в хранилище). Процесс наполнения Data Warehouse.

-- Почему ClickHouse быстрее PostgreSQL для аналитики? -- Колоночное хранение: читает только нужные столбцы. Сжатие: данные одного типа сжимаются лучше. Векторизация: обрабатывает данные батчами. Для SUM(amount) по 1 млрд строк — разница в 100×.

Потренируйтесь решать задачи — откройте тренажёр с 1500+ вопросами для подготовки к собеседованиям аналитиков.

FAQ

Нужно ли аналитику уметь строить ETL?

Понимать — обязательно. Строить — зависит от компании. В маленьких командах аналитик может настраивать dbt и Airflow. В больших — есть data engineers.

Какое хранилище выбрать?

Малый объём + бюджет → PostgreSQL с materialized views. Средний → ClickHouse (self-hosted) или BigQuery (managed). Enterprise → Snowflake, Redshift.

Как тренироваться

Data Warehouse — обязательная тема для middle+ аналитика. Задачи по SQL и архитектуре — в тренажёре Карьерник. Больше вопросов — в разделе с примерами.

Тренироваться в Telegram