Sobes.tech
ინტერვიუს დახმარება
რესურსები
ინტერვიუს მომზადება
რესურსები
სამუშაოს ძებნა
რესურსები
იურიდიული
დავუბრუნდეთ კითხვებს
Senior

დავუშვათ, ჩვენ დიდი რეკლამა ქსელი ვართ. ჩვენ ვაყენებთ ბანერებს პარტნიორ საიტებზე მთელ მსოფლიოში. ჩვენ უნდა შევქმნათ რეალურ დროში მოვლენების შეგროვებისა და დამუშავების სისტემა. ეს მონაცემები კრიტიკულია ორი მიზნისთვის: გადასახადები: რეკლამატორებიდან კლიკებზე თანხის ჩამოჭრა. ანალიტიკა: მიმდინარე კამპანიების ეფექტიანობის ჩვენება (CTR, ჩვენებები) პირად პანელზე. შესავალი მონაცემები (საწვავის გამოთვლისთვის) თქვენ უნდა შეაფასოთ საჭირო შესაძლებლობები (RPS, ტრაფიკი, შენახვა), დაყრდნობით შემდეგ მეტრიკებს: პარტნიორი ქსელი: 500,000 აქტიური საიტი. ტრაფიკი: საშუალოდ, თითოეული საიტი იღებს 2 გვერდის ნახვას წამში. რეკლამა ბლოკები: თითოეულ გვერდზე ერთდროულად გამოჩნდება 3 ბანერი. გადაყვანა: საშუალო CTR (Click-Through Rate) 1% არის. არასამართლიანობა: პიკი დატვირთვა (საღამოს საათები) ოთხჯერ მაღალია საშუალოსთან შედარებით. შემთხვევის ზომა: შემთხვევის ობიექტი (ID ბანერი, ID საიტი, UserID, Timestamp, შემთხვევის ტიპი) დაახლოებით 500 ბაიტია. ტექნიკური მოთხოვნები Near Real-Time: მონაცემები ანალიტიკური ინტერფეისში უნდა გამოჩნდეს მაქსიმუმ 10 წამის დაგვიანებით. სანდოობა: კლიკების დაკარგვა მიუღებელია (ეს პირდაპირი თანხის დაკარგვაა). ჩვენება დაკარგვა (impressions) მისაღებია 0.01%-მდე. სკალირებადობა: სისტემა უნდა იყოს ადვილად გაფართოებადი პლატფორმების ზრდასთან ერთად.

sobes.tech AI

პასუხი AI-სგან

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

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

  • Активных сайтов: 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 секунд.
წინაშემდეგი