Базы данных
System Design: аналитическая платформа
Netflix анализирует поведение 260 миллионов пользователей: какой контент смотрят, на каком моменте бросают, какой thumbnail кликают. Это петабайты событий ежедневно. Обычный PostgreSQL задохнётся на таком масштабе. Netflix использует Apache Iceberg + Spark + Trino - запросы к триллионам строк за секунды.
- **Cloudflare**: ClickHouse обрабатывает 36M HTTP запросов/сек в режиме real-time аналитики
- **Shopify**: Snowflake + dbt - 500+ dbt моделей, ежедневная аналитика транзакций миллионов магазинов
- **ByteDance (TikTok)**: ClickHouse кластер 10,000+ нод для аналитики рекомендательной системы
OLTP vs OLAP: два мира
OLTP (Online Transaction Processing) оптимизирован для коротких транзакций: INSERT, UPDATE, SELECT по primary key. OLAP (Online Analytical Processing) оптимизирован для аналитических запросов: GROUP BY, агрегации по миллиардам строк. Одна БД не может быть хороша в обоих - это разные trade-offs в хранении, индексах и оптимизаторе.
Amazon разделил OLTP (Aurora) и OLAP (Redshift) ещё в 2012. Shopify хранит транзакции в MySQL (OLTP), аналитику в Snowflake (OLAP). Netflix использует Apache Iceberg как единый формат для data lake поверх S3, с запросами через Spark и Trino.
Почему нельзя запускать OLAP аналитические запросы прямо на production OLTP базе?
Star и Snowflake схемы
Star schema - центральная fact table (события: продажи, клики, поездки) окружена dimension tables (время, продукт, пользователь, geography). Денормализована: нет join между dimension tables. Snowflake schema нормализует dimension tables - меньше дублирования данных, но больше join'ов при запросе.
Amazon Redshift рекомендует star schema как основной паттерн. Walmart использует одно из крупнейших data warehouse в мире на Teradata со star schema - 2.5 петабайта транзакций розничной торговли. Facebook Analytics использует Hive/Presto с денормализованными wide tables для ad performance.
В чём преимущество star schema над snowflake schema для OLAP запросов?
ClickHouse: колоночное хранилище
ClickHouse - open source колоночная СУБД от Яндекса, используется Cloudflare, Uber, ByteDance. Колоночное хранение: данные одной колонки хранятся рядом - агрегации читают только нужные поля. Для аналитики SELECT sum(revenue) FROM fact_sales читает одну колонку, не все. MergeTree engine: данные пишутся в parts, которые периодически сливаются.
Cloudflare использует ClickHouse для обработки 36 миллионов HTTP запросов в секунду с логированием в real-time. ByteDance (TikTok) использует ClickHouse кластер из 10,000+ нод. Uber перешёл с Vertica на ClickHouse для некоторых аналитических задач - экономия 90% затрат при сравнимой производительности.
Почему колоночное хранилище быстрее для аналитических агрегаций чем строковое?
Materialized Views и предагрегация
Materialized View - предвычисленный результат запроса, хранящийся как таблица. При новых данных MV обновляется инкрементально. В ClickHouse MV запускается автоматически при каждой вставке в source table - это не периодическое обновление как в PostgreSQL, а real-time агрегация на лету.
PostgreSQL Materialized View требует явного REFRESH MATERIALIZED VIEW - это batch обновление, не real-time. Для real-time в PostgreSQL используют pg_ivm (incremental view maintenance) или внешние ETL. TimescaleDB Continuous Aggregates - аналог ClickHouse MV для временных рядов.
Чем ClickHouse Materialized View отличается от PostgreSQL MATERIALIZED VIEW?
Data Pipeline архитектура
ETL (Extract-Transform-Load) традиционная модель: данные трансформируются до загрузки в DWH. ELT (Extract-Load-Transform) современная модель: сырые данные загружаются в data lake/DWH, трансформации выполняются на месте SQL/dbt. Lambda architecture совмещает batch (точность) и stream (актуальность) обработку.
Airbnb разработал Airflow (Apache) для оркестрации pipeline. Shopify использует dbt для трансформаций в Snowflake - 500+ моделей. Lyft разработал Amundsen - data discovery tool с метаданными о всех dataset. GitLab открыл весь analytics stack: Snowflake + dbt + Airflow.
Для аналитики достаточно PostgreSQL с хорошими индексами - специализированные OLAP БД не нужны
PostgreSQL хорош для OLAP до ~100GB. При терабайтах данных и сложных аналитических запросах колоночные СУБД быстрее в 10-100x
PostgreSQL - строковое хранилище: для SELECT sum(revenue) читается каждая строка целиком. ClickHouse читает только колонку revenue. При 50 колонках и 10B строк разница в I/O составляет 50x. Плюс ClickHouse применяет vectorized execution и SIMD инструкции CPU для агрегаций.
В чём ключевое различие ETL и ELT подходов?
Итоги
- **OLTP vs OLAP** - два разных trade-off: row store для транзакций, column store для агрегаций
- **Star schema** - факт-таблица + измерения, денормализована для минимизации join'ов в аналитических запросах
- **ELT + dbt** - сырые данные в data warehouse, трансформации SQL внутри; ClickHouse MV для real-time pre-aggregation
Связанные темы
Аналитические системы строятся на нескольких фундаментальных концепциях:
- Партиционирование — ClickHouse и Snowflake используют partition pruning для пропуска ненужных партиций в аналитических запросах
- Time-series базы данных — TimescaleDB Continuous Aggregates - аналог ClickHouse Materialized Views для временных рядов
- LSM-Tree — ClickHouse MergeTree - вариация LSM-Tree: данные пишутся в parts и периодически merge-ируются
Вопросы для размышления
- Компания выбирает между ClickHouse и Snowflake для аналитики. Snowflake - managed сервис, ClickHouse - self-hosted. Какие факторы определяют выбор помимо стоимости?
- dbt incremental model обрабатывает только новые строки по условию created_at > max(created_at). Какие данные этот подход пропустит и как это починить?
- Lambda architecture совмещает batch и stream слои. В каких случаях Kappa architecture (только stream) является более простой альтернативой?