See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale Tripadvisor versucht, dies zu bewerten, sobald Sie mit der Website interagieren, und bietet Ihnen dann bei jedem Klick immer relevantere Informationen – innerhalb von Millisekunden. In diesem Artikel gibt Dean Poulin (Tripadvisor Data Engineering Leader am AI Service and Products Team) einen Blick darauf, wie diese Personalisierung angetrieben wird. Es basiert auf dem folgenden AWS re:Invent Talk: Pre-Trip Orientierung In den Worten von Dean... Tripadvisor wurde im Jahr 2000 gegründet und hat sich zu einem globalen Marktführer im Bereich Reisen und Gastfreundschaft entwickelt, der Hunderte von Millionen Reisenden hilft, ihre perfekten Reisen zu planen. Tripadvisor generiert über 1,8 Milliarden US-Dollar Umsatz und ist ein börsennotiertes Unternehmen auf der NASDAQ-Börse.Heute verfügen wir über ein talentiertes Team von über 2.800 Mitarbeitern, die Innovationen vorantreiben, und unsere Plattform bedient eine erstaunliche Zahl von 400 Millionen einzigartigen Besuchern pro Monat – eine Zahl, die ständig wächst. An jedem Tag bearbeitet unser System mehr als 2 Milliarden Anfragen von 25 bis 50 Millionen Benutzern. Jeder Klick, den Sie auf Tripadvisor machen, wird in Echtzeit verarbeitet. Danach nutzen wir Machine Learning-Modelle, um personalisierte Empfehlungen zu liefern – um Sie näher an diese perfekte Reise zu bringen. Im Herzen dieser Personalisierungs-Engine ist ScyllaDB, der auf AWS läuft. Dies ermöglicht es uns, Millisekundenlatenz auf einer Skala zu liefern, die nur wenige Organisationen erreichen. . 425K operations per second on ScyllaDB with P99 latencies for reads and writes around 1-3 milliseconds Wir werden untersuchen, wie wir Reisenden helfen, alles zu entdecken, was sie brauchen, um ihre perfekte Reise zu planen: ob es sich dabei um versteckte Edelsteine, Sehenswürdigkeiten, unvergessliche Erlebnisse oder die besten Orte zum Verweilen und Essen handelt. Personalisierte Trip-Planung Sobald Sie auf der TripAdvisor-Homepage landen, weiß Tripadvisor bereits, ob Sie ein Foodie, ein Abenteurer oder ein Strandliebhaber sind – und Sie sehen Spot-on-Empfehlungen, die für Ihre eigenen Interessen personalisiert erscheinen. Während Sie auf Tripadvisor surfen, beginnen wir, das, was Sie sehen, mithilfe von Machine Learning-Modellen zu personalisieren, die Bewertungen basierend auf Ihrer aktuellen und früheren Surfaktivität berechnen. Wir empfehlen Hotels und Erlebnisse, von denen wir glauben, dass Sie interessiert sind. Wir sortieren Hotels nach Ihren persönlichen Vorlieben. Wir empfehlen beliebte Sehenswürdigkeiten in der Nähe des Hotels, das Sie sehen. Das Modell von Tripadvisor dient der Architektur Tripadvisor läuft auf Hunderten von unabhängig skalierbaren Mikroservices in Kubernetes on-prem und in Amazon EKS. Unsere ML Model Serving Platform wird durch einen dieser Mikroservices ausgestellt. Dieser Gateway-Dienst extrahiert über 100 ML-Modelle aus den Kundenservices – was es uns ermöglicht, A/B-Tests durchzuführen, um die besten Modelle mit unserer Experimentierplattform zu finden. Die ML-Modelle werden hauptsächlich von unseren Datenwissenschaftlern und Machine Learning-Ingenieuren mit Jupyter Notebooks auf Kubeflow entwickelt. Sie werden mithilfe von ML Flow verwaltet und geschult, und wir setzen sie auf Seldon Core in Kubernetes ein. Der Custom Feature Store Der Feature Store bedient hauptsächlich User Features und Static Features. Static Features werden in Redis gespeichert, weil sie sich nicht sehr oft ändern. Wir führen täglich Datenleitungen aus, um Daten aus unserem Offline-Datenlager in unseren Feature Store als Static Features zu laden. Benutzerfunktionen werden in Echtzeit über eine Plattform namens Visitor Platform bereitgestellt. Wir führen dynamische CQL-Abfragen gegen ScyllaDB aus. . we do not need a caching layer because ScyllaDB is so fast Unser Feature Store bietet bis zu 5 Millionen statische Funktionen pro Sekunde und eine halbe Million Benutzerfunktionen pro Sekunde. Was ist ein ML Feature? Features sind Eingabevariablen zu den ML Modellen, die verwendet werden, um eine Vorhersage zu machen. Some examples of Static Features are awards that a restaurant has won or amenities offered by a hotel (like free Wi-Fi, pet friendly or fitness center). Benutzerfunktionen werden in Echtzeit gesammelt, während Benutzer auf der Website surfen. Wir speichern sie in ScyllaDB, damit wir blitzschnelle Abfragen erhalten können. Einige Beispiele für Benutzerfunktionen sind die Hotels, die in den letzten 30 Minuten angesehen wurden, Restaurants, die in den letzten 24 Stunden angesehen wurden, oder Bewertungen, die in den letzten 30 Tagen eingereicht wurden. Die Technologien, die die Besucherplattform stärken ScyllaDB ist der Kern der Visitor Platform. Wir verwenden Java-basierte Spring Boot-Mikroservices, um die Plattform unseren Kunden zu präsentieren. Dies wird auf AWS ECS Fargate bereitgestellt. Wir betreiben Apache Spark auf Kubernetes für unsere täglichen Datenspeicherungsaufgaben, unsere Offline-zu-Online-Aufgaben. Dann verwenden wir diese Jobs, um Daten aus unserem Offline-Datenlager in ScyllaDB zu laden, damit sie auf der Live-Website verfügbar sind. Der Datenfluss der Besucherplattform Die folgende Grafik zeigt, wie Daten in vier Phasen durch unsere Plattform fließen: produzieren, aufnehmen, organisieren und aktivieren. Einige dieser Daten umfassen unser Cross-Device User Identity Graph, Behavior Tracking-Ereignisse (wie Seitenbesuche und Klicks) und Streaming-Ereignisse, die durch Kinesis gehen. Die Microservices der Visitor Platform werden verwendet, um diese Daten zu erfassen und zu organisieren.Die Daten in ScyllaDB werden in zwei Schlüsselräumen gespeichert: Der Visitor Core-Schlüsselraum, der das Visitor Identity Graph enthält Der Visitor Metric Keyspace, der Fakten und Metriken enthält (die Dinge, die die Leute beim Surfen auf der Website taten) Wir produzieren Datenprodukte, die täglich gestempelt werden, in unserem Offline-Datenlager – wo sie für andere Integrationen und andere Datenleitungen zur Verarbeitung zur Verfügung stehen. Hier ist ein Blick auf die Visitor Platform nach den Zahlen: Warum zwei Datenbanken? Unsere Online-Datenbank konzentriert sich auf den Live-Website-Traffic in Echtzeit. ScyllaDB erfüllt diese Rolle, indem es sehr niedrige Verzögerungen und hohe Durchsatzmengen bietet. Wir verwenden kurzfristige TTLs, um zu verhindern, dass die Daten in der Online-Datenbank unbegrenzt wachsen, und unsere Datenspeicherungsaufgaben sorgen dafür, dass wir nur Benutzeraktivitätsdaten für echte Besucher speichern. Tripadvisor.com bekommt viel Bot-Traffic, und wir wollen ihre Daten nicht speichern und versuchen, Bots zu personalisieren - also löschen und reinigen wir all diese Daten. Unser Offline-Datenlager speichert historische Daten, die für die Berichterstattung, die Erstellung anderer Datenprodukte und die Ausbildung unserer ML-Modelle verwendet werden.Wir wollen keine großen Offline-Datenprozesse, die die Leistung unserer Live-Site beeinflussen, also haben wir zwei separate Datenbanken, die für zwei verschiedene Zwecke verwendet werden. Besucher-Plattform Microservices Wir verwenden 5 Mikroservices für die Visitor-Plattform: Visitor Core verwaltet das Geräteübergreifende Benutzeridentitätsdiagramm basierend auf Cookies und Geräte-IDs. Visitor Metric ist unsere Abfrage-Engine, die uns die Möglichkeit bietet, Fakten und Metriken für bestimmte Besucher aufzudecken.Wir verwenden eine Domainspezifische Sprache namens Visitor Query Language, oder VQL. Dieses Beispiel VQL ermöglicht es Ihnen, die neuesten Trade-Click-Fakten in den letzten drei Stunden zu sehen. Visitor Publisher und Visitor Saver verwalten den Schreibweg und schreiben Daten in die Plattform.Neben dem Speichern von Daten in ScyllaDB streamen wir auch Daten in das Offline-Datenlager. Visitor Composite vereinfacht die Veröffentlichung von Daten in Batchverarbeitungsjobs. Es abstrahiert Visitor Saver und Visitor Core, um Besucher zu identifizieren und Fakten und Metriken in einem einzigen API-Anruf zu veröffentlichen. Roundtrip Microservice Latenz Dieses Diagramm zeigt, wie unsere Microservice-Latenzen im Laufe der Zeit stabil bleiben. Die durchschnittliche Latenz beträgt nur 2,5 Millisekunden, und unser P999 beträgt weniger als 12,5 Millisekunden. Unsere Mikroservice-Clients haben strenge Latenzanforderungen. 95% der Anrufe müssen in 12 Millisekunden oder weniger abgeschlossen werden. ScyllaDB Latenz Hier ist ein Snapshot der Leistung von ScyllaDB über drei Tage. Auf dem Höhepunkt verarbeitet ScyllaDB 340.000 Operationen pro Sekunde (einschließlich Schreiben und Lesen und Löschen) und die CPU schwankt bei nur 21%. ScyllaDB liefert für uns Mikrosekunden schreiben und Millisekunden lesen. Partitionierung von Daten in ScyllaDB Dieses Bild zeigt, wie wir Daten in ScyllaDB partitionieren. The Visitor Metric Keyspace has two tables: Fact and Raw Metrics. The primary key on the Fact table is Visitor GUID, Fact Type, and Created At Date. The composite partition key is the Visitor GUID and Fact Type. The clustering key is Created At Date, which allows us to sort data in partitions by date. The attributes column contains a JSON object representing the event that occurred there. Some example Facts are Search Terms, Page Views, and Bookings. Wir verwenden die Leveled Compaction Strategie von ScyllaDB, weil: Optimiert für Range Queries Es bewältigt hohe Kardinalität sehr gut Es ist besser für lesebedürftige Workloads, und wir haben etwa 2-3X mehr Lesen als Schreiben Warum ScyllaDB? Unsere Lösung wurde ursprünglich mit Cassandra on-prem gebaut. Aber da die Skala zugenommen hat, hat auch die operative Belastung zugenommen. Es erforderte dedizierte Betriebsunterstützung, damit wir Upgrades der Datenbank, Backups usw. verwalten können. Auch unsere Lösung erfordert sehr niedrige Latenzzeiten für Kernkomponenten. Unser User Identity Management-System muss den Benutzer innerhalb von 30 Millisekunden identifizieren – und für die beste Personalisierung benötigen wir unsere Event-Tracking-Plattform, um in 40 Millisekunden zu reagieren. Es ist entscheidend, dass unsere Lösung das Rendering der Seite nicht blockiert, so dass unsere SLAs sehr niedrig sind. Wir haben einen Proof of Concept mit ScyllaDB ausgeführt und fanden heraus, dass der Durchsatz viel besser war als Cassandra und die Betriebsbelastung wurde beseitigt. Wir wollten eine vollständig verwaltete Option, also wechselten wir von Cassandra zu ScyllaDB Cloud und folgten einer doppelten Schreibstrategie. Das ermöglichte es uns, mit null Ausfallzeiten zu migrieren, während wir 40.000 Operationen oder Anfragen pro Sekunde bearbeiten. Dieses Diagramm zeigt, wie die BYOA-Implementierung von ScyllaDB aussieht. Im Zentrum des Diagramms sehen Sie einen 6-Node-ScyllaDB-Cluster, der auf EC2 ausgeführt wird. ScyllaDB Monitor gibt uns Grafana-Dashboards sowie Prometheus-Metriken. ScyllaDB Manager kümmert sich um Infrastrukturautomatisierung wie das Auslösen von Backups und Reparaturen. Mit dieser Implementierung könnte ScyllaDB sehr nahe an unseren Microservices platziert werden, um uns noch geringere Latenzzeiten sowie eine viel höhere Durchsatzleistung und Leistung zu geben. Zusammenfassend hoffe ich, dass Sie jetzt ein besseres Verständnis für unsere Architektur haben, die Technologien, die die Plattform leiten, und wie ScyllaDB eine entscheidende Rolle spielt, damit wir mit der extrem hohen Skala von Tripadvisor umgehen können. Über Cynthia Dunlop Cynthia ist Senior Director of Content Strategy bei ScyllaDB und schreibt seit über 20 Jahren über Softwareentwicklung und Qualitätstechnik.