Hvordan Amp på Amazon brugte data til at øge kundeengagementet, del 1: Opbygning af en dataanalyseplatform

amp, den nye live radio-app fra Amazon, er en genopfindelse af radio med menneske-kurateret live-lydshows. Det er designet til at give en problemfri kundeoplevelse til lyttere og skabere ved at debutere interaktive live-lydshows fra dine yndlingskunstnere, radio-dj's, podcastere og venner.

Men som et nyt produkt i et nyt rum for Amazon havde Amp brug for mere relevante data for at informere deres beslutningsproces. Amp ønskede en skalerbar data- og analyseplatform, der muliggør nem adgang til data og udfører ML-eksperimenter (machine leaning) til live lydtransskription, indholdsmoderering, feature engineering og en personlig showanbefalingstjeneste og til at inspicere eller måle forretnings-KPI'er og metrics.

Dette indlæg er det første i en todelt serie. Del 1 viser, hvordan data blev indsamlet og behandlet ved hjælp af data- og analyseplatformen, og del 2 viser, hvordan dataene blev brugt til at oprette showanbefalinger vha Amazon SageMaker, en fuldt administreret ML-tjeneste. Tjenesten med personligt tilpasset showanbefalingsliste har vist et 3 % boost til kundeengagement-målinger, der er sporet (såsom at kunne lide et show, følge en skaber eller aktivere kommende shownotifikationer) siden lanceringen i maj 2022.

Løsningsoversigt

Datakilderne til Amp kan bredt kategoriseres som enten streaming (næsten i realtid) eller batch (tidspunkt). Kildedataene udsendes fra Amp-ejede systemer eller andre Amazon-systemer. De to forskellige datatyper er som følger:

• Streaming af data – Denne type data består hovedsageligt af følger, notifikationer (vedrørende brugeres venner, yndlingsskabere eller shows), aktivitetsopdateringer, liveshow-interaktioner (opkald, co-værter, afstemninger, chat i appen), realtid opdateringer om live-show-aktiviteter (live-lyttetal, likes), live-lydafspilningsmålinger og andre klikstream-metrics fra Amp-applikationen. Amp-interessenter kræver disse data for at drive ML-processer eller forudsigelige modeller, indholdsmodereringsværktøjer og produkt- og programdashboards (f.eks. trendingshows). Streaming af data gør det muligt for Amp-kunder at udføre og måle eksperimenter.
• Batch data – Disse data består hovedsageligt af katalogdata, show- eller skabermetadata og brugerprofildata. Batchdata muliggør mere punkt-i-tid rapportering og analyser i forhold til realtid.

Følgende diagram illustrerer højniveauarkitekturen.

Amp data- og analyseplatformen kan opdeles i tre systemer på højt niveau:

• Streamingdataindtagelse, streambehandling og transformation og streamlagring
• Batchdataindtagelse, batchbehandling og -transformation og batchlagring
• Business intelligence (BI) og analyse

I de følgende afsnit diskuterer vi hver komponent mere detaljeret.

Streaming af dataindtagelse, behandling, transformation og lagring

Amp oprettede en serverløs streaming-indtagelsespipeline, der var i stand til at udnytte data fra kilder uden behov for infrastrukturstyring, som vist i følgende diagram.

Pipelinen var i stand til at indtage Amp-show-katalogdataene (hvilke shows er tilgængelige på Amp) og videregive dem til datasøen til to forskellige brugssager: en til næsten-realtidsanalyse og en til batchanalyse.

Som en del af indtagelsespipelinen har Amp-teamet en Amazon Simple Queue Service (Amazon SQS) kø, der modtager beskeder fra en upstream Amazon Simple Notification Service (Amazon SNS) emne, der indeholder oplysninger om ændringer af shows i kataloget. Disse ændringer kan være tilføjelse af nye shows eller justeringer af eksisterende, der er planlagt.

Når beskeden modtages af SQS-køen, udløser den AWS Lambda funktion til at foretage et API-kald til Amp-katalogtjenesten. Lambda-funktionen henter de ønskede show-metadata, filtrerer metadataene og sender derefter outputmetadataene til Amazon Kinesis datastrømme. Amazon Kinesis Data Firehose modtager registreringerne fra datastrømmen. Kinesis Data Firehose kalder derefter en sekundær Lambda-funktion til at udføre en datatransformation, der udjævner de modtagne JSON-poster og skriver de transformerede poster til en Amazon Simple Storage Service (Amazon S3) datasø til forbrug af Amp-interessenter.

Kinesis Data Firehose aktiverede buffering og skrivning af data til Amazon S3 hvert 60. sekund. Dette hjalp Amp-teams med at træffe beslutninger om programmering i næsten realtid, som påvirkede eksterne kunder.

Streaming-optagelsespipelinen understøttede følgende mål: ydeevne, tilgængelighed, skalerbarhed og fleksibilitet til at sende data til flere downstream-applikationer eller tjenester:

• Kinesis Data Streams håndterer streamingdataindtagelse, når det er nødvendigt. Kinesis Data Streams understøttede disse mål ved at gøre Amp-teamet i stand til hurtigt at indtage data til analyser med minimal driftsbelastning. Som en fuldt administreret service reducerede den driftsomkostningerne, og Amp var i stand til at skalere med produktbehovene.
• Lambda gjorde det muligt for teamet at skabe letvægtsfunktioner til at køre API-kald og udføre datatransformationer.
• Fordi Kinesis Data Firehose er en administreret tjeneste, var den i stand til at håndtere alle skalerings-, sønderdelings- og overvågningsbehovene for streamingdataene uden yderligere overhøring for teamet.

Batchdataindtagelse, behandling, transformation og lagring

Amp skabte en transient batch (tidpunkt) indtagelsespipeline, der er i stand til dataindtagelse, behandling og transformation og lagring, som vist i følgende diagram.

En transient extract, transform and load (ETL) og extract, load, and transform (ELT) jobtilgang blev implementeret på grund af batch-karakteren af ​​disse arbejdsbelastninger og ukendte datamængder. Som en del af workflowautomatiseringen blev Amazon SQS brugt til at udløse en Lambda-funktion. Lambda-funktionen aktiverede derefter AWS Glue-crawleren for at udlede skemaet og datatyperne. Crawleren skrev skemaets metadata til AWS Glue Data Catalog, hvilket gav et samlet metadatalager til datadeling.

ETL- og ELT-jobbene skulle køre på enten en fastsat tidsplan eller hændelsesdrevet arbejdsgang. For at håndtere disse behov brugte Amp Amazon administrerede arbejdsgange til Apache Airflow (Amazon MWAA). Apache Airflow er en open source Python-baseret workflow management platform. Amazon MWAA er en fuldt administreret tjeneste, der automatisk håndterer skalering. Det giver sekvensering, fejlhåndtering, genforsøgslogik og tilstand. Med Amazon MWAA var Amp i stand til at drage fordel af fordelene ved Airflow til joborkestrering uden at skulle administrere eller vedligeholde dedikerede Airflow-servere. Derudover var Amp ved at bruge Amazon MWAA i stand til at oprette et kodelager og workflow-pipeline gemt i Amazon S3, som Amazon MWAA kunne få adgang til. Pipelinen gjorde det muligt for Amp-dataingeniører nemt at implementere Airflow DAG'er eller PySpark-scripts på tværs af flere miljøer.

Amp brugt Amazon EMR on Amazon Elastic Kubernetes Service (Amazon EKS) til at konfigurere og administrere containere til deres databehandlings- og transformationsjob. På grund af Amp-tjenestens unikke karakter var de oprindelige forventede datamængder, der ville blive behandlet, relativt ukendte. For at give fleksibilitet efterhånden som tjenesten udviklede sig, besluttede teamet at gå med Amazon EMR på EKS for at eliminere enhver unødvendig operationel overhøring, der kræves for at bootstrap og skalere Amazon EMR til databehandling. Denne tilgang tillod dem at køre forbigående hybrid EMR-klynger understøttet af en blanding af AWS Fargate , Amazon Elastic Compute Cloud (Amazon EC2) noder, hvor alle systemopgaver og arbejdsbelastninger blev overført til Fargate, mens Amazon EC2 håndterede al Apache Spark-behandling og transformation. Dette gav fleksibiliteten til at have en klynge med én node kørende, mens Amazon EKS auto scaler dynamisk instantierede og bootstrappede eventuelle yderligere EC2 noder, der var nødvendige til jobbet. Da jobbet var færdigt, blev de automatisk slettet af klyngens automatiske skalering. Dette mønster eliminerede behovet for, at teamet skulle administrere nogen af ​​de klynge-bootstrap-handlinger eller skalering, der kræves for at reagere på skiftende arbejdsbelastninger.

Amazon S3 blev brugt som den centrale datasø, og data blev gemt i Apache Parquet (Parquet) format. Parket er et søjleformet format, som fremskynder datahentning og giver effektiv datakomprimering. Amazon S3 leverede fleksibiliteten, skalerbarheden og sikkerhedsbehovene til Amp. Med Amazon S3 var Amp-teamet i stand til at centralisere datalagring på ét sted og samle adgang til dataene på tværs af næsten enhver tjeneste eller værktøj inden for eller uden for AWS. Datasøen blev opdelt i to S3 buckets: en til rådataindtagelse og en til transformeret dataoutput. Amazon EMR udførte transformationen fra rådata til transformerede data. Med Amazon S3 som den centrale datasø var Amp i stand til sikkert at eksponere og dele dataene med andre teams på tværs af Amp og Amazon.

For at forenkle datadefinition, klargøring af tabeladgang og tilføjelse og fjernelse af tabeller brugte de AWS Glue-crawlere og AWS Glue Data Catalog. Fordi Amp er en ny tjeneste og i konstant udvikling, havde teamet brug for en måde at nemt definere, få adgang til og administrere tabellerne i datasøen. Crawlerne håndterede datadefinition (herunder skemaændringer) og tilføjelse og fjernelse af tabeller, mens datakataloget fungerede som et samlet metadatalager.

Business intelligence og analyse

Følgende diagram illustrerer arkitekturen for BI- og analysekomponenten.

Amp valgte at gemme dataene i S3 datasøen, og ikke i datavarehuset. Dette gjorde det muligt for dem at få adgang til det på en samlet måde gennem AWS Glue Data Catalog og gav større fleksibilitet for dataforbrugere. Dette resulterede i hurtigere dataadgang på tværs af en række tjenester eller værktøjer. Da data blev lagret i Amazon S3, reducerede det også omkostningerne til datavarehusinfrastrukturen, fordi omkostningerne er en funktion af computertypen og mængden af ​​lagrede data.

Amazon rødforskydning RA3-nodetype blev brugt som beregningslag for at gøre det muligt for interessenter at forespørge data gemt i Amazon S3. Amazon Redshift RA3-noder afkobler lagring og beregning og er designet til et adgangsmønster gennem AWS Glue Data Catalog. RA3-noder introducerer Amazon Redshift Managed Storage, som er Amazon S3-støttet. Kombinationen af ​​disse funktioner gjorde det muligt for Amp at tilpasse klyngerne i den rigtige størrelse og give deres kunder bedre forespørgselsydeevne og samtidig minimere omkostningerne.

Amazon Redshift-konfiguration blev automatiseret ved hjælp af en Lambda-funktion, som koblede til en given klynge og kørte parameteriserede SQL-sætninger. SQL-sætningerne indeholdt logikken til at implementere skemaer, brugergrupper og brugere, mens AWS Secrets Manager blev brugt til automatisk at generere, gemme og rotere Amazon Redshift-brugeradgangskoder. De underliggende konfigurationsvariabler blev gemt i Amazon DynamoDB. Lambda-funktionen hentede variablerne og anmodede om midlertidige Amazon Redshift-legitimationsoplysninger for at udføre konfigurationen. Denne proces gjorde det muligt for Amp-teamet at opsætte Amazon Redshift-klynger på en ensartet måde.

Forretningsmæssige resultater

Amp var i stand til at opnå følgende forretningsresultater:

• Forretningsrapportering – Standardrapportering, der kræves for at drive virksomheden, såsom daglige flash-rapporter, aggregerede virksomhedsgennemgange eller projekt- og programopdateringer.
• Produktrapportering – Specifik rapportering påkrævet for at muliggøre inspektion eller måling af nøgleprodukt-KPI'er og -metrics. Dette inkluderede visuelle rapporter via dashboards såsom marketingsfremmeeffektivitet, app-engagement-metrics og trending shows.
• ML eksperimentering – Aktiveret downstream Amazon-teams til at bruge disse data til at understøtte eksperimenter eller generere forudsigelser og anbefalinger. For eksempel hjalp ML-eksperimenter som en personlig anbefalingsliste for show, kategorisering af show og indholdsmoderering med Amps brugerfastholdelse.

Nøglefordele

Ved at implementere en skalerbar, omkostningseffektiv arkitektur var Amp i stand til at opnå følgende:

• Begrænset operationel kompleksitet – De byggede et fleksibelt system, der brugte AWS-administrerede tjenester, hvor det var muligt.
• Brug datasprogene – Amp var i stand til at understøtte de to mest almindelige datamanipulationssprog, Python og SQL, til at udføre platformsoperationer, udføre ML-eksperimenter og generere analyser. Med denne støtte var udviklerne med Amp i stand til at bruge sprog, de var fortrolige med.
• Aktiver eksperimentering og måling – Amp gjorde det muligt for udviklere hurtigt at generere de datasæt, der var nødvendige for at udføre eksperimenter og måle resultaterne. Dette hjælper med at optimere Amp-kundeoplevelsen.
• Byg for at lære, men design efter skala – Amp er et nyt produkt, der er ved at finde sit markedstilpasning og var i stand til at fokusere deres første energi på at bygge lige nok funktioner til at få feedback. Dette gjorde det muligt for dem at dreje mod det rigtige produktmarkedspas med hver lancering. De var i stand til at bygge gradvist, men planlægger på lang sigt.

Konklusion

I dette indlæg så vi, hvordan Amp skabte deres dataanalyseplatform ved hjælp af brugeradfærdsdata fra streaming- og batchdatakilder. Nøglefaktorerne, der drev implementeringen, var behovet for at levere en fleksibel, skalerbar, omkostningseffektiv og indsatseffektiv dataanalyseplatform. Designvalg blev foretaget ved at evaluere forskellige AWS-tjenester.

del 2 af denne serie viser, hvordan vi brugte disse data og opbyggede den personlige anbefalingsliste for show ved hjælp af SageMaker.

Som næste trin anbefaler vi, at du dykker dybt ned i hver fase af dit datapipeline-system og træffer designvalg, der ville være omkostningseffektive og skalerbare til dine behov. For mere information kan du også tjekke andre kundebrugssager i AWS Analytics-blog.

Hvis du har feedback om dette indlæg, så send det i kommentarfeltet.

---

Om forfatterne

Tulip Gupta er Solutions Architect hos Amazon Web Services. Hun arbejder sammen med Amazon om at designe, bygge og implementere teknologiløsninger på AWS. Hun hjælper kunder med at indføre bedste praksis, mens hun implementerer løsning i AWS, og hun er Analytics- og ML-entusiast. I sin fritid nyder hun at svømme, vandre og spille brætspil.

David Kuo er Solutions Architect hos Amazon Web Services. Han arbejder med AWS-kunder for at designe, bygge og implementere teknologiløsninger på AWS. Han arbejder med medie- og underholdningskunder og har interesser i maskinlæringsteknologier. I sin fritid spekulerer han på, hvad han skal gøre med sin fritid.

Manolya McCormick er Sr Software Development Engineer for Amp på Amazon. Hun designer og bygger distribuerede systemer ved hjælp af AWS til at betjene kundevendte applikationer. Hun nyder at læse og lave nye opskrifter i sin fritid.

Jeff Christophersen er Sr. Data Engineer for Amp på Amazon. Han arbejder på at designe, bygge og implementere Big Data-løsninger på AWS, der driver handlingsorienteret indsigt. Han assisterer interne teams med at indføre skalerbare og automatiserede løsninger og er Analytics- og Big Data-entusiast. I fritiden, når han ikke er på et par ski, kan du finde ham på hans mountainbike.