Спроектируйте сбор кликстрима через Kafka
Вопрос
Сайт и мобильное приложение генерируют события поведения (просмотры, клики, добавления в корзину): 50 тысяч событий в секунду в пике, 2 млрд в сутки. Нужны: дашборды с задержкой до минуты, сырые данные в хранилище для аналитиков и ML, хранение 2 лет. Спроектируйте пайплайн.
Коротко
Что должно быть в решении
- 1Требования: потребители, свежесть, хранение 2 лет, потери допустимы или нет, ПДн и согласия
- 2Оценка нагрузки: 50 тысяч в секунду, размер события, объём в Kafka за неделю retention и в хранилище за 2 года
- 3Сбор: SDK с батчингом и ретраями, приёмный сервис (collector) с валидацией по схеме, запись в Kafka с ключом по пользователю или сессии
- 4Kafka: число партиций с запасом, репликация 3, acks=all, retention, Schema Registry
- 5Потребители: стриминг агрегатов для дашбордов (Flink или ClickHouse Kafka engine), выгрузка сырья в объектное хранилище в Parquet по часам
- 6Качество: дедупликация по id события, опоздавшие события, невалидные в отдельный топик
- 7Эксплуатация: мониторинг lag, объёма, доли невалидных, стоимость хранения и политика удаления
Что спросит интервьюер
- Как обработать события, пришедшие с телефона через сутки?
- Как поменять схему события, не сломав потребителей?
- Сколько партиций вы заведёте и почему?
Разбор
Сильный ответ отделяет приём от обработки: collector быстро валидирует и пишет в Kafka, а дальше независимые группы консьюмеров делают дашборды и сырой слой. Ключ партиционирования выбирается под порядок (пользователь или сессия) с оглядкой на горячие ключи. Схемы в реестре с правилами совместимости. Дедупликация по id события, явная политика для опозданий, невалидные события не теряются, а уходят в отдельный топик. Объёмы посчитаны, и хранение 2 лет идёт в сжатом Parquet в объектном хранилище, а не в Kafka.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.