Real-time аналитика выручки по миллионам транзакций/день: как?

Question

IT Interview Practice · Accepted Answer

**Стримьте транзакции через Kafka в стрим-процессор, который предагрегирует их в OLAP-хранилище, чтобы дашборды читали крошечные предвычисленные rollup-ы вместо сканирования сырых событий.** При миллионах транзакций/день вы никогда не запускаете `SUM()` по сырой таблице на каждую загрузку страницы — вы агрегируете один раз, на записи.

## Архитектура

```text
Payment svc ──▶ Kafka topic ──▶ Flink/Kafka Streams ──┬─▶ OLAP (ClickHouse/Druid)  ◀── Dashboard
 (txn events)   (buffer,replay)   (windowed pre-agg)    │      (per-minute rollups)     (read)
                                                         └─▶ S3/Parquet (raw, replay/audit)
                                     state store ◀──────────┘  (exactly-once checkpoints)
```

## Как это работает

- **Kafka** — durable-лог. Каждый платёж публикует событие (`amount`, `currency`, `ts`, `merchant`). Он буферизует всплески, отделяет производителей от потребителей и позволяет **переиграть** историю для перестройки агрегатов.
- **Стрим-процессор (Flink / Kafka Streams)** держит **tumbling/sliding-окна** (поминутно/почасово) и сворачивает каждое событие в текущий итог в своём **state store**. На выходе — предагрегированная строка на (минута, измерение).
- **OLAP-хранилище (ClickHouse, Druid, Pinot)** хранит эти rollup-ы колоночно. Дашборд, запрашивающий «выручку за 24 ч», сканирует ~1440 строк, а не миллионы — доли секунды.
- **Материализованные представления** в ClickHouse могут делать тот же rollup внутри БД (`AggregatingMergeTree`), если хочется меньше движущихся частей.

## Взгляд с точки зрения интервью

Интервьюер прощупывает, делаете ли вы **предагрегацию на записи против скана на чтении** и понимаете ли **exactly-once**. Хорошие ответы называют Kafka + OLAP; отличные объясняют, **почему поздние/дублирующиеся события портят итоги** и как это чинить: идемпотентные ключи, **checkpointing + транзакционный sink** во Flink для exactly-once и **watermarks** для закрытия окон несмотря на поздние прибытия. Частая ловушка — предлагать `SELECT SUM()` на Postgres — нормально при тысячах/день, оно рушится при миллионах.

## Компромиссы и сбои

- **Lambda против Kappa.** Lambda запускает batch-слой (ночной Spark сверяет источник истины) рядом со стрим-слоем (быстрый, но приблизительный) — точно, но две кодовые базы. **Kappa** использует только стрим-слой и **переигрывает Kafka** для исправления багов — проще, одна кодовая база, теперь это распространённый дефолт.
- **Exactly-once не бесплатен.** Транзакционные sink-и добавляют latency и стоимость throughput; многие команды вместо этого принимают **at-least-once + идемпотентные upsert** по ключу `txn_id`.
- **Поздние данные.** Платёж, рассчитавшийся на 2 ч позже, приходит после закрытия своего окна. Watermarks + allowed-lateness заново открывают окна, либо ночной batch-джоб корректирует вчерашние числа.
- **Мультивалютность / возвраты** должны моделироваться как знаковые события, иначе «выручка» уплывает.
- **Когда не нужно:** несколько тысяч транзакций/день не требуют ничего из этого — rollup-таблица в Postgres, обновляемая cron-ом, побьёт кластер Kafka+Flink, который надо эксплуатировать.

Архитектура

Как это работает

Взгляд с точки зрения интервью

Компромиссы и сбои

Похожие вопросы