See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale „TripAdvisor“ bando tai įvertinti, kai tik bendraujate su svetaine, o po to kiekvienu paspaudimu suteikia vis aktualesnę informaciją – per keletą milisekundžių. Šiame straipsnyje Deanas Poulinas (Tripadvisor duomenų inžinerijos lyderis, dirbantis AI paslaugų ir produktų komandoje) apžvelgia, kaip jie skatina šį personalizavimą. Jis grindžiamas šiuo AWS re:Invent pokalbiu: Išankstinė orientacija Dean žodžiais... Pradėkime nuo to, kas yra „TripAdvisor“ ir kokiu mastu mes veikiame. 2000 m. įkurta „TripAdvisor“ tapo pasauliniu lyderiu kelionių ir svetingumo srityje, padėdama šimtams milijonų keliautojų planuoti savo puikias keliones. „TripAdvisor“ generuoja daugiau nei 1,8 mlrd. JAV dolerių pajamų ir yra viešai biržinė bendrovė NASDAQ biržoje. Šiandien turime talentingą daugiau nei 2800 darbuotojų komandą, skatinančią inovacijas, o mūsų platforma aptarnauja 400 milijonų unikalių lankytojų per mėnesį – skaičius nuolat auga. Kiekvieną dieną mūsų sistema tvarko daugiau nei 2 milijardus užklausų nuo 25 iki 50 milijonų vartotojų. Kiekvienas paspaudimas „Tripadvisor“ yra tvarkomas realiu laiku. Po to mes naudojame mašininio mokymosi modelius, kad pateiktume personalizuotas rekomendacijas – priartintume jus prie tobulos kelionės. Šio personalizavimo variklio širdyje yra „ScyllaDB“, veikiantis AWS. Tai leidžia mums teikti milisekundės vėlavimą tokiu mastu, kurį pasiekia nedaugelis organizacijų. . 425K operations per second on ScyllaDB with P99 latencies for reads and writes around 1-3 milliseconds Mes išnagrinėsime, kaip mes padedame keliautojams atrasti viską, ko jiems reikia norint suplanuoti savo puikią kelionę: ar tai yra paslėptų brangakmenių atradimas, privalomų lankytinų vietų atradimas, nepamirštamos patirtys, ar geriausios vietos apsistoti ir pavalgyti. Asmeninis kelionės planavimas Įsivaizduokite, kad planuojate kelionę.Kai tik nusileidžiate „Tripadvisor“ pagrindiniame puslapyje, „Tripadvisor“ jau žino, ar esate maisto mėgėjas, nuotykių mėgėjas ar paplūdimio mylėtojas – ir matote rekomendacijas vietoje, kurios atrodo pritaikytos jūsų pačių interesams. Naršydami „Tripadvisor“, mes pradedame personalizuoti tai, ką matote, naudodamiesi „Machine Learning“ modeliais, kurie apskaičiuoja balus pagal jūsų dabartinę ir ankstesnę naršymo veiklą. Rekomenduojame viešbučius ir patirtį, kurios, mūsų manymu, jus domina. Rūšiuojame viešbučius pagal jūsų asmeninius pageidavimus. Rekomenduojame populiarius lankytinus objektus netoli viešbučio, kurį žiūrite. Tripadvisor modelis, kuris tarnauja architektūrai „Tripadvisor“ veikia su šimtais nepriklausomai skaluojamų mikropaslaugų „Kubernetes on-prem“ ir „Amazon EKS“. Mūsų ML modelio aptarnavimo platforma pateikiama per vieną iš šių mikropaslaugų. Ši vartų paslauga ištraukia daugiau nei 100 ML modelių iš klientų paslaugų – tai leidžia mums atlikti A/B testus, kad rastume geriausius modelius naudojant mūsų eksperimentinę platformą. ML modelius pirmiausia kuria mūsų duomenų mokslininkai ir mašinų mokymosi inžinieriai, naudodami Jupyter Notebooks „Kubeflow“. Jie yra valdomi ir apmokyti naudojant ML Flow, ir mes juos diegiame „Seldon Core“ „Kubernetes“. Custom Feature parduotuvė Funkcijų parduotuvė pirmiausia aptarnauja naudotojų funkcijas ir statines funkcijas. Statinės funkcijos saugomos „Redis“, nes jos dažnai nesikeičia.Mes kasdien vykdome duomenų vamzdynus, kad įkeltume duomenis iš mūsų neprisijungusių duomenų saugyklos į mūsų funkcijų parduotuvę kaip statines funkcijas. Naudotojo funkcijos teikiamos realiu laiku per platformą, vadinamą Lankytojų platforma. Mes vykdome dinamines CQL užklausas prieš ScyllaDB, ir . we do not need a caching layer because ScyllaDB is so fast Mūsų funkcijų parduotuvė aptarnauja iki 5 milijonų statinių funkcijų per sekundę ir pusę milijono naudotojų funkcijų per sekundę. Kas yra ML funkcija? Funkcijos yra ML modelių įvesties kintamieji, kurie naudojami prognozavimui. Kai kurie statinių funkcijų pavyzdžiai yra apdovanojimai, kuriuos laimėjo restoranas, arba patogumai, kuriuos siūlo viešbutis (pvz., Nemokamas belaidis internetas, gyvūnėliai ar fitneso centras). Naudotojo funkcijos renkamos realiu laiku, kai vartotojai naršo svetainėje. Mes jas saugome „ScyllaDB“, kad galėtume gauti greitų užklausų.Kai kurie naudotojo funkcijų pavyzdžiai yra per pastarąsias 30 minučių peržiūrėti viešbučiai, per pastarąsias 24 valandas peržiūrėti restoranai arba per pastarąsias 30 dienų pateikti atsiliepimai. Technologijos, leidžiančios lankytojų platformą ScyllaDB yra lankytojų platformos pagrindas. Mes naudojame Java pagrįstas „Spring Boot“ mikroservices, kad galėtume atskleisti platformą savo klientams. Tai įdiegiama „AWS ECS Fargate“. Mes paleidžiame „Apache Spark“ „Kubernetes“ mūsų kasdieniams duomenų saugojimo darbams, mūsų neprisijungus prie internetinių darbų. Tada mes naudojame tuos darbus, kad duomenis iš mūsų neprisijungusio duomenų saugyklos įkeltume į „ScyllaDB“, kad jie būtų prieinami tiesioginėje svetainėje. Mes taip pat naudojame „Amazon Kinesis“, kad apdorotume vartotojų srauto stebėjimo įvykius. Lankytojų platformos duomenų srautas Toliau pateiktoje diagramoje parodyta, kaip duomenys teka per mūsų platformą keturiais etapais: gaminti, įsisavinti, organizuoti ir aktyvuoti. Duomenis gamina mūsų svetainė ir mūsų mobiliosios programėlės. Kai kurie iš šių duomenų apima mūsų „Cross-Device User Identity Graph“, elgesio stebėjimo įvykius (pvz., puslapių peržiūras ir paspaudimus) ir transliavimo įvykius, kurie vyksta per „Kinesis“. „Visitor Platform“ mikroservisai naudojami šiems duomenims įsisavinti ir organizuoti. „ScyllaDB“ duomenys saugomi dviejose raktinėse erdvėse: Lankytojo pagrindinė raktažodžio erdvė, kurioje yra Lankytojo tapatybės grafikas Lankytojo metrinė raktažodžio erdvė, kurioje yra faktai ir rodikliai (daiktai, kuriuos žmonės padarė naršydami svetainėje) Mes naudojame kasdienius ETL procesus, kad išlaikytume ir išvalytume duomenis platformoje. „Data Products“ gaminame kasdien spausdintus duomenų produktus mūsų neprisijungus duomenų sandėlyje – kur jie yra prieinami kitoms integracijoms ir kitiems duomenų vamzdynams, kurie gali būti naudojami jų apdorojimui. Štai apžvalga lankytojų platforma pagal skaičius: Kodėl dvi duomenų bazės? Mūsų internetinė duomenų bazė yra orientuota į realaus laiko, tiesioginį svetainės srautą. „ScyllaDB“ užpildo šį vaidmenį, suteikdama labai mažą vėlavimą ir didelį pralaidumą. Mes naudojame trumpalaikius TTL, kad užkirstume kelią duomenų augimui internetinėje duomenų bazėje neribotą laiką, o mūsų duomenų saugojimo darbai užtikrina, kad mes saugome tik naudotojų aktyvumo duomenis tikriems lankytojams. „Tripadvisor.com“ gauna daug botų srauto, ir mes nenorime saugoti jų duomenų ir bandyti personalizuoti robotų – todėl mes ištriname ir išvalome visus tuos duomenis. Mūsų neprisijungę duomenų sandėlis saugo istorinius duomenis, naudojamus ataskaitoms, kitų duomenų produktų kūrimui ir mūsų ML modelių mokymui.Mes nenorime, kad didelio masto neprisijungę duomenų procesai paveiktų mūsų tiesioginės svetainės našumą, todėl turime dvi atskiras duomenų bazes, naudojamas dviem skirtingais tikslais. Mikropaslaugų lankytojų platforma Mes naudojame 5 mikroservices lankytojų platformai: „Visitor Core“ tvarko įvairių įrenginių naudotojo tapatybės grafiką, pagrįstą slapukais ir įrenginio ID. "Visitor Metric" yra mūsų užklausų variklis, kuris suteikia mums galimybę atskleisti faktus ir rodiklius konkretiems lankytojams.Naudojame domeno specifinę kalbą, vadinamą lankytojų užklausų kalba arba VQL. Šis pavyzdys "VQL" leidžia peržiūrėti naujausius prekybos spustelėjimų faktus per pastarąsias tris valandas. Visitor Publisher ir Visitor Saver tvarko rašymo kelią, įrašydami duomenis į platformą. Be duomenų išsaugojimo ScyllaDB, mes taip pat perduodame duomenis į neprisijungusį duomenų saugyklą. "Visitor Composite" supaprastina duomenų publikavimą partijų apdorojimo užduotims.Tai apima "Visitor Saver" ir "Visitor Core", kad būtų galima identifikuoti lankytojus ir skelbti faktus ir rodiklius viename API kvietime. „Roundtrip Microservice“ vėlavimas Ši diagrama parodo, kaip mūsų mikroservisų vėlavimas laikui bėgant išlieka stabilus. Vidutinis vėlavimas yra tik 2,5 milisekundės, o mūsų P999 yra mažesnis nei 12,5 milisekundės. Mūsų mikroservisų klientai turi griežtus vėlavimo reikalavimus. 95% skambučių turi būti užbaigtos per 12 milisekundžių ar mažiau. ScyllaDB vėlavimas Štai trumpas „ScyllaDB“ veiklos rezultatas per tris dienas. Piko metu "ScyllaDB" tvarko 340 000 operacijų per sekundę (įskaitant rašymą, skaitymą ir ištrynimą), o procesorius svyruoja tik 21%. ScyllaDB suteikia mums mikrosekundes rašyti ir milisekundes skaityti. Duomenų suskirstymas į ScyllaDB Šiame paveikslėlyje parodyta, kaip mes suskirstome duomenis į ScyllaDB. „Visitor Metric Keyspace“ turi dvi lenteles: „Faktas“ ir „Žaliavos metrikos“. Pagrindinis raktas „Faktų“ lentelėje yra „Visitor GUID“, „Faktų tipas“ ir „Created At Date“. Sudėtinis pertvarkymo raktas yra „Visitor GUID“ ir „Faktų tipas“. Klasifikavimo raktas yra „Created At Date“, kuris leidžia suskirstyti duomenis į pertvarkas pagal datą. Atributų stulpelyje yra JSON objektas, atstovaujantis ten įvykusiam įvykiui. Mes naudojame „ScyllaDB“ lyginamosios suspaudimo strategiją, nes: Optimizuotas užklausų diapazonui Labai gerai susidoroja su aukštu kardinališkumu Tai geriau skaityti sunkias darbo apkrovas, ir mes turime apie 2-3 kartus daugiau skaityti nei rašyti Kodėl ScyllaDB? Mūsų sprendimas iš pradžių buvo sukurtas naudojant „Cassandra on-prem“. Tačiau, didėjant mastui, taip pat padidėjo ir operacinė našta. Tam, kad galėtume tvarkyti duomenų bazės atnaujinimus, atsargines kopijas ir t. t. Taip pat mūsų sprendimas reikalauja labai mažų pagrindinių komponentų vėlavimų. Mūsų naudotojo tapatybės valdymo sistema turi identifikuoti vartotoją per 30 milisekundžių – ir geriausiam personalizavimui, mums reikia, kad mūsų renginių sekimo platforma reaguotų per 40 milisekundžių. Svarbu, kad mūsų sprendimas neužblokuotų puslapio pateikimo, todėl mūsų SLA yra labai mažos. Mes atlikome „Proof of Concept“ su „ScyllaDB“ ir nustatėme, kad našumas yra daug geresnis nei „Cassandra“, o operacinė našta buvo pašalinta. „ScyllaDB“ mums suteikė neįtikėtinai greitą gyvo aptarnavimo duomenų bazę su mažiausiais įmanomais vėlavimais. Mes norėjome visiškai valdomos parinkties, todėl perėjome iš „Cassandra“ į „ScyllaDB Cloud“, laikydamiesi dvigubo rašymo strategijos.Tai leido mums perkelti su nuliniu neveikimo laikotarpiu ir tvarkyti 40 000 operacijų ar užklausų per sekundę.Vėliau mes perėjome iš „ScyllaDB Cloud“ į „ScyllaDB“ modelį „Atnešk savo paskyrą“, kuriame „ScyllaDB“ komanda gali įdiegti „ScyllaDB“ duomenų bazę į savo „AWS“ paskyrą. Ši diagrama parodo, kaip atrodo „ScyllaDB“ BYOA diegimas. Diagramos centre galite pamatyti 6 mazgų ScyllaDB klasterį, kuris veikia EC2. ScyllaDB Monitor suteikia mums Grafana valdymo plokštes, taip pat Prometheus rodiklius. ScyllaDB Manager rūpinasi infrastruktūros automatizavimu, pvz., Atsarginių kopijų ir remonto paleidimu. Naudojant šį diegimą, „ScyllaDB“ galėtų būti išdėstytas labai arti mūsų mikroservisų, kad suteiktų dar mažesnius vėlavimus, taip pat daug didesnį našumą ir našumą. Apibendrinant, tikiuosi, kad dabar turite geresnį supratimą apie mūsų architektūrą, technologijas, kurios palaiko platformą, ir kaip ScyllaDB atlieka svarbų vaidmenį, leidžiantį mums susidoroti su itin dideliu „TripAdvisor“ mastu. Apie Cynthia Dunlop Cynthia yra ScyllaDB turinio strategijos vyresnysis direktorius.Ji jau daugiau nei 20 metų rašo apie programinės įrangos kūrimą ir kokybės inžineriją.

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

Šis garso įrašas sukurtas originalia istorijos kalba!

Per ilgai; Skaityti

Make resilience your competitive advantage

Kaip „TripAdvisor“ teikia realaus laiko pritaikymą mastu su ML

About Author

KOMENTARAI

PABAIGTI ŽYMES

ŠIS STRAIPSNIS BUVO PRISTATYMAS

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps