See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale Che tipo di viaggiatore sei? TripAdvisor cerca di valutare questo non appena interagisci con il sito, quindi ti offre informazioni sempre più rilevanti su ogni clic, in pochi millisecondi. Questa personalizzazione è alimentata da modelli ML avanzati che agiscono sui dati memorizzati su ScyllaDB in esecuzione su AWS. In questo articolo, Dean Poulin (Tripadvisor Data Engineering Lead sul team di servizi e prodotti AI) fornisce uno sguardo a come alimentano questa personalizzazione. È basato sul seguente AWS re:Invent talk: Orientazione Pre-Trip Le parole di Dean... Fondata nel 2000, Tripadvisor è diventata un leader globale nel settore dei viaggi e dell'ospitalità, aiutando centinaia di milioni di viaggiatori a pianificare i loro viaggi perfetti. Tripadvisor genera oltre 1,8 miliardi di dollari di ricavi ed è una società quotata pubblicamente sulla borsa NASDAQ. Oggi, abbiamo un team di oltre 2.800 dipendenti di talento che guidano l'innovazione e la nostra piattaforma serve 400 milioni di visitatori unici al mese - un numero che continua a crescere. Ogni giorno, il nostro sistema gestisce più di 2 miliardi di richieste da 25 a 50 milioni di utenti. Ogni clic su Tripadvisor viene elaborato in tempo reale. Dietro a ciò, stiamo sfruttando i modelli di machine learning per fornire raccomandazioni personalizzate – portandoti più vicino a quel viaggio perfetto. Al centro di questo motore di personalizzazione è ScyllaDB che funziona su AWS. Questo ci consente di fornire una latenza millisecondaria su una scala che poche organizzazioni raggiungono. . 425K operations per second on ScyllaDB with P99 latencies for reads and writes around 1-3 milliseconds Condividerò come Tripadvisor sfrutta la potenza di ScyllaDB, AWS e l'apprendimento automatico in tempo reale per fornire raccomandazioni personalizzate per ogni utente. esploreremo come aiutiamo i viaggiatori a scoprire tutto ciò di cui hanno bisogno per pianificare il loro viaggio perfetto: sia che si tratti di scoprire gemme nascoste, attrazioni da visitare, esperienze indimenticabili o i migliori luoghi dove soggiornare e cenare. Pianificazione Trip Personalizzata Immaginate di pianificare un viaggio.Quando si atterra sulla homepage di Tripadvisor, Tripadvisor sa già se siete un foodie, un avventuriero o un amante della spiaggia - e si vedono raccomandazioni spot-on che sembrano personalizzati per i vostri interessi. Mentre navighi su Tripadvisor, iniziamo a personalizzare ciò che vedi utilizzando modelli di Machine Learning che calcolano i punteggi in base alla tua attività di navigazione corrente e precedente. Raccomandiamo alberghi e esperienze che riteniamo ti interessino. Classichiamo alberghi in base alle tue preferenze personali. Raccomandiamo punti di interesse popolari vicino all'hotel che stai visualizzando. Questi sono tutti allineati in base alle tue preferenze personali e alle tue attività di navigazione precedenti. Il modello di Tripadvisor che serve l'architettura Tripadvisor funziona su centinaia di microservizi scalabili indipendentemente in Kubernetes on-prem e in Amazon EKS. La nostra ML Model Serving Platform è esposta attraverso uno di questi microservizi. Questo servizio di gateway estrae oltre 100 modelli ML dai Servizi Clienti – che ci permette di eseguire test A/B per trovare i modelli migliori utilizzando la nostra piattaforma di sperimentazione. I modelli ML sono sviluppati principalmente dai nostri scienziati dei dati e dagli ingegneri di apprendimento automatico utilizzando i notebook Jupyter su Kubeflow. Essi sono gestiti e addestrati utilizzando ML Flow, e li sviluppiamo su Seldon Core in Kubernetes. Il Custom Feature Store Il Feature Store serve principalmente le funzionalità utente e le funzionalità statiche. Le funzionalità statiche sono memorizzate in Redis perché non cambiano molto spesso. Eseguiamo giornalmente pipeline dati per caricare i dati dal nostro magazzino dati offline nel nostro Feature Store come funzionalità statiche. Le funzionalità utente vengono fornite in tempo reale attraverso una piattaforma chiamata Visitor Platform. Eseguiamo query CQL dinamiche contro ScyllaDB, e . we do not need a caching layer because ScyllaDB is so fast Il nostro Feature Store offre fino a 5 milioni di funzionalità statiche al secondo e mezzo milione di funzionalità utente al secondo. Che cosa è un ML Feature? Le caratteristiche sono variabili di input per i modelli ML che vengono utilizzati per fare una previsione. Alcuni esempi di funzionalità statiche includono premi che un ristorante ha vinto o servizi offerti da un hotel (come la connessione Wi-Fi gratuita, il benessere degli animali domestici o il centro fitness). Le funzionalità utente vengono raccolte in tempo reale mentre gli utenti navigano sul sito. Le memorizziamo in ScyllaDB in modo da poter ricevere richieste rapide. Alcuni esempi di funzionalità utente includono gli hotel visualizzati negli ultimi 30 minuti, i ristoranti visualizzati negli ultimi 24 ore o le recensioni inviate negli ultimi 30 giorni. Le tecnologie che alimentano la piattaforma dei visitatori ScyllaDB è al centro della Visitor Platform. Utilizziamo i microservizi Spring Boot basati su Java per esporre la piattaforma ai nostri clienti. Questo viene implementato su AWS ECS Fargate. Eseguiamo Apache Spark su Kubernetes per i nostri lavori di conservazione dei dati quotidiani, i nostri lavori offline a quelli online. Quindi utilizziamo questi lavori per caricare i dati dal nostro magazzino dati offline in ScyllaDB in modo che siano disponibili sul sito live. Utilizziamo anche Amazon Kinesis per elaborare eventi di tracciamento degli utenti in streaming. Il flusso di dati della piattaforma dei visitatori Il grafico seguente mostra come i dati fluiscono attraverso la nostra piattaforma in quattro fasi: produrre, ingerire, organizzare e attivare. I dati sono generati dal nostro sito web e dalle nostre applicazioni mobili. Alcuni di questi dati includono il nostro grafico di identità utente cross-device, gli eventi di tracciamento del comportamento (come le visualizzazioni di pagine e i clic) e gli eventi di streaming che passano attraverso Kinesis. I microservizi della Visitor Platform vengono utilizzati per ingerire e organizzare questi dati.I dati in ScyllaDB sono memorizzati in due spazi chiave: Lo spazio chiave Visitor Core, che contiene il Grafico di identità del visitatore Lo spazio chiave Metrico del visitatore, che contiene i fatti e le metriche (le cose che le persone hanno fatto mentre navigavano nel sito) Utilizziamo processi ETL quotidiani per mantenere e pulire i dati nella piattaforma. Produciamo Prodotti dati, stampati quotidianamente, nel nostro magazzino dati offline – dove sono disponibili per altre integrazioni e altri tubi dati da utilizzare nel loro trattamento. Ecco uno sguardo alla piattaforma dei visitatori per i numeri: Perché due database? Il nostro database online si concentra sul traffico del sito web in tempo reale e dal vivo. ScyllaDB compie questo ruolo fornendo latenze molto basse e trasmissione elevata. Utilizziamo TTL a breve termine per impedire che i dati nel database online crescano a tempo indeterminato, e i nostri lavori di conservazione dei dati garantiscono che conserviamo solo i dati sull'attività degli utenti per i visitatori reali. Tripadvisor.com ottiene un sacco di traffico bot, e non vogliamo memorizzare i loro dati e cercare di personalizzare i bot - quindi cancelleremo e pulire tutti quei dati. Il nostro magazzino dati offline conserva i dati storici utilizzati per la segnalazione, la creazione di altri prodotti dati e la formazione dei nostri modelli ML. Non vogliamo che i processi di dati offline su larga scala influenzino le prestazioni del nostro sito live, quindi abbiamo due banche dati separate utilizzate per due scopi diversi. Piattaforma Visitor Microservices Utilizziamo 5 microservizi per la piattaforma Visitor: Visitor Core gestisce il grafico di identità utente cross-device in base ai cookie e agli ID del dispositivo. Visitor Metric è il nostro motore di query, e che ci fornisce la possibilità di esporre fatti e metriche per visitatori specifici. Utilizziamo un linguaggio specifico per il dominio chiamato visitor query language, o VQL. Questo esempio VQL consente di visualizzare i più recenti fatti di clic commerciali negli ultimi tre ore. Visitor Publisher e Visitor Saver gestiscono il percorso di scrittura, scrivendo i dati nella piattaforma. Oltre a salvare i dati in ScyllaDB, trasmettiamo anche i dati al magazzino dati offline. Visitor Composite semplifica la pubblicazione dei dati nei lavori di elaborazione dei lotti. Abstrae Visitor Saver e Visitor Core per identificare i visitatori e pubblicare fatti e metriche in una singola chiamata API. Roundtrip Microservizio Latency Questo grafico illustra come le nostre latenze dei microservizi rimangano stabili nel tempo. La latenza media è di soli 2,5 millisecondi, e il nostro P999 è inferiore a 12,5 millisecondi. Questa è una prestazione impressionante, soprattutto dato che gestiamo più di 1 miliardo di richieste al giorno. I nostri clienti microservizi hanno requisiti di latenza rigorosi. il 95% delle chiamate deve essere completato in 12 millisecondi o meno. ScyllaDB latenza Ecco una panoramica delle prestazioni di ScyllaDB in tre giorni. Al suo picco, ScyllaDB gestisce 340.000 operazioni al secondo (comprese le scrittura e la lettura e la cancellazione) e la CPU è fluttuante a soli 21%. ScyllaDB fornisce microsecondi di scrittura e millisecondi di lettura per noi. Partizionare i dati in ScyllaDB Questa immagine mostra come partizioniamo i dati in ScyllaDB. Il Visitor Metric Keyspace ha due tabelle: Fact e Raw Metrics. La chiave primaria nella tabella Fact è Visitor GUID, Fact Type e Created At Date. La chiave di partizione composita è la Visitor GUID e Fact Type. La chiave di raggruppamento è Created At Date, che ci consente di ordinare i dati in partizioni per data. La colonna attributi contiene un oggetto JSON che rappresenta l'evento che si è verificato lì. Alcuni esempi di fatti sono i termini di ricerca, le visualizzazioni delle pagine e le prenotazioni. Utilizziamo la strategia di compattazione livellata di ScyllaDB perché: Ottimizzato per le domande di range Gestire molto bene la cardinalità È meglio per i carichi di lavoro pesanti in lettura, e abbiamo circa 2-3 volte più letture di scrittura Perché ScyllaDB? La nostra soluzione è stata originariamente costruita utilizzando Cassandra on-prem. Ma man mano che la scala è aumentata, lo è stato anche il carico operativo. Ci sono state richieste operazioni dedicate per gestire gli aggiornamenti dei database, i backup, ecc. Inoltre, la nostra soluzione richiede latenze molto basse per i componenti principali. Il nostro sistema di gestione dell'identità utente deve identificare l'utente entro 30 millisecondi - e per la migliore personalizzazione, abbiamo bisogno della nostra piattaforma di tracciamento degli eventi per rispondere in 40 millisecondi. È fondamentale che la nostra soluzione non blocchi il rendering della pagina in modo che i nostri SLA siano molto bassi. Con Cassandra, abbiamo avuto un impatto sulle prestazioni dalla raccolta dei rifiuti. Abbiamo eseguito una Proof of Concept con ScyllaDB e abbiamo scoperto che il throughput era molto migliore di Cassandra e il carico operativo è stato eliminato. Abbiamo voluto un'opzione completamente gestita, quindi abbiamo migrato da Cassandra a ScyllaDB Cloud, seguendo una strategia di doppia scrittura. Ciò ci ha permesso di migrare con zero tempi di interruzione mentre gestiamo 40.000 operazioni o richieste al secondo. Questo diagramma mostra come appare la distribuzione BYOA di ScyllaDB. Nel centro del diagramma, è possibile vedere un cluster ScyllaDB a 6 nodi in esecuzione su EC2. ScyllaDB Monitor ci fornisce i dashboard Grafana e le metriche Prometheus. ScyllaDB Manager si prende cura dell'automazione dell'infrastruttura come l'attivazione di backup e riparazioni. Con questa distribuzione, ScyllaDB potrebbe essere collocato molto vicino ai nostri microservizi per darci latenze ancora più basse e una trasmissione e prestazioni molto più elevate. In conclusione, spero che ora abbiate una migliore comprensione della nostra architettura, delle tecnologie che alimentano la piattaforma e di come ScyllaDB svolga un ruolo critico nel permetterci di gestire la scala estremamente alta di TripAdvisor. di Cynthia Dunlop Cynthia è Senior Director of Content Strategy di ScyllaDB. Ha scritto sullo sviluppo di software e l'ingegneria della qualità per oltre 20 anni.