See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale Tripadvisor forsøger at vurdere dette, så snart du interagerer med webstedet, og giver dig derefter mere og mere relevante oplysninger på hvert klik – inden for et spørgsmål om millisekunder. I denne artikel giver Dean Poulin (Tripadvisor Data Engineering Lead på teamet AI Service and Products) et kig på, hvordan de styrer denne personalisering. Det er baseret på følgende AWS re:Invent tal: Pre-Trip orientering I Dean’s ord... Tripadvisor blev grundlagt i 2000 og er blevet en global leder inden for rejser og gæstfrihed, der hjælper hundredvis af millioner af rejsende med at planlægge deres perfekte rejser. Tripadvisor genererer over 1,8 milliarder dollars i indtægter og er et offentligt børsnoteret selskab på NASDAQ. I dag har vi et talentfuldt team på over 2.800 medarbejdere, der driver innovation, og vores platform betjener en betagende 400 millioner unikke besøgende om måneden – et tal, der fortsat vokser. På en given dag håndterer vores system mere end 2 milliarder forespørgsler fra 25 til 50 millioner brugere. Hvert klik, du foretager på TripAdvisor, behandles i realtid. Bag det, udnytter vi maskinlæringsmodeller til at levere personlige anbefalinger – hvilket bringer dig tættere på den perfekte rejse. I hjertet af denne personaliseringsmotor er ScyllaDB kørende på AWS. Dette giver os mulighed for at levere millisekunders latency på en skala, som få organisationer når. . 425K operations per second on ScyllaDB with P99 latencies for reads and writes around 1-3 milliseconds Vi vil udforske, hvordan vi hjælper rejsende med at opdage alt, hvad de behøver for at planlægge deres perfekte rejse: hvad enten det er at opdage skjulte perler, must-see attraktioner, uforglemmelige oplevelser eller de bedste steder at bo og spise. Personlig rejseplanlægning Så snart du lander på TripAdvisor-hjemmesiden, ved TripAdvisor allerede, om du er en foodie, en eventyrer eller en strandelsker – og du ser spot-on-anbefalinger, der ser ud til at være personligt tilpasset dine egne interesser. Når du surfer rundt på TripAdvisor, begynder vi at personliggøre, hvad du ser ved hjælp af Machine Learning-modeller, der beregner score baseret på din nuværende og tidligere browsingaktivitet. Vi anbefaler hoteller og oplevelser, som vi tror, du vil være interesseret i. Vi sorterer hoteller baseret på dine personlige præferencer. Vi anbefaler populære seværdigheder i nærheden af det hotel, du ser. Disse er alle tilpasset baseret på dine egne personlige præferencer og tidligere browsingaktiviteter. Tripadvisor’s model, der tjener arkitektur Tripadvisor kører på hundredvis af uafhængigt skalerbare mikroservices i Kubernetes on-prem og i Amazon EKS. Vores ML Model Serving Platform er eksponeret gennem en af disse mikroservices. Denne gateway-tjeneste udtrækker over 100 ML-modeller fra kundeservicen – hvilket giver os mulighed for at køre A/B-tests for at finde de bedste modeller ved hjælp af vores eksperimenteringsplatform. ML-modellerne er primært udviklet af vores dataforskere og maskinlæringsingeniører ved hjælp af Jupyter Notebooks på Kubeflow. De administreres og trænes ved hjælp af ML Flow, og vi implementerer dem på Seldon Core i Kubernetes. Den Custom Feature butik Funktionsbutikken serverer primært brugerfunktioner og statiske funktioner. Statiske funktioner gemmes i Redis, fordi de ikke ændrer sig meget ofte. Vi kører data pipelines dagligt for at indlæse data fra vores offline data lager i vores funktionsbutik som statiske funktioner. Brugerfunktioner leveres i realtid via en platform kaldet Visitor Platform. Vi udfører dynamiske CQL-forespørgsler mod ScyllaDB, og . we do not need a caching layer because ScyllaDB is so fast Vores funktionsbutik leverer op til 5 millioner statiske funktioner pr. sekund og en halv million brugerfunktioner pr. sekund. Hvad er en ML Feature? Funktioner er indgangsvariabler til ML-modellerne, der bruges til at foretage en forudsigelse. Nogle eksempler på statiske funktioner er priser, som en restaurant har vundet, eller faciliteter, der tilbydes af et hotel (såsom gratis Wi-Fi, kæledyrsvenligt eller fitnesscenter). Vi gemmer dem i ScyllaDB, så vi kan få lynhurtige forespørgsler. Nogle eksempler på brugerfunktioner er de hoteller, der er set i løbet af de sidste 30 minutter, restauranter, der er set i løbet af de sidste 24 timer, eller anmeldelser, der er indsendt i løbet af de sidste 30 dage. De teknologier, der styrker besøgende platform ScyllaDB er kernen i Visitor Platform. Vi bruger Java-baserede Spring Boot-mikroservices til at eksponere platformen for vores kunder. Dette er implementeret på AWS ECS Fargate. Vi kører Apache Spark på Kubernetes til vores daglige datalagringsopgaver, vores offline til onlineopgaver. Så bruger vi disse job til at indlæse data fra vores offline data warehouse til ScyllaDB, så de er tilgængelige på live-stedet. Besøgende platforms datastrøm Følgende graf viser, hvordan data strømmer gennem vores platform i fire faser: producere, indtage, organisere og aktivere. Nogle af disse data omfatter vores Cross-Device User Identity Graph, Behavior Tracking events (såsom sidevisninger og klik) og streaming events, der går gennem Kinesis. Visitor Platforms microservices bruges til at indtaste og organisere disse data. Dataene i ScyllaDB gemmes i to nøgleområder: Visitor Core-tastaturet, der indeholder Visitor Identity Graph Visitor Metric keyspace, som indeholder fakta og målinger (de ting, folk gjorde, mens de browsede på webstedet) Vi producerer Data Products, stemplet dagligt, i vores offline data warehouse – hvor de er tilgængelige for andre integrationer og andre data pipelines til brug i deres behandling. Her er et kig på Visitor Platform efter tallene: Hvorfor to databaser? Vores online database er fokuseret på real-time, live websteds trafik. ScyllaDB opfylder denne rolle ved at give meget lave forsinkelser og højt gennemsnit. Vi bruger kortsigtede TTL'er til at forhindre, at dataene i online-databasen vokser på ubestemt tid, og vores datalagringsopgaver sikrer, at vi kun opbevarer brugeraktivitetsdata for rigtige besøgende. Tripadvisor.com får en masse bot-trafik, og vi ønsker ikke at gemme deres data og forsøge at personliggøre bots - så vi sletter og rydder alle disse data op. Vores offline data warehouse gemmer historiske data, der bruges til rapportering, oprettelse af andre dataprodukter og træning af vores ML-modeller. Vi ønsker ikke, at store offline dataprocesser påvirker vores live-sites ydeevne, så vi har to separate databaser, der bruges til to forskellige formål. Besøgende platform Microservices Vi bruger 5 mikroservices til besøgende platform: Visitor Core administrerer brugeridentitetsdiagrammet på tværs af enheder baseret på cookies og enheds-id'er. Visitor Metric er vores forespørgselsmotor, og det giver os mulighed for at udsætte fakta og målinger for specifikke besøgende. Vi bruger et domænespecifikt sprog kaldet besøgende forespørgselssprog, eller VQL. Dette eksempel VQL giver dig mulighed for at se de seneste handels klik fakta i løbet af de sidste tre timer. Visitor Publisher og Visitor Saver håndterer skrivevejen og skriver data til platformen. Udover at gemme data i ScyllaDB, streamer vi også data til offline-datalageret. Visitor Composite forenkler offentliggørelsen af data i batchbehandlingsopgaver. Det abstrakterer Visitor Saver og Visitor Core til at identificere besøgende og offentliggøre fakta og målinger i et enkelt API-opkald. Roundtrip Microservice Latency tilgængelig Dette diagram illustrerer, hvordan vores microservice latencies forbliver stabile over tid. Den gennemsnitlige latens er kun 2,5 millisekunder, og vores P999 er under 12,5 millisekunder. Vores mikroservice-kunder har strenge latenskrav. 95% af opkaldene skal afsluttes på 12 millisekunder eller mindre. ScyllaDB forsinkelse Her er et snapshot af ScyllaDB's ydeevne over tre dage. På sit højdepunkt håndterer ScyllaDB 340.000 operationer i sekundet (herunder skrives og læses og slettes), og CPU'en svinger på kun 21%. ScyllaDB leverer mikrosekunder skrives og millisekunder læses for os. Dette niveau af blæsende hurtig ydeevne er præcis, hvorfor vi valgte ScyllaDB. Partitionering af data i ScyllaDB Dette billede viser, hvordan vi partitioner data i ScyllaDB. Visitor Metric Keyspace har to tabeller: Fact og Raw Metrics. Den primære nøgle på Fact-tabellen er Visitor GUID, Fact Type og Created At Date. Den sammensatte partitionsnøgle er Visitor GUID og Fact Type. Klasteringsnøglen er Created At Date, som giver os mulighed for at sortere data i partitioner efter dato. Attributkolonnen indeholder et JSON-objekt, der repræsenterer den begivenhed, der fandt sted der. Vi bruger ScyllaDB’s Leveled Compaction Strategy, fordi: Det er optimeret til rækkeforespørgsler Det håndterer høj kardinalitet meget godt Det er bedre for læsning tunge arbejdsbyrder, og vi har omkring 2-3X flere læsninger end skriver Hvorfor ScyllaDB? Vores løsning blev oprindeligt bygget ved hjælp af Cassandra on-prem. Men da skalaen voksede, gjorde det også den operationelle byrde. Det krævede dedikeret operationel support for at vi kunne administrere databaseopgraderinger, backups osv. Også vores løsning kræver meget lave latenstider for kernekomponenter. Vores User Identity Management-system skal identificere brugeren inden for 30 millisekunder – og for den bedste personalisering kræver vi vores Event Tracking-platform til at reagere på 40 millisekunder. Det er afgørende, at vores løsning ikke blokerer rendering af siden, så vores SLA'er er meget lave. Med Cassandra havde vi indvirkninger på ydeevnen fra skraldespand. Vi kørte en Proof of Concept med ScyllaDB og fandt, at gennemstrømningen var meget bedre end Cassandra, og den operationelle byrde blev elimineret. Vi ønskede en fuldt administreret mulighed, så vi migrerede fra Cassandra til ScyllaDB Cloud efter en dobbeltskrivningsstrategi. Det gjorde det muligt for os at migrere med nul nedetid, mens vi håndterede 40.000 operationer eller anmodninger pr. sekund. Senere migrerede vi fra ScyllaDB Cloud til ScyllaDB's "Bring Your Own Account" -model, hvor du kan få ScyllaDB-teamet til at implementere ScyllaDB-databasen i din egen AWS-konto. Dette diagram viser, hvordan ScyllaDB's BYOA-implementering ser ud. I midten af diagrammet kan du se en 6-node ScyllaDB-kluster, der kører på EC2. ScyllaDB Monitor giver os Grafana dashboards samt Prometheus metrics. ScyllaDB Manager tager sig af infrastruktur automatisering som udløser backups og reparationer. Med denne implementering kunne ScyllaDB placeres meget tæt på vores microservices for at give os endnu lavere latencer samt meget højere gennemsnit og ydeevne. Sammenfattende håber jeg, at du nu har en bedre forståelse af vores arkitektur, de teknologier, der driver platformen, og hvordan ScyllaDB spiller en kritisk rolle i at give os mulighed for at håndtere Tripadvisors ekstremt høje skala. Anmeldelse af Cynthia Dunlop Cynthia er Senior Director of Content Strategy hos ScyllaDB. Hun har skrevet om softwareudvikling og kvalitetsteknik i over 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

Denne lyd er produceret på historiens originalsprog!

For langt; At læse

Make resilience your competitive advantage

Hvordan TripAdvisor leverer realtidspersonalisering på skala med ML

About Author

KOMMENTARER

HÆNG TAGS

DENNE ARTIKEL BLEV PRÆsenterET I

Related Stories

Meet Brave: HackerNoon Company of the Week

Meet inDrive: The HackerNoon Company of the Week

Meet Octopus Network: HackerNoon Company of the Week

Meet Bybit: HackerNoon Company of the Week

Meet Brave: HackerNoon Company of the Week

Meet inDrive: The HackerNoon Company of the Week

Meet Octopus Network: HackerNoon Company of the Week

Meet Bybit: HackerNoon Company of the Week

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps