Як TripAdvisor надає персоналізацію в реальному часі в масштабі за допомогою ML

See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale Tripadvisor намагається оцінити це, як тільки ви взаємодієте з сайтом, а потім пропонує вам все більш актуальну інформацію на кожному натисканні - протягом декількох мілісекунд. У цій статті Дін Поулін (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, Tripadvisor вже знає, чи є ви їдальником, авантюристом або любителем пляжу - і ви бачите рекомендації на місці, які здаються персоналізованими для ваших власних інтересів. Коли ви переглядаєте TripAdvisor, ми починаємо персоналізувати те, що ви бачите, за допомогою моделей машинного навчання, які обчислюють оцінки на основі вашої поточної та попередньої активності перегляду. Ми рекомендуємо готелі та досвід, які, на нашу думку, вас зацікавлять. Ми класифікуємо готелі на основі ваших особистих уподобань. Ми рекомендуємо популярні точки інтересу поблизу готелю, який ви переглядаєте. Модель Tripadvisor, що обслуговує архітектуру Tripadvisor працює на сотнях незалежно розширюваних мікросервісів в Kubernetes on-prem і в Amazon EKS. Наша ML Model Serving Platform відображається через одну з цих мікросервісів. Цей сервіс брандмауера витягує понад 100 моделей ML з сервісів клієнта, що дозволяє нам проводити A/B-тести, щоб знайти найкращі моделі за допомогою нашої експериментальної платформи. Моделі ML розробляються в основному нашими вченими з даних та інженерами з машинного навчання за допомогою ноутбуків Jupyter на Kubeflow. Вони управляються та навчаються за допомогою ML Flow, і ми розгортаємо їх на Seldon Core в Kubernetes. Магазин Custom Feature Магазин функцій в першу чергу обслуговує функції користувача та статичні функції. Статичні функції зберігаються в Redis, тому що вони не змінюються дуже часто. Ми щодня запускаємо трубопроводи даних, щоб завантажувати дані з нашого автономного сховища даних в наш Магазин функцій як статичні функції. Функції користувача надаються в режимі реального часу через платформу під назвою Visitor Platform.We execute dynamic CQL queries against ScyllaDB, and . 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. Ми використовуємо мікросервіси Spring Boot на основі Java, щоб розкрити платформу нашим клієнтам. Це розгортається на AWS ECS Fargate. Ми запускаємо Apache Spark на Kubernetes для наших щоденних завдань з збереження даних, наших офлайн до онлайн завдань. Потім ми використовуємо ці роботи, щоб завантажити дані з нашого офлайн сховища даних в ScyllaDB, щоб вони були доступні на реальному сайті. Ми також використовуємо Amazon Kinesis для обробки потокових подій відстеження користувачів. Потік даних платформи відвідувачів Наступна графіка показує, як дані протікають через нашу платформу в чотири етапи: виробляти, вживати, організовувати та активувати. Дані виробляються нашим веб-сайтом та нашими мобільними додатками. Деякі з цих даних включають наш Cross-Device User Identity Graph, події відстеження поведінки (наприклад, перегляди сторінок та кліки) та потокові події, які проходять через Kinesis. Мікросервіси Visitor Platform використовуються для введення та організації цих даних.Дані в ScyllaDB зберігаються в двох ключових просторах: Ключовий простір Visitor Core, що містить графік ідентичності відвідувача Відвідувач метричний ключовий простір, який містить факти і метрики (ті речі, які люди робили, коли вони переглядали сайт) Ми використовуємо щоденні процеси ETL для підтримки та очищення даних на платформі.Ми виробляємо продукти даних, щоденно штамповані, в нашому офлайн сховищі даних - де вони доступні для інших інтеграцій та інших трубопроводів даних для використання в їх обробці. Ось погляд на платформу відвідувачів за цифрами: Чому дві бази даних? Наша онлайн-база даних орієнтована на трафік веб-сайтів в реальному часі. ScyllaDB виконує цю роль, надаючи дуже низькі затримки та високу пропускну здатність. Ми використовуємо короткострокові TTL, щоб запобігти безстроковому зростанню даних в онлайн-базі даних, а наші роботи з збереження даних забезпечують, що ми зберігаємо дані про активність користувачів тільки для реальних відвідувачів. Tripadvisor.com отримує багато трафіку ботів, і ми не хочемо зберігати їхні дані і намагатися персоналізувати ботів - тому ми видаляємо і очищаємо всі ці дані. Наш офлайн склад даних зберігає історичні дані, які використовуються для звітування, створення інших продуктів даних та навчання наших моделей ML. Ми не хочемо, щоб масштабні офлайн процеси даних впливали на продуктивність нашого сайту, тому у нас є дві окремі бази даних, які використовуються для двох різних цілей. Відвідувачі платформи Microservices Ми використовуємо 5 мікросервісів для платформи відвідувачів: Visitor Core керує графом ідентичності користувача на різних пристроях на основі файлів cookie та ідентифікаторів пристроїв. Visitor Metric - це наша система запитів, яка надає нам можливість розкривати факти та показники для конкретних відвідувачів.Ми використовуємо мову, специфічну для домену, яка називається мовою запитів відвідувачів, або VQL. Цей приклад VQL дозволяє переглядати останні факти про кліки в торгівлі за останні три години. Visitor Publisher і Visitor Saver обробляють шлях написання, записуючи дані на платформу.На додаток до збереження даних в ScyllaDB, ми також передаємо дані в офлайновий склад даних. Visitor Composite спрощує публікацію даних у роботах з обробки партій. Він абстрагує Visitor Saver і Visitor Core, щоб ідентифікувати відвідувачів та публікувати факти та показники в одному виклику API. Мікросервіс Roundtrip Latency Цей графік показує, як наші затримки мікропослуг залишаються стабільними з плином часу. Середня затримка становить всього 2,5 мілісекунди, а наш P999 – менше 12,5 мілісекунди. Наші клієнти мікропослуг мають суворі вимоги щодо затримки. 95% дзвінків повинні бути завершені за 12 мілісекунд або менше. ScyllaDB Латентність Ось короткий опис результатів ScyllaDB протягом трьох днів. На піку, ScyllaDB обробляє 340 000 операцій в секунду (включаючи запису, читання і видалення), а процесор коливається всього на 21%. ScyllaDB надає нам мікросекундні записи та мілісекундні читання.Цей рівень швидкої продуктивності саме тому ми вибрали ScyllaDB. Розподіл даних в ScyllaDB На даному зображенні показано, як ми розділяємо дані в ScyllaDB. Відвідувач Метричний ключовий простір має дві таблиці: Факт і Raw Metrics. Первинний ключ на таблиці Факт є Відвідувач GUID, Тип Факту та Створений на дату. Складовий ключ розділу є Відвідувач GUID і Тип Факту. Кластерний ключ створюється на дату, що дозволяє нам сортувати дані в розділах за датою. Стовп атрибутів містить об'єкт JSON, що представляє подію, що відбулася там. Деякі приклади Факти - це пошукові терміни, перегляди сторінки та бронювання. Ми використовуємо стратегію рівняння ScyllaDB, тому що: Оптимізовано для запитів діапазону Дуже добре справляється з високою кардинальністю Це краще для важких для читання робочих навантажень, і у нас приблизно 2-3 рази більше читань, ніж записів. Чому ScyllaDB? Наше рішення спочатку було побудовано за допомогою Cassandra on-prem. Але оскільки масштаб збільшився, операційне навантаження також зросло. Для того, щоб ми могли керувати оновленнями бази даних, резервними копіями і т. Д. Крім того, наше рішення вимагає дуже низьких затримок для основних компонентів. Наша система управління ідентичністю користувачів повинна ідентифікувати користувача протягом 30 мілісекунд – і для найкращої персоналізації ми вимагаємо від нашої платформи відстеження подій реагувати за 40 мілісекунд. Важливо, щоб наше рішення не блокувало рендеринг сторінки, тому наші SLA дуже низькі. Ми запустили Proof of Concept з ScyllaDB і виявили, що пропускна здатність набагато краща, ніж Cassandra, і операційне навантаження було усунуто. Ми хотіли повністю керованого варіанту, тому ми мігрували з Cassandra в ScyllaDB Cloud, слідуючи стратегії подвійного написання. Це дозволило нам мігрувати з нульовим періодом зупинки при обробці 40 000 операцій або запитів в секунду. Пізніше ми мігрували з ScyllaDB Cloud до моделі ScyllaDB "Приведи свій власний обліковий запис", де ви можете мати команду ScyllaDB розгортати базу даних ScyllaDB у свій власний обліковий запис AWS. Це дало нам поліпшену продуктивність, а також кращу конфіденційність даних. Цей діаграм показує, як виглядає розгортання BYOA ScyllaDB. У центрі діаграми можна побачити 6-вузловий кластер ScyllaDB, який працює на EC2. ScyllaDB Monitor дає нам панелі Grafana, а також метрики Prometheus. ScyllaDB Manager дбає про автоматизацію інфраструктури, наприклад, запускає резервні копії та ремонти. За допомогою цього розгортання ScyllaDB може бути розташований дуже близько до наших мікросервісів, щоб дати нам ще менші затримки, а також набагато більшу пропускну здатність і продуктивність. У підсумку, я сподіваюся, що ви тепер маєте краще розуміння нашої архітектури, технологій, які підтримують платформу, і як ScyllaDB відіграє критичну роль у тому, що дозволяє нам справлятися з надзвичайно високим масштабом TripAdvisor. Про Cynthia Dunlop Синтія є старшим директором з стратегії контенту в ScyllaDB. Вона пише про розробку програмного забезпечення та інженерії якості протягом 20 років.