A missão da Booking.com é facilitar a experiência do mundo para todos. Para ajudar as pessoas a descobrir destinos, somos um dos principais anunciantes de viagens no Google Pay Per Click (PPC). A Booking Holdings, como um todo, gastou US$ 4,7 bilhões em marketing em todas as marcas nos primeiros nove meses de 2022[1]. Como executamos o PPC em nossa escala e com eficiência? Neste artigo, queremos ilustrar nosso uso extensivo da nuvem pública, especificamente o Google Cloud Platform (GCP). Desde a ingestão de dados, ciência de dados até nossos lances de anúncios[2], o GCP é um acelerador em nosso ciclo de desenvolvimento, às vezes reduzindo o tempo de lançamento no mercado de meses para semanas.

Quais são os desafios do PPC?

O PPC como negócio representa um problema de otimização global. Do ponto de vista técnico, resolver isso requer aprendizado de máquina e infraestrutura operacional em escala, que está processando feedback de desempenho, avaliando o desempenho histórico e depois de executar algoritmos, comunicando os resultados de volta a um provedor de mecanismo de pesquisa. Abordaremos alguns dos principais aspectos de nossa pilha de tecnologia que permite esse recurso.

Ingestão de dados e análise em escala

A ingestão de dados de desempenho, gerados por um provedor de pesquisa ou internamente, é uma entrada importante para nossos algoritmos. Fazemos uso extensivo do Google BigQuery em PPC devido à escala de nossos negócios (até 2 milhões de diárias reservadas por dia). Nossa equipe executa coletivamente mais de 1 milhão de consultas por mês, verificando mais de 2 PB de dados. O BigQuery economiza um tempo substancial — em vez de esperar horas no Hive/Hadoop, nosso tempo médio de execução de consulta é de 20 segundos para lote e 2 segundos para consultas interativas[3].

O BigQuery também oferece suporte nativo para esquemas de dados aninhados e repetidos[4][5]. Aproveitamos esse recurso em nossos sistemas de licitação de anúncios, mantendo exibições de dados consistentes das planilhas de nossos especialistas de conta, para os cadernos de nossos cientistas de dados e para os dados na memória de nosso sistema de licitação. Esse recurso elimina o código para analisar dados, reduz nossa dívida técnica e reduz nosso tempo de desenvolvimento.

Uma visão unificada para dados operacionais

Mantivemos a maior parte de nossos dados operacionais em bancos de dados relacionais, como o MySQL. À medida que evoluímos, precisávamos cada vez mais entrelaçar esses dados com dados analíticos em uma visão unificada. Agora usamos o Spanner[6][7], um banco de dados SQL distribuído globalmente, porque ele possui vários recursos exclusivos que se adaptam perfeitamente ao nosso caso de uso:

1. O Spanner e o BigQuery forçam a multiplicação um do outro por meio de consultas federadas: armazenamos dados relacionais que mudam rapidamente no Spanner e gravamos dados analíticos orientados por anexos no BigQuery. Quando nossas consultas abrangem ambos os conjuntos de dados, as Federated Queries obtêm dados consistentes com instantâneos em tempo real de ambos os armazenamentos imediatamente. Não precisamos mover dados ou gastar ciclos de desenvolvimento para configurar (e manter) pipelines de dados[8][9][10].
2. O Spanner possui recursos avançados de evolução de esquema: para tabelas grandes com dados de anúncio em evolução, o Spanner pode reduzir o tempo de alterações de esquema para minutos ou segundos, em comparação com dias em uma solução de banco de dados relacional mais comum.
3. As tabelas intercaladas nos permitem armazenar dados da API de anúncios separados de nossos dados internos sem prejudicar o desempenho. Para dados estruturados e hierárquicos, esse recurso nos permite colocar os dados relacionados próximos, maximizando a localidade espacial.

Os dados, entregues com qualidade no momento necessário, estão no centro do desempenho do nosso sistema. Para fluxos de trabalho que abrangem vários sistemas de dados, optamos por usar o Google Dataflow, uma estrutura híbrida gerenciada de lote/streaming, com integração nativa com BigQuery e Spanner.

Vemos duas grandes vantagens com essa abordagem:

1. O Dataflow implementa o Beam — uma API que efetivamente abstrai o processamento de big data dos detalhes de implementação da plataforma de tempo de execução: permite que nos concentremos na solução de lógica de negócios e paralelismo de dados, tornando nossa iteração de desenvolvimento mais rápida.
2. Ele é executado como um serviço gerenciado, com manutenção mínima.

Evoluindo nossa infraestrutura

A otimização de nossa operação de GCP vem com seu conjunto exclusivo de desafios. Em nossa escala, pequenos custos se somam e isso exige que pensemos profundamente sobre a dimensão do custo de infraestrutura desde o início, no momento do projeto, o que foi tanto uma mudança cultural quanto uma mudança de processo. Por exemplo, em uma de nossas primeiras agregações do BigQuery, tínhamos uma consulta grande que juntava dados estatísticos com metadados e depois os agregava. Devido à grande junção e ao uso de CURRENT_DATE() como uma função dinâmica, uma implementação ingênua do BigQuery custaria US$ 1 por execução e, ao longo de um dia, custaria US$ 1.500. Buscando diminuir o custo e aumentar o desempenho, usamos o BigQuery para agregação, mantivemos os metadados no MySQL e juntamos as duas tabelas na memória do aplicativo. Essa abordagem nos permitiu armazenar em cache os resultados do BigQuery com a presença de funções dinâmicas[11][12][13].

Desenvolvimento futuro

No PPC, tivemos um tremendo sucesso ao criar nossos sistemas na nuvem pública, especificamente no GCP. BigQuery, Dataflow e Spanner aceleraram nossos ciclos de desenvolvimento, reduziram nosso tempo de lançamento no mercado e provaram seu valor comercial. Gostaríamos de agradecer às fantásticas equipes do Google por sua colaboração e parceria conosco. Na Booking.com , temos problemas complexos e desafiadores para resolver. Temos uma equipe de PPC incrivelmente talentosa e trabalhadora, e usamos tecnologia inovadora para ajudar as pessoas a descobrir viagens de maneiras divertidas e criativas. Se isso o entusiasma, considere trabalhar conosco - inscreva-se em jobs.booking.com !

Agradecimentos especiais a Baris Gul, Igor Dralyuk, Sergey Dovgal ( sdovgal ), Mustafa Elbadry , Martijn Hensema e toda a equipe PPC da Booking.com por contribuir com este artigo.

Notas de rodapé:

[1] Reserva 3T 2022 10T:https://s201.q4cdn.com/865305287/files/doc_financials/2022/q3/9fdc627b-3967-4970-aae0-b9581971f96d.pdf
[2] (documento interno) PPC GCP Projects Retrospective
[3] (documento interno) Resumo do PPC BigQuery
[4] Descrição do Protobuf em Dremel:https://research.google/pubs/pub36632/ [5] Dremel: Uma Década de Análise SQL Interativa em Escala da Web:https://research.google/pubs/pub49489/
[6] Spanner: banco de dados globalmente distribuído do Google:https://research.google/pubs/pub39966/
[7] Spanner: tornando-se um sistema SQLhttps://research.google/pubs/pub46103/
[8] Consulta F1:https://research.google/pubs/pub47224/ [9] F1 Relâmpago HTAP:http://www.vldb.org/pvldb/vol13/p3313-yang.pdf
[10] F1: Um banco de dados SQL distribuído que escala:https://research.google/pubs/pub41344/
[11] Cache de resultados do BQ:https://cloud.google.com/bigquery/docs/cached-results
[12] (documento interno) Controle de custos do BigQuery em PPC: controle de custos do BigQuery
[13] (documento interno) PPC — Movendo agregações do local para o BigQuery