Как агрегировать CTR по минутам и где хранить результат
Как должен выглядеть stream job для CTR dashboard: что он читает, что считает и куда пишет результат для графика рекламодателя?
Короткий ответ
Stream job читает impression/click, группирует по campaign_id и time bucket, считает impressions/clicks/CTR, пишет агрегаты в OLAP storage вроде ClickHouse для dashboard API.
Полный разбор
Stream processing слой читает события из Kafka, валидирует схему, дедуплицирует по event_id, назначает event-time bucket и агрегирует counters: impressions, clicks, возможно spend и другие метрики.
Ключ агрегации: campaign_id + bucket_start + dimensions, если нужны разрезы по placement, region или device. CTR лучше хранить не только как ratio, а как числитель и знаменатель: clicks и impressions. Тогда можно корректно пересчитывать CTR на больших окнах.
Результат пишется в хранилище для аналитических запросов: ClickHouse/Druid/Pinot/Timescale в зависимости от требований. Dashboard API читает уже агрегированные ряды, а не сырые события. Для свежих данных можно хранить minute buckets, а для истории компактизировать в 5-minute/hour/day buckets.
Теория
Realtime dashboard обычно строится как pipeline: event log -> stream aggregation -> OLAP/time-series storage -> API/dashboard.
Типичные ошибки
- Пытаться читать сырые события из dashboard.
- Хранить только CTR и потерять clicks/impressions.
- Не учесть late events и backfill/compaction.
Как отвечать на собеседовании
- Опиши pipeline по слоям.
- Скажи, что CTR хранится как clicks/impressions, а не только ratio.