Vea la ingeniería detrás de la personalización en tiempo actual en la escala masiva (y de rápido crecimiento) de TripAdvisor
¿Qué tipo de viajero eres? TripAdvisor intenta evaluar esto tan pronto como se relacione con el sitio, luego le ofrece información cada vez más relevante con cada clic, dentro de una cuestión de milisegundos. Esta personalización está impulsada por modelos ML avanzados que actúan sobre datos almacenados en Scylladb que se ejecuta en AWS.
En este artículo, Dean Poulin (TripAdvisor Knowledge Engineering Ingeniería en el equipo de servicios y productos de IA) proporciona una mirada a cómo impulsan esta personalización. Dean comparte una muestra de los desafíos técnicos involucrados en la entrega de personalización en tiempo actual en la escala masiva (y de rápido crecimiento) de TripAdvisor.
Se basa en el siguiente AWS Re: Invent Discuss:
https://www.youtube.com/watch?v=fttwnnaiuyi
Orientación previa al viaje
En palabras de Dean …
Comencemos con una instantánea rápida de quién es TripAdvisor y la escala en la que operamos. Fundada 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 en ingresos y es una empresa que cotiza en bolsa en la Bolsa de Nasdaq. Hoy, tenemos un equipo talentoso de más de 2.800 empleados que impulsan la innovación, y nuestra plataforma atiende a los asombrosos 400 millones de visitantes únicos por mes, un número que está creciendo continuamente.
En cualquier día, nuestro sistema maneja más de 2 mil millones de solicitudes de 25 a 50 millones de usuarios. Cada clic que haga en TripAdvisor se procesa en tiempo actual. Detrás de eso, estamos aprovechando modelos de aprendizaje automático para ofrecer recomendaciones personalizadas, lo que lo acerca a ese viaje perfecto. En el corazón de este motor de personalización se encuentra ScylladB en AWS. Esto nos permite entregar la latencia de milisegundos a una escala que pocas organizaciones alcancen. En el pico del tráfico, golpeamos Operaciones de 425k por segundo en ScylladB con latencias P99 para lecturas y escribe alrededor de 1-3 milisegundos.
Compartiré cómo TripAdvisor está aprovechando el poder de Scylladb, AWS y el aprendizaje automático en tiempo actual para entregar 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 gemas ocultas, atracciones imprescindibles, experiencias inolvidables o los mejores lugares para quedarse y cenar. Este [article] Se trata de la ingeniería detrás de eso: cómo entregamos contenido sin problemas y relevantes a los usuarios en tiempo actual, ayudándoles a encontrar exactamente lo que están buscando lo más rápido posible.
Planificación de viaje personalizada
Imagina que estás planeando un viaje. Tan pronto como aterriza en la página de inicio de TripAdvisor, TripAdvisor ya sabe si eres un entusiasta, un aventurero o un amante de la playa, y estás viendo recomendaciones que parecen personalizadas para tus propios intereses. ¿Cómo sucede eso en milisegundos?
A medida que navega por TripAdvisor, comenzamos a personalizar lo que ve utilizando modelos de aprendizaje automático que calculan las puntuaciones en función de su actividad de navegación precise y previa. Recomendamos hoteles y experiencias que creemos que estaría interesado. Ordenamos hoteles en función de sus preferencias personales. Recomendamos puntos de interés populares cerca del resort que está viendo. Todos estos están sintonizados según sus propias preferencias personales y actividad previa de navegación.
Arquitectura de servicio modelo de TripAdvisor
TripAdvisor se ejecuta en cientos de microservicios escalables independientemente en Kubernetes en Prem y en Amazon EKS. Nuestra plataforma de servicio ML modelo está expuesta a través de uno de estos microservicios.
Este servicio de puerta de enlace abstrae más de 100 ml de modelos de los servicios al 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 que utilizan cuadernos Jupyter en Kubeflow. Se administran y entrenan usando ML Stream, 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 características personalizadas
La tienda de funciones sirve principalmente características del usuario y características estáticas. Las características estáticas se almacenan en Redis porque no cambian muy a menudo. Ejecutaremos tuberías de datos diariamente para cargar datos de nuestro almacén de datos fuera de línea en nuestro almacén de funciones como características estáticas.
Las características del usuario se sirven en tiempo actual a través de una plataforma llamada plataforma de visitantes. Ejecutamos consultas CQL dinámicas contra Scylladb, y No necesitamos una capa de almacenamiento en caché porque Scylladb es muy rápido.
Nuestra tienda de características sirve hasta 5 millones de características estáticas por segundo y medio millón de características de usuario por segundo.
¿Qué es una característica de ML?
Las características son variables de entrada a los modelos ML que se utilizan para hacer una predicción. Hay características estáticas y características del usuario.
Algunos ejemplos de características estáticas son los premios que un restaurante ha ganado o los servicios ofrecidos por un resort (como Wi-Fi gratuito, amigable para mascotas o gimnasio).
Las características del usuario se recopilan en tiempo actual a medida que los usuarios navegan por el sitio. Los almacenamos en Scylladb para que podamos obtener consultas rápidas de Lightning. Algunos ejemplos de características del usuario son los hoteles vistos en los últimos 30 minutos, los restaurantes vistos en las últimas 24 horas o las revisiones enviadas en los últimos 30 días.
La plataforma de visitantes de tecnologías que alimentan
Scylladb está en el núcleo de la plataforma de visitantes. Utilizamos microservicios de arranque de primavera 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, nuestro fuera de línea con los trabajos en línea. Luego usamos esos trabajos para cargar datos de nuestro almacén de datos fuera de línea en ScylladB para que estén disponibles en el sitio en vivo. También utilizamos Amazon Kinesis para procesar eventos de seguimiento de usuarios.
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 producidos por nuestro sitio net y nuestras aplicaciones móviles. Algunos de esos datos incluyen nuestro gráfico de identidad de usuario de servicio cruzado, eventos de seguimiento de comportamiento (como vistas y clics de página) y eventos de transmisión que pasan por kinesis. Además, la segmentación de la audiencia se carga en nuestra plataforma.
Los microservicios de la plataforma de visitantes se utilizan para ingerir y organizar estos datos. Los datos en Scylladb se almacenan en dos espacios de teclas:
- El espacio de llave del núcleo del visitante, que contiene el gráfico de identidad del visitante
- El espacio de la llave de la métrica de los visitantes, que contiene hechos y métricas (las cosas que la gente hizo al examinar 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 fuera de línea, donde están disponibles para otras integraciones y otras tuberías de datos para usar en su procesamiento.
Aquí hay un vistazo a la plataforma de visitantes por los números:
¿Por qué dos bases de datos?
Nuestra base de datos en línea se centra en el tráfico del sitio net en vivo en tiempo actual. ScylladB cumple este papel al proporcionar latencias muy bajas y alto rendimiento. Utilizamos TTL a corto plazo para evitar que los datos en la base de datos en línea aumenten indefinidamente, y nuestros trabajos de retención de datos aseguran que solo mantengamos datos de actividades del usuario para visitantes reales. TripAdvisor.com obtiene mucho tráfico de bot, y no queremos almacenar sus datos e intentar personalizar los bots, para que eliminemos y limpiemos todos esos datos.
Nuestro almacén de datos fuera de línea conserva datos históricos utilizados para informar, crear otros productos de datos y capacitar a nuestros modelos ML. No queremos procesos de datos fuera de línea a gran escala que afecten el rendimiento de nuestro sitio en vivo, por lo que tenemos dos bases de datos separadas utilizadas para dos propósitos diferentes.
Microservicios de plataforma de visitantes
Usamos 5 microservicios para la plataforma de visitantes:
- Núcleo de visitante administra el gráfico de identidad del usuario de los dispositivos cruzados basado en cookies e ID de dispositivo.
- Métrica de visitante es nuestro motor de consulta, y eso nos proporciona la capacidad de exponer hechos y métricas para visitantes específicos. Utilizamos un lenguaje específico de dominio llamado Lenguaje de consultas de visitantes, o VQL. Este ejemplo VQL le permite ver los últimos hechos de clic en el comercio en las últimas tres horas.
- Editor de visitantes y Ahorrador de visitante Maneje la ruta de escritura, escribiendo datos en la plataforma. Además de guardar datos en ScylladB, también transmitimos datos al almacén de datos fuera de línea. Eso ha terminado con Amazon Kinesis.
- Compuesto de visitante Simplifica la publicación de datos en trabajos de procesamiento por lotes. Abraza el ahorro de visitantes y el núcleo de visitantes para identificar a los visitantes y publicar hechos y métricas en una sola llamada API.
Latencia de microservicio de ida y vuelta
Este gráfico ilustra cómo nuestras latencias de microservicio permanecen estables con el tiempo.
La latencia promedio es de solo 2.5 milisegundos, y nuestro P999 tiene menos de 12.5 milisegundos. Este es un rendimiento impresionante, especialmente dado que manejamos más de mil millones de solicitudes por día.
Nuestros clientes de microservicio tienen requisitos de latencia estrictos. El 95% de las llamadas deben completarse en 12 milisegundos o menos. Si repasan eso, nos pagan y tendremos que averiguar qué está afectando las latencias.
Latencia de scylladb
Aquí hay una instantánea del rendimiento de Scylladb durante tres días.
En Peak, ScylladB maneja 340,000 operaciones por segundo (incluidas las escrituras y lecturas y eliminaciones) y la CPU está rondando solo el 21%. ¡Esta es una escala de alta escala en acción!
Scylladb ofrece escrituras de microsegundos y lecturas de milisegundos para nosotros. Este nivel de rendimiento rápido es exactamente por qué elegimos scylladb.
Partición de datos en Scylladb
Esta imagen muestra cómo dividimos los datos en Scylladb.
El espacio de llave métrica del visitante tiene dos tablas: hecho y métricas en bruto. La clave principal en la tabla de hechos es GUID del visitante, tipo de hecho y creado en la fecha. La tecla de partición compuesta es el Guid y el tipo de hechos del visitante. La clave de agrupación se crea en la fecha, lo que nos permite ordenar datos en particiones por fecha. La columna de atributos contiene un objeto JSON que representa el evento que ocurrió allí. Algunos hechos de ejemplo son términos de búsqueda, vistas de página y reservas.
Usamos la estrategia de compactación nivelada de Scylladb porque:
- Está optimizado para consultas de rango
- Maneja muy bien la alta cardinalidad
- Es mejor para las cargas de trabajo de lectura, y tenemos alrededor de 2-3x más lecturas de lo que escribe
¿Por qué Scylladb?
Nuestra solución se construyó originalmente usando Cassandra en el premio. Pero a medida que aumentó la escala, también lo hizo la carga operativa. Se requiere soporte de operaciones dedicadas para que podamos administrar las actualizaciones de la base de datos, las copias de seguridad, and so on. Además, nuestra solución requiere latencias muy bajas para los componentes centrales. Nuestro sistema de gestión de identidad de usuario debe identificar al usuario dentro de los 30 milisegundos, y para la mejor personalización, requerimos que nuestra plataforma de seguimiento de eventos responda en 40 milisegundos. Es elementary que nuestra solución no bloquee la página para que nuestros SLA sean muy bajos. Con Cassandra, tuvimos impactos en el rendimiento de la recolección de basura. Eso estaba impactando principalmente las latencias de la cola, las latencias P999 y P9999.
Realizamos una prueba de concepto con Scylladb y encontramos que el rendimiento es mucho mejor que Cassandra y la carga operativa fue eliminada. 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 administrada, por lo que emigramos de Cassandra a Scylladb Cloud, siguiendo una estrategia de doble escritura. Eso nos permitió migrar con cero tiempo de inactividad mientras manejaba 40,000 operaciones o solicitudes por segundo. Más tarde, migramos de Scylladb Cloud a el modelo de “traer su propia cuenta” de Scylladb, donde puede hacer que el equipo de Scylladb despliegue la base de datos de Scylladb en su propia cuenta AWS. Esto nos dio un rendimiento mejorado, así como una mejor privacidad de datos.
Este diagrama muestra cómo se ve la implementación de BYOA de Scylladb.
En el centro del diagrama, puede ver un clúster SCYLLADB de 6 nodos que se ejecuta en EC2. Y luego hay dos instancias de EC2 adicionales.
- Scylladb Monitor nos ofrece paneles de Grafana, así como métricas Prometheus.
- SCYLLADB Supervisor se encarga de la automatización de infraestructura, como activar copias de seguridad y reparaciones.
Con esta implementación, ScylladB podría ubicarse muy cerca de nuestros microservicios para darnos latencias aún más bajas, así como un rendimiento y rendimiento mucho más altos.
Envolviendo, espero que ahora comprenda mejor nuestra arquitectura, las tecnologías que alimentan la plataforma y cómo ScylladB juega un papel elementary en permitirnos manejar la escala extremadamente alta de TripAdvisor.
Acerca de Cynthia Dunlop
Cynthia es directora senior de estrategia de contenido en Scylladb. Ella ha estado escribiendo sobre desarrollo de software program e ingeniería de calidad durante más de 20 años.
