Как TripAdvisor предоставя персонализиране в реално време в мащаб с ML

See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale Tripadvisor се опитва да оцени това веднага след като се свържете със сайта, след което ви предлага все по-подходяща информация при всяко кликване – в рамките на милисекунди. В тази статия Dean Poulin (Tripadvisor Data Engineering Lead на екипа на AI Services and Products) дава поглед върху това как те подпомагат тази персонализация. Тя се основава на следния AWS re:Invent talk: Предварителна ориентация По думите на Дин... Основана през 2000 г., TripAdvisor се превърна в световен лидер в областта на пътуванията и гостоприемството, помагайки на стотици милиони пътници да планират перфектните си пътувания. TripAdvisor генерира над 1,8 милиарда долара приходи и е публично търгувана компания на борсата NASDAQ. Днес имаме талантлив екип от над 2800 служители, които водят иновациите, а нашата платформа обслужва поразително 400 милиона уникални посетители на месец – число, което непрекъснато се увеличава. На всеки даден ден нашата система обработва над 2 милиарда заявки от 25 до 50 милиона потребители. Всеки клик, който правите на TripAdvisor, се обработва в реално време. Зад това ние използваме модели за машинно обучение, за да ви предоставим персонализирани препоръки – което ви приближава до това перфектно пътуване. В сърцето на този двигател за персонализиране е ScyllaDB, който работи на AWS. Това ни позволява да доставяме милисекундна латентност в мащаб, който малко организации достигат. . 425K operations per second on ScyllaDB with P99 latencies for reads and writes around 1-3 milliseconds Ще споделя как TripAdvisor използва силата на ScyllaDB, AWS и машинното обучение в реално време, за да предостави персонализирани препоръки за всеки потребител. Ще проучим как помагаме на пътниците да открият всичко, от което се нуждаят, за да планират перфектното си пътуване: независимо дали става дума за откриване на скрити скъпоценности, незабравими атракции, незабравими преживявания или най-добрите места за престой и вечеря. Персонализирано пътуване планиране Веднага щом пристигнете на началната страница на TripAdvisor, TripAdvisor вече знае дали сте готвач, авантюрист или любител на плажа – и виждате препоръки на място, които изглеждат персонализирани за вашите собствени интереси. Докато сърфирате в Tripadvisor, ние започваме да персонализираме това, което виждате, като използваме модели за машинно обучение, които изчисляват резултатите въз основа на текущата и предишната ви активност при сърфиране. Препоръчваме хотели и преживявания, които смятаме, че биха ви заинтересували. Сортираме хотели въз основа на личните ви предпочитания. Препоръчваме популярни атракции в близост до хотела, който разглеждате. Моделът на Tripadvisor, който служи на архитектурата Tripadvisor работи на стотици независимо мащабируеми микроуслуги в Kubernetes on-prem и в Amazon EKS. Нашата платформа за обслужване на модели ML е изложена чрез една от тези микроуслуги. Тази портална услуга извлича над 100 модели ML от услугите на клиентите – което ни позволява да изпълняваме A/B тестове, за да намерим най-добрите модели, използвайки нашата експериментална платформа. Моделите ML се разработват главно от нашите учени по данни и инженери по машинно обучение, използващи Jupyter Notebooks на Kubeflow. Те се управляват и обучават с помощта на ML Flow, а ние ги разгръщаме на Seldon Core в Kubernetes. Магазинът Custom Feature Магазинът за функции обслужва предимно потребителски функции и статични функции. Статичните функции се съхраняват в Redis, защото не се променят много често. Ние управляваме ежедневно тръбопроводи за данни, за да зареждаме данни от нашия офлайн склад за данни в нашия Магазин за функции като статични функции. Потребителските функции се обслужват в реално време чрез платформа, наречена Visitor Platform. Ние изпълняваме динамични CQL заявки срещу ScyllaDB, и . we do not need a caching layer because ScyllaDB is so fast Нашият магазин за функции обслужва до 5 милиона статични функции в секунда и половин милион потребителски функции в секунда. Какво е ML Feature? Функциите са входни променливи на ML моделите, които се използват за да се направи прогноза. Някои примери за статични функции включват награди, които ресторантът е спечелил, или удобства, предлагани от хотел (като безплатен Wi-Fi, домашен любимец или фитнес център). Потребителските функции се събират в реално време, когато потребителите сърфират в сайта. Ние ги съхраняваме в ScyllaDB, за да можем да получаваме бързи заявки.Някои примери за потребителски функции включват хотели, разгледани през последните 30 минути, ресторанти, разгледани през последните 24 часа, или отзиви, подадени през последните 30 дни. Технологиите, подпомагащи платформата за посетители ScyllaDB е в основата на Visitor Platform. Ние използваме Java базирани Spring Boot микроуслуги, за да изложим платформата на нашите клиенти. Това се разгръща на AWS ECS Fargate. Ние изпълняваме Apache Spark на Kubernetes за нашите ежедневни задачи за съхранение на данни, нашите офлайн към онлайн работни места. След това използваме тези работни места, за да зареждаме данни от нашия офлайн склад за данни в ScyllaDB, така че те да са достъпни на живо на сайта. Ние също използваме Amazon Kinesis за обработка на събития за проследяване на потребителите. Потокът от данни на Платформата за посетители Следващата графика показва как данните преминават през нашата платформа в четири етапа: произвеждане, поглъщане, организиране и активиране. Някои от тези данни включват нашата Cross-Device User Identity Graph, събития за проследяване на поведението (като прегледи на страници и кликвания) и събития за стрийминг, които преминават през Kinesis. Микрослужбите на Visitor Platform се използват за поглъщане и организиране на тези данни.Данните в ScyllaDB се съхраняват в две ключови пространства: Ключовото пространство Visitor Core, което съдържа Графа за самоличност на посетителя Посетител метрично ключово пространство, което съдържа факти и показатели (нещата, които хората са направили, докато са сърфирали в сайта) Ние използваме ежедневни ETL процеси, за да поддържаме и почистваме данните в платформата.Ние произвеждаме продукти за данни, ежедневно отпечатани, в нашия офлайн склад за данни – където те са на разположение за други интеграции и други тръбопроводи за данни, които да се използват при тяхната обработка. Ето един поглед към Платформата за посетители по числа: Защо две бази данни? Нашата онлайн база данни е фокусирана върху трафика на уебсайта в реално време. ScyllaDB изпълнява тази роля, като осигурява много ниски закъснения и висок пропуск. Ние използваме краткосрочни TTLs, за да предотвратим растежа на данните в онлайн базата данни за неопределено време, а нашите задачи за запазване на данни гарантират, че запазваме само данни за активността на потребителите за реални посетители. Tripadvisor.com получава много трафик на ботове и не искаме да съхраняваме техните данни и да се опитваме да персонализираме ботове - така че изтриваме и почистваме всички тези данни. Нашият офлайн склад за данни съхранява исторически данни, използвани за отчитане, създаване на други продукти за данни и обучение на нашите модели ML. Ние не искаме мащабни офлайн процеси за данни, които да повлияят на производителността на нашия сайт на живо, така че имаме две отделни бази данни, използвани за две различни цели. Платформа за посетители Microservices Ние използваме 5 микроуслуги за Платформа за посетители: Visitor Core управлява графиката за идентичност на потребителя на различни устройства въз основа на бисквитки и идентификатори на устройства. Visitor Metric е нашата машина за заявки, която ни дава възможност да разкриваме факти и показатели за конкретни посетители.Ние използваме специфичен за домейна език, наречен език за заявки за посетители, или VQL. Този пример VQL ви позволява да видите най-новите факти за търговски кликвания през последните три часа. Visitor Publisher и Visitor Saver се справят с пътеката за писане, като записват данни в платформата. В допълнение към съхраняването на данни в ScyllaDB, ние също прехвърляме данни към офлайн хранилището на данни. Visitor Composite опростява публикуването на данни в задачи за обработка на партиди. Той абстрахира Visitor Saver и Visitor Core, за да идентифицира посетителите и да публикува факти и показатели в един API повикване. Roundtrip Microservice Латентност Тази диаграма илюстрира как нашите закъснения на микроуслугите остават стабилни с течение на времето. Средната латентност е само 2,5 милисекунди, а нашият P999 е под 12,5 милисекунди. Това е впечатляваща производителност, особено като се има предвид, че обработваме над 1 милиард заявки на ден. Нашите клиенти за микроуслуги имат строги изисквания за закъснение. 95% от обажданията трябва да бъдат завършени за 12 милисекунди или по-малко. ScyllaDB Латентност Ето кратка снимка на представянето на ScyllaDB за три дни. На върха, ScyllaDB обработва 340 000 операции в секунда (включително писане и четене и изтриване) и процесора се колебае само на 21%. ScyllaDB доставя микросекунди за писане и милисекунди за четене за нас.Това ниво на блестяща бърза производителност е точно защо избрахме ScyllaDB. Разделяне на данни в ScyllaDB Това изображение показва как разделяме данните в ScyllaDB. Visitor Metric Keyspace има две таблици: Fact и Raw Metrics. Основният ключ в таблицата Fact е Visitor GUID, Fact Type и Created At Date. Композитният ключ за разделяне е Visitor GUID и Fact Type. Класиращият ключ е Created At Date, което ни позволява да сортираме данните в раздели по дата. Колоната с атрибути съдържа JSON обект, който представлява събитието, което се е случило там. Някои примерни факти са Search Terms, Page Views и Bookings. Използваме Стратегията за нивото на компресиране на ScyllaDB, защото: Оптимизиран за заявки за диапазон Той се справя с висока кардиналност много добре По-добре е за тежки за четене работни натоварвания и имаме около 2-3 пъти повече четения, отколкото пише. Защо ScyllaDB? Нашето решение първоначално е изградено с помощта на Cassandra on-prem. Но тъй като мащабът се е увеличил, операционната тежест също така. Това изисква специална операционна поддръжка, за да можем да управляваме надстройките на базата данни, резервни копия и т.н. Също така, нашето решение изисква много ниски закъснения за основните компоненти. Системата ни за управление на потребителската идентичност трябва да идентифицира потребителя в рамките на 30 милисекунди – и за най-добрата персонализация, ние изискваме платформата ни за проследяване на събития да отговори в рамките на 40 милисекунди. Изпълнихме Proof of Concept с ScyllaDB и открихме, че пропускът е много по-добър от Cassandra и операционната тежест беше елиминирана. Искахме напълно управлявана опция, така че мигрирахме от Cassandra към ScyllaDB Cloud, следвайки стратегия за двойно писане.Това ни позволи да мигрираме с нулево време за спиране, докато обработваме 40 000 операции или заявки в секунда.По-късно мигрирахме от ScyllaDB Cloud към модела на ScyllaDB „Доведете своя собствен акаунт“, където можете да накарате екипа на ScyllaDB да разгърне базата данни на ScyllaDB в собствения си AWS акаунт. Тази диаграма показва как изглежда разгръщането на BYOA на ScyllaDB. В центъра на диаграмата можете да видите 6-възел ScyllaDB клъстер, който работи на EC2. ScyllaDB Monitor ни дава графични табла, както и показатели на Prometheus. ScyllaDB Manager се грижи за автоматизацията на инфраструктурата като активиране на резервни копия и ремонти. С това разгръщане ScyllaDB може да бъде съвместно разположен много близо до нашите микроуслуги, за да ни даде още по-ниски закъснения, както и много по-висок пропуск и производителност. Накратко, надявам се, че сега имате по-добро разбиране за нашата архитектура, технологиите, които задвижват платформата, и как ScyllaDB играе критична роля, за да ни позволи да се справим с изключително високия мащаб на TripAdvisor. Още за Cynthia Dunlop Синтия е старши директор по стратегия на съдържанието в ScyllaDB. Тя пише за разработване на софтуер и инженерство на качеството в продължение на повече от 20 години.