See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale Vilken typ av resenär är du? Tripadvisor försöker utvärdera detta så snart du engagerar dig med webbplatsen, och sedan erbjuda dig mer och mer relevant information vid varje klick – inom millisekunder. I den här artikeln ger Dean Poulin (Tripadvisor Data Engineering Lead på AI Service and Products-teamet) en titt på hur de driver denna personalisering. Det är baserat på följande AWS re:Invent tal: Pre-Trip orientering I Deans ord... Tripadvisor grundades år 2000 och har blivit en global ledare inom resor och gästfrihet, vilket hjälper hundratals miljoner resenärer att planera sina perfekta resor. Tripadvisor genererar över 1,8 miljarder dollar i intäkter och är ett offentligt börsnoterat företag på NASDAQ-börsen. Idag har vi ett begåvat team på över 2 800 anställda som driver innovation, och vår plattform betjänar en fantastisk 400 miljoner unika besökare per månad – ett antal som ständigt växer. På en viss dag hanterar vårt system mer än 2 miljarder förfrågningar från 25 till 50 miljoner användare. Varje klick du gör på Tripadvisor behandlas i realtid. Bakom det utnyttjar vi maskininlärningsmodeller för att leverera personliga rekommendationer – vilket ger dig närmare den perfekta resan. I hjärtat av denna anpassningsmotor är ScyllaDB som körs på AWS. Detta gör att vi kan leverera millisekundlatens i en skala som få organisationer når. . 425K operations per second on ScyllaDB with P99 latencies for reads and writes around 1-3 milliseconds Jag kommer att dela med mig av hur TripAdvisor utnyttjar kraften i ScyllaDB, AWS och maskininlärning i realtid för att leverera personliga rekommendationer för varje användare. Vi kommer att undersöka hur vi hjälper resenärer att upptäcka allt de behöver för att planera sin perfekta resa: oavsett om det är att upptäcka dolda pärlor, måste-se attraktioner, oförglömliga upplevelser eller de bästa ställena att bo och äta. Personlig Trip Planering Så snart du landar på Tripadvisor hemsida vet Tripadvisor redan om du är en foodie, en äventyrare eller en strandälskare – och du ser spot-on-rekommendationer som verkar personliga för dina egna intressen. När du surfar på TripAdvisor börjar vi personifiera vad du ser med hjälp av maskininlärningsmodeller som beräknar poäng baserat på din nuvarande och tidigare surfningsaktivitet. Vi rekommenderar hotell och upplevelser som vi tror att du skulle vara intresserad av. Vi sorterar hotell baserat på dina personliga preferenser. Vi rekommenderar populära sevärdheter nära det hotell du tittar på. Dessa är alla anpassade efter dina personliga preferenser och tidigare surfningsaktiviteter. Tripadvisors modell som tjänar arkitektur Tripadvisor körs på hundratals självständigt skalbara microservices i Kubernetes on-prem och i Amazon EKS. Vår ML Model Serving Platform exponeras genom en av dessa microservices. Denna gateway-tjänst extraherar över 100 ML-modeller från kundtjänsten – vilket gör att vi kan köra A/B-tester för att hitta de bästa modellerna med hjälp av vår experimentplattform. ML-modellerna är främst utvecklade av våra datavetenskapare och maskininlärningsingenjörer med Jupyter Notebooks på Kubeflow. De hanteras och utbildas med ML Flow, och vi distribuerar dem på Seldon Core i Kubernetes. Custom Feature Butik Funktionsbutiken tjänar främst användarfunktioner och statiska funktioner. Statiska funktioner lagras i Redis eftersom de inte ändras mycket ofta. Vi kör data pipelines dagligen för att ladda data från vårt offline datalager till vår funktionsbutik som statiska funktioner. Användarfunktioner levereras i realtid via en plattform som heter Visitor Platform. Vi utför dynamiska CQL-frågor mot ScyllaDB, och . we do not need a caching layer because ScyllaDB is so fast Vår funktionsbutik serverar upp till 5 miljoner statiska funktioner per sekund och en halv miljon användarfunktioner per sekund. Vad är en ML Feature? Funktioner är ingångsvariabler till ML-modellerna som används för att göra en förutsägelse. Några exempel på statiska funktioner är priser som en restaurang har vunnit eller bekvämligheter som erbjuds av ett hotell (som gratis Wi-Fi, husdjurvänligt eller fitnesscenter). Användarfunktioner samlas in i realtid när användare surfar på webbplatsen. Vi lagrar dem i ScyllaDB så att vi kan få blixtsnabba frågor. Några exempel på användarfunktioner är de hotell som har visats under de senaste 30 minuterna, restauranger som har visats under de senaste 24 timmarna eller recensioner som har lämnats in under de senaste 30 dagarna. The Technologies Powering Besökare Plattform ScyllaDB är kärnan i Visitor Platform. Vi använder Java-baserade Spring Boot microservices för att exponera plattformen för våra kunder. Detta distribueras på AWS ECS Fargate. Vi kör Apache Spark på Kubernetes för våra dagliga datalagringsarbeten, våra offline till onlinearbeten. Sedan använder vi dessa jobb för att ladda data från vårt offline datalager till ScyllaDB så att de är tillgängliga på den levande platsen. Vi använder också Amazon Kinesis för att bearbeta strömmande användarspårningshändelser. Besökare Plattform Data Flow Följande diagram visar hur data flödar genom vår plattform i fyra steg: producera, ta in, organisera och aktivera. Data produceras av vår webbplats och våra mobila appar. Några av dessa data inkluderar vår Cross-Device User Identity Graph, Behavior Tracking händelser (som sidvisningar och klick) och streaming händelser som går igenom Kinesis. Visitor Platforms microservices används för att ta in och organisera dessa data. Data i ScyllaDB lagras i två nyckelrum: Visitor Core-nyckelutrymmet, som innehåller Visitor Identity Graph Visitor Metric keyspace, som innehåller fakta och mätvärden (det som användarna gjorde när de surfar på webbplatsen) Vi använder dagliga ETL-processer för att underhålla och rensa upp data i plattformen.Vi producerar dataprodukter, stämplade dagligen, i vårt offline-datalager – där de är tillgängliga för andra integrationer och andra data pipelines att använda i sin behandling. Här är en titt på Visitor Platform efter siffror: Varför två databaser? ScyllaDB fyller denna roll genom att tillhandahålla mycket låga latenstider och hög genomströmning.Vi använder kortsiktiga TTLs för att förhindra att data i online-databasen växer på obestämd tid, och våra datalagringsjobb säkerställer att vi bara behåller användaraktivitetsdata för riktiga besökare. Tripadvisor.com får mycket bot-trafik, och vi vill inte lagra deras data och försöka personifiera bots - så vi tar bort och rensa bort alla dessa data. Vårt offline-datalager behåller historiska data som används för rapportering, skapande av andra dataprodukter och utbildning av våra ML-modeller.Vi vill inte ha stora offline-dataprocesser som påverkar prestandan på vår levande webbplats, så vi har två separata databaser som används för två olika ändamål. Besökare Plattform Microservices Vi använder 5 microservices för Visitor Platform: Visitor Core hanterar diagrammet för användaridentitet mellan enheter baserat på cookies och enhets-ID:n. Visitor Metric är vår sökmotor, och det ger oss möjligheten att exponera fakta och mätvärden för specifika besökare.Vi använder ett domänspecifikt språk som kallas visitor query language, eller VQL. Detta exempel VQL låter dig se de senaste kommersiella klickfakturorna under de senaste tre timmarna. Visitor Publisher och Visitor Saver hanterar skrivvägen och skriver data till plattformen. Förutom att spara data i ScyllaDB strömmar vi också data till datalagret offline. Visitor Composite förenklar publiceringen av data i batchbearbetningsjobb. Det abstrakt Visitor Saver och Visitor Core för att identifiera besökare och publicera fakta och mätvärden i ett enda API-samtal. Om Roundtrip Microservice Latency Detta diagram illustrerar hur våra mikrotjänstlatenser förblir stabila över tiden. Den genomsnittliga latensen är bara 2,5 millisekunder, och vår P999 är under 12,5 millisekunder. Våra mikrotjänstkunder har strikta latenskraven. 95% av samtal måste slutföras på 12 millisekunder eller mindre. ScyllaDB latens Här är en ögonblicksbild av ScyllaDB: s prestanda över tre dagar. Vid sin topp hanterar ScyllaDB 340 000 operationer per sekund (inklusive skriver och läser och raderar) och processorn svänger på bara 21%. ScyllaDB levererar mikrosekunder skrivs och millisekunder läses för oss. Partitionera data till ScyllaDB Den här bilden visar hur vi partitionerar data till ScyllaDB. Visitor Metric Keyspace har två tabeller: Fact och Raw Metrics. Den primära nyckeln på Fact-tabellen är Visitor GUID, Fact Type och Created At Date. Den sammansatta partitionsnyckeln är Visitor GUID och Fact Type. Klusternyckeln är Created At Date, vilket gör att vi kan sortera data i partitioner efter datum. Attributkolumnen innehåller ett JSON-objekt som representerar händelsen som inträffade där. Vi använder ScyllaDB: s nivellerade komprimeringsstrategi eftersom: Det är optimerat för intervallfrågor Hanterar hög kardinalitet mycket bra Det är bättre för läs-tunga arbetsbelastningar, och vi har ungefär 2-3X fler läser än skriver Varför ScyllaDB? Vår lösning byggdes ursprungligen med hjälp av Cassandra on-prem. Men när storleken ökade, ökade också den operativa bördan. Det krävde dedikerad driftstöd för att vi skulle kunna hantera databasuppgraderingar, säkerhetskopior etc. Dessutom kräver vår lösning mycket låga latenstider för kärnkomponenter. Vårt användaridentitetshanteringssystem måste identifiera användaren inom 30 millisekunder – och för bästa personalisering kräver vi att vår Event Tracking-plattform svarar inom 40 millisekunder. Det är viktigt att vår lösning inte blockerar renderingen av sidan så våra SLA:er är mycket låga. Vi körde en Proof of Concept med ScyllaDB och fann att genomströmningen var mycket bättre än Cassandra och den operativa bördan eliminerades. Vi ville ha ett helt hanterat alternativ, så vi migrerade från Cassandra till ScyllaDB Cloud, efter en dubbelskrivningsstrategi. Det gjorde att vi kunde migrera med noll driftstopp samtidigt som vi hanterade 40 000 operationer eller förfrågningar per sekund. Senare migrerade vi från ScyllaDB Cloud till ScyllaDB:s "Bring Your Own Account" -modell, där du kan få ScyllaDB-teamet att distribuera ScyllaDB-databasen till ditt eget AWS-konto. Det här diagrammet visar hur ScyllaDB:s BYOA-distribution ser ut. I mitten av diagrammet kan du se en 6-nodig ScyllaDB-kluster som körs på EC2. ScyllaDB Monitor ger oss Grafana-dashboards samt Prometheus-mätningar. ScyllaDB Manager tar hand om infrastrukturautomation som utlösning av säkerhetskopior och reparationer. Med denna utbyggnad skulle ScyllaDB kunna placeras mycket nära våra microservices för att ge oss ännu lägre latenstider samt mycket högre genomströmning och prestanda. Sammanfattningsvis hoppas jag att du nu har en bättre förståelse för vår arkitektur, de teknologier som driver plattformen och hur ScyllaDB spelar en viktig roll för att vi ska kunna hantera Tripadvisors extremt höga skala. Om Cynthia Dunlop Cynthia är Senior Director of Content Strategy på ScyllaDB. Hon har skrivit om mjukvaruutveckling och kvalitetsteknik i över 20 år.

This story contains new, firsthand information uncovered by the writer.

Visit Website

ScyllaDB Vs. Apache Cassandra

ScyllaDB Vs. DynamoDB

Download ScyllaDB

Community Events

Work At ScyllaDB

Det här ljudet är producerat på berättelsens originalspråk!

För länge; Att läsa

Make resilience your competitive advantage

Hur TripAdvisor levererar realtidspersonalisering i skala med ML

About Author

KOMMENTARER

HÄNG TAGGAR

DENNA ARTIKEL PRESENTERAS I

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps