Какие события класть в Kafka и как партиционировать
Для realtime CTR dashboard нужно описать Kafka/event log. Какая схема события нужна и по какому ключу партиционировать?
Короткий ответ
События: impression/click с event_id, campaign_id, ad_id, advertiser_id, timestamp, dimensions. Для агрегации CTR ключом часто делают campaign_id или campaign_id+time bucket.
Полный разбор
В Kafka кладем immutable events: impression и click. Минимальная схема: event_id, event_type, timestamp, campaign_id, ad_id, advertiser_id, user/session id в безопасной форме, placement, region/device, price/cost при необходимости.
Ключ партиционирования зависит от агрегации. Если dashboard в основном строит CTR по campaign_id, полезно партиционировать по campaign_id, чтобы события одной кампании попадали в один поток обработки или по крайней мере стабильно распределялись. Но при hot campaigns может понадобиться salting: campaign_id + shard.
Нужно обсудить порядок, дубликаты и late events. Event_id помогает дедупликации, event time нужен для правильных окон, ingestion time - для мониторинга задержки. Click может прийти после impression с задержкой, поэтому stream job должен учитывать watermark/allowed lateness.
Теория
В streaming system design ключ партиционирования выбирают под будущую агрегацию и hot-key риски.
Типичные ошибки
- Сказать "кладем логи" без схемы события.
- Партиционировать случайно и потом делать глобальный shuffle.
- Не обсудить late events и deduplication.
Как отвечать на собеседовании
- Назови схему impression/click события.
- Скажи про campaign_id как ключ и hot campaign salting.