See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale Tripadvisor essaie d'évaluer cela dès que vous interagissez avec le site, puis vous offre des informations de plus en plus pertinentes à chaque clic - en quelques millisecondes. Cette personnalisation est alimentée par des modèles ML avancés agissant sur les données stockées sur ScyllaDB fonctionnant sur AWS. Dans cet article, Dean Poulin (Tripadvisor Data Engineering Lead sur l’équipe des services et produits d’IA) donne un aperçu de la façon dont ils alimentent cette personnalisation. Il est basé sur le discours suivant AWS re:Invent: Orientation pré-trip Les mots de Dean... Fondée en 2000, Tripadvisor est devenue un leader mondial dans le domaine des voyages et de l'hospitalité, aidant des centaines de millions de voyageurs à planifier leurs voyages parfaits. Tripadvisor génère plus de 1,8 milliard de dollars de revenus et est une société cotée à la bourse NASDAQ. Aujourd'hui, nous avons une équipe talentueuse de plus de 2 800 employés qui favorisent l'innovation et notre plateforme dessert un nombre impressionnant de 400 millions de visiteurs uniques par mois - un nombre qui ne cesse de croître. Chaque jour, notre système traite plus de 2 milliards de demandes de 25 à 50 millions d’utilisateurs. Chaque clic que vous faites sur TripAdvisor est traité en temps réel. Derrière cela, nous tirons parti de modèles d’apprentissage automatique pour vous fournir des recommandations personnalisées – vous rapprochant de ce voyage parfait. Au cœur de ce moteur de personnalisation, ScyllaDB fonctionne sur AWS. Cela nous permet de fournir une latence de millisecondes à une échelle que peu d’organisations atteignent. . 425K operations per second on ScyllaDB with P99 latencies for reads and writes around 1-3 milliseconds Je vais partager comment TripAdvisor exploite la puissance de ScyllaDB, AWS et de l’apprentissage automatique en temps réel pour fournir des recommandations personnalisées à chaque utilisateur.Nous allons explorer comment nous aidons les voyageurs à découvrir tout ce dont ils ont besoin pour planifier leur voyage parfait: qu’il s’agisse de découvrir des joyaux cachés, des attractions incontournables, des expériences inoubliables ou les meilleurs endroits où séjourner et dîner. Planification de voyage personnalisée Imaginez que vous planifiez un voyage.Dès que vous arrivez sur la page d’accueil de Tripadvisor, Tripadvisor sait déjà si vous êtes un gourou, un aventurier ou un amoureux de la plage – et vous voyez des recommandations sur place qui semblent personnalisées à vos propres intérêts. Lorsque vous naviguez sur TripAdvisor, nous commençons à personnaliser ce que vous voyez en utilisant des modèles d’apprentissage automatique qui calculent les scores en fonction de votre activité de navigation actuelle et précédente. Nous recommandons les hôtels et les expériences que nous pensons vous intéresser. Nous trions les hôtels en fonction de vos préférences personnelles. Nous recommandons les points d’intérêt populaires près de l’hôtel que vous consultez. Le modèle de Tripadvisor servant l’architecture Tripadvisor s'exécute sur des centaines de microservices indépendamment évolutifs dans Kubernetes on-prem et dans Amazon EKS. Notre plateforme de serveur de modèle ML est exposée à travers l'un de ces microservices. Ce service de passerelle extrait plus de 100 modèles ML des Services Client – ce qui nous permet d’exécuter des tests A/B pour trouver les meilleurs modèles à l’aide de notre plate-forme d’expérimentation. Les modèles ML sont principalement développés par nos scientifiques des données et nos ingénieurs en apprentissage automatique à l’aide de Jupyter Notebooks sur Kubeflow. Ils sont gérés et formés à l’aide de ML Flow, et nous les déployons sur Seldon Core dans Kubernetes. La boutique Custom Feature Le Store de fonctionnalités sert principalement aux fonctionnalités utilisateur et statiques. Les fonctionnalités statiques sont stockées dans Redis car elles ne changent pas très souvent. Nous exécutons quotidiennement des pipelines de données pour charger des données de notre entrepôt de données hors ligne dans notre Store de fonctionnalités en tant que fonctionnalités statiques. Les fonctionnalités utilisateur sont fournies en temps réel via une plate-forme appelée Visitor Platform. Nous exécutons des requêtes CQL dynamiques contre ScyllaDB, et . we do not need a caching layer because ScyllaDB is so fast Notre boutique de fonctionnalités fournit jusqu'à 5 millions de fonctionnalités statiques par seconde et un demi-million de fonctionnalités utilisateur par seconde. Qu’est-ce qu’une fonction ML ? Les caractéristiques sont des variables d'entrée pour les Modèles ML qui sont utilisés pour faire une prédiction. Certains exemples de fonctionnalités statiques sont des récompenses qu’un restaurant a remportées ou des commodités offertes par un hôtel (comme la connexion Wi-Fi gratuite, animal de compagnie ou centre de remise en forme). Les fonctionnalités utilisateur sont collectées en temps réel lorsque les utilisateurs naviguent sur le site. Nous les stockons dans ScyllaDB afin que nous puissions obtenir des requêtes rapides. Certains exemples de fonctionnalités utilisateur sont les hôtels consultés au cours des 30 dernières minutes, les restaurants consultés au cours des 24 dernières heures ou les avis soumis au cours des 30 derniers jours. Les technologies qui permettent la plateforme des visiteurs ScyllaDB est au cœur de la Plateforme Visitor. Nous utilisons des microservices Spring Boot basés sur Java pour exposer la plate-forme à nos clients. Ceci est déployé sur AWS ECS Fargate. Nous exécutons Apache Spark sur Kubernetes pour nos tâches de conservation de données quotidiennes, nos tâches hors ligne et en ligne. Ensuite, nous utilisons ces tâches pour charger des données de notre entrepôt de données hors ligne dans ScyllaDB afin qu'elles soient disponibles sur le site en direct. Nous utilisons également Amazon Kinesis pour traiter les événements de suivi des utilisateurs en streaming. Le flux de données de la plate-forme des visiteurs Le graphique suivant montre comment les données circulent à travers notre plate-forme en quatre étapes: produire, ingérer, organiser et activer. Les données sont produites par notre site Web et nos applications mobiles.Certaines de ces données comprennent notre graphique d’identité utilisateur à travers les appareils, les événements de suivi du comportement (comme les vues de pages et les clics) et les événements de streaming qui passent par Kinesis. Les microservices de Visitor Platform sont utilisés pour saisir et organiser ces données.Les données dans ScyllaDB sont stockées dans deux espaces clés: L'espace clé Visitor Core, qui contient le graphique d'identité du visiteur L'espace clé Métrique des visiteurs, qui contient des faits et des mesures (les choses que les gens ont faites pendant qu'ils naviguaient sur le site) Nous utilisons des processus ETL quotidiens pour maintenir et nettoyer les données dans la plate-forme.Nous produisons des produits de données, stampés quotidiennement, dans notre entrepôt de données hors ligne – où ils sont disponibles pour d’autres intégrations et autres pipelines de données à utiliser dans leur traitement. Voici un aperçu de la plateforme des visiteurs par les chiffres: Pourquoi deux bases de données ? Notre base de données en ligne est axée sur le trafic du site en temps réel et en direct. ScyllaDB remplit ce rôle en fournissant des latences très faibles et un débit élevé.Nous utilisons des TTL à court terme pour empêcher les données dans la base de données en ligne de croître indéfiniment, et nos tâches de conservation de données veillent à ce que nous conservions uniquement les données d'activité des utilisateurs pour les visiteurs réels. Tripadvisor.com reçoit beaucoup de trafic de robots, et nous ne voulons pas stocker leurs données et essayer de personnaliser les robots - alors nous supprimons et nettoyons toutes ces données. Notre entrepôt de données hors ligne conserve les données historiques utilisées pour les rapports, la création d'autres produits de données et la formation de nos modèles ML. Nous ne voulons pas que les processus de données hors ligne à grande échelle affectent les performances de notre site en direct, nous avons donc deux bases de données distinctes utilisées à deux fins différentes. Plateforme Visitor Microservices Nous utilisons 5 microservices pour la Plateforme Visiteur : Visitor Core gère le graphique d’identité utilisateur inter-appareil basé sur les cookies et les identifiants d’appareil. Visitor Metric est notre moteur de requête, et cela nous donne la possibilité d'exposer des faits et des mesures pour des visiteurs spécifiques. Nous utilisons un langage spécifique au domaine appelé langage de requête des visiteurs, ou VQL. Cet exemple VQL vous permet de voir les derniers faits de clics commerciaux au cours des trois dernières heures. Visitor Publisher et Visitor Saver gèrent le chemin d'écriture, en écrivant des données dans la plate-forme. En plus de stocker des données dans ScyllaDB, nous diffusons également des données dans le stockage de données hors ligne. Visitor Composite simplifie la publication de données dans les tâches de traitement de lots. Il abstrait Visitor Saver et Visitor Core pour identifier les visiteurs et publier des faits et des mesures dans un seul appel API. Roundtrip Microservices Latence Ce graphique illustre comment nos latences de microservice restent stables au fil du temps. La latence moyenne est de seulement 2,5 millisecondes, et notre P999 est inférieure à 12,5 millisecondes. Nos clients de microservices ont des exigences de latence strictes. 95% des appels doivent être terminés en 12 millisecondes ou moins. ScyllaDB Latence Voici un aperçu des performances de ScyllaDB sur trois jours. À son apogée, ScyllaDB gère 340 000 opérations par seconde (y compris les enregistrements, les lectures et les suppressions) et la CPU n’a que 21%. ScyllaDB fournit des microsecondes d'écriture et des millisecondes de lecture pour nous. Ce niveau de performance rapide est précisément la raison pour laquelle nous avons choisi ScyllaDB. Partitionnement des données dans ScyllaDB Cette image montre comment nous partitionnons les données dans ScyllaDB. Le Visitor Metric Keyspace a deux tables : Fact et Raw Metrics. La clé principale de la table Fact est Visitor GUID, Fact Type et Created At Date. La clé de partition composite est Visitor GUID et Fact Type. La clé de cluster est Created At Date, ce qui nous permet de trier les données en partitions par date. La colonne attributs contient un objet JSON représentant l'événement qui s'y est produit. Certains exemples de faits sont les termes de recherche, les vues de page et les réservations. Nous utilisons la stratégie de compactage équilibré de ScyllaDB parce que: Il est optimisé pour les requêtes de gamme Il gère très bien la cardinalité Il est préférable pour les charges de travail lourdes en lecture, et nous avons environ 2 à 3 fois plus de lectures que d’écrits Pourquoi ScyllaDB ? Notre solution a été construite à l’origine à l’aide de Cassandra on-prem. Mais à mesure que l’échelle a augmenté, la charge opérationnelle a également augmenté. Il a nécessité un support d’opérations dédiées pour que nous puissions gérer les mises à niveau de la base de données, les sauvegardes, etc. De plus, notre solution nécessite des latences très faibles pour les composants de base. Notre système de gestion de l’identité utilisateur doit identifier l’utilisateur dans les 30 millisecondes – et pour la meilleure personnalisation, nous avons besoin de notre plate-forme de suivi des événements pour répondre en 40 millisecondes. Il est essentiel que notre solution ne bloque pas le rendu de la page, de sorte que nos SLA sont très faibles. Avec Cassandra, nous Nous avons effectué une preuve de concept avec ScyllaDB et nous avons constaté que le débit était beaucoup meilleur que Cassandra et que la charge opérationnelle a été éliminée. Nous voulions une option entièrement gérée, donc nous avons migré de Cassandra vers ScyllaDB Cloud, en suivant une stratégie de double écriture. Cela nous a permis de migrer avec zéro temps d’arrêt tout en traitant 40 000 opérations ou demandes par seconde. Plus tard, nous avons migré de ScyllaDB Cloud vers le modèle « Apportez votre propre compte » de ScyllaDB, où vous pouvez avoir l’équipe de ScyllaDB déployer la base de données ScyllaDB dans votre propre compte AWS. Ce diagramme montre à quoi ressemble le déploiement BYOA de ScyllaDB. Au centre du diagramme, vous pouvez voir un cluster ScyllaDB de 6 nœuds qui fonctionne sur EC2. ScyllaDB Monitor nous donne des tableaux de bord Grafana ainsi que des métriques Prometheus. ScyllaDB Manager s'occupe de l'automatisation de l'infrastructure telle que le déclenchement de sauvegardes et de réparations. Avec ce déploiement, ScyllaDB pourrait être co-localisé très près de nos microservices pour nous donner des latences encore plus faibles, ainsi que des rendements et des performances beaucoup plus élevés. En résumé, j'espère que vous aurez maintenant une meilleure compréhension de notre architecture, des technologies qui alimentent la plate-forme et de la façon dont ScyllaDB joue un rôle crucial pour nous permettre de gérer l'échelle extrêmement élevée de TripAdvisor. À propos de Cynthia Dunlop Cynthia est directrice générale de la stratégie de contenu chez ScyllaDB. Elle écrit sur le développement de logiciels et l'ingénierie de la qualité depuis plus de 20 ans.