Биёлайлик, биз катта реклама тармоғимиз. Биз ҳамкор сайтларда баннерлар ўрнатамиз дунё бўйлаб. Ҳақиқий вақтда воқеаларни йиғиш ва ишлаш тизимини лойиҳалашимиз керак. Бу маълумотлар икки мақсад учун жуда муҳим: Ҳисобга олиш: Кликлар учун рекламодавчилардан пул олиш. Таҳлил: Кампанияларнинг ҳозирги самарадорлигини (CTR, кўрсатишлар) шахсий панелда кўрсатиш. Кириш маълумотлари (юкламани ҳисоблаш учун) Ўзингиз талаб қилинган қувватларни баҳолашингиз керак (RPS, трафик, сақлаш), қуйидаги метрикларга асосланиб: Ҳамкор тармоқ: 500,000 фаол сайт. Трафик: Ўртача, ҳар бир сайтда сонияга 2 саҳифа кўрсатишлар олади. Реклама блоклари: Ҳар бир саҳифада бир вақтнинг ўзида 3 баннер кўрсатилади. Конверсия: Ўртача CTR (Click-Through Rate) 1%. Нотўғрилик: Пик юкланиш (кечқурун соатлари) ўртача билан солиштирганда 4 марта юқори. Ҳодиса ҳажми: Ҳодиса объекти (ID баннер, ID сайт, UserID, Timestamp, ҳодиса тури) тахминан 500 байт. Техник талаблар Near Real-Time: Аналитика интерфейсда маълумотлар 10 сониядан ортиқ бўлмаган кечиктириш билан кўрсатилиши керак. Ишончлилик: Кликларни йўқотиш қабул қилинмайди (бу тўғридан-тўғри пул йўқотишни англатади). Кўрсатишлар йўқотилиши (impressions) 0.01% гача қабул қилинади. Ўлчамлилик: Тизим платформалар сонининг ўсиши билан осонлик билан кенгайиши керак.

Для проектирования системы сбора и обработки событий в реальном времени для крупной рекламной сети с указанными параметрами, рассмотрим ключевые аспекты:

Оценка нагрузки

• Активных сайтов: 500,000
• Просмотры страниц в секунду на сайте: 2
• Баннеры на странице: 3
• CTR: 1%
• Пиковая нагрузка: ×4
• Размер события: 500 байт

Расчёт событий в секунду (RPS):

• Просмотры страниц: 500,000 × 2 = 1,000,000 в секунду
• Показов баннеров: 1,000,000 × 3 = 3,000,000 показов в секунду
• Клики: 3,000,000 × 1% = 30,000 кликов в секунду

Пиковая нагрузка: 3,000,000 × 4 = 12,000,000 показов и 30,000 × 4 = 120,000 кликов в секунду.

Трафик данных

• Показ: 500 байт × 12,000,000 = ~6 ГБ/сек
• Клик: 500 байт × 120,000 = ~60 МБ/сек

Архитектура системы

1. Сбор данных:

   • Использовать легковесные агенты или SDK на сайтах для отправки событий.
   • Протоколы: HTTP/2, gRPC или Kafka Producer для высокой пропускной способности.

2. Приём и буферизация:

   • Использовать распределённый брокер сообщений (например, Apache Kafka) для устойчивого приёма и буферизации событий.
   • Настроить партиционирование по ID сайта или баннера для масштабируемости.

3. Обработка:

   • Потоковая обработка с помощью систем типа Apache Flink, Kafka Streams или собственного сервиса на Go.
   • Клики обрабатывать с гарантией доставки (exactly-once или at-least-once).
   • Показов можно допускать небольшую потерю (0.01%), использовать компромиссы в обработке.

4. Хранение:

   • Для биллинга — база данных с транзакционной поддержкой (например, PostgreSQL, CockroachDB).
   • Для аналитики — OLAP-хранилище или колоночная БД (ClickHouse, Druid) для быстрых агрегаций.

5. Отображение данных:

   • Кэширование агрегированных данных для быстрого доступа в личном кабинете.
   • Обновление данных с задержкой не более 10 секунд.

Масштабируемость и надёжность

• Горизонтальное масштабирование всех компонентов.
• Репликация и резервирование брокеров и баз данных.
• Мониторинг и алерты на потерю данных и задержки.

Итог

• Система должна выдерживать до 12 млн событий в секунду на пике.
• Использовать распределённые технологии для приёма и обработки.
• Обеспечить гарантии доставки для кликов и минимальные потери для показов.
• Обеспечить near real-time обновление аналитики с задержкой до 10 секунд.