Архитектура продукта Thumbtack RTB Bidder
-
Upload
anatoliy-nikulin -
Category
Software
-
view
71 -
download
6
Transcript of Архитектура продукта Thumbtack RTB Bidder
N☆SQL
Опыт применения NoSQL решений в проекте Thumbtack RTB Bidder.
Или как покупать контекстную рекламу в режиме реального времени, и не утонуть в водопаде
данных.
Анатолий Никулин
RTB Architecture
Термины: RTB Exchange (SSP) - биржа, Bidder (DSP) - брокерCreative - он же баннерPublisher - сайт
CPI - Cost per ImpressionCPA - Cost per action
Real Time Core (Bidder)За 30 ms надо выбрать пару: Creative + Ставка (Bid)
Что принимаем и что отдаем
Creative
id: 123123 - идентификаторsize: 120x50 - размерsnippet : "<img src='my-image-adserver.com/1234567'/>" … ...index: { city: [omsk, moskow, spb] age: [20-25, 30-31]}
динамическиекатегории
Как хранить креатив в RDBMS?
Идеально подходящая структура - JSON
Где JSON - там и MongoDB :-)
● Динамическая структура
● Гибкий поиск по полям JSON
● Нет проблем с меняющейся схемой, в
процессе разработки.
* MongoDB хранит креативы, кампании, можно делать выборки и отчёты. Но поиск в режиме реального времени мы ей не доверили. Запилили сами внутрипроцессный кэш:-) Mongo - не для RT
Redis - оперативная статистика
Данных много и обновляются они раз в час
Статистика цен, в разных срезах:
● По дням недели
● По паблишерам
● По времени суток
● По доходности креативов
Events
1000 QPS = 86 400 000 в сутки
Зачем хранить запросы?
1. История посещений пользователя. По ней можно вычислить соц. дем. и кое-какие интересы.
rbc.ru60%
40%
habr.ru80%
20%
Зачем хранить запросы?
2. Referer. &q=”пластиковые окна”
В нем часто можно встретить поисковые запросы,
из которых также можно попытаться достать интересы.
Зачем хранить ответы?
Для анализа успешности и эффективности торговой
стратегии.
победа % поражение + цена вопроса
Данные льются в HDFSони не упорядоченны
Bulk-load
Вопросы?