6. Аукцион второй цены
• Выигравший участник платит вторую цену +
delta (1 цент, 1 копейка)
• Если участник один, оплачивается
минимальная цена (floor cpm) + delta
• Аукцион второй цены стимулирует
участников называть реальную цену
• Время ответа: 100ms
7. Основные субъекты рынка
• SSP (Sell Side Platform) – обслуживает
интересы площадок
• DSP (Demand Side Platform) – обслуживает
интересы рекламодателей
• DMP (Data Management Platforms/Data
Exchange) – собирает данные о
пользователе
8. SSP
• Обслуживает интересы площадок
размещения (сайтов)
• Технологически проще DSP
• По сути, одинаковая бизнес-модель у всех
SSP
9. DSP
• Обслуживает рекламодателей
• Сложнее чем SSP
• Разные бизнес модели: retargeting, search
retargeting, audience targeting
• Разные модели оплаты: pay-per-click, pay-
per-conversion
10. Retargeting
• Показываем рекламу только тем
пользователям, которые уже были на сайте
рекламодателя
• По статистике, вероятность конверсии
может вырасти с 0.005% до 0.9%
11. Audience targeting
• Показываем объявления только
заинтересованной аудитории
• Например, показываем рекламу новой
Honda посетителям автомобильных сайтов
• Данные можно брать свои, можно покупать
у DMP
12. Pay-per-click/pay-per-conversion
• Рекламодатель платит DSP только в случае
совершения пользователем целевого
действия (клик, конверсия)
• DSP всегда платит SSP за показы
• Вывод: DSP должна хорошо уметь
оценивать вероятность клика/конверсии
19. Что еще?
• До RTB-эры данные о пользователе (частота
показов, посещенные сайты) хранились в
cookie
• Cookie sync обеспечивает только
синхронизацию ID. Остальное нужно
хранить в БД на стороне DSP (NoSQL )
21. Основные проблемы
• HTTP-нагрузка (тысячи входящих и
исходящий HTTP-запросов в секунду)
• Хранение и анализ логов (10-100Gb в день)
• Online хранилища (match table, user table)
• Machine learning: алгоритмы предсказания
кликов/конверсий
22. HTTP-нагрузка
• Средняя SSP: 5 000 входящих, 20 000
исходящих запросов в секунду
• Средняя DSP: 10 000 входящих запросов в
секунду
23. HTTP-нагрузка, что делать?
• Не боятся!
• Использовать Java/C++, остерегаться Python
и PHP
• Использовать event-driven подход, lock-free
синхронизацию и т.д.
28. Что храним?
SSP USER ID SSP INTERNAL USER ID
10:22741675 adfox 03goMw3rI64
USER ID USER DATA
03goMw3rI64 Частота показов по кампаниям и т.д.
Cookie sync table (100 млн записей)
User data (100 млн записей)
29. Требование к хранилищу
• Ответ на чтение: 10ms (помним, timeout
всего аукциона 100ms)
• Хранение всех данных в RAM
• Цена! И еще раз цена!
• Легкое масштабирование
30. Чего требовать не надо
• Надежности
• 99,99% availability – более, чем достаточно
33. Проблемы
• Данных много: 10-100Gb в день
• Люди хотят быстро получать ответы на
сложные вопросы: сколько у нас есть
показов в Киеве людям в возрасте 20-25
лет, которые до этого искали билеты на
самолет в Яндексе
35. Философия данных
• Там где идет речь об аналитике, как
правило, скорость ответа важнее точности
• Там, где идет речь о деньгах, как правило,
точность важнее скорости
36. Как пожертвовать точностью?
date domain city impressions (показы)
2013-01-14 12:12 a.com Moscow 1
Считаем показы в Москве за один день:
SELECT sum(impressions) WHERE
city=‘Moscow’ and date=‘2013-01-14’
37. Sampling
• Выбросим случайны 9 строчек из 10
• Для оставшихся строчке умножим
impressions на 10
• SELECT sum(impressions) WHERE
city=‘Moscow’ and date=‘2013-01-14’
date domain city impressions (показы)
2013-01-14 12:12 a.com Moscow 10
38. Sampling – считаем ошибку
• Пусть в ответе на запрос мы получили число
N
• Тогда оценка ошибки:
• При N=1 000 000, ошибка: 0.6%
2
N /10
44. Колоночные БД
• Важно! Hbase, Cassandra – не колоночные
• Пример: SELECT sum(impressions) WHERE
city=‘Moscow’ and date=‘2013-01-14’
• Будут прочитаны только файлы для с
данными impressions и city
45. Колоночные БД – преимущества
• Данные хорошо сжимаются (данные в
колонках однородные)
• Скорость агрегирующих запросов в разы
выше
• Недостатки: сложность загрузки данных
48. Несколько фактов
• На рынке есть хорошие open-source
решения
• Лучше плохой алгоритм, чем никакой
• Алгоритм важен, но еще важнее параметры
обучений (features) и настройки
- Всемдоброеутро! Яприятноудивлен, чтовстольраннийчассобралосьтакмноголюдей. Значиттемадостаточноинтересная.(Всемдоброеутрохорошо, чтолюдейтакнемного. Значитвывсенастольколюбите RTB, чтоготовыпожертвоватьутреннимсном)(пауза)Вообще, язанимаюсьвсякимиштукамиоколо RTB ужепочти 4ре года, имогурассказатьоченьмногоинтересного. Вообщемойдоклад, скореепростыкбизнесаитехнологии, прото, какбизнесдиктуеттехнологическиеусловиявданнойобласти. Слайдовяприготовилмного, такчтонеуверен, чтопровсеуспеюрассказатьподробно. Хочуспроситьувас: подминимитеруките, комускореепробизнесаспекты RTB? Акомупротехнологии?И еще последний момент. В любой момент вы можете прервать меня и задавать вопросы. Возможно, мы я тогда про что-то не успею рассказать, но это лучше недопонимания. На простые вопросы я буду отвечать сразу.Однако, если вопрос сложный, я его с вашего позвления пропущу, и отвечу после в частном порядке
RTB. Расшифровываетсякак Real time bidding, илиаукционреальноговремени. Этонекотораяпопыткаперенестибиржевыемоделивмиронлайнрекламы. Насамомделе, доконцанеясночтоизэтоговышло. Рынокпоявилсягде-тов 2009-ом годуидосихпорстремительноэволюционирует
Самаяраспостраненнаямодель - retargeting.- (!!!!!) КСТАТИ, НАВЕРНОЕ, У МНОГИХ ТУТ СТОИТ AD-BLOCK ИЛИ ЧТО-ТО ВРОДЕ ЭТОГО. ПОДНИМИТЕ РУКУ, У КОГО ОН ЕСТЬ?- Остальные, наверное, знаютчтотакоеретаргетинг. Этокогдавыодинраззашливинтернет-магазин, апослецелыймесяцвасмучаетрекламаэтогожемагазина.- Каксказалодинмойзнакомый: невозможнокупитьженеподарокнановыйгодвинтернете, чтобыонаобэтомнеузнала. Хотя, думаю, этонесамаянеловкаяситцацяикотораяможетвсвязисретаргетингомвозникнуть- Итого, идеяретаргетингапонятно. Надопонимать, чтоделаетсяэтонеизвредности. Статистика - упрямаявещь. Вероятностьконверсииприусловиипоказаретаргетированногобаннерасущественновыше
Итого, длясоответсвияпользователейнужнохранитьтакуютаблицуиздвухколонок, коотораяназывается match tableНадопонимать, чтовмиререкламыпользовательэтонетожесамое, чтопользовательсайта. Людиимеютсвойствотеретькуки, менятьбраузерыит.д. Такчтодлясредней DSP таблицапользователейможетбытьот 10 до 100 млн.Ещевпрошломслайдебылапредставленачутьупрощеннаякартинамира. Всеможетбытьнесколькосложнее. Такчтовзависимостиотреализации cookie sync table могутхранитькак SSP, таки DSP. Лучшебы, чтобывсегдахранили SSP, ноэтонетак
Ещепарумоментовпро cookie sync. Взависимостиоттого, гдестоитпиксельнастороне SSP или DSP, различаютдвавида
Чтотутещеможносказать? Ну, например, еслираньшетакуюинформацию, какчастотупоказовбаннера, илипоследнийпоказбаннерахраниливкуках, топри RTB этовозможностьисчезла. Механизм cookie sync имеетограничения, такчтотакиевещиприходитсяхранитьв БД настороне DSP. Обычно, используютсявсякиеNoSQLрешения.
----- Meeting Notes (4/21/13 23:08) -----И так, переходим к самому интересному. К обзору технологий, которые позволяют работать всей этой экосистеме.Если приглядется, на картинке изображен двигатель машины марки Лада, которая отличается качеством.На самом деле, в мире RTB все так же. Нет устоявшихся технологий и компании не могут много вкладывать в IT. Зато получается очень весело и интересно!
Ну, первыйпункт, этонебоятся. ПОДНИМИТЕ РУКИ ТЕ, КТО ПИСАЛ СИСТЕМЫ ОБРАБАТЫВАЮЩИЕ более 1000 запросоввсекунду?Вотвидете, этонетакстрашно. Современноежелезоифреймворкидовольномощные.Еще, конечно, надописатьна Java или C++. Ну, есливзятьэкзотикуerlangтожеможетбытьподойдет. Главное, избегать PHP и Python. Наверное, наэтихтехнологияхможночто-тонаписать, ноуспешныеисториимненеизвестны. Нуиобязательносмотритевсторону event-driven программирования, lock free синхронизацииивообщевсторонувсяхновыхмногопоточныхштук
Несколькопримеровтого, чтостоитиспользоватьдля Java иС++. В C++ яразбираюсьнеочень, такчтотамможетбытьещечто-нибудьесть.
Золотое правило рекламы. Все храним только в оперативной памяти
Это относится ко всем рекламным кампаниям, таргетингам, настройкам. Никаких SQL-запросов.На диск можно писать только логи
Так, с HTTP разобрались. Теперь про хранение данных о пользователях.
Во-первых скорость и еще раз скорость. Время чтения не должно превышать 10 милисекунд. Ну или такого порядка. Помним, что на аукционный запрос надо ответитьза 100 миллисекундИз скорости сдедуют, что хранилище должно читать данные из памяти, диск не должен быть задействован. Да, на диск будет происходить запись, потому что надежностьнам все-таки не повредит. Но чтение – только оперативная памятьЕще важна цена. Если это платное решение, и хранение пользователя стоит 1 доллар за 1000 пользователей, то при 100 миллионах записей месячная цена будетоколо 100 000 долларов. Такие затраты посильны для банков, но не для DSPНу еще неплохо бы чтобы эта штука легко масштабировалась. Бизнес DSP штука нестабильная с непредсказуемым ростом
А теперь еще более важная штука – что требовать не надо. На самом деле, в таких вещах всегда важно смягчать требования там, где это возможно. Это может упростить жизнь в несколько раз.Как ни странно слышать это про базы данных, но в данном случае нам не нужна надежность. База может иногда терять данные, не отвечать на запросы и т.д. Если одному из миллиона пользователеймы покажем не тот баннер или же не покажем ничего – не страшно. Главное, чтобы ошибки не были системными и были распределенными.
Вот список вариантов для хранения данных о пользователе, которые существуют на рынке. Кстати, про MySQL/PostgreSQL. Я не знаю, можно ли их эффективно использовать как key value storage для таблиц с 100 миллионами строк. Если кто-то расскажет, буду благодарен.
И так, самое интересное. Это оффлайновая обработка данных. Обычно, на каждое действие (показ, аукцион, клик) пишется строчка в лог, а потом люди хотят по этим логам получать какую-то аналитику.Например, статистические отчеты.ЭТА САМАЯ ИНТЕРЕСНАЯ ЧАСТЬ ДОКЛАДА. ТОТ, КТО ЕЩЕ НЕ ПОТЕРЯЛ ИНТЕРЕСА, УЗНАЕТ, КАК СОКРАТИТЬ ОБЪЕМ ХРАНИМЫХ ДАННЫХ в 10 РАЗ НЕ ПОТЕРЯВ ПРАКТИЧЕСКИ НИЧЕГО
И так, какие с логами есть проблемы. Например, из много. В зависимости от размера DSP от 10 до 100 гигабайт в день.Во-вторых, люди хотят быстро получать ответы на сложные вопросы. Например ????
И так, про философию данных в RTB.Посмотрите на скришоты, всем видно? Это типичные разговоры про данные с конечными пользователями. (Зачитать, если не видно??)
Итак, выводы из предыдущих скриншотов. Вывода два и они очень важны:
Как пожертвовать точностью и как-то от этого выиграть? Сейчас я приведу пример довольно простой техники.Практическая задача: у нас есть логи показов баннеров. Будем считать количество показов в городе Москва за 14 января сего года. Для удобства, представим, что все у нас хранится в SQL таблице. Тогда запрос будет выглядеть примерно так.Помним о средних размерах DSP, это может быть 30 миллионов показов в сутки. Что же делать?
Ответ – sampling. Около каждой строчки подкинем 10гранный кубик. Если выпала единичка, оставляем строчку. Иначе выкидываем.Итого мы выкиним 9 из 10 строчек. А в оставшихся строчках давайте домножим количество показов на 10.И выполним тот же запрос. Выглядит радикально?
На самом деле нет! Пусть в ответ на запрос (помним, мы считаем количество показов в москве от 14 января) мы получили число N. Тогда статистическая ошибка будет ….Ну например, если у нас был в Москве один миллион показов, то ошибка будет около половины процента, т.е. совсем не много
Как видно, чем меньше ответ, тем больше значение ошибки. Однако, если мы вспомним наш изначальный кейс, когда цифра по показам нужна менеджеру по продажам, то и 10% ошибка не страшна.Сильно большая ошибка возникает, когда ответ на вопрос менее 3000. Но в этом случае, ответ настолько мало отличается от 0, что и ошибка в общем-то не важна
Ладно,Sampling это просто, есть вещи куда интереснее. Например, давайте добавим колонку идентификатор пользователя в наш лог. И попытаемся посчитать количество уникальных пользователей за один день.Опять же, для простоты будем мыслить в терминах SQL. Посмотрите на запрос, это еще мощнее чем предыдущий. sum относительно простая операция по сравнению с count distinct
Что же делать? Есть куча вероятностных алгоритмов для подсчета уникальных пользователей с ошибкой. К сожаление, в рамках доклада нет времени рассказывать о них подробно, но они довольно красивые.Советую погуглить и почитать.
Так, давайте резюмируем и поговорим про конкретные технологии, а не про алгоритмы.Во-первых, в большинстве случаев используется несколько технологий, для разных задач.В целом популярен Hadoop. Он стабилен, относительно других NoSQLрешений.Еще удобен Storm. Это такой потоковый MapReduce, которые местами заменяет хадупА еще спасают, колоночные базы данных.У НАС ЕЩЕ ЕСТЬ ВРЕМЯ? Тогда расскажу про них подробнее.
Основная идея. Если в традиционных БД данные хранятся по строкам, то в колоночных БД – по столбцам. Один столбец – один файл.
Важно.Hbaseи Cassandra не колоночные БД, хотя их так иногда называют. Так вышло, что здесь вышла путаница в терминологии. Но важно понимать, что Cassandra и Hbaseхранят данные по строчкам.Давайте посмотрим все тот же любимый пример в виде SQL запроса и будем считать количество показов в москве за определенный деньСила колоночных БД в том, что будут прочитаны только два файла с данными по нужным колонкам. При большой таблице (а в реальной жизни в логах может быть около 50 полей),будут прочитаны всего 4% дневных данных