Comment Amp sur Amazon a utilisé les données pour accroître l'engagement des clients, Partie 1 : Créer une plateforme d'analyse de données

Ampli, la nouvelle application de radio en direct d'Amazon, est une réinvention de la radio avec des émissions audio en direct organisées par des humains. Il est conçu pour offrir une expérience client transparente aux auditeurs et aux créateurs en lançant des émissions audio interactives en direct de vos artistes, DJ radio, podcasteurs et amis préférés.

Cependant, en tant que nouveau produit dans un nouvel espace pour Amazon, Amp avait besoin de données plus pertinentes pour éclairer son processus de prise de décision. Amp voulait une plate-forme de données et d'analyse évolutive pour permettre un accès facile aux données et effectuer des expériences d'apprentissage automatique (ML) pour la transcription audio en direct, la modération de contenu, l'ingénierie des fonctionnalités et un service de recommandation d'émissions personnelles, et pour inspecter ou mesurer les KPI et les métriques de l'entreprise.

Cet article est le premier d'une série en deux parties. La partie 1 montre comment les données ont été collectées et traitées à l'aide de la plate-forme de données et d'analyse, et Partie 2 montre comment les données ont été utilisées pour créer des recommandations d'émissions à l'aide Amazon Sage Maker, un service de ML entièrement géré. Le service de liste de recommandations d'émissions personnalisées a augmenté de 3 % les mesures d'engagement des clients suivies (comme aimer une émission, suivre un créateur ou activer les notifications d'émissions à venir) depuis son lancement en mai 2022.

Vue d'ensemble de la solution

Les sources de données pour Amp peuvent être globalement classées en flux (temps quasi réel) ou en lots (point dans le temps). Les données source sont émises à partir de systèmes appartenant à Amp ou d'autres systèmes Amazon. Les deux types de données différents sont les suivants :

• Streaming de données - Ce type de données se compose principalement de suivis, de notifications (concernant les amis des utilisateurs, les créateurs préférés ou les émissions), les mises à jour d'activité, les interactions d'émissions en direct (appels, co-hôtes, sondages, chat in-app), en temps réel mises à jour sur les activités d'émission en direct (nombre d'écoutes en direct, likes), mesures de lecture audio en direct et autres mesures de flux de clics de l'application Amp. Les parties prenantes d'Amp ont besoin de ces données pour alimenter les processus ML ou les modèles prédictifs, les outils de modération de contenu et les tableaux de bord des produits et programmes (par exemple, les émissions de tendances). Les données en streaming permettent aux clients d'Amp de mener et de mesurer des expérimentations.
• Données de lot – Ces données sont principalement constituées de données de catalogue, de métadonnées d'émission ou de créateur et de données de profil d'utilisateur. Les données par lots permettent davantage de rapports et d'analyses ponctuelles par rapport au temps réel.

Le schéma suivant illustre l'architecture de haut niveau.

La plate-forme de données et d'analyse Amp peut être décomposée en trois systèmes de haut niveau :

• Ingestion de données en continu, traitement et transformation de flux, et stockage de flux
• Ingestion de données par lots, traitement et transformation par lots et stockage par lots
• Intelligence d'affaires (BI) et analytique

Dans les sections suivantes, nous abordons chaque composant plus en détail.

Ingestion, traitement, transformation et stockage de données en continu

Amp a créé un pipeline d'ingestion de streaming sans serveur capable d'exploiter les données de sources sans avoir besoin de gestion d'infrastructure, comme illustré dans le schéma suivant.

Le pipeline a pu ingérer les données du catalogue d'émissions Amp (les émissions disponibles sur Amp) et les transmettre au lac de données pour deux cas d'utilisation différents : l'un pour l'analyse en temps quasi réel et l'autre pour l'analyse par lots.

Dans le cadre du pipeline d'ingestion, l'équipe Amp dispose d'un Service Amazon Simple Queue (Amazon SQS) file d'attente qui reçoit des messages d'un serveur en amont Service de notification simple d'Amazon (Amazon SNS) rubrique qui contient des informations sur les modifications apportées aux émissions dans le catalogue. Ces changements pourraient être l'ajout de nouveaux spectacles ou des ajustements à ceux déjà programmés.

Lorsque le message est reçu par la file d'attente SQS, il déclenche le AWS Lambda pour effectuer un appel API au service de catalogue Amp. La fonction Lambda récupère les métadonnées d'émission souhaitées, filtre les métadonnées, puis envoie les métadonnées de sortie à Flux de données Amazon Kinesis. Firehose de données Amazon Kinesis reçoit les enregistrements du flux de données. Kinesis Data Firehose appelle ensuite une fonction Lambda secondaire pour effectuer une transformation de données qui aplatit les enregistrements JSON reçus et écrit les enregistrements transformés dans un Service de stockage simple Amazon (Amazon S3) lac de données pour la consommation par les parties prenantes d'Amp.

Kinesis Data Firehose a activé la mise en mémoire tampon et l'écriture de données sur Amazon S3 toutes les 60 secondes. Cela a aidé les équipes Amp à prendre des décisions de programmation en temps quasi réel qui ont eu un impact sur les clients externes.

Le pipeline d'ingestion de flux a pris en charge les objectifs suivants : performances, disponibilité, évolutivité et flexibilité pour envoyer des données à plusieurs applications ou services en aval :

• Kinesis Data Streams gère l'ingestion de données en streaming si nécessaire. Kinesis Data Streams a soutenu ces objectifs en permettant à l'équipe Amp d'ingérer rapidement des données à des fins d'analyse avec une charge opérationnelle minimale. En tant que service entièrement géré, il a réduit les frais généraux opérationnels et Amp a pu évoluer avec les besoins du produit.
• Lambda a permis à l'équipe de créer des fonctions légères pour exécuter des appels d'API et effectuer des transformations de données.
• Étant donné que Kinesis Data Firehose est un service géré, il a été en mesure de gérer tous les besoins de mise à l'échelle, de partitionnement et de surveillance des données en streaming sans que l'équipe n'en entende plus.

Ingestion, traitement, transformation et stockage de données par lots

Amp a créé un pipeline d'ingestion par lots transitoire (instantané) capable d'ingérer, de traiter, de transformer et de stocker des données, comme illustré dans le schéma suivant.

Une approche de travail transitoire d'extraction, de transformation et de chargement (ETL) et d'extraction, de chargement et de transformation (ELT) a été mise en œuvre en raison de la nature par lots de ces charges de travail et des volumes de données inconnus. Dans le cadre de l'automatisation du workflow, Amazon SQS a été utilisé pour déclencher une fonction Lambda. La fonction Lambda a ensuite activé le robot d'exploration AWS Glue pour déduire le schéma et les types de données. L'analyseur a écrit les métadonnées du schéma dans le catalogue de données AWS Glue, fournissant un magasin de métadonnées unifié pour le partage des données.

Les travaux ETL et ELT devaient s'exécuter soit selon un calendrier défini, soit selon un flux de travail piloté par les événements. Pour répondre à ces besoins, Amp a utilisé Flux de travail gérés par Amazon pour Apache Airflow (Amazon MWAA). Apache Airflow est une plate-forme de gestion de flux de travail open source basée sur Python. Amazon MWAA est un service entièrement géré qui gère automatiquement la mise à l'échelle. Il fournit le séquencement, la gestion des erreurs, la logique de nouvelle tentative et l'état. Avec Amazon MWAA, Amp a pu tirer parti des avantages d'Airflow pour l'orchestration des tâches sans avoir à gérer ou à maintenir des serveurs Airflow dédiés. De plus, en utilisant Amazon MWAA, Amp a pu créer un référentiel de code et un pipeline de flux de travail stockés dans Amazon S3 auxquels Amazon MWAA pouvait accéder. Le pipeline a permis aux ingénieurs de données d'Amp de déployer facilement des DAG Airflow ou des scripts PySpark dans plusieurs environnements.

Ampli utilisé Amazon DME on Service Amazon Elastic Kubernetes (Amazon EKS) pour configurer et gérer des conteneurs pour leurs tâches de traitement et de transformation de données. En raison de la nature unique du service Amp, les volumes de données initialement prévus qui seraient traités étaient relativement inconnus. Pour offrir de la flexibilité au fur et à mesure de l'évolution du service, l'équipe a décidé d'utiliser Amazon EMR sur EKS afin d'éliminer tout bruit opérationnel inutile nécessaire pour démarrer et faire évoluer Amazon EMR pour le traitement des données. Cette approche leur a permis d'exécuter des clusters EMR hybrides transitoires soutenus par un mélange de AWSFargate et les Cloud de calcul élastique Amazon (Amazon EC2), où toutes les tâches et charges de travail du système ont été déchargées sur Fargate, tandis qu'Amazon EC2 a géré tout le traitement et la transformation d'Apache Spark. Cela offrait la flexibilité d'avoir un cluster avec un nœud en cours d'exécution, tandis que le scaler automatique Amazon EKS instanciait et démarrait dynamiquement tous les nœuds EC2 supplémentaires nécessaires pour la tâche. Une fois la tâche terminée, ils ont été automatiquement supprimés par l'autoscaler de cluster. Ce modèle a éliminé la nécessité pour l'équipe de gérer les actions d'amorçage du cluster ou la mise à l'échelle nécessaires pour répondre à l'évolution des charges de travail.

Amazon S3 a été utilisé comme lac de données central et les données ont été stockées au format Apache Parquet (Parquet). Parquet est un format en colonne qui accélère la récupération des données et assure une compression efficace des données. Amazon S3 a fourni la flexibilité, l'évolutivité et les besoins de sécurité d'Amp. Avec Amazon S3, l'équipe Amp a pu centraliser le stockage des données en un seul endroit et fédérer l'accès aux données virtuellement sur n'importe quel service ou outil à l'intérieur ou à l'extérieur d'AWS. Le lac de données a été divisé en deux compartiments S3 : un pour l'ingestion de données brutes et un pour la sortie de données transformées. Amazon EMR a effectué la transformation des données brutes en données transformées. Avec Amazon S3 comme lac de données central, Amp a pu exposer et partager en toute sécurité les données avec d'autres équipes d'Amp et d'Amazon.

Pour simplifier la définition des données, le provisionnement de l'accès aux tables et l'ajout et la suppression de tables, ils ont utilisé les robots d'exploration AWS Glue et le catalogue de données AWS Glue. Étant donné qu'Amp est un nouveau service en constante évolution, l'équipe avait besoin d'un moyen de définir, d'accéder et de gérer facilement les tables du lac de données. Les robots d'exploration géraient la définition des données (y compris les modifications de schéma) et l'ajout et la suppression de tables, tandis que le catalogue de données servait de magasin de métadonnées unifié.

Business intelligence et analytique

Le schéma suivant illustre l'architecture du composant BI et analytique.

Amp a choisi de stocker les données dans le lac de données S3, et non dans l'entrepôt de données. Cela leur a permis d'y accéder de manière unifiée via le catalogue de données AWS Glue et a fourni une plus grande flexibilité aux consommateurs de données. Cela s'est traduit par un accès plus rapide aux données sur une variété de services ou d'outils. Le stockage des données dans Amazon S3 a également réduit les coûts d'infrastructure de l'entrepôt de données, car les coûts sont fonction du type de calcul et de la quantité de données stockées.

Le Redshift d'Amazon Le type de nœud RA3 a été utilisé comme couche de calcul pour permettre aux parties prenantes d'interroger les données stockées dans Amazon S3. Les nœuds Amazon Redshift RA3 découplent le stockage et le calcul, et sont conçus pour un modèle d'accès via le catalogue de données AWS Glue. Les nœuds RA3 introduisent Amazon Redshift Managed Storage, qui est soutenu par Amazon S3. La combinaison de ces fonctionnalités a permis à Amp de dimensionner correctement les clusters et de fournir de meilleures performances de requête à ses clients tout en minimisant les coûts.

La configuration d'Amazon Redshift a été automatisée à l'aide d'une fonction Lambda, qui s'est connectée à un cluster donné et a exécuté des instructions SQL paramétrées. Les instructions SQL contenaient la logique de déploiement des schémas, des groupes d'utilisateurs et des utilisateurs, tandis que AWS Secrets Manager a été utilisé pour générer, stocker et faire pivoter automatiquement les mots de passe des utilisateurs d'Amazon Redshift. Les variables de configuration sous-jacentes ont été stockées dans Amazon DynamoDB. La fonction Lambda a récupéré les variables et demandé des informations d'identification Amazon Redshift temporaires pour effectuer la configuration. Ce processus a permis à l'équipe Amp de configurer des clusters Amazon Redshift de manière cohérente.

Résultats commerciaux

Amp a pu obtenir les résultats commerciaux suivants :

• Rapports d'activité – Rapports standard requis pour gérer l'entreprise, tels que des rapports flash quotidiens, des mécanismes d'examen d'entreprise agrégés ou des mises à jour de projets et de programmes.
• Rapports sur les produits – Rapports spécifiques requis pour permettre l'inspection ou la mesure des principaux KPI et métriques du produit. Cela comprenait des rapports visuels via des tableaux de bord tels que l'efficacité de la promotion marketing, les mesures d'engagement des applications et les émissions de tendances.
• Expérimentation ML – Permettre aux équipes Amazon en aval d'utiliser ces données pour soutenir l'expérimentation ou générer des prédictions et des recommandations. Par exemple, des expérimentations ML telles qu'une liste personnalisée de recommandations d'émissions, la catégorisation d'émissions et la modération de contenu ont contribué à la fidélisation des utilisateurs d'Amp.

Principaux avantages

En mettant en œuvre une architecture évolutive et rentable, Amp a pu obtenir les résultats suivants :

• Complexité opérationnelle limitée – Ils ont construit un système flexible qui a utilisé les services gérés AWS dans la mesure du possible.
• Utiliser les langages des données – Amp a pu prendre en charge les deux langages de manipulation de données les plus courants, Python et SQL, pour effectuer des opérations de plateforme, mener des expériences de ML et générer des analyses. Grâce à ce support, les développeurs d'Amp ont pu utiliser des langages avec lesquels ils étaient familiers.
• Permettre l'expérimentation et la mesure – Amp a permis aux développeurs de générer rapidement les ensembles de données nécessaires pour mener des expériences et mesurer les résultats. Cela aide à optimiser l'expérience client Amp.
• Construire pour apprendre mais concevoir à l'échelle – Amp est un nouveau produit qui trouve son marché et a pu concentrer son énergie initiale sur la création de suffisamment de fonctionnalités pour obtenir des commentaires. Cela leur a permis de pivoter vers le marché de produits adapté à chaque lancement. Ils ont pu construire progressivement, mais planifier à long terme.

Conclusion

Dans cet article, nous avons vu comment Amp a créé sa plate-forme d'analyse de données à l'aide de données comportementales des utilisateurs provenant de sources de données en continu et par lots. Les facteurs clés qui ont motivé la mise en œuvre étaient la nécessité de fournir une plate-forme d'analyse de données flexible, évolutive, rentable et efficace en termes d'efforts. Des choix de conception ont été faits en évaluant divers services AWS.

Partie 2 de cette série montre comment nous avons utilisé ces données et créé la liste personnalisée de recommandations d'émissions à l'aide de SageMaker.

Comme prochaines étapes, nous vous recommandons d'approfondir chaque étape de votre système de pipeline de données et de faire des choix de conception qui seraient rentables et évolutifs pour vos besoins. Pour plus d'informations, vous pouvez également consulter d'autres cas d'utilisation client dans le Blog d'analyse AWS.

Si vous avez des commentaires sur cet article, soumettez-les dans la section des commentaires.

---

À propos des auteurs

Tulipe Gupta est architecte de solutions chez Amazon Web Services. Elle travaille avec Amazon pour concevoir, créer et déployer des solutions technologiques sur AWS. Elle aide les clients à adopter les meilleures pratiques lors du déploiement de la solution dans AWS, et est une passionnée d'analyse et de ML. Dans ses temps libres, elle aime nager, faire de la randonnée et jouer à des jeux de société.

David Kuo est architecte de solutions chez Amazon Web Services. Il travaille avec les clients d'AWS pour concevoir, créer et déployer des solutions technologiques sur AWS. Il travaille avec des clients des médias et du divertissement et s'intéresse aux technologies d'apprentissage automatique. Dans ses temps libres, il se demande ce qu'il devrait faire de son temps libre.

Manolya McCormick est un ingénieur en développement logiciel senior pour Amp sur Amazon. Elle conçoit et construit des systèmes distribués à l'aide d'AWS pour servir les applications destinées aux clients. Elle aime lire et cuisiner de nouvelles recettes pendant son temps libre.

Jeff Christopherson est un ingénieur principal des données pour Amp sur Amazon. Il travaille à la conception, à la construction et au déploiement de solutions Big Data sur AWS qui génèrent des informations exploitables. Il accompagne les équipes internes dans l'adoption de solutions évolutives et automatisées, et est un passionné d'Analytics et de Big Data. Dans ses temps libres, lorsqu'il n'est pas sur une paire de skis, vous pouvez le trouver sur son VTT.