Архитектура продукта 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

Вопросы?