See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale Milyen utazó vagy?A TripAdvisor megpróbálja ezt értékelni, amint kapcsolatba lép a webhellyel, majd minden egyes kattintással egyre relevánsabb információkat kínál – milliszekundumok alatt. Ebben a cikkben Dean Poulin (a Tripadvisor adatfejlesztési vezetője az AI szolgáltatások és termékek csapatában) megvizsgálja, hogyan hajtják végre ezt a személyre szabást. Dean megosztja a Tripadvisor hatalmas (és gyorsan növekvő) méretű valós idejű személyre szabásának technikai kihívásait. A következő AWS re:Invent beszélgetésen alapul: Utazás előtti orientáció Dean szavaival... A 2000-ben alapított Tripadvisor világelsővé vált az utazások és a vendéglátás területén, segítve több száz millió utazót tökéletes utazásaik megtervezésében.A Tripadvisor több mint 1,8 milliárd dolláros bevételt generál, és nyilvánosan jegyzett vállalat a NASDAQ tőzsdén. Egy adott napon rendszerünk több mint 2 milliárd kérelmet kezel 25 és 50 millió felhasználótól. A Tripadvisor-on tett minden kattintást valós időben dolgozzuk fel. Ezután gépi tanulási modelleket használunk, hogy személyre szabott ajánlásokat nyújtsunk – közelebb hozva Önt a tökéletes utazáshoz. Ennek a személyre szabási motornak a középpontjában a ScyllaDB működik az AWS-en. Ez lehetővé teszi számunkra, hogy milliszekundum késleltetést biztosítsunk olyan skálán, amelyet kevés szervezet ér el. . 425K operations per second on ScyllaDB with P99 latencies for reads and writes around 1-3 milliseconds Meg fogom osztani, hogy a TripAdvisor hogyan használja ki a ScyllaDB, az AWS és a valós idejű gépi tanulás erejét, hogy személyre szabott ajánlásokat nyújtson minden felhasználó számára. Meg fogjuk vizsgálni, hogyan segítünk az utazóknak felfedezni mindent, amire szükségük van a tökéletes utazás megtervezéséhez: legyen szó rejtett drágakövek felfedezéséről, látnivalókról, felejthetetlen élményekről, vagy a legjobb helyekről, ahol maradhatnak és vacsorázhatnak. Személyre szabott utazási terv Képzelje el, hogy utazást tervez.Amint megérkezik a TripAdvisor honlapjára, a TripAdvisor már tudja, hogy élelmiszer-élvező, kalandor vagy strandszerető - és olyan ajánlásokat lát, amelyek úgy tűnnek, hogy személyre szabottak az Ön érdekeihez. A Tripadvisor böngészésekor elkezdjük személyre szabni azt, amit lát, olyan gépi tanulási modellek segítségével, amelyek az Ön aktuális és korábbi böngészési tevékenysége alapján számolják ki a pontszámokat. Ajánljuk azokat a szállodákat és élményeket, amelyekről úgy gondoljuk, hogy érdekelnek Önt. Szállodákat az Ön személyes preferenciái alapján rendezünk. Ajánljuk a népszerű látnivalókat az Ön által megtekintett szálloda közelében. Ezek mindegyike az Ön személyes preferenciái és korábbi böngészési tevékenysége alapján van beállítva. A Tripadvisor modellje szolgálja az architektúrát A Tripadvisor több száz önállóan skálázható mikroszolgáltatáson fut a Kubernetes on-prem és az Amazon EKS-ben. Ez az átjáró szolgáltatás több mint 100 ML modellt von le az Ügyfélszolgálatból – ami lehetővé teszi számunkra, hogy A/B teszteket végezzünk a legjobb modellek megtalálása érdekében kísérleti platformunk segítségével. Az ML modelleket elsősorban adatkutatóink és gépi tanulási mérnökeink fejlesztették ki a Jupyter Notebooks segítségével a Kubeflow-on. Custom Feature áruház A funkciós áruház elsősorban a felhasználói funkciókat és a statikus funkciókat szolgálja. A statikus funkciókat a Redis tárolja, mert nem változnak túl gyakran. Naponta adatvezetékeket futtatunk, hogy offline adattárunkból statisztikai funkciók formájában töltse fel az adatokat a funkciós áruházunkba. A felhasználói funkciókat valós időben nyújtjuk a Visitor Platform nevű platformon keresztül. Dinamikus CQL lekérdezéseket hajtunk végre a ScyllaDB-vel szemben, és . we do not need a caching layer because ScyllaDB is so fast A funkciótárunk másodpercenként akár 5 millió statikus funkciót és másodpercenként félmillió felhasználói funkciót is kiszolgál. Mi az ML funkció? A tulajdonságok az ML Modellek beviteli változói, amelyeket előrejelzés készítésére használnak. Néhány példa a statikus funkciókra olyan díjak, amelyeket egy étterem nyert, vagy a szálloda által kínált szolgáltatások (például ingyenes Wi-Fi, háziállatbarát vagy fitneszközpont). A felhasználói funkciókat valós időben gyűjtjük, amikor a felhasználók a webhelyen böngésznek. A ScyllaDB-ben tároljuk őket, így villámgyors lekérdezéseket kaphatunk. A felhasználói funkciók néhány példája az elmúlt 30 percben megtekintett szállodák, az elmúlt 24 órában megtekintett éttermek, vagy az elmúlt 30 napban benyújtott vélemények. A technológiák látogatói platformja A ScyllaDB a látogatói platform középpontjában áll. Java-alapú Spring Boot mikroszolgáltatásokat használunk a platform ügyfeleink számára történő feltárására. Ezt az AWS ECS Fargate-on telepítjük. A Kubernetes-on futtatjuk az Apache Spark-ot a napi adatmegőrzési munkákhoz, az offline munkákhoz az online munkákhoz. Ezután ezeket a munkákat használjuk az offline adattárunkból származó adatok feltöltésére a ScyllaDB-be, hogy azok elérhetőek legyenek az élő helyszínen. Az Amazon Kinesis-t is használjuk a felhasználói követési események streamingjének feldolgozásához. A látogatói platform adatáramlása Az alábbi grafikon azt mutatja, hogy az adatok hogyan áramlanak platformunkon keresztül négy szakaszban: termelés, bevitel, szervezés és aktiválás. Az adatokat weboldalunk és mobilalkalmazásaink állítják elő.Ebben az adatban szerepelnek a Cross-Device User Identity Graph, a viselkedési nyomon követési események (például az oldalnézetek és a kattintások) és a Kinesis-en keresztül zajló streaming események is. A Visitor Platform mikroszolgáltatásait használják ezeknek az adatoknak a beszerzésére és megszervezésére.Az adatok a ScyllaDB-ben két kulcsterületben tárolódnak: A látogatói kulcsszó, amely tartalmazza a látogatói személyazonossági diagramot A Visitor Metric billentyűzet, amely tényeket és mutatókat tartalmaz (azokat a dolgokat, amelyeket az emberek a webhely böngészésekor végeztek) Napi ETL-folyamatokat használunk a platformon belüli adatok karbantartására és tisztítására. Naponta pecsételt adattermékeket állítunk elő offline adattárunkban – ahol más integrációk és egyéb adatvezetékek is rendelkezésre állnak a feldolgozásukhoz. Itt van egy pillantás a látogatói platformra a számok szerint: Miért két adatbázis? Online adatbázisunk a valós idejű, élő webhelyforgalomra összpontosít. ScyllaDB tölt be ezt a szerepet azáltal, hogy nagyon alacsony késleltetést és nagy átviteli sebességet biztosít. rövidtávú TTL-eket használunk, hogy megakadályozzuk az online adatbázisban lévő adatok határozatlan ideig történő növekedését, és adatmegőrzési munkáink biztosítják, hogy csak a valódi látogatók felhasználói aktivitási adatait tároljuk. Az offline adattárunk megőrzi a jelentések készítéséhez, más adattermékek létrehozásához és az ML Modellek képzéséhez használt történelmi adatokat. Nem akarjuk, hogy az élő webhely teljesítményét befolyásoló nagyméretű offline adatfeldolgozások működjenek, ezért két külön adatbázissal rendelkezünk, amelyeket két különböző célra használunk. Microservices látogatói platform 5 mikroszolgáltatást használunk a látogatói platformhoz: A Visitor Core a cookie-k és az eszközazonosítók alapján kezeli az eszközök közötti felhasználói személyazonossági diagramot. A Visitor Metric a lekérdezésmotorunk, amely lehetővé teszi számunkra a tények és mutatók feltárását bizonyos látogatók számára. domain-specifikus nyelvet használunk, a látogató lekérdezés nyelvével, vagy VQL. Ez a példa VQL lehetővé teszi az elmúlt három óra legújabb kereskedelmi kattintási tényeinek megtekintését. A Visitor Publisher és a Visitor Saver kezeli az írási utat, és adatokat ír a platformra.A ScyllaDB-ben való mentés mellett az adatokat az offline adattárba is továbbítjuk. A Visitor Composite egyszerűsíti az adatok közzétételét a tételes feldolgozási munkákban. A Visitor Saver és a Visitor Core segítségével azonosítja a látogatókat, és egyetlen API-hívásban közzéteszi a tényeket és a mutatókat. Roundtrip Microservice késleltetés Ez a grafikon azt mutatja, hogy miként maradnak stabilak a mikroszolgáltatási késleltetések az idő múlásával. Az átlagos késleltetés mindössze 2,5 milliszekundum, a P999 pedig kevesebb, mint 12,5 milliszekundum. Ez lenyűgöző teljesítmény, különösen, ha figyelembe vesszük, hogy naponta több mint 1 milliárd kérést kezelünk. A mikroszolgáltató ügyfeleinknek szigorú késleltetési követelményei vannak. a hívások 95% -ának 12 milliszekundum alatt kell befejeződnie. ScyllaDB késleltetés Itt van egy pillanatkép a ScyllaDB teljesítményéről három nap alatt. A csúcson a ScyllaDB másodpercenként 340 000 műveletet kezel (beleértve az írást, az olvasást és a törlést), és a CPU mindössze 21 százalékkal ingadozik. A ScyllaDB mikrosekundum írást és milliszekundum olvasást biztosít számunkra.A gyors teljesítmény ezen szintje éppen ezért választottuk a ScyllaDB-t. Az adatok felosztása a ScyllaDB-be Ez a kép azt mutatja, hogyan osztjuk fel az adatokat a ScyllaDB-be. A Visitor Metric Keyspace két táblával rendelkezik: Fact és Raw Metrics. A Fact tábla elsődleges kulcsa a Visitor GUID, a Fact Type és a Created At Date. A kompozit partíciókulcs a Visitor GUID és a Fact Type. A klaszterkulcs a Created At Date, amely lehetővé teszi számunkra, hogy dátum szerint osztályozzuk az adatokat partíciókban. Az attribútumoszlop tartalmaz egy JSON objektumot, amely az ott bekövetkezett eseményt képviseli. Néhány példa tények a Search Terms, Page Views és Bookings. A ScyllaDB kiegyenlített tömörítési stratégiáját használjuk, mert: Optimalizálva a tartománykérésekhez Nagyon jól kezeli a magas kardinalitást Jobb az olvasó-súlyos munkaterhelésekhez, és körülbelül 2-3X több olvasás van, mint írás. Miért a ScyllaDB? A megoldásunk eredetileg Cassandra on-prem használatával készült. De ahogy a skála nőtt, a működési terhek is megnövekedtek. Szükséges volt a dedikált műveleti támogatásra ahhoz, hogy kezeljük az adatbázis-frissítéseket, biztonsági mentéseket stb. Ezenkívül a megoldásunk nagyon alacsony késleltetést igényel az alapvető összetevők számára. A felhasználói személyazonosság-kezelő rendszerünknek 30 milliszekundum alatt kell azonosítania a felhasználót – és a legjobb személyre szabás érdekében 40 milliszekundum alatt kell reagálnia az Eseménykövetési platformunkra. Fontos, hogy megoldásunk ne blokkolja az oldal megjelenítését, így az SLA-k nagyon alacsonyak. A ScyllaDB-vel elvégeztük a Proof of Concept programot, és úgy találtuk, hogy az átviteli teljesítmény sokkal jobb, mint a Cassandra, és a működési terhek megszűntek. Teljesen felügyelt opciót akartunk, ezért áttértünk a Cassandra-ról a ScyllaDB Cloud-ra, egy kettős írási stratégiát követve. Ez lehetővé tette számunkra, hogy nulla leállási idővel áttérjünk, miközben másodpercenként 40 000 műveletet vagy kérést kezelünk.Később áttértünk a ScyllaDB Cloud-ról a ScyllaDB „Vigye el saját fiókját” modelljére, ahol a ScyllaDB csapat telepítheti a ScyllaDB-adatbázist saját AWS-fiókjába. Ez a diagram azt mutatja, hogy milyen a ScyllaDB BYOA telepítése. A diagram közepén egy 6 csomópontos ScyllaDB klaszter látható, amely az EC2-en fut. A ScyllaDB Monitor grafán eszköztáblákat és Prometheus mutatókat kínál. A ScyllaDB Manager gondoskodik az infrastruktúra automatizálásáról, például a biztonsági mentések és javítások kiváltásáról. Ezzel a telepítéssel a ScyllaDB nagyon közel helyezhető el a mikroszolgáltatásainkhoz, hogy még alacsonyabb késleltetési időt, valamint sokkal magasabb átviteli sebességet és teljesítményt nyújtson. Összefoglalva, remélem, hogy most már jobban megérted architektúráinkat, a platformot támogató technológiákat, és azt, hogy a ScyllaDB hogyan játszik kritikus szerepet abban, hogy lehetővé tegyük számunkra, hogy kezeljük a TripAdvisor rendkívül nagy skáláját. Született Cynthia Dunlop Cynthia a ScyllaDB tartalmi stratégiájának vezető igazgatója, aki több mint 20 éve ír a szoftverfejlesztésről és a minőségfejlesztésről.

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

Ez a hanganyag a történet eredeti nyelvén készült!

Hogyan kínál a TripAdvisor valós idejű személyre szabást a skálán az ML-vel

About Author

HOZZÁSZÓLÁSOK

HANG TAGOK

EZT A CIKKET BEMUTATTA

Related Stories

Of The First and Last Things: Part 3

The Little Shop at Fishbourne

Of The First and Last Things: Part 1

HackerNoon Social Media Presence: A Complete Guide

Of The First and Last Things: Part 3

The Little Shop at Fishbourne

Of The First and Last Things: Part 1

HackerNoon Social Media Presence: A Complete Guide

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps