Wie Amp auf Amazon Daten nutzte, um die Kundenbindung zu steigern, Teil 1: Aufbau einer Datenanalyseplattform

Ampere, die neue Live-Radio-App von Amazon, ist eine Neuerfindung des Radios mit von Menschen kuratierten Live-Audioshows. Es wurde entwickelt, um Zuhörern und Schöpfern ein nahtloses Kundenerlebnis zu bieten, indem es erstmals interaktive Live-Audioshows von Ihren Lieblingskünstlern, Radio-DJs, Podcastern und Freunden präsentiert.

Als neues Produkt in einem neuen Bereich für Amazon benötigte Amp jedoch relevantere Daten, um seinen Entscheidungsprozess zu informieren. Amp wollte eine skalierbare Daten- und Analyseplattform, um einen einfachen Zugriff auf Daten zu ermöglichen und Machine-Leaning-Experimente (ML) für Live-Audiotranskription, Inhaltsmoderation, Feature-Engineering und einen persönlichen Show-Empfehlungsdienst durchzuführen und Geschäfts-KPIs und -Metriken zu überprüfen oder zu messen.

Dieser Beitrag ist der erste einer zweiteiligen Serie. Teil 1 zeigt, wie Daten mithilfe der Daten- und Analyseplattform gesammelt und verarbeitet wurden, und Teil 2 zeigt, wie die Daten verwendet wurden, um Show-Empfehlungen zu erstellen Amazon Sage Maker, ein vollständig verwalteter ML-Dienst. Der personalisierte Show-Empfehlungslistendienst hat seit seiner Einführung im Mai 3 einen Anstieg der erfassten Kundenbindungsmetriken (z. B. das Liken einer Show, das Folgen eines Creators oder das Aktivieren von Benachrichtigungen über bevorstehende Shows) um 2022 % verzeichnet.

Lösungsüberblick

Die Datenquellen für Amp können allgemein entweder als Streaming (Fast-Echtzeit) oder Batch (Zeitpunkt) kategorisiert werden. Die Quelldaten werden von Amp-eigenen Systemen oder anderen Amazon-Systemen ausgegeben. Die beiden unterschiedlichen Datentypen sind wie folgt:

• Daten streamen – Diese Art von Daten besteht hauptsächlich aus Follows, Benachrichtigungen (in Bezug auf die Freunde der Benutzer, Lieblingsschöpfer oder Shows), Aktivitätsaktualisierungen, Live-Show-Interaktionen (Call-Ins, Co-Hosts, Umfragen, In-App-Chat), Echtzeit Updates zu Live-Show-Aktivitäten (Anzahl der Live-Hörer, Likes), Live-Audio-Wiedergabemetriken und andere Clickstream-Metriken aus der Amp-Anwendung. Amp-Stakeholder benötigen diese Daten, um ML-Prozesse oder Vorhersagemodelle, Tools zur Moderation von Inhalten sowie Produkt- und Programm-Dashboards (z. B. Trendshows) zu unterstützen. Streaming-Daten ermöglichen es Amp-Kunden, Experimente durchzuführen und zu messen.
• Chargendaten – Diese Daten bestehen hauptsächlich aus Katalogdaten, Show- oder Creator-Metadaten und Benutzerprofildaten. Batch-Daten ermöglichen mehr Point-in-Time-Berichte und -Analysen als Echtzeit.

Das folgende Diagramm veranschaulicht die High-Level-Architektur.

Die Daten- und Analyseplattform von Amp kann in drei übergeordnete Systeme unterteilt werden:

• Aufnahme von Streaming-Daten, Stream-Verarbeitung und -Transformation sowie Stream-Speicherung
• Batch-Datenerfassung, Batch-Verarbeitung und -Umwandlung sowie Batch-Speicherung
• Business Intelligence (BI) und Analytik

In den folgenden Abschnitten besprechen wir jede Komponente ausführlicher.

Aufnahme, Verarbeitung, Transformation und Speicherung von Streaming-Daten

Amp hat eine serverlose Streaming-Ingestion-Pipeline erstellt, die in der Lage ist, Daten aus Quellen anzuzapfen, ohne dass eine Infrastrukturverwaltung erforderlich ist, wie im folgenden Diagramm dargestellt.

Die Pipeline konnte die Amp-Show-Katalogdaten (welche Shows sind auf Amp verfügbar) aufnehmen und für zwei verschiedene Anwendungsfälle an den Data Lake weiterleiten: einen für Analysen in nahezu Echtzeit und einen für Batch-Analysen.

Als Teil der Aufnahmepipeline verfügt das Amp-Team über eine Amazon Simple Queue-Dienst (Amazon SQS)-Warteschlange, die Nachrichten von einem Upstream empfängt Amazon Simple Notification Service (Amazon SNS) Thema, das Informationen zu Änderungen an Shows im Katalog enthält. Diese Änderungen können das Hinzufügen neuer Shows oder Anpassungen bestehender Shows sein, die geplant wurden.

Wenn die Nachricht von der SQS-Warteschlange empfangen wird, löst sie die aus AWS Lambda -Funktion, um einen API-Aufruf an den Amp-Katalogdienst zu tätigen. Die Lambda-Funktion ruft die gewünschten Show-Metadaten ab, filtert die Metadaten und sendet dann die Ausgabe-Metadaten an Amazon Kinesis-Datenströme. Amazon Kinesis Data Firehose erhält die Datensätze aus dem Datenstrom. Kinesis Data Firehose ruft dann eine sekundäre Lambda-Funktion auf, um eine Datentransformation durchzuführen, die die empfangenen JSON-Datensätze vereinfacht und die transformierten Datensätze in eine schreibt Amazon Simple Storage-Service (Amazon S3) Data Lake zur Nutzung durch Amp-Stakeholder.

Kinesis Data Firehose ermöglichte das Puffern und Schreiben von Daten in Amazon S3 alle 60 Sekunden. Dies half den Amp-Teams, Programmierentscheidungen nahezu in Echtzeit zu treffen, die sich auf externe Kunden auswirkten.

Die Streaming-Erfassungspipeline unterstützte die folgenden Ziele: Leistung, Verfügbarkeit, Skalierbarkeit und Flexibilität, um Daten an mehrere nachgelagerte Anwendungen oder Dienste zu senden:

• Kinesis Data Streams übernimmt bei Bedarf die Aufnahme von Streaming-Daten. Kinesis Data Streams unterstützte diese Ziele, indem es dem Amp-Team ermöglichte, schnell Daten für Analysen mit minimaler Betriebslast aufzunehmen. Als vollständig verwalteter Service reduzierte es den Betriebsaufwand und Amp konnte mit den Produktanforderungen skalieren.
• Lambda ermöglichte es dem Team, einfache Funktionen zu erstellen, um API-Aufrufe auszuführen und Datentransformationen durchzuführen.
• Da es sich bei Kinesis Data Firehose um einen Managed Service handelt, konnte es alle Skalierungs-, Sharding- und Überwachungsanforderungen der Streaming-Daten bewältigen, ohne dass das Team zusätzlich belauscht werden musste.

Batch-Datenerfassung, -verarbeitung, -transformation und -speicherung

Amp hat eine transiente Batch-Ingestion-Pipeline (Point-in-Time) erstellt, die Daten aufnehmen, verarbeiten, umwandeln und speichern kann, wie im folgenden Diagramm dargestellt.

Aufgrund der Stapelnatur dieser Workloads und unbekannter Datenmengen wurde ein transienter Ansatz zum Extrahieren, Transformieren und Laden (ETL) und zum Extrahieren, Laden und Transformieren (ELT) implementiert. Als Teil der Workflow-Automatisierung wurde Amazon SQS verwendet, um eine Lambda-Funktion auszulösen. Die Lambda-Funktion aktivierte dann den AWS Glue-Crawler, um das Schema und die Datentypen abzuleiten. Der Crawler schrieb die Schema-Metadaten in den AWS Glue-Datenkatalog und stellte so einen einheitlichen Metadatenspeicher für die gemeinsame Nutzung von Daten bereit.

Die ETL- und ELT-Jobs mussten entweder nach einem festgelegten Zeitplan oder einem ereignisgesteuerten Workflow ausgeführt werden. Um diese Anforderungen zu erfüllen, wurde Amp verwendet Von Amazon verwaltete Workflows für Apache Airflow (Amazon MWAA). Apache Airflow ist eine Python-basierte Open-Source-Workflow-Management-Plattform. Amazon MWAA ist ein vollständig verwalteter Service, der die Skalierung automatisch übernimmt. Es bietet Sequenzierung, Fehlerbehandlung, Wiederholungslogik und Status. Mit Amazon MWAA konnte Amp die Vorteile von Airflow für die Job-Orchestrierung nutzen, ohne dedizierte Airflow-Server verwalten oder warten zu müssen. Darüber hinaus konnte Amp durch die Verwendung von Amazon MWAA ein Code-Repository und eine Workflow-Pipeline erstellen, die in Amazon S3 gespeichert sind und auf die Amazon MWAA zugreifen kann. Die Pipeline ermöglichte es den Amp-Dateningenieuren, Airflow-DAGs oder PySpark-Skripte problemlos in mehreren Umgebungen bereitzustellen.

Verstärker gebraucht Amazon EMR on Amazon Elastic Kubernetes-Service (Amazon EKS) zur Konfiguration und Verwaltung von Containern für ihre Datenverarbeitungs- und Transformationsaufgaben. Aufgrund der Einzigartigkeit des Amp-Dienstes waren die ursprünglich zu erwartenden Datenmengen, die verarbeitet werden würden, relativ unbekannt. Um bei der Weiterentwicklung des Dienstes Flexibilität zu bieten, entschied sich das Team für Amazon EMR auf EKS, um unnötige operative Überhörungen zu eliminieren, die für das Bootstrapping und Skalieren von Amazon EMR für die Datenverarbeitung erforderlich sind. Dieser Ansatz ermöglichte es ihnen, transiente hybride EMR-Cluster auszuführen, die durch eine Mischung aus unterstützt wurden AWS Fargate und Amazon Elastic Compute-Cloud (Amazon EC2)-Knoten, bei denen alle Systemaufgaben und Workloads an Fargate ausgelagert wurden, während Amazon EC2 die gesamte Apache Spark-Verarbeitung und -Transformation übernahm. Dies bot die Flexibilität, einen Cluster mit einem laufenden Knoten zu haben, während der Amazon EKS-Autoscaler alle zusätzlichen EC2-Knoten, die für den Job erforderlich waren, dynamisch instanziiert und gebootstrapped hat. Nach Abschluss des Auftrags wurden sie automatisch vom Cluster Auto Scaler gelöscht. Dieses Muster beseitigte die Notwendigkeit für das Team, die Cluster-Bootstrap-Aktionen oder die Skalierung zu verwalten, die erforderlich sind, um auf sich entwickelnde Workloads zu reagieren.

Als zentraler Data Lake wurde Amazon S3 verwendet und die Daten im Apache Parquet (Parquet)-Format gespeichert. Parquet ist ein Spaltenformat, das den Datenabruf beschleunigt und eine effiziente Datenkomprimierung bietet. Amazon S3 stellte die Flexibilität, Skalierbarkeit und Sicherheitsanforderungen für Amp bereit. Mit Amazon S3 war das Amp-Team in der Lage, die Datenspeicherung an einem Ort zu zentralisieren und den Zugriff auf die Daten praktisch über jeden Dienst oder jedes Tool innerhalb oder außerhalb von AWS zu föderieren. Der Data Lake wurde in zwei S3-Buckets aufgeteilt: einen für die Aufnahme von Rohdaten und einen für die Ausgabe transformierter Daten. Amazon EMR führte die Transformation von Rohdaten in transformierte Daten durch. Mit Amazon S3 als zentralem Data Lake war Amp in der Lage, die Daten sicher bereitzustellen und mit anderen Teams in Amp und Amazon zu teilen.

Um die Datendefinition, die Bereitstellung des Tabellenzugriffs und das Hinzufügen und Entfernen von Tabellen zu vereinfachen, nutzten sie AWS Glue-Crawler und den AWS Glue-Datenkatalog. Da Amp ein neuer Dienst ist und sich ständig weiterentwickelt, benötigte das Team eine Möglichkeit, die Tabellen im Data Lake einfach zu definieren, darauf zuzugreifen und sie zu verwalten. Die Crawler handhabten die Datendefinition (einschließlich Schemaänderungen) und das Hinzufügen und Entfernen von Tabellen, während der Datenkatalog als einheitlicher Metadatenspeicher diente.

Business Intelligence und Analytik

Das folgende Diagramm veranschaulicht die Architektur für die BI- und Analysekomponente.

Amp entschied sich dafür, die Daten im S3 Data Lake und nicht im Data Warehouse zu speichern. Dies ermöglichte ihnen einen einheitlichen Zugriff über den AWS Glue-Datenkatalog und bot den Datenkonsumenten mehr Flexibilität. Dies führte zu einem schnelleren Datenzugriff über eine Vielzahl von Diensten oder Tools hinweg. Da die Daten in Amazon S3 gespeichert werden, wurden auch die Kosten für die Data-Warehouse-Infrastruktur gesenkt, da die Kosten eine Funktion des Rechentyps und der Menge der gespeicherten Daten sind.

Das Amazon RedShift Der Knotentyp RA3 wurde als Rechenschicht verwendet, um es Stakeholdern zu ermöglichen, in Amazon S3 gespeicherte Daten abzufragen. Amazon Redshift RA3-Knoten entkoppeln Speicher und Rechenleistung und sind für ein Zugriffsmuster über den AWS Glue-Datenkatalog konzipiert. RA3-Knoten führen Amazon Redshift Managed Storage ein, das von Amazon S3 unterstützt wird. Die Kombination dieser Funktionen ermöglichte es Amp, die Cluster richtig zu dimensionieren und seinen Kunden eine bessere Abfrageleistung bei gleichzeitiger Minimierung der Kosten zu bieten.

Die Amazon Redshift-Konfiguration wurde mithilfe einer Lambda-Funktion automatisiert, die eine Verbindung zu einem bestimmten Cluster herstellte und parametrisierte SQL-Anweisungen ausführte. Die SQL-Anweisungen enthielten die Logik zum Bereitstellen von Schemas, Benutzergruppen und Benutzern, während AWS Secrets Manager wurde verwendet, um Amazon Redshift-Benutzerkennwörter automatisch zu generieren, zu speichern und zu rotieren. Die zugrunde liegenden Konfigurationsvariablen wurden in gespeichert Amazon DynamoDB. Die Lambda-Funktion hat die Variablen abgerufen und temporäre Amazon Redshift-Anmeldeinformationen angefordert, um die Konfiguration durchzuführen. Dieser Prozess ermöglichte es dem Amp-Team, Amazon Redshift-Cluster auf konsistente Weise einzurichten.

Geschäftsergebnisse

Amp konnte die folgenden Geschäftsergebnisse erzielen:

• Geschäftsberichterstattung – Standardberichte, die für den Geschäftsbetrieb erforderlich sind, wie z. B. tägliche Flash-Berichte, aggregierte Geschäftsüberprüfungsmechanismen oder Projekt- und Programmaktualisierungen.
• Produktberichterstattung – Spezifische Berichterstattung erforderlich, um die Überprüfung oder Messung wichtiger Produkt-KPIs und -Metriken zu ermöglichen. Dazu gehörten visuelle Berichte über Dashboards wie die Effektivität von Marketingaktionen, Metriken zum App-Engagement und Trendshows.
• ML-Experimente – Befähigung nachgelagerter Amazon-Teams, diese Daten zur Unterstützung von Experimenten zu verwenden oder Vorhersagen und Empfehlungen zu generieren. Beispielsweise halfen ML-Experimente wie eine personalisierte Empfehlungsliste für Sendungen, die Kategorisierung von Sendungen und die Moderation von Inhalten bei der Benutzerbindung von Amp.

Ihre Vorteile:

Durch die Implementierung einer skalierbaren, kosteneffizienten Architektur konnte Amp Folgendes erreichen:

• Begrenzte betriebliche Komplexität – Sie haben ein flexibles System aufgebaut, das wo immer möglich AWS Managed Services nutzte.
• Verwenden Sie die Sprachen der Daten – Amp konnte die beiden gängigsten Datenmanipulationssprachen Python und SQL unterstützen, um Plattformoperationen durchzuführen, ML-Experimente durchzuführen und Analysen zu generieren. Mit dieser Unterstützung konnten die Entwickler von Amp Sprachen verwenden, mit denen sie vertraut waren.
• Ermöglichen Sie Experimente und Messungen – Amp ermöglichte es Entwicklern, schnell die Datensätze zu generieren, die für die Durchführung von Experimenten und die Messung der Ergebnisse erforderlich sind. Dies hilft bei der Optimierung des Amp-Kundenerlebnisses.
• Bauen Sie, um zu lernen, aber entwerfen Sie maßstabsgetreu – Amp ist ein neues Produkt, das seine Markttauglichkeit findet, und konnte seine anfängliche Energie darauf konzentrieren, gerade genug Funktionen zu entwickeln, um Feedback zu erhalten. Dies ermöglichte es ihnen, sich bei jeder Markteinführung auf den richtigen Produktmarkt zu konzentrieren. Sie konnten schrittweise bauen, aber langfristig planen.

Zusammenfassung

In diesem Beitrag haben wir gesehen, wie Amp seine Datenanalyseplattform mithilfe von Benutzerverhaltensdaten aus Streaming- und Batch-Datenquellen erstellt hat. Die Schlüsselfaktoren, die die Implementierung vorangetrieben haben, waren die Notwendigkeit, eine flexible, skalierbare, kosteneffiziente und aufwandseffiziente Datenanalyseplattform bereitzustellen. Es wurden Designentscheidungen getroffen, um verschiedene AWS-Services zu bewerten.

Teil 2 dieser Serie zeigt, wie wir diese Daten verwendet und die personalisierte Show-Empfehlungsliste mit SageMaker erstellt haben.

Als nächste Schritte empfehlen wir, sich intensiv mit jeder Phase Ihres Datenpipelinesystems auseinanderzusetzen und Designentscheidungen zu treffen, die für Ihre Anforderungen kostengünstig und skalierbar sind. Weitere Informationen finden Sie auch in anderen Anwendungsfällen von Kunden AWS Analytics-Blog.

Wenn Sie Feedback zu diesem Beitrag haben, senden Sie es im Kommentarbereich.

---

Über die Autoren

Tulpe Gupta ist Lösungsarchitekt bei Amazon Web Services. Sie arbeitet mit Amazon zusammen, um Technologielösungen auf AWS zu entwerfen, zu erstellen und bereitzustellen. Sie unterstützt Kunden bei der Übernahme von Best Practices bei der Bereitstellung von Lösungen in AWS und ist eine begeisterte Analytikerin und ML-Expertin. In ihrer Freizeit geht sie gerne schwimmen, wandert und spielt Gesellschaftsspiele.

David Kuo ist Lösungsarchitekt bei Amazon Web Services. Er arbeitet mit AWS-Kunden zusammen, um Technologielösungen auf AWS zu entwerfen, zu erstellen und bereitzustellen. Er arbeitet mit Kunden aus der Medien- und Unterhaltungsbranche zusammen und interessiert sich für maschinelle Lerntechnologien. In seiner Freizeit fragt er sich, was er mit seiner Freizeit anfangen soll.

Manolya McCormick ist Senior Software Development Engineer für Amp bei Amazon. Sie entwirft und baut verteilte Systeme mit AWS, um kundenorientierte Anwendungen zu bedienen. In ihrer Freizeit liest und kocht sie gerne neue Rezepte.

Jeff Christophersen ist Senior Data Engineer für Amp bei Amazon. Er arbeitet an der Entwicklung, Erstellung und Bereitstellung von Big-Data-Lösungen auf AWS, die umsetzbare Erkenntnisse liefern. Er unterstützt interne Teams bei der Einführung skalierbarer und automatisierter Lösungen und ist ein begeisterter Analytiker und Big Data-Enthusiast. In seiner Freizeit, wenn er nicht auf den Skiern steht, findet man ihn auf seinem Mountainbike.