Tiago Peczenyj
Weborama
BIG DATA,
PERFORMANCE, POSIX,
RTB E OS DESAFIOS DA
PROPAGANDA NA WEB
Tiago Peczenyj
@pac_man
Programador poliglota (ruby, java, perl,
python, lua) trabalhei por quase 5 anos
com distribuiç...
PROPAGANDA
QUEM ANUNCIA?
O QUE AS EMPRESAS BUSCAM?
LUCRO!
É UM CUSTO
NECESSÁRIO PARA OS NEGÓCIOS
PROPAGANDA
PROPAGANDA NA INTERNET
WHY?
É LÁ QUE ESTÁ A MINHA AUDIÊNCIA
OFERTA X DEMANDA
O “AD SERVER”
IFRAME + REDIRECTS
MUITOS REDIRECTS
MONETIZAÇÃO
CPC – custo por click
CPM – custo por mil
impressões
CPA – custo por ação
TIPOS
CAMPANHA OFF LINE
CAMPANHA ON LINE
O “Ad Server” precisa decidir
qual campanha sera mostrada
É preciso decidir também o que
mostrar
PARA UM DADO USUARIO…
EXEMPLO : BANNERS
MUITOS BANNERS
VEJAMOS…
DYNAMIC CREATIVE OPTIMIZATION
DCO
Section of the ad that
changes dynamically,
during ad view.
WORKFLOW
ADOBE CREATIVE SUITE EXTENSION
+
+
O ad server sabe o ip de origem do
request http
Utilizando uma base de dados geográfica
(ex MaxMind) posso saber qual a
...
HTTP HEADER / USER AGENT
O Sistema Operacional
Nome do Browser / versão
Se é um Mobile, Tablet, Video Game
ou Desktop
Posso inferir alguns perf...
RETARGETING
Com retargeting, eu posso marcar um
usuário para mostrar insistentemente
uma campanha de forma a acelerar uma
possivel co...
COOKIES
Funcionam muito bem juntos
Porém é relativamente caro
Solução: aumentar eficiencia ao
restringir o grupo de usuarios, a...
BIG DATA!
Cada vez que um banner / ads é impresso
eu sei:
Qual Usuário / Cookie está envolvido
Aonde ele está geográficamente
Qua...
SALVANDO O REQUEST
A partir do Historico do Usuário, eu posso usar
uma série de Algoritmos de Inteligência
Artificial para determinar os pro...
Existem muitas empresas no ramo
de tracking de usuarios segundo
alguns criterios.
É possivel trocar informações sobre
um...
Domínio A quer trocar dados com o Domínio B
1. No domínio A adicionamos <img src> para
um pixel 1x1 localizado no domínio ...
Cookies:
dominioA => id=X
dominioB => id=Y
“A” quer saber qual o id do usuario X no dominio “B". Add pixel:
http://dominio...
Vimos ser possivel marcar usuarios para retargeting,
alterar o conteudo de acordo com o perfil, mas como
determinar para q...
REAL TIME BIDDING!
SSP E DSP
LEILÃO
 Permite que diferentes DSPs possam disputar o
mesmo usuario (competitividade).
 Cada DSPs possui um conjunto de campanh...
Operações relativas a advertising
exigem rapidez (ou podem não
ser percebidos a tempo) e
escalabilidade.
Essencial enten...
BIOS
Linguagem não escala
Framework não escala
Componente não escala
Biblioteca não escala
Arquiteturas muito bem construi...
É possivel desenhar uma aplicação web quase
perfeita.
Todavia, uma vez em produção, não raro se
adiciona entropia/ruido ...
A duração total de uma tarefa é a soma das
durações das sub-tarefas associadas.
Para que uma tarefa seja completada em
m...
L1 cache reference 0.5 ns
Branch Mispredict 5 ns
L2 cache reference 7 ns 14 x L1
Mutex lock/unlock 25 ns
Main memory refer...
CAOS
Manter e evoluir uma aplicação web
(advertising por exemplo) é uma
tarefa que não deve ser
subestimada.
A aplicação depe...
É o processo mediante o qual se equilibra
aquilo que já sabemos (assimilação) com
aquilo que podemos ser solicitados
apren...
A mente humana, para resolução de
problemas, funciona de forma
causal.
Quando nós não percebemos as
causas, nós frequent...
LOAD BALANCE
HTTP SESSION
HTTP SESSION COOKIE-BASED
SERVIR ESTATICOS DIRETAMENTE
USE CACHE
MULTIPLOS REQUESTS EM PARALELO
 Fazer um bom uso da infraestrutura: servidor web,
servidor de aplicação, middlewares, caches, load
balance, proxy, etc
...
Armazenamento chave/valor
Muito rapido
Uso intenso de memória
Possui coleções, listas, etc
Expiração de chaves
Supor...
Modelagem de Dados: Um objeto pode ter
varias entradas no Redis versus armazenar
id => objeto serializado (xml, blob).
S...
É possivel enviar codigo Lua para o Redis
usando EVAL
É possivel executar um script usando
EVALSHA
É possivel chamar a ...
local key = KEYS[1]
local value = KEYS[2]
local decoder = __LUA(decode)__() -- substituir por f_93983…()
local encoder = _...
Encarar os problemas de forma
pragmática
Esconder os detalhes do acesso ao Redis
através de uma abstração de alto nivel
...
Banco NoSQL Chave / Valor com alta
disponibilidade, tolerante a falhas e com
escalabilidade quase linear
Trabalha facilm...
O problema: com uma estrutura de centenas de
processos assincronos que acessam MySQL,
apresentou, entre outros gargalos, ...
$scalar
@array
%hash
(PERL)
 Atualmente está na versão 5.18.1
 Linguagem procedural (C, shell script, awk, sed) com
suporte à orientação a objetos.
...
package Point;
use Moose;
has 'x' => (is => 'rw', isa => 'Int');
has 'y' => (is => 'rw', isa => 'Int');
sub clear {
my $se...
package Point3D;
use Moose;
extends 'Point';
has 'z' => (is => 'rw', isa => 'Int');
after 'clear' => sub {
my $self = shif...
package Comparable;
use Moose::Role;
requires 'compare';
sub equal_to {
my ( $self, $other ) = @_;
$self->compare($other) ...
CRUD -> GET / PUT / DELETE
Interface Protocol Buffer
Orientação a Objetos com Moo
Foco em Performance
Uso da API POSI...
use Riak::Light;
my $client = Riak::Light->new(
host => '127.0.0.1',
port => 8087
);
$client->is_alive() or die "ops, riak...
Requests/segundo Data::Riak (REST)
Data::Riak (REST) 318
Net::Riak (REST) 478 50%
Riak::Tiny (REST) 544 71%
Data::Riak::Fa...
Abstração I/O (socket, arquivos, named
pipes)
Bufferizado ou não
Bloqueante ou não
Funções sysread / syswrite
É preci...
IO::Socket::INET
Alarm (signals)
Select
Setsockopt
Windows / SunOS / NetBSD 6
TIMEOUT IO
As vezes é necessario reescrever a roda
Interface PBC < overhead < REST
Uso de secondary indexes pode evitar
duplicação...
Servidor de alta performance escrito em C que
permite trabalhar com filtros de Bloom
Verificar se um dado está no Riak é...
Ad Blocking (21 %)
Browser refusing third-party cookies
Privacy
Browser Fingerprint
OUTROS DESAFIOS
Tiago Peczenyj
@pac_man
http://pacman.blog.br
tiago.peczenyj@gmail.com
OBRIGADO!
Upcoming SlideShare
Loading in …5
×

Big Data, Performance, Posix, RTB no mercado de publicidade online

979 views
913 views

Published on

Vou colocar uma série de links e erratas na descrição, ja ja

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
979
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
14
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Big Data, Performance, Posix, RTB no mercado de publicidade online

  1. 1. Tiago Peczenyj Weborama BIG DATA, PERFORMANCE, POSIX, RTB E OS DESAFIOS DA PROPAGANDA NA WEB
  2. 2. Tiago Peczenyj @pac_man Programador poliglota (ruby, java, perl, python, lua) trabalhei por quase 5 anos com distribuição de vídeos na globo.com. Hoje sou Software Engineer no time de Big Data da Weborama (França). Bebo cerveja nas horas vagas. QUEM SOU EU?
  3. 3. PROPAGANDA
  4. 4. QUEM ANUNCIA?
  5. 5. O QUE AS EMPRESAS BUSCAM?
  6. 6. LUCRO!
  7. 7. É UM CUSTO NECESSÁRIO PARA OS NEGÓCIOS PROPAGANDA
  8. 8. PROPAGANDA NA INTERNET
  9. 9. WHY?
  10. 10. É LÁ QUE ESTÁ A MINHA AUDIÊNCIA
  11. 11. OFERTA X DEMANDA
  12. 12. O “AD SERVER”
  13. 13. IFRAME + REDIRECTS
  14. 14. MUITOS REDIRECTS
  15. 15. MONETIZAÇÃO
  16. 16. CPC – custo por click CPM – custo por mil impressões CPA – custo por ação TIPOS
  17. 17. CAMPANHA OFF LINE
  18. 18. CAMPANHA ON LINE
  19. 19. O “Ad Server” precisa decidir qual campanha sera mostrada É preciso decidir também o que mostrar PARA UM DADO USUARIO…
  20. 20. EXEMPLO : BANNERS
  21. 21. MUITOS BANNERS
  22. 22. VEJAMOS…
  23. 23. DYNAMIC CREATIVE OPTIMIZATION
  24. 24. DCO Section of the ad that changes dynamically, during ad view.
  25. 25. WORKFLOW
  26. 26. ADOBE CREATIVE SUITE EXTENSION + +
  27. 27. O ad server sabe o ip de origem do request http Utilizando uma base de dados geográfica (ex MaxMind) posso saber qual a provavel localização do visitante Posso então fazer referências locais (nome do País, Estado, Cidade, Bairro…) Também é possivel saber o provedor de acesso (Intelig, Vivo, Net…) ALEM DO RANDÔMICO
  28. 28. HTTP HEADER / USER AGENT
  29. 29. O Sistema Operacional Nome do Browser / versão Se é um Mobile, Tablet, Video Game ou Desktop Posso inferir alguns perfis de consumo! SABENDO O USER AGENT
  30. 30. RETARGETING
  31. 31. Com retargeting, eu posso marcar um usuário para mostrar insistentemente uma campanha de forma a acelerar uma possivel conversão. O protocolo HTTP é stateless, porém é possivel utilizar COOKIES para identificar usuarios Estabelecemos uma sessão para cada usuario no nosso “ad server” RETARGETING
  32. 32. COOKIES
  33. 33. Funcionam muito bem juntos Porém é relativamente caro Solução: aumentar eficiencia ao restringir o grupo de usuarios, ao qual tenha mais potencial de convergir após algumas impressões Surgem os perfis geográficos, demograficos e comportamentais. DCO + RETARGETING
  34. 34. BIG DATA!
  35. 35. Cada vez que um banner / ads é impresso eu sei: Qual Usuário / Cookie está envolvido Aonde ele está geográficamente Qual é o aparelho, resolução da tela, sistema operacional Qual pagina ele visitou! BIG DATA!!
  36. 36. SALVANDO O REQUEST
  37. 37. A partir do Historico do Usuário, eu posso usar uma série de Algoritmos de Inteligência Artificial para determinar os provaveis perfis A segmentação é algo constante, feita a cada vez que o usuario surge na internet Os Algoritmos não são fixos ( a pesquisa é constante) Surgem novas Oportunidades de Negócio, Algoritmos e Competidores BIG DATA!!!
  38. 38. Existem muitas empresas no ramo de tracking de usuarios segundo alguns criterios. É possivel trocar informações sobre um determinado usuario de forma a melhorar os perfis existentes. Geralmente é feito através da troca de pixels DATA PROVIDERS
  39. 39. Domínio A quer trocar dados com o Domínio B 1. No domínio A adicionamos <img src> para um pixel 1x1 localizado no domínio B 2. O domínio B redireciona para o A, utilizando uma determinada regra de formação de url + query string 3. O domínio A salva localmente as informações e serve um pixel 1x1 gif PIXEL SYNC
  40. 40. Cookies: dominioA => id=X dominioB => id=Y “A” quer saber qual o id do usuario X no dominio “B". Add pixel: http://dominioB.com/pixel.gif?from=A (que redireciona para) http://dominioA.com/pixel.gif?id=Y “A” salva internamente no perfil de X: Ids => { dominio B => Y } EXEMPLO PIXEL SYNC
  41. 41. Vimos ser possivel marcar usuarios para retargeting, alterar o conteudo de acordo com o perfil, mas como determinar para quem mostrar a propaganda? A regra para escolher uma dada campanha pode levar em conta o sistema operacional, tipo de aparelho mobile, região geográfica e alguns tipos de perfis mais simples. Escolher individuos baseados em algoritmos mais complexos/especificos exige ser o ad server. Exige? PARA QUEM?
  42. 42. REAL TIME BIDDING!
  43. 43. SSP E DSP
  44. 44. LEILÃO
  45. 45.  Permite que diferentes DSPs possam disputar o mesmo usuario (competitividade).  Cada DSPs possui um conjunto de campanhas e uma forma proprietária de segmentar os usuarios.  Assim um dado usuario pode ser muito relevante para a DSP A, enquanto não é tão atrativo para a B.  Os dois maiores BIDs pagam.  É possivel não fazer nenhum BID.  Exige baixa latência nas transações ( da ordem de 100 ms). REAL TIME BIDDING
  46. 46. Operações relativas a advertising exigem rapidez (ou podem não ser percebidos a tempo) e escalabilidade. Essencial entender qual é o maior problema relacionado a performance em operações web. PERFORMANCE/ESCALABILIDADE!
  47. 47. BIOS
  48. 48. Linguagem não escala Framework não escala Componente não escala Biblioteca não escala Arquiteturas muito bem construidas é que escalam (ou não) ESCALABILIDADE
  49. 49. É possivel desenhar uma aplicação web quase perfeita. Todavia, uma vez em produção, não raro se adiciona entropia/ruido na arquitetura/aplicação para atender melhor a requisitos de negócios (ditos urgentes) A soma da aplicação + infraestrutura + arquivos de configuração + sistema operacional + hardware + versões de bibliotecas/ linguagem + aspectos ambientais nem sempre funciona da forma esperada. ARQUITETURA
  50. 50. A duração total de uma tarefa é a soma das durações das sub-tarefas associadas. Para que uma tarefa seja completada em menos tempo, podemos optar por Hardware mais rapido Utilizar um algoritmo mais eficiente (Big O) Paralelizar algumas sub-tarefas Utilizar melhor os recursos disponiveis Diminuir o overhead! PERFORMANCE
  51. 51. L1 cache reference 0.5 ns Branch Mispredict 5 ns L2 cache reference 7 ns 14 x L1 Mutex lock/unlock 25 ns Main memory reference 100 ns 14 x L2, 200 x L1 Send 1 K bytes 1 Gbps Net 10.000 ns Read 1 MB from RAM (sequenc) 250.000 ns Read 1 MB from SSD (sequenc) 1 ms 4x memory Disk Seek 10 ms Antigo Delay Read 1 MB from Disc (sequenc) 20 ms 80x RAM, 20x SSD Send packet CA->NE->CA 150 ms Netherlands / California PERFORMANCE Fonte: https://gist.github.com/jboner/2841832
  52. 52. CAOS
  53. 53. Manter e evoluir uma aplicação web (advertising por exemplo) é uma tarefa que não deve ser subestimada. A aplicação depende de uma série de times diferentes para funcionar adequadamente. Comunicação é essencial DESIGN
  54. 54. É o processo mediante o qual se equilibra aquilo que já sabemos (assimilação) com aquilo que podemos ser solicitados aprender e que não se ajusta completamente à nossa compreensão (acomodação) EQUILIBRAÇÃO (PIAGET)
  55. 55. A mente humana, para resolução de problemas, funciona de forma causal. Quando nós não percebemos as causas, nós frequentemente inventamos alguma. CAUSALIDADE
  56. 56. LOAD BALANCE
  57. 57. HTTP SESSION
  58. 58. HTTP SESSION COOKIE-BASED
  59. 59. SERVIR ESTATICOS DIRETAMENTE
  60. 60. USE CACHE
  61. 61. MULTIPLOS REQUESTS EM PARALELO
  62. 62.  Fazer um bom uso da infraestrutura: servidor web, servidor de aplicação, middlewares, caches, load balance, proxy, etc  Design da solução de forma a evitar ponto unico de falha  Fazer uso racional dos logs / unix signals  Automatizar e versionar infraestrutura (git + puppet , chef…)  Possuir ambiente espelho ao produção para teste/homologação  Monitorar tudo (nagios, new relic, statsD)  Ferramentas para detecção de problemas (wireshark)  Time multidisciplinar ( #devops ) MISCELÂNEA
  63. 63. Armazenamento chave/valor Muito rapido Uso intenso de memória Possui coleções, listas, etc Expiração de chaves Suporte a scripts em Lua BIG DATA : REDIS
  64. 64. Modelagem de Dados: Um objeto pode ter varias entradas no Redis versus armazenar id => objeto serializado (xml, blob). Se o acesso ao Redis for um gargalo, minimizar acesso trafegando o mínimo de dados e/ou no mínimo de vezes. Compare o preço de recuperar o objeto, deserializar, alterar, serializar e armazenar novamente com o tempo de submeter um script lua que faça o mesmo BIG DATA : REDIS
  65. 65. É possivel enviar codigo Lua para o Redis usando EVAL É possivel executar um script usando EVALSHA É possivel chamar a funcao atraves de f_<sha1>() Produz processamento no servidor, mas Lua é eficiente, pode valer a pena. BIG DATA : REDIS
  66. 66. local key = KEYS[1] local value = KEYS[2] local decoder = __LUA(decode)__() -- substituir por f_93983…() local encoder = __LUA(encode)__() -- antes de utilizar local sereal_string = redis.call( 'get‟ , key ) local decoded_string = decoder.decode_sereal(sereal_string) local decoded_number = tonumber(decoded_string) sereal_string = encoder.encode_sereal(decoded_number + value) return redis.call( 'set‟ , key , sereal_string) REDIS : EXEMPLOS INCREMENTAR VALOR SERIALIZADO
  67. 67. Encarar os problemas de forma pragmática Esconder os detalhes do acesso ao Redis através de uma abstração de alto nivel (um objeto/client/driver) Lembrar que acesso ao REDIS é I/O (bloqueante), mas não necessariamente devemos entrar em paranóia REDIS : CONCLUSÃO
  68. 68. Banco NoSQL Chave / Valor com alta disponibilidade, tolerante a falhas e com escalabilidade quase linear Trabalha facilmente com grandes volumes de dados Não é tão rapido quanto Redis… Excelente para armazenar dados de forma permanente Suporta map-reduce em JavaScript e Erlang Trabalha com interfaces Rest e Protocol Buffer Suporta multiplos backends plugaveis (Memory, LevelDB,…) BIG DATA : RIAK
  69. 69. O problema: com uma estrutura de centenas de processos assincronos que acessam MySQL, apresentou, entre outros gargalos, o acesso ao Riak O Backend da Weborama é totalmente feito em Perl. O driver em questão era o Net::Riak. Surge a ideia de escrever um novo cliente, extremamente leve e direto (CRUD) utilizando a interface Protocol Buffer. Nasce o primeiro projeto open-source da Weborama: Riak::Light RIAK::LIGHT
  70. 70. $scalar @array %hash (PERL)
  71. 71.  Atualmente está na versão 5.18.1  Linguagem procedural (C, shell script, awk, sed) com suporte à orientação a objetos.  Perl versão 5 é mais antigo do que Java, Ruby ou PHP (backward compatibility insano).  Mais de 124.284 módulos disponíveis no CPAN.  Presente no começo da web interativa (cgi-bin)  Profundas ligações com o movimento open source (Patch).  Movimento de renovação da linguagem Modern Perl  BioPerl, CERN, Estante Virtual, Booking.com, youporn (PERL)
  72. 72. package Point; use Moose; has 'x' => (is => 'rw', isa => 'Int'); has 'y' => (is => 'rw', isa => 'Int'); sub clear { my $self = shift; $self->x(0); $self->y(0); } … my $point = Point->new( x=> 1, y => 2); MOOSE
  73. 73. package Point3D; use Moose; extends 'Point'; has 'z' => (is => 'rw', isa => 'Int'); after 'clear' => sub { my $self = shift; $self->z(0); }; MOOSE
  74. 74. package Comparable; use Moose::Role; requires 'compare'; sub equal_to { my ( $self, $other ) = @_; $self->compare($other) == 0; } package Foo; use Moose; with „Comparable‟; # inject equal_to method sub compare { … } MOOSE ROLES
  75. 75. CRUD -> GET / PUT / DELETE Interface Protocol Buffer Orientação a Objetos com Moo Foco em Performance Uso da API POSIX não bufferizada Timeout I/O RIAK::LIGHT
  76. 76. use Riak::Light; my $client = Riak::Light->new( host => '127.0.0.1', port => 8087 ); $client->is_alive() or die "ops, riak is not alive"; $client->put_raw( foo => baz => "sometext"); # plain/text my $text = $client->get_raw( foo => 'baz'); $client->del(foo => 'bar'); RIAK::LIGHT
  77. 77. Requests/segundo Data::Riak (REST) Data::Riak (REST) 318 Net::Riak (REST) 478 50% Riak::Tiny (REST) 544 71% Data::Riak::Fast (REST) 594 87% Net::Riak (PBC) 1031 224% Riak::Light (PBC) 3774 1086% BENCHMARK (GET) https://github.com/Weborama/Riak-Light
  78. 78. Abstração I/O (socket, arquivos, named pipes) Bufferizado ou não Bloqueante ou não Funções sysread / syswrite É preciso observar que nem sempre vc vai escrever/ler todos os bytes que vc espera de uma vez ERRNO global POSIX
  79. 79. IO::Socket::INET Alarm (signals) Select Setsockopt Windows / SunOS / NetBSD 6 TIMEOUT IO
  80. 80. As vezes é necessario reescrever a roda Interface PBC < overhead < REST Uso de secondary indexes pode evitar duplicação de dados Não acessar diretamente da camada de negócios! Map/Reduce não apresentou a performance esperada Dividimos o perfil entre diferentes buckets para propositos diferentes RIAK CONCLUSÃO
  81. 81. Servidor de alta performance escrito em C que permite trabalhar com filtros de Bloom Verificar se um dado está no Riak é relativamente lento Armazenas as chaves no Redis utiliza muita memoria Nesse filtro, um falso negativo é impossivel! Atenuamos o problema pois liberamos memoria no Redis e poucos requests efetivamente vão ao Riak https://github.com/armon/bloomd BLOOMD SERVER
  82. 82. Ad Blocking (21 %) Browser refusing third-party cookies Privacy Browser Fingerprint OUTROS DESAFIOS
  83. 83. Tiago Peczenyj @pac_man http://pacman.blog.br tiago.peczenyj@gmail.com OBRIGADO!

×