Сравнение OLTP и OLAP (кратко по пунктам)
- Архитектура
- OLTP: оптимизирован под транзакции, низкая задержка, высокая конкуренция записей/чтений; чаще кластер из реляционных СУБД (мастер/репликации или распределённые ACID-системы).
- OLAP: оптимизирован под аналитические запросы (сканы, агрегации); архитектура — хранилище данных/дата-лейк + MPP/колоночные движки, поддержка батч/стрим обработки.
- Требования к хранению и формату
- OLTP: строчно-ориентированное хранение, нормализованные схемы, индексы по PK/FK, быстрые случайные записи, сильные ACID-границы.
- OLAP: колонночные форматы (Parquet, ORC, ClickHouse), денормализованные звёздные/снежинные схемы (fact + dimensions), сегментация/партицирование для сканов.
- Доступ и SLA
- OLTP: миллисекундные ответы, тысячи+ TPS, согласованность данных.
- OLAP: секунды–минуты для тяжёлых запросов, высокая пропускная способность на чтение, оптимизация под большие сканы и агрегации.
- Индексация и оптимизации
- OLTP: B-tree/Hash индексы, транзакционные логи, репликация для чтений.
- OLAP: партицирование по времени/ключу, сортировочные ключи (clustering), проекции, материализованные агрегаты, сжатие.
Стратегия хранения и агрегирования для интернет‑магазина с $10^7$ пользователей и аналитикой по поведению
1) Оценки объёмов (пример, укажите свои метрики)
- Пусть среднее действий на пользователя в день = $a=5$. Тогда событий в день:
$$E_{day}=a\times U=5\times 10^7=5\cdot 10^7.$$ - Если средний размер ивента $s=1,000$ байт, суточный объём:
$$S_{day}=E_{day}\times s=5\cdot 10^7\times 10^3=5\cdot 10^{10}\text{байт}(\approx 50\text{GB}).$$ - Годовой сырый объём ≈ $S_{year}=S_{day}\times 365\approx 18,250\text{GB}(\approx 17.8\text{TB}).$
2) Компоненты архитектуры (рекомендация)
- OLTP слой: реляционная СУБД для транзакций (Postgres / Amazon Aurora / CockroachDB). Нормализованные таблицы: users, products, orders, payments. Обеспечить ACID.
- CDC/интеграция: логическая репликация (Debezium) → Kafka (event bus). Все изменения и события (клики, просмотры, add-to-cart, order) в поток.
- Raw landing (data lake): сохранять поток в S3/ADLS в колонночном Parquet/ORC (партиционирование по дате).
- Stream‑аналитика (реал‑тайм): движок типа ClickHouse / Druid / Materialize / Pinot для минутной/секундной свежести метрик; агрегаты в реальном времени (DAU, конверсия).
- DW для сложной аналитики: BigQuery / Snowflake / Redshift Spectrum для ELT и ad-hoc BI, модель звезда (факты + размерности).
- Data marts / BI: агрегированные таблицы и витрины для дашбордов и аналитики.
3) Моделирование данных (рекомендуемые таблицы)
- Фактная таблица событий (fact_events) — денормализованный: $‘even{t}_{i}d‘,‘use{r}_{i}d‘,‘sessio{n}_{i}d‘,‘even{t}_{t}ype‘,‘produc{t}_{i}d‘,‘ts‘,дополнительныеатрибуты‘$. Партиционирование по дате (`ts`), кластеризация по `user_id`/`product_id`.
- Факт заказов (fact_orders) — агрегаты по заказам; связи с users, products.
- Размерности: dim_users (актуальные профили), dim_products, dim_campaigns.
- Хранить сырой поток (raw_events) в дата-лейке без преобразований для повторной обработки.
4) Агрегации и расписание
- Near‑real‑time (каждую минуту/5 минут): ключевые KPI (DAU, корзина, конверсия, revenue per minute) — поддерживать в OLAP-движке стримовыми агрегатами (Kafka Streams / materialized views).
- Часовые: предагрегаты по сегментам (country, device, acquisition_channel) — materialized views или batch jobs.
- Дневные/ночные ETL (ELT): полные денормализованные витрины и исторические агрегаты в DW.
- Хранение сырья: hot хранение $T_{hot}=90$ дней, холодный архив > $T_{cold}=1$ год (S3 + glacier).
5) Технические оптимизации и приближённые алгоритмы
- Использовать проекции/материализованные представления для часто вызываемых срезов (funnels, retention).
- Эффективные структуры для уникальных пользователей: HyperLogLog для уникальных подсчётов (DAU/MAU) — экономит память.
- Heavy-hitters/Top-k: Count-Min Sketch или streaming top-k.
- Sessionization — в стриме с оконной агрегацией по session_id с таймаутом (например, 30 минут).
- Downsampling для долгой истории: оставить полные события $T_{detailed}=90$ дней, затем аггрегаты по дням/неделям для «старых» периодов.
6) Партицирование, индексирование, шардирование
- Партицирование фактов по дате (`dt = DATE(ts)`) + дополнительные локальные сегменты по `user_id % N`, где $N$ выбирается по объёму (напр., $N=256$ или $512$).
- Кластер/сортировка по `user_id` и `product_id` для ускорения пользовательских срезов и join-ов.
- В OLTP — индексы по PK, FK и по полям с высокочастыми селектами (email, user_id, order_id).
7) Примеры агрегатов и частота
- DAU: агрегировать в реальном времени → окно 24h sliding → обновление каждую минуту.
- Conversion rate: events(add_to_cart → purchase) — precompute funnels в стриме; hourly rollups.
- Cohorts/Retention: ежедневные когорты, расчёт retention на DW (батч).
- LTV by acquisition channel: nightly ETL, сложные расчёты в DW.
8) Резервирование, мониторинг, тестирование
- Мониторить задержки CDC → Kafka → OLAP pipeline, метрики обработки сообщений и задержек.
- Тестировать восстановление из raw-лейка (replay).
- Авто‑скейлинг для OLAP‑кластера при пиковых нагрузках (распродажи).
9) Пример стека (вариант)
- OLTP: PostgreSQL / Aurora; CDC: Debezium → Kafka.
- Raw: S3 (Parquet).
- Real‑time OLAP: ClickHouse/Druid для быстрых дашбордов.
- DW: BigQuery / Snowflake для BI и сложной аналитики.
- Orchestration: Airflow / Dagster; BI: Looker / Superset / Metabase.
Короткая сводка по подходу: OLTP — хранить транзакции корректно и эффективно; весь поток событий дублируется в Kafka → raw lake → два пути: (1) стрим‑агрегаты в ClickHouse/Druid для моментальной аналитики, (2) регулярный ELT в DW (Snowflake/BigQuery) для сложных отчётов и исторической аналитики; использовать партицирование, материализованные представления и приближённые структуры (HLL, CMS) для масштабирования при $10^7$ пользователях.
Если хотите — могу дать схему конкретных таблиц (DDL) и пример расписания ETL/SQL для типичных отчётов.