Big Data, Performance, Posix, RTB no mercado de publicidade online
-
Upload
tiago-peczenyj -
Category
Technology
-
view
807 -
download
0
description
Transcript of Big Data, Performance, Posix, RTB no mercado de publicidade online
Tiago Peczenyj
Weborama
BIG DATA, PERFORMANCE,
POSIX, RTB E OS DESAFIOS DA
PROPAGANDA NA WEB
Tiago Peczenyj@pac_manProgramador 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?
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 clickCPM – 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
Dynamic ElementsSection 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 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
HTTP HEADER / USER AGENT
O Sistema OperacionalNome do Browser / versãoSe é um Mobile, Tablet, Video Game ou Desktop
Posso inferir alguns perfis de consumo!
SABENDO O USER AGENT
RETARGETING
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
COOKIES
Funcionam muito bem juntosPorém é relativamente caroSoluçã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
BIG DATA!
Cada vez que um banner / ads é impresso eu sei: Qual Usuário / Cookie está envolvido
Aonde ele está geográficamenteQual é o aparelho, resolução da tela, sistema operacional
Qual pagina ele visitou!
BIG DATA!!
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 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!!!
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
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
Cookies:dominioA => id=XdominioB => 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 perfi l de X:
Ids => { dominio B => Y }
EXEMPLO PIXEL SYNC
Vimos ser possivel marcar usuarios para retargeting, alterar o conteudo de acordo com o perfi l, 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?
REAL TIME BIDDING!
SSP E DSP
LEILÃO
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
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!
BIOS
Linguagem não escalaFramework não escalaComponente não escalaBiblioteca não escalaArquiteturas muito bem construidas é que escalam (ou não)
ESCALABILIDADE
É 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
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 porHardware mais rapidoUtilizar um algoritmo mais eficiente (Big O)
Paralelizar algumas sub-tarefasUtilizar melhor os recursos disponiveisDiminuir o overhead!
PERFORMANCE
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
CAOS
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
É 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)
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
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
Design da solução de forma a evitar ponto unico de falha
Fazer uso racional dos logs / unix signalsAutomatizar e versionar infraestrutura (git + puppet ,
chef…)Possuir ambiente espelho ao produção para
teste/homologaçãoMonitorar tudo (nagios, new relic, statsD)Ferramentas para detecção de problemas (wireshark)Time multidisciplinar ( #devops )
MISCELÂNEA
Armazenamento chave/valorMuito rapidoUso intenso de memóriaPossui coleções, listas, etcExpiração de chavesSuporte a scripts em Lua
BIG DATA : REDIS
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
É 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
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 : EXEMPLOSINCREMENTAR VALOR SERIALIZADO
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
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
permanenteSuporta map-reduce em JavaScript e ErlangTrabalha com interfaces Rest e Protocol BufferSuporta multiplos backends plugaveis (Memory,
LevelDB,…)
BIG DATA : RIAK
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
$scalar@array%hash
(PERL)
Atualmente está na versão 5.18.1Linguagem 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 PerlBioPerl, CERN, Estante Virtual, Booking.com,
youporn
(PERL)
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
package Point3D;use Moose; extends 'Point'; has 'z' => (is => 'rw', isa => 'Int'); after 'clear' => sub { my $self = shift; $self->z(0);};
MOOSE
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
CRUD -> GET / PUT / DELETEInterface Protocol BufferOrientação a Objetos com MooFoco em PerformanceUso da API POSIX não bufferizada
Timeout I/O
RIAK::LIGHT
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
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
Abstração I/O (socket, arquivos, named pipes)
Bufferizado ou nãoBloqueante ou nãoFunções sysread / syswriteÉ preciso observar que nem sempre vc vai escrever/ler todos os bytes que vc espera de uma vez
ERRNO global
POSIX
IO::Socket::INETAlarm (signals)SelectSetsockoptWindows / SunOS / NetBSD 6
TIMEOUT IO
As vezes é necessario reescrever a rodaInterface PBC < overhead < RESTUso 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
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
Ad Blocking (21 %)Browser refusing third-party cookies
PrivacyBrowser Fingerprint
OUTROS DESAFIOS
Tiago Peczenyj@pac_manhttp://[email protected]
OBRIGADO!