See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale Tripadvisor yrittää arvioida tätä heti, kun olet yhteydessä sivustoon, ja sitten tarjoaa sinulle yhä tärkeämpiä tietoja jokaisella napsautuksella – millisekuntien kuluessa. Tässä artikkelissa Dean Poulin (Tripadvisor Data Engineering Lead, AI Service and Products -tiimi) antaa katsauksen siihen, miten he tukevat tätä personointia. Se perustuu seuraavaan AWS re:Invent -keskusteluun: Pre-Trip suuntautuminen Deanin sanoin... Tripadvisor on vuonna 2000 perustettu matkailu- ja vieraanvaraisuusalan maailmanlaajuinen johtaja, joka auttaa satoja miljoonia matkailijoita suunnittelemaan täydellisiä matkoja. Tripadvisor tuottaa yli 1,8 miljardia dollaria tuloja ja on julkisesti noteerattu yritys NASDAQ-pörssissä. Nykyään meillä on yli 2 800 lahjakasta työntekijää, jotka edistävät innovaatioita, ja alustamme palvelee hämmästyttävää 400 miljoonaa ainutlaatuista kävijää kuukaudessa – määrä kasvaa jatkuvasti. Joka päivä järjestelmämme käsittelee yli 2 miljardia pyyntöä 25–50 miljoonalta käyttäjältä. Jokainen Tripadvisorissa tekemäsi napsautus käsitellään reaaliajassa. Tämän jälkeen hyödynnämme koneoppimismalleja henkilökohtaisten suositusten toimittamiseksi – saamme sinut lähemmäksi täydellistä matkaa. Tämän yksilöintimoottorin ytimessä on ScyllaDB, joka toimii AWS:llä. . 425K operations per second on ScyllaDB with P99 latencies for reads and writes around 1-3 milliseconds Kerron, miten TripAdvisor hyödyntää ScyllaDB:n, AWS:n ja reaaliaikaisen koneoppimisen voimavaroja tarjotakseen yksilöllisiä suosituksia jokaiselle käyttäjälle.Tutkimme, miten autamme matkustajia löytämään kaiken, mitä he tarvitsevat täydellisen matkansa suunnittelussa: onko kyseessä piilotettujen jalokivien löytäminen, nähtävyyksien näkeminen, unohtumattomat kokemukset tai parhaat paikat yöpyä ja syödä. Henkilökohtainen matkasuunnittelu Kun saavut TripAdvisorin kotisivulle, TripAdvisor tietää jo, oletko ravintolailija, seikkailija tai rantaviihtäjä – ja näet spot-on-suosituksia, jotka näyttävät yksilöllisiltä omille kiinnostuksillesi. Kun selaat TripAdvisoria, alamme räätälöidä, mitä näet, käyttämällä koneoppimismalleja, jotka laskevat pisteet nykyisen ja aiemman selaustoimintasi perusteella. Suosittelemme hotelleja ja kokemuksia, joista uskomme, että olet kiinnostunut. lajittelemme hotellit henkilökohtaisten mieltymystesi perusteella. Suosittelemme suosittuja kiinnostavia kohteita lähellä katsomasi hotellia. Kaikki nämä ovat räätälöityjä omien henkilökohtaisten mieltymystesi ja aiemman selaustoimintasi perusteella. TripAdvisorin malli, joka palvelee arkkitehtuuria Tripadvisor käyttää satoja itsenäisesti skaalautuvia mikrosivustoja Kubernetes on-prem -palvelussa ja Amazon EKS:ssä. Tämä porttipalvelu poimii yli 100 ML-mallia asiakaspalvelusta – jonka avulla voimme suorittaa A/B-testejä löytääksemme parhaat mallit kokeilualustallamme. ML-mallit kehittävät ensisijaisesti tietojenkäsittelytieteilijämme ja koneen oppimisen insinöörit käyttämällä Jupyter-muistikirjoja Kubeflow: ssä. Ne hallitaan ja koulutetaan käyttämällä ML Flow -palvelua, ja siirrämme ne Seldon Core -palveluun Kubernetesissa. Custom Feature Store tarjoaa ominaisuuksia ML-malleillemme, joiden avulla ne voivat tehdä tarkkoja ennusteita. Custom Feature -myymälä Ominaisuuskauppa palvelee ensisijaisesti käyttäjäominaisuuksia ja staattisia ominaisuuksia. Staattiset ominaisuudet tallennetaan Redisiin, koska ne eivät muutu kovin usein. Käytämme päivittäin dataputkia lataamaan tietoja offline-tietovarastostamme ominaisuuskauppaan staattisina ominaisuuksina. Käyttäjäominaisuudet toimitetaan reaaliajassa Visitor Platform -alustan kautta. Teemme dynaamisia CQL-kyselyitä ScyllaDB:tä vastaan ja . we do not need a caching layer because ScyllaDB is so fast Meidän Feature Store tarjoaa jopa 5 miljoonaa staattista ominaisuutta sekunnissa ja puoli miljoonaa käyttäjäominaisuutta sekunnissa. Mikä on ML Feature? Ominaisuudet ovat ML-malleihin sisältyviä muuttujia, joita käytetään ennustamiseen. Joitakin esimerkkejä staattisista ominaisuuksista ovat ravintolan voittamat palkinnot tai hotellin tarjoamat mukavuudet (kuten ilmainen Wi-Fi, lemmikkiystävällinen tai kuntosali). Käyttäjäominaisuudet kerätään reaaliajassa, kun käyttäjät selaavat sivustoa. Tallennamme ne ScyllaDB:ään, jotta voimme saada salamanopeita kyselyitä.Jotkut esimerkit käyttäjäominaisuuksista ovat viimeisten 30 minuutin aikana katsotut hotellit, viimeisten 24 tunnin aikana katsotut ravintolat tai viimeisten 30 päivän aikana lähetetyt arviot. Teknologia, joka antaa vierailijoille voimaa ScyllaDB on Visitor Platformin ytimessä. Käytämme Java-pohjaisia Spring Boot -mikropalveluita paljastaaksemme alustan asiakkaillemme. Tätä käytetään AWS ECS Fargate -sovelluksessa. Käytämme Apache Sparkia Kubernetesissa päivittäisiin tietojen säilyttämistyöhön, offline-työhön ja online-työhön. Sitten käytämme näitä työpaikkoja lataamaan tietoja offline-tietovarastostamme ScyllaDB:hen, jotta ne ovat käytettävissä live-sivustossa. Käytämme myös Amazon Kinesia suoratoistopalvelujen tapahtumien käsittelyyn. Vierailijapalveluiden tiedonkulku Seuraavassa grafiikassa näytetään, miten tiedot kulkevat alustamme läpi neljässä vaiheessa: tuottaa, imeä, järjestää ja aktivoida. Tietoja tuottavat verkkosivustomme ja mobiilisovelluksemme. Osa näistä tiedoista sisältää laitteiden välisen käyttäjän tunnistusgraafimme, käyttäytymisen seurantatapahtumat (kuten sivunäkymät ja napsautukset) ja suoratoistotapahtumat, jotka kulkevat Kinesisin kautta. Visitor Platformin mikrosivustoja käytetään näiden tietojen syöttämiseen ja järjestämiseen.ScyllaDB:ssä olevat tiedot tallennetaan kahteen avainsivustoon: Visitor Core -näppäimistö, joka sisältää Visitor Identity Graphin Visitor Metric -näppäimistö, joka sisältää faktoja ja mittareita (asiat, joita ihmiset tekivät selaamalla sivustoa) Käytämme päivittäisiä ETL-prosesseja tietojen ylläpitämiseen ja puhdistamiseen alustassa. Tuotamme päivittäin leimattuja tietotuotteita offline-tietovarastossamme – missä ne ovat käytettävissä muille integraatioille ja muille tietoputkille niiden käsittelyssä. Tässä on katso Visitor Platform numeroiden mukaan: Miksi kaksi tietokantaa? Online-tietokannassamme keskitytään reaaliaikaiseen, reaaliaikaiseen verkkosivustojen liikenteeseen. ScyllaDB täyttää tämän tehtävän tarjoamalla erittäin alhaiset viiveet ja suuren läpiviennin. Käytämme lyhyen aikavälin TTL:itä estämään online-tietokannassa olevien tietojen kasvua loputtomiin, ja tietojen säilyttämisen tehtävät varmistavat, että säilytämme vain käyttäjätoimintatietoja todellisista kävijöistä. Tripadvisor.com saa paljon bot-liikennettä, emmekä halua tallentaa niiden tietoja ja yrittää personoida robotteja - joten poistamme ja puhdistamme kaikki nämä tiedot. Offline-tietovarastossamme säilytetään historiallisia tietoja, joita käytetään raportointiin, muiden tietotuotteiden luomiseen ja ML-malliemme kouluttamiseen.Emme halua laajamittaisia offline-tietoprosesseja, jotka vaikuttavat live-sivustomme suorituskykyyn, joten meillä on kaksi erillistä tietokantaa, joita käytetään kahteen eri tarkoitukseen. Visitor Platform Microservices -palvelut Käytämme 5 mikropalvelua Visitor Platformille: Visitor Core hallinnoi laitteiden välistä käyttäjän henkilöllisyyden kaaviota evästeiden ja laitteen tunnisteiden perusteella. Visitor Metric on kyselymoottori, joka antaa meille mahdollisuuden paljastaa tosiasioita ja mittareita tietyille kävijöille. Käytämme verkkotunnuskohtaista kieltä, jota kutsutaan vierailijakyselykieleksi tai VQL:ksi. Visitor Publisher ja Visitor Saver käsittelevät kirjoituspolkua ja kirjoittavat tietoja alustalle. ScyllaDB:ssä tallennettujen tietojen lisäksi lähetämme tietoja myös offline-tietovarastoon. Visitor Composite yksinkertaistaa tietojen julkaisemista eräprosessointitehtävissä. Se abstraktio Visitor Saver ja Visitor Core tunnistaa kävijät ja julkaisee tosiasioita ja mittareita yhdellä API-puhelulla. Roundtrip Microservice latenssi Tämä kaavio kuvaa, miten mikrosivustojen viive pysyy vakaana ajan myötä. Keskimääräinen viive on vain 2,5 millisekuntia, ja P999 on alle 12,5 millisekuntia.Tämä on vaikuttava suorituskyky, varsinkin kun otetaan huomioon, että käsittelemme yli 1 miljardia pyyntöä päivässä. Microservice-asiakkaillamme on tiukat viivevaatimukset. 95% puheluista on suoritettava 12 millisekunnissa tai vähemmän. ScyllaDB latenssi Tässä on lyhyt kuva ScyllaDB: n suorituskyvystä kolmen päivän aikana. Huipulla ScyllaDB käsittelee 340 000 toimintoa sekunnissa (mukaan lukien kirjoittaminen ja lukeminen ja poistaminen) ja prosessori vaihtelee vain 21 prosentilla. ScyllaDB toimittaa meille mikrosekunnin kirjoituksia ja millisekunnin lukemisia.Tämä nopean suorituskyvyn taso on juuri se, miksi valitsimme ScyllaDB: n. Tietojen jakaminen ScyllaDB:ään Tässä kuvassa näytetään, miten jaamme tiedot ScyllaDB:ään. Visitor Metric Keyspace sisältää kaksi taulukkoa: Fact ja Raw Metrics. Fact-taulukon ensisijainen avain on Visitor GUID, Fact Type ja Created At Date. Yhdistelmäositusavain on Visitor GUID ja Fact Type. Ryhmittymän avain on Created At Date, jonka avulla voimme lajitella tietoja osioissa päivämäärän mukaan. Attribuuttikerroksessa on JSON-objekti, joka edustaa tapahtumaa, joka tapahtui siellä. Käytämme ScyllaDB: n tasoitettua pakkausstrategiaa, koska: Se on optimoitu range-kyselyihin Se käsittelee korkeaa kardinaalisuutta hyvin Se on parempi lukemisen raskaille työmäärille, ja meillä on noin 2-3X enemmän lukemia kuin kirjoittamia Miksi ScyllaDB? Ratkaisumme on alun perin rakennettu käyttämällä Cassandra on-prem -ratkaisua. Mutta kun mittakaava kasvoi, niin myös operatiivinen taakka. Se vaati omistautunutta toiminnan tukea, jotta voimme hallita tietokannan päivityksiä, varmuuskopioita jne. Myös ratkaisumme vaatii hyvin alhaisia viiveitä ydinkomponenteille. Käyttäjätunnistushallintajärjestelmämme on tunnistettava käyttäjä 30 millisekunnin kuluessa – ja parhaan personoinnin saavuttamiseksi vaadimme Tapahtumien seuranta-alustamme vastaamaan 40 millisekunnissa. On tärkeää, että ratkaisumme ei estä sivun näyttämistä, joten SLA-sopimuksemme ovat hyvin alhaiset. Teimme ScyllaDB:n kanssa Proof of Conceptin ja havaitsimme läpäisyn olevan paljon parempi kuin Cassandra ja operatiivinen taakka poistettiin. Halusimme täysin hallitun vaihtoehdon, joten siirrymme Cassandrasta ScyllaDB-pilveen kaksinkertaisen kirjoitusstrategian mukaisesti. Tämä antoi meille mahdollisuuden siirtyä nollalla pysähtymisajalla käsittelemällä 40 000 toimintoa tai pyyntöä sekunnissa. Myöhemmin siirrymme ScyllaDB-pilvestä ScyllaDB:n "Tuokaa oma tilisi" -malliin, jossa voit saada ScyllaDB-tiimin käyttöön ScyllaDB-tietokannan omalle AWS-tilillesi. Tässä kaaviossa näkyy, miltä ScyllaDB:n BYOA-asennus näyttää. Kaavion keskellä näet kuuden solmun ScyllaDB-klusterin, joka toimii EC2:lla. ScyllaDB Monitor antaa meille Grafana-ohjauspaneeleja sekä Prometheus-metriikoita. ScyllaDB Manager huolehtii infrastruktuurin automaatiosta, kuten varmuuskopioiden ja korjausten käynnistämisestä. Tämän käyttöönoton myötä ScyllaDB voidaan sijoittaa hyvin lähelle mikropalvelujamme, mikä antaa meille vielä pienemmät viiveet sekä paljon suuremman läpäisyn ja suorituskyvyn. Kaiken kaikkiaan toivon, että sinulla on nyt parempi käsitys arkkitehtuuristamme, alustan käyttämistä tekniikoista ja siitä, miten ScyllaDB:llä on kriittinen rooli, jotta voimme käsitellä TripAdvisorin erittäin suurta mittakaavaa. Pääosat Cynthia Dunlop Cynthia on ScyllaDB:n sisältöstrategian johtaja, joka on kirjoittanut ohjelmistokehityksestä ja laatutekniikasta yli 20 vuoden ajan.