See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale ¿Qué tipo de viajero eres? Tripadvisor intenta evaluar esto tan pronto como interactúes con el sitio, luego te ofrece información cada vez más relevante a cada clic, en cuestión de milisegundos. En este artículo, Dean Poulin (Tripadvisor Data Engineering Lead en el equipo de Servicios y Productos de IA) ofrece una mirada a cómo impulsan esta personalización. Se basa en la siguiente conversación de AWS re:Invent: Orientación Pre-Trip En palabras de Dean... Fundado en 2000, TripAdvisor se ha convertido en un líder mundial en viajes y hospitalidad, ayudando a cientos de millones de viajeros a planificar sus viajes perfectos. TripAdvisor genera más de 1.8 mil millones de dólares en ingresos y es una compañía publicamente negociada en la Bolsa de Valores NASDAQ. Hoy en día, tenemos un talentoso equipo de más de 2.800 empleados que impulsan la innovación, y nuestra plataforma sirve a 400 millones de visitantes únicos al mes, un número que crece continuamente. En cualquier día, nuestro sistema gestiona más de 2 mil millones de solicitudes de 25 a 50 millones de usuarios. Cada clic que haces en Tripadvisor se procesa en tiempo real. Detrás de eso, estamos aprovechando modelos de aprendizaje automático para entregar recomendaciones personalizadas – acercándote a ese viaje perfecto. En el corazón de este motor de personalización está ScyllaDB que funciona en AWS. Esto nos permite ofrecer una latencia de milisegundos a una escala que pocas organizaciones alcanzan. . 425K operations per second on ScyllaDB with P99 latencies for reads and writes around 1-3 milliseconds Compartiremos cómo Tripadvisor está aprovechando el poder de ScyllaDB, AWS y el aprendizaje automático en tiempo real para ofrecer recomendaciones personalizadas para cada usuario. Exploraremos cómo ayudamos a los viajeros a descubrir todo lo que necesitan para planificar su viaje perfecto: ya sea descubriendo joyas ocultas, atracciones imprescindibles, experiencias inolvidables o los mejores lugares para alojarse y cenar. Planificación de viaje personalizada Imagínese que está planeando un viaje. tan pronto como aterriza en la página principal de TripAdvisor, TripAdvisor ya sabe si usted es un foodie, un aventurero o un amante de la playa - y está viendo recomendaciones spot-on que parecen personalizadas para sus propios intereses. A medida que navega por TripAdvisor, comenzamos a personalizar lo que ve a través de modelos de Machine Learning que calculan las puntuaciones basadas en su actividad de navegación actual y anterior. Recomendamos hoteles y experiencias que creemos que le interesarían. Classificamos hoteles según sus preferencias personales. Recomendamos puntos de interés populares cerca del hotel que está viendo. Todos estos están ajustados en función de sus propias preferencias personales y de su actividad de navegación anterior. El modelo de Tripadvisor que sirve la arquitectura Tripadvisor se ejecuta en cientos de microservicios escalables de forma independiente en Kubernetes on-prem y en Amazon EKS. Nuestra Plataforma de Servicio de Modelos ML se expone a través de uno de estos microservicios. Este servicio de gateway extrae más de 100 modelos ML de los Servicios del Cliente, lo que nos permite ejecutar pruebas A/B para encontrar los mejores modelos utilizando nuestra plataforma de experimentación.Los modelos ML son desarrollados principalmente por nuestros científicos de datos e ingenieros de aprendizaje automático utilizando Jupyter Notebooks en Kubeflow. Se manejan y entrenan utilizando ML Flow, y los implementamos en Seldon Core en Kubernetes.Nuestra Tienda de características personalizadas proporciona características a nuestros modelos ML, lo que les permite hacer predicciones precisas. La tienda de caracteres personalizados La tienda de características sirve principalmente a las características de usuario y las características estáticas. Las características estáticas se almacenan en Redis porque no cambian con mucha frecuencia. ejecutamos diariamente tuberías de datos para cargar datos de nuestro almacén de datos fuera de línea a nuestra tienda de características como características estáticas. Las funciones de usuario se proporcionan en tiempo real a través de una plataforma llamada Plataforma de Visitantes. ejecutamos consultas CQL dinámicas contra ScyllaDB, y . we do not need a caching layer because ScyllaDB is so fast Nuestra tienda de características ofrece hasta 5 millones de funciones estáticas por segundo y medio millón de funciones de usuario por segundo. ¿Qué es una característica ML? Las características son variables de entrada para los modelos ML que se utilizan para hacer una predicción. Algunos ejemplos de Funciones estáticas son premios que ha ganado un restaurante o comodidades ofrecidas por un hotel (como Wi-Fi gratuito, amigable con mascotas o centro de fitness). Las características del usuario se recopilan en tiempo real a medida que los usuarios navegan por el sitio. Las almacenamos en ScyllaDB para que podamos obtener consultas rápidas. Algunos ejemplos de características del usuario son los hoteles visitados en los últimos 30 minutos, restaurantes visitados en las últimas 24 horas o reseñas enviadas en los últimos 30 días. Las tecnologías que impulsan la plataforma de visitantes ScyllaDB es el núcleo de la Plataforma de Visitantes. Utilizamos microservicios Spring Boot basados en Java para exponer la plataforma a nuestros clientes. Esto se implementa en AWS ECS Fargate. Ejecutamos Apache Spark en Kubernetes para nuestros trabajos diarios de retención de datos, nuestros trabajos offline a en línea. Luego utilizamos esos trabajos para cargar datos de nuestro almacén de datos offline a ScyllaDB para que estén disponibles en el sitio en vivo. También utilizamos Amazon Kinesis para procesar eventos de seguimiento de usuarios en streaming. El flujo de datos de la plataforma de visitantes El siguiente gráfico muestra cómo los datos fluyen a través de nuestra plataforma en cuatro etapas: producir, ingerir, organizar y activar. Los datos son generados por nuestro sitio web y nuestras aplicaciones móviles.Algunos de esos datos incluyen nuestro Gráfico de Identidad de Usuario Cross-Device, eventos de seguimiento del comportamiento (como vistas de páginas y clics) y eventos de transmisión que pasan a través de Kinesis. Los microservicios de Visitor Platform se utilizan para ingerir y organizar estos datos.Los datos en ScyllaDB se almacenan en dos espacios clave: El espacio clave del núcleo del visitante, que contiene el gráfico de identidad del visitante El espacio clave Metrica del visitante, que contiene hechos y métricas (las cosas que las personas hicieron mientras navegaban por el sitio) Utilizamos procesos ETL diarios para mantener y limpiar los datos en la plataforma. Producimos Productos de Datos, estampados diariamente, en nuestro almacén de datos offline – donde están disponibles para otras integraciones y otras rutas de datos para usar en su procesamiento. Aquí está una mirada a la Plataforma de Visitantes por números: ¿Por qué dos bases de datos? Nuestra base de datos en línea se centra en el tráfico en tiempo real y en vivo del sitio web. ScyllaDB cumple este papel proporcionando latencias muy bajas y alta transmisión. Utilizamos TTLs a corto plazo para evitar que los datos en la base de datos en línea crezcan indefinidamente, y nuestros trabajos de retención de datos aseguran que solo conservamos datos de actividad del usuario para los visitantes reales. Tripadvisor.com recibe mucho tráfico de bot, y no queremos almacenar sus datos y tratar de personalizar a los bots, por lo que borramos y limpiamos todos esos datos. Nuestro almacén de datos offline almacena los datos históricos utilizados para informar, crear otros productos de datos y capacitar a nuestros modelos ML. No queremos que los procesos de datos offline a gran escala afecten al rendimiento de nuestro sitio en vivo, por lo que tenemos dos bases de datos separadas que se utilizan para dos fines diferentes. Plataformas de microservicios de visitantes Utilizamos 5 microservices para la Plataforma de Visitantes: Visitor Core gestiona el gráfico de identidad de usuario cross-device basado en cookies e ID de dispositivo. Visitor Metric es nuestro motor de consultas, y que nos proporciona la capacidad de exponer hechos y métricas para visitantes específicos. usamos un idioma específico de dominio llamado lenguaje de consulta de visitantes, o VQL. Este ejemplo VQL le permite ver los últimos datos de clic comercial en las últimas tres horas. Visitor Publisher y Visitor Saver manejan el camino de escritura, escribiendo datos en la plataforma. Además de guardar datos en ScyllaDB, también transmitimos datos al almacén de datos offline. Visitor Composite simplifica la publicación de datos en tareas de procesamiento de lotes. Abstrae Visitor Saver y Visitor Core para identificar a los visitantes y publicar hechos y métricas en una única llamada de API. Latencia Roundtrip Microservice Este gráfico ilustra cómo nuestras latencias de microservicio permanecen estables a lo largo del tiempo. La latencia promedio es de sólo 2,5 milisegundos, y nuestro P999 es inferior a 12,5 milisegundos. Nuestros clientes de microservicios tienen estrictos requisitos de latencia. 95% de las llamadas deben completarse en 12 milisegundos o menos. La Latencia de ScyllaDB Aquí está un resumen del rendimiento de ScyllaDB en tres días. En su pico, ScyllaDB está manejando 340.000 operaciones por segundo (incluyendo escritos, leídos y borrados) y la CPU está volviendo a tan sólo 21%. ScyllaDB proporciona microsegundos de escritura y milisegundos de lectura para nosotros.Este nivel de rendimiento rápido es precisamente por eso que elegimos ScyllaDB. Particionamiento de datos en ScyllaDB Esta imagen muestra cómo separamos los datos en ScyllaDB. El Visitor Metric Keyspace tiene dos tablas: Fact y Raw Metrics. La clave principal en la tabla Fact es Visitor GUID, Fact Type, y Created At Date. La clave de partición compuesta es el Visitor GUID y Fact Type. La clave de agrupamiento es Created At Date, lo que nos permite ordenar los datos en particiones por fecha. La columna de atributos contiene un objeto JSON que representa el evento que ocurrió allí. Algunos ejemplos de hechos son términos de búsqueda, vistas de página y reservas. Utilizamos la estrategia de compactación nivelada de ScyllaDB porque: Se optimiza para las consultas de rango Trata muy bien la alta cardinalidad Es mejor para cargas de trabajo pesadas de lectura, y tenemos aproximadamente 2-3 veces más lecturas que escritas ¿Por qué ScyllaDB? Nuestra solución fue construida originalmente utilizando Cassandra on-prem. Pero a medida que la escala creció, la carga operativa también. Se requirió soporte de operaciones dedicadas para que podamos gestionar las actualizaciones de la base de datos, copias de seguridad, etc. Además, nuestra solución requiere latencias muy bajas para los componentes principales. Nuestro sistema de Gestión de Identidad del Usuario debe identificar al usuario dentro de 30 milisegundos – y para la mejor personalización, requerimos que nuestra plataforma de seguimiento de eventos responda en 40 milisegundos. Es crucial que nuestra solución no bloquee la renderización de la página, por lo que nuestros SLA son muy bajos. Con Cassandra, tuvimos impactos en el rendimiento de la recogida de basura. Realizamos una prueba de concepto con ScyllaDB y encontramos que la transmisión es mucho mejor que Cassandra y la carga operativa se eliminó. ScyllaDB nos dio una base de datos de servicio en vivo monstruosamente rápida con las latencias más bajas posibles. Queríamos una opción totalmente gestionada, por lo que migraron de Cassandra a ScyllaDB Cloud, siguiendo una estrategia de doble escritura. Esto nos permitió migrar con tiempo de inactividad cero mientras manejábamos 40.000 operaciones o solicitudes por segundo. Más tarde, migraron de ScyllaDB Cloud al modelo "Trae tu cuenta" de ScyllaDB, donde puede tener que el equipo de ScyllaDB implemente la base de datos de ScyllaDB en su propia cuenta de AWS. Esto nos dio un mejor rendimiento y una mejor privacidad de datos. Este diagrama muestra cómo se ve la implementación BYOA de ScyllaDB. En el centro del diagrama, se puede ver un clúster ScyllaDB de 6 nodos que se ejecuta en EC2. ScyllaDB Monitor nos da los dashboards de Grafana así como las métricas de Prometheus. ScyllaDB Manager se ocupa de la automatización de la infraestructura como la activación de copias de seguridad y reparaciones. Con esta implementación, ScyllaDB podría ser co-localizado muy cerca de nuestros microservicios para darnos latencias aún más bajas, así como mucho mayor rendimiento y rendimiento. En resumen, espero que ahora tenga una mejor comprensión de nuestra arquitectura, las tecnologías que alimentan la plataforma y cómo ScyllaDB juega un papel crítico en permitirnos manejar la escala extremadamente alta de TripAdvisor. Más sobre Cynthia Dunlop Cynthia es directora senior de estrategia de contenido en ScyllaDB. Ha estado escribiendo sobre desarrollo de software e ingeniería de calidad durante más de 20 años.