La mission de Booking.com est de permettre à chacun de découvrir le monde plus facilement. Pour aider les gens à découvrir des destinations, nous sommes l'un des principaux annonceurs de voyages sur Google Pay Per Click (PPC). Booking Holdings, dans son ensemble, a dépensé 4,7 milliards de dollars en marketing pour toutes les marques au cours des neuf premiers mois de 2022[1]. Comment gérons-nous le PPC à notre échelle et efficacement ? Dans cet article, nous voulons illustrer notre utilisation intensive du cloud public, en particulier Google Cloud Platform (GCP). De l'ingestion de données à la science des données, en passant par nos enchères publicitaires[2], GCP est un accélérateur de notre cycle de développement, réduisant parfois le délai de mise sur le marché de plusieurs mois à plusieurs semaines.

Quels sont les défis de PPC ?

Le PPC en tant qu'entreprise représente un problème d'optimisation global. D'un point de vue technique, la résolution de ce problème nécessite un apprentissage automatique et une infrastructure opérationnelle à grande échelle, qui traite les commentaires sur les performances, évalue les performances historiques et, après avoir exécuté des algorithmes, communique les résultats à un fournisseur de moteur de recherche. Nous aborderons certains des aspects clés de notre pile technologique permettant cette capacité.

Ingestion de données et analyse à grande échelle

L'ingestion de données de performance, qu'elles soient générées par un moteur de recherche ou en interne, est une entrée clé pour nos algorithmes. Nous utilisons largement Google BigQuery dans PPC en raison de l'ampleur de notre activité (jusqu'à 2 millions de nuitées réservées par jour). Notre équipe exécute collectivement plus d'un million de requêtes par mois, analysant plus de 2 Po de données. BigQuery nous fait gagner un temps considérable : au lieu d'attendre des heures dans Hive/Hadoop, notre temps d'exécution médian des requêtes est de 20 secondes pour les requêtes par lots et de 2 secondes pour les requêtes interactives[3].

BigQuery offre également une prise en charge native des schémas de données imbriqués et répétés[4][5]. Nous tirons parti de cette fonctionnalité dans nos systèmes d'enchères publicitaires, en maintenant des vues de données cohérentes depuis les feuilles de calcul de nos spécialistes de compte, vers les blocs-notes de nos scientifiques des données, jusqu'aux données en mémoire de notre système d'enchères. Cette fonctionnalité élimine le code pour analyser les données, réduit notre dette technique et raccourcit notre temps de développement.

Une vue unifiée pour les données opérationnelles

Nous avons conservé la plupart de nos données opérationnelles dans des bases de données relationnelles, comme MySQL. Au fur et à mesure de notre évolution, nous avons eu de plus en plus besoin d'entrelacer ces données avec des données analytiques dans une vue unifiée. Nous utilisons maintenant Spanner[6][7], une base de données SQL distribuée à l'échelle mondiale, car elle possède un certain nombre de fonctionnalités uniques qui correspondent parfaitement à notre cas d'utilisation :

1. Spanner et BigQuery se multiplient mutuellement via des requêtes fédérées : nous stockons des données relationnelles à évolution rapide dans Spanner et écrivons des données analytiques orientées vers l'ajout dans BigQuery. Lorsque nos requêtes couvrent les deux ensembles de données, les requêtes fédérées récupèrent immédiatement des données en temps réel et cohérentes avec les instantanés des deux magasins. Nous n'avons pas besoin de déplacer des données ou de passer des cycles de développement pour configurer (et maintenir) des pipelines de données[8][9][10].
2. Spanner dispose de puissantes capacités d'évolution de schéma : pour les tables volumineuses avec des données de publicité évolutives, Spanner peut réduire le temps de modification du schéma à quelques minutes ou secondes, par rapport aux jours dans une solution de base de données relationnelle plus courante.
3. Les tables entrelacées nous permettent de stocker les données de l'API Ads séparément de nos données internes sans dégrader les performances. Pour les données structurées et hiérarchiques, cette fonctionnalité nous permet de rapprocher les données liées, maximisant ainsi la localité spatiale.

Les données, livrées avec qualité au moment voulu, sont au cœur de la performance de notre système. Pour les workflows couvrant plusieurs systèmes de données, nous choisissons d'utiliser Google Dataflow, un framework hybride batch/streaming géré, avec une intégration native à BigQuery et Spanner.

Nous voyons deux avantages majeurs à cette approche :

1. Dataflow implémente Beam, une API qui extrait efficacement le traitement du Big Data des détails d'implémentation de la plate-forme d'exécution : elle nous permet de nous concentrer sur la résolution de la logique métier et du parallélisme des données, ce qui accélère notre itération de développement.
2. Il fonctionne comme un service géré, avec une maintenance minimale.

Faire évoluer notre infrastructure

L'optimisation de nos opérations GCP s'accompagne d'un ensemble unique de défis. À notre échelle, les petits coûts s'additionnent et cela nous oblige à réfléchir en profondeur à la dimension des coûts d'infrastructure dès le début, au moment de la conception, ce qui était autant un changement culturel qu'un changement de processus. Par exemple, dans l'une de nos premières agrégations BigQuery, nous avions une grande requête qui associait des données statistiques à des métadonnées, puis les agrégeait. En raison de la grande jointure et de l'utilisation de CURRENT_DATE() en tant que fonction dynamique, une mise en œuvre naïve de BigQuery aurait coûté 1 $ par exécution, et sur une journée, cela aurait coûté 1 500 $. Afin de réduire les coûts et d'augmenter les performances, nous avons utilisé BigQuery pour l'agrégation, conservé les métadonnées sur MySQL et joint les deux tables dans la mémoire de l'application. Cette approche nous a permis de mettre en cache les résultats de BigQuery avec la présence de fonctions dynamiques[11][12][13].

Développement futur

Dans PPC, nous avons eu un énorme succès en construisant nos systèmes sur le cloud public, en particulier GCP. BigQuery, Dataflow et Spanner ont accéléré nos cycles de développement, raccourci nos délais de mise sur le marché et prouvé leur valeur commerciale. Nous tenons à remercier les fantastiques équipes de Google pour leur collaboration et leur partenariat avec nous. Chez Booking.com , nous avons des problèmes complexes et difficiles à résoudre. Nous avons une équipe PPC incroyablement talentueuse et travailleuse, et nous utilisons une technologie innovante pour aider les gens à découvrir le voyage de manière amusante et créative. Si cela vous passionne, envisagez de travailler avec nous — postulez sur jobs.booking.com !

Un merci spécial à Baris Gul, Igor Dralyuk, Sergey Dovgal ( sdovgal ), Mustafa Elbadry , Martijn Hensema et toute l'équipe PPC de Booking.com pour avoir contribué à cet article.

Notes de bas de page :

[1] Réservation Q3 2022 10Q :https://s201.q4cdn.com/865305287/files/doc_financials/2022/q3/9fdc627b-3967-4970-aae0-b9581971f96d.pdf
[2] (Document interne) Rétrospective des projets PPC GCP
[3] (Document interne) Résumé PPC BigQuery
[4] Description de Protobuf dans Dremel :https://research.google/pubs/pub36632/ [5] Dremel : Une décennie d'analyse SQL interactive à l'échelle du Web :https://research.google/pubs/pub49489/
[6] Spanner : base de données mondialement distribuée de Google :https://research.google/pubs/pub39966/
[7] Spanner : devenir un système SQLhttps://research.google/pubs/pub46103/
[8] Requête F1 :https://research.google/pubs/pub47224/ [9] HTAP Foudre F1 :http://www.vldb.org/pvldb/vol13/p3313-yang.pdf
[10] F1 : Une base de données SQL distribuée qui évolue :https://research.google/pubs/pub41344/
[11] Mise en cache des résultats BQ :https://cloud.google.com/bigquery/docs/cached-results
[12] (Document interne) Contrôle des coûts BigQuery dans PPC : Contrôle des coûts BigQuery
[13] (Document interne) PPC — Déplacement des agrégations d'onprem vers BigQuery