Your SlideShare is downloading. ×
0
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Rtb
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rtb

837

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
837
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
30
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • - Всемдоброеутро! Яприятноудивлен, чтовстольраннийчассобралосьтакмноголюдей. Значиттемадостаточноинтересная.(Всемдоброеутрохорошо, чтолюдейтакнемного. Значитвывсенастольколюбите RTB, чтоготовыпожертвоватьутреннимсном)(пауза)Вообще, язанимаюсьвсякимиштукамиоколо RTB ужепочти 4ре года, имогурассказатьоченьмногоинтересного. Вообщемойдоклад, скореепростыкбизнесаитехнологии, прото, какбизнесдиктуеттехнологическиеусловиявданнойобласти. Слайдовяприготовилмного, такчтонеуверен, чтопровсеуспеюрассказатьподробно. Хочуспроситьувас: подминимитеруките, комускореепробизнесаспекты RTB? Акомупротехнологии?И еще последний момент. В любой момент вы можете прервать меня и задавать вопросы. Возможно, мы я тогда про что-то не успею рассказать, но это лучше недопонимания. На простые вопросы я буду отвечать сразу.Однако, если вопрос сложный, я его с вашего позвления пропущу, и отвечу после в частном порядке
  • RTB. Расшифровываетсякак Real time bidding, илиаукционреальноговремени. Этонекотораяпопыткаперенестибиржевыемоделивмиронлайнрекламы. Насамомделе, доконцанеясночтоизэтоговышло. Рынокпоявилсягде-тов 2009-ом годуидосихпорстремительноэволюционирует
  • Итак, давайтенемногопроисторию. Воткакбылаустроенажизньдо RTB. Площадка, продаваярекламноеместоставилакодкакой-нибудьрекламнойсети. Сзаходомпользователя, вызывалсяэтоткодирекламнаясетьискалаподходящееобъявлениевсвоейбазе. Еслиподходящийбаннернашелся, тосетьвыдавала HTML-коддляотображениябаннера. Еслиничегоненашлось, сетьвыдавалакодследующейрекламнойсетивцепочке.Впрочем, этонето, чтобыистория. Простораньшеэтобылединственныйвариант
  • Итак, проблемыстарогоподхода: - Нуво-первых, то, какоеобъявлениебудетпоказановрезультате, сильнозависитотпорядкарекламныхсетейвцепочке. Здесьнетчестнойконкуреции - Во-вторых, длиннаяцепочкарекламныхсетейтормозитзагрузкусайта - Ряддругихпроблем
  • Чтобырешитьэтупроблему, появилось RTB. Накаждыйрекламныйпоказпроводитсяаукцион. Аукционпроводяттакназываемые SSP, sell-side platforms, которыепредставляютинтересыплощадок. Ваукционахучаствуют DSP, demand side platforms, которыепредставляютинтересырекламодателей.Аукционпроводитьсячерез HTTP. SSP вместес HTTP запросомприсылаетмногоразнойинформации: IP адреспользователя, егобраузер, urlразмещенияит.д.Вответ DSP отвечаетставкойи HTML-кодом, которыйбудетпоказанпользователювслучаевыигрыша
  • RTB - этоаукционвторойцены. Все сначала удивляются и расстраиваются. Но на самом деле, так выгоднее
  • Итак, ещераз, повторяем!Ещебывают DMP, этоплатформы, которыеводихместахсобираютданныеопользователе. "Данные" этообычнопол, возраститакдалее. Этиданные DMP продают DSP, чтобытемоглипоказыватьболеетаргетированнуюрекламуПро DMP мысегодняговоритьнебудем. Во-первых, этонетакинтересно. А, во-вторых, яперсональносчитаю, чтоэтодовольнодурацкийибесполезныйбизнес
  • Подробнеепо SSP. Во-первых, какяужеисказал, SSP обслуживаетинтересыплощадок. Во-вторых, SSP штукахотьисложная, нопроще DSP. Ещеонивсеодинаковыевсмыслебизнесмоделе.Явсеклонюктому, что SSP этонеоченьинтересно, имыпронихсегодняпочтинебудемговорить
  • Абудемговоритьвосновномпро DSP. Какяужеиговорил, DSP обслуживаетрекламодаталей. АсрекламщикамивсегдавсесложноТехнологическиэтосложнееиинтереснее. Тутестьнесколькоинтересныхбизнесмоделей, онекоторыхизнихярасскажупоподробнее
  • Самаяраспостраненнаямодель - retargeting.- (!!!!!) КСТАТИ, НАВЕРНОЕ, У МНОГИХ ТУТ СТОИТ AD-BLOCK ИЛИ ЧТО-ТО ВРОДЕ ЭТОГО. ПОДНИМИТЕ РУКУ, У КОГО ОН ЕСТЬ?- Остальные, наверное, знаютчтотакоеретаргетинг. Этокогдавыодинраззашливинтернет-магазин, апослецелыймесяцвасмучаетрекламаэтогожемагазина.- Каксказалодинмойзнакомый: невозможнокупитьженеподарокнановыйгодвинтернете, чтобыонаобэтомнеузнала. Хотя, думаю, этонесамаянеловкаяситцацяикотораяможетвсвязисретаргетингомвозникнуть- Итого, идеяретаргетингапонятно. Надопонимать, чтоделаетсяэтонеизвредности. Статистика - упрямаявещь. Вероятностьконверсииприусловиипоказаретаргетированногобаннерасущественновыше
  • Ещеестьаудиторныйтаргетинг. Есливкратце, этопоказобъявленийзаинтересованнойаудитории. Останавливатьсянаэтомнебудем. По-моемумнению, этонеоченьрабочаямодель
  • Ещеважнаяштукапо DSP. Некоторыеигрокиработаютсрекламодателямипомоделиоплатызакликилизаконверсию. Приэтомрасчетыс SSP происходятвсегдазапоказы. Тутпоявляетсякучаинтересныхтехническихмоментов, связанныхсточнойоценкивероятностикликаиликонверсиидлякаждого RTB запроса, чтобынеработатьвминус. Всяэтаисторияназываетсяарбитраж. Пронееподробнееярасскажувконце, еслиуспею
  • - Ещеважнаяштуканазывается cookie sync. Этонасамомделеоченьнудноинеинтересно. Новажносточкизренияпониманиятехнологий. - Обратитевниманиенакартинкунаслайде. Еслиничегонепонятно, тотакидолжнобыть. Какяисказал, cookie sync эторутина, нопостарайтесьпотерпетьпаруминутиявсеобъясню
  • Итак, зачемвсеэтонужно. До RTB дляидентификациипользователейихраненияонихинформации ()
  • Вотещеразпроблема. Когда SSP размещаеткоднасайте, онооперируеткукамивсвоемдомене, ssp.com. Приэтому DSP кукивсвоемдоменеикакая-тосвояинформацияопользователе.Если, например, DSP показалокакое-тообъявление 100 разодномупользователспомощьюдругого SSP ипользовательнанемнекликал, тонаверное, показыватьегодальшебесполезно. Нокакузнать, чтонатекущем SSP пришелтотсамыйпользователь.
  • Итак, решение. Когда SSP показыватобъявление, неважнооткакого DSP, оноставитвконцемногомаленьких, прозрачныхпикселей (такназываемыезиро-пиксели). Каждыйпиксельсоответсвуетодной DSP.Этипикселивызывают URL насайте DSP, передаваявпараметрахзапросасвойидентификаторпользователя. А DSP всвоюочередь, идетифицируетпользовтелякукойвсвоемдоменеиможетвнутрисебязапомнитьсоответсвие.Когдавследующийразот SSP придетзапрос, DSP сможетвтаблиценайтисвой, внутреннийидентификаторпользователяииспользоватьэтуинформацию
  • Итого, длясоответсвияпользователейнужнохранитьтакуютаблицуиздвухколонок, коотораяназывается 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. Зато получается очень весело и интересно!
  • Итак, перечислимосновныетехнологическиепроблемы
  • HTTP нагрузкавцифрах. Каквидно, нетакмало. Чтожеснейделать?
  • Ну, первыйпункт, этонебоятся. ПОДНИМИТЕ РУКИ ТЕ, КТО ПИСАЛ СИСТЕМЫ ОБРАБАТЫВАЮЩИЕ более 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% дневных данных
  • Итак, резюмируем про колоночные БД.
  • Transcript

    • 1. Анатомия RTBВладимир Климонтович
    • 2. Real time biding
    • 3. Old school
    • 4. Проблемы• Финальный исход зависит от порядка adnetworks в цепочке• Большой размер цепочки замедляетзагрузку страницы
    • 5. RTB! (new school)
    • 6. Аукцион второй цены• Выигравший участник платит вторую цену +delta (1 цент, 1 копейка)• Если участник один, оплачиваетсяминимальная цена (floor cpm) + delta• Аукцион второй цены стимулируетучастников называть реальную цену• Время ответа: 100ms
    • 7. Основные субъекты рынка• SSP (Sell Side Platform) – обслуживаетинтересы площадок• DSP (Demand Side Platform) – обслуживаетинтересы рекламодателей• DMP (Data Management Platforms/DataExchange) – собирает данные опользователе
    • 8. SSP• Обслуживает интересы площадокразмещения (сайтов)• Технологически проще DSP• По сути, одинаковая бизнес-модель у всехSSP
    • 9. DSP• Обслуживает рекламодателей• Сложнее чем SSP• Разные бизнес модели: retargeting, searchretargeting, 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 должна хорошо уметьоценивать вероятность клика/конверсии
    • 13. Cookie sync
    • 14. Cookie sync – проблема• До RTB-эры пользователейидентифицировали по cookie• Но DSP и SSP “живут в разных доменах”
    • 15. Cookie sync – проблема
    • 16. Cookie sync – решение (sync pixel)
    • 17. Match table• Порядок: 10-100 млн строк• В идеале хранится на стороне SSP, но невсегдаSSP User Id DSP User ID10:22741675 03goMw3rI64
    • 18. Виды cookie sync• Инициированный SSP• Инициированный DSP
    • 19. Что еще?• До RTB-эры данные о пользователе (частотапоказов, посещенные сайты) хранились вcookie• Cookie sync обеспечивает толькосинхронизацию ID. Остальное нужнохранить в БД на стороне DSP (NoSQL )
    • 20. Под капотом RTB
    • 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синхронизацию и т.д.
    • 24. HTTP-нагрузка: библиотеки• Java: akka, NIO, Netty• C++: libevent, libev
    • 25. И последнее: RAM и только RAM!
    • 26. Храним в памяти• Все рекламные кампании, таргетинги,настройки и т.д.• На диск пишем только логи, ничего нечитаем
    • 27. Online хранение пользователей
    • 28. Что храним?SSP USER ID SSP INTERNAL USER ID10:22741675 adfox 03goMw3rI64USER ID USER DATA03goMw3rI64 Частота показов по кампаниям и т.д.Cookie sync table (100 млн записей)User data (100 млн записей)
    • 29. Требование к хранилищу• Ответ на чтение: 10ms (помним, timeoutвсего аукциона 100ms)• Хранение всех данных в RAM• Цена! И еще раз цена!• Легкое масштабирование
    • 30. Чего требовать не надо• Надежности• 99,99% availability – более, чем достаточно
    • 31. Варианты• Терпимые: Mongo, Redis, Cassandra,Tarantool• Плохие: Hbase• Неясные: MySQL/PostgreSQL
    • 32. Offline данные оно же Big Data
    • 33. Проблемы• Данных много: 10-100Gb в день• Люди хотят быстро получать ответы насложные вопросы: сколько у нас естьпоказов в Киеве людям в возрасте 20-25лет, которые до этого искали билеты насамолет в Яндексе
    • 34. Философия данных
    • 35. Философия данных• Там где идет речь об аналитике, какправило, скорость ответа важнее точности• Там, где идет речь о деньгах, как правило,точность важнее скорости
    • 36. Как пожертвовать точностью?date domain city impressions (показы)2013-01-14 12:12 a.com Moscow 1Считаем показы в Москве за один день:SELECT sum(impressions) WHEREcity=‘Moscow’ and date=‘2013-01-14’
    • 37. Sampling• Выбросим случайны 9 строчек из 10• Для оставшихся строчке умножимimpressions на 10• SELECT sum(impressions) WHEREcity=‘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%2N /10
    • 39. Sampling0.00%10.00%20.00%30.00%40.00%50.00%Статистическая ошибка
    • 40. Уникальные пользователи• SELECT count (distinct user_id) WHEREcity=‘Moscow’ and date=‘2013-01-14’• Как оптимизировать?date domain city user_id impressions (показы)2013-01-14 12:12 a.com Moscow 6VdckZtTUkN 1
    • 41. Вероятностные алгоритмы• Наглядные: K-minimum values, linear counter• Другие: LogLog counters
    • 42. Что использовать?• Apache Hadoop – лучшее из худшихрешений• Storm (from Twitter) – потоковый“MapReduce”. Для некоторых задачзаменяет Hadoop• Колоночные БД
    • 43. Колоночные БД
    • 44. Колоночные БД• Важно! Hbase, Cassandra – не колоночные• Пример: SELECT sum(impressions) WHEREcity=‘Moscow’ and date=‘2013-01-14’• Будут прочитаны только файлы для сданными impressions и city
    • 45. Колоночные БД – преимущества• Данные хорошо сжимаются (данные вколонках однородные)• Скорость агрегирующих запросов в разывыше• Недостатки: сложность загрузки данных
    • 46. Machine learning
    • 47. Machine learning• Предсказание вероятности клика• Предсказание вероятности конверсии• Look-alike (предсказание пола, возраста,поведения пользователя)
    • 48. Несколько фактов• На рынке есть хорошие open-sourceрешения• Лучше плохой алгоритм, чем никакой• Алгоритм важен, но еще важнее параметрыобучений (features) и настройки
    • 49. Вопросы?• klimontovich@gmail.com• Skype: klimontovich

    ×