La misión de Booking.com es hacer que sea más fácil para todos experimentar el mundo. Para ayudar a las personas a descubrir destinos, somos un anunciante de viajes líder en Google Pay Per Click (PPC). Booking Holdings, en su conjunto, gastó 4700 millones de dólares en marketing en todas las marcas en los primeros nueve meses de 2022[1]. ¿Cómo ejecutamos PPC a nuestra escala y de manera eficiente? En este artículo, queremos ilustrar nuestro amplio uso de la nube pública, específicamente Google Cloud Platform (GCP). Desde la ingestión de datos, la ciencia de datos hasta nuestra licitación de anuncios[2], GCP es un acelerador en nuestro ciclo de desarrollo, que a veces reduce el tiempo de comercialización de meses a semanas.

¿Cuáles son los desafíos de PPC?

PPC como negocio representa un problema de optimización global. Desde una perspectiva técnica, resolver esto requiere aprendizaje automático e infraestructura operativa a escala, que procesa comentarios sobre el rendimiento, evalúa el rendimiento histórico y, después de ejecutar algoritmos, comunica los resultados a un proveedor de motores de búsqueda. Abordaremos algunos de los aspectos clave de nuestra pila de tecnología que permite esta capacidad.

Ingestión de datos y análisis a escala

La ingestión de datos de rendimiento, ya sea generados por un proveedor de búsqueda o internamente, es una entrada clave para nuestros algoritmos. Hacemos un uso extensivo de Google BigQuery en PPC debido a la escala de nuestro negocio (hasta 2 millones de noches de habitación reservadas por día). Nuestro equipo ejecuta colectivamente más de 1 millón de consultas por mes, escaneando más de 2 PB de datos. BigQuery nos ahorra una cantidad considerable de tiempo: en lugar de esperar horas en Hive/Hadoop, nuestro tiempo medio de ejecución de consultas es de 20 segundos para consultas por lotes y de 2 segundos para consultas interactivas[3].

BigQuery también ofrece soporte nativo para esquemas de datos anidados y repetidos[4][5]. Aprovechamos esta característica en nuestros sistemas de licitación de anuncios, manteniendo vistas de datos coherentes desde las hojas de cálculo de nuestros especialistas en cuentas, los cuadernos de nuestros científicos de datos y los datos en memoria de nuestro sistema de licitación. Esta característica elimina el código para analizar datos, reduce nuestra deuda técnica y acorta nuestro tiempo de desarrollo.

Una vista unificada para datos operativos

Mantuvimos la mayoría de nuestros datos operativos en bases de datos relacionales, como MySQL. A medida que evolucionamos, necesitábamos cada vez más entretejer esos datos con datos analíticos en una vista unificada. Ahora usamos Spanner[6][7], una base de datos SQL distribuida globalmente, porque tiene una serie de características únicas que se adaptan perfectamente a nuestro caso de uso:

1. Spanner y BigQuery se fuerzan a multiplicarse entre sí a través de consultas federadas: almacenamos datos relacionales que cambian rápidamente en Spanner y escribimos datos analíticos orientados a anexos en BigQuery. Cuando nuestras consultas abarcan ambos conjuntos de datos, las consultas federadas obtienen datos consistentes en instantáneas en tiempo real de ambos almacenes de inmediato. No necesitamos mover datos ni gastar ciclos de desarrollo para configurar (y mantener) canalizaciones de datos[8][9][10].
2. Spanner tiene poderosas capacidades de evolución de esquemas: para tablas grandes con datos de anuncios en evolución, Spanner puede reducir el tiempo de cambios de esquema a minutos o segundos, en comparación con días en una solución de base de datos relacional más común.
3. Las tablas intercaladas nos permiten almacenar datos de la API de anuncios separados de nuestros datos internos sin degradar el rendimiento. Para datos estructurados y jerárquicos, esta característica nos permite ubicar datos relacionados juntos, maximizando la localidad espacial.

Los datos, entregados con calidad en el momento requerido, están en el corazón del rendimiento de nuestro sistema. Para los flujos de trabajo que abarcan múltiples sistemas de datos, optamos por usar Google Dataflow, un marco híbrido administrado por lotes/transmisión, con integración nativa con BigQuery y Spanner.

Vemos dos ventajas principales con este enfoque:

1. Dataflow implementa Beam, una API que abstrae efectivamente el procesamiento de big data de los detalles de implementación de la plataforma de tiempo de ejecución: nos permite centrarnos en resolver la lógica comercial y el paralelismo de datos, lo que hace que nuestra iteración de desarrollo sea más rápida.
2. Se ejecuta como un servicio administrado, con un mantenimiento mínimo.

Evolución de nuestra infraestructura

La optimización de nuestra operación de GCP viene con un conjunto único de desafíos. A nuestra escala, los costos pequeños se suman y esto requiere que pensemos profundamente en la dimensión del costo de la infraestructura desde el principio, en el momento del diseño, que fue tanto un cambio cultural como un cambio de proceso. Como ejemplo, en una de nuestras primeras agregaciones de BigQuery, teníamos una consulta grande que unía datos estadísticos con metadatos y luego los agregaba. Debido a la combinación grande y al uso de CURRENT_DATE() como una función dinámica, una implementación ingenua de BigQuery habría costado $1 por ejecución y, durante un día, costaría $1500. Buscando reducir el costo y aumentar el rendimiento, usamos BigQuery para la agregación, mantuvimos los metadatos en MySQL y unimos las dos tablas en la memoria de la aplicación. Este enfoque nos permitió almacenar en caché los resultados de BigQuery con la presencia de funciones dinámicas[11][12][13].

Desarrollo futuro

En PPC, hemos tenido un gran éxito al construir nuestros sistemas en la nube pública, específicamente GCP. BigQuery, Dataflow y Spanner aceleraron nuestros ciclos de desarrollo, acortaron el tiempo de comercialización y demostraron su valor comercial. Nos gusta agradecer a los fantásticos equipos de Google por su colaboración y asociación con nosotros. En Booking.com , tenemos problemas complejos y desafiantes que resolver. Contamos con un equipo de PPC increíblemente talentoso y trabajador, y utilizamos tecnología innovadora para ayudar a las personas a descubrir los viajes de maneras divertidas y creativas. Si esto le emociona, considere trabajar con nosotros. ¡Solicite en jobs.booking.com !

Un agradecimiento especial a Baris Gul, Igor Dralyuk, Sergey Dovgal ( sdovgal ), Mustafa Elbadry , Martijn Hensema y todo el equipo de PPC de Booking.com por contribuir con este artículo.

Notas al pie:

[1] Reserva Q3 2022 10Q: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) Resumen de PPC BigQuery
[4] Descripción de Protobuf en Dremel:https://research.google/pubs/pub36632/ [5] Dremel: una década de análisis SQL interactivo a escala web:https://research.google/pubs/pub49489/
[6] Spanner: base de datos distribuida globalmente de Google:https://research.google/pubs/pub39966/
[7] Spanner: convertirse en un 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: una base de datos SQL distribuida escalable:https://research.google/pubs/pub41344/
[11] Caché de resultados de BQ:https://cloud.google.com/bigquery/docs/cached-results
[12] (Documento interno) Control de costos de BigQuery en PPC: Control de costos de BigQuery
[13] (Documento interno) PPC: Mover agregaciones de local a BigQuery