Hur Amp på Amazon använde data för att öka kundernas engagemang, del 1: Bygga en dataanalysplattform

Förstärkare, den nya liveradioappen från Amazon, är en ny uppfinning av radio med människokurerade liveljudprogram. Den är designad för att ge en sömlös kundupplevelse till lyssnare och kreatörer genom att debutera interaktiva liveljudprogram från dina favoritartister, radio-DJ:s, podcasters och vänner.

Men som en ny produkt i ett nytt utrymme för Amazon behövde Amp mer relevant data för att informera sin beslutsprocess. Amp ville ha en skalbar data- och analysplattform för att möjliggöra enkel åtkomst till data och utföra experiment med maskinlutning (ML) för liveljudtranskription, innehållsmoderering, funktionsteknik och en personlig showrekommendationstjänst, och för att inspektera eller mäta affärs-KPI:er och mätvärden.

Det här inlägget är det första i en serie i två delar. Del 1 visar hur data samlades in och bearbetades med hjälp av data- och analysplattformen, och del 2 visar hur data användes för att skapa showrekommendationer med hjälp av Amazon SageMaker, en helt hanterad ML-tjänst. Den personliga tjänsten för rekommendationslistor för program har visat en ökning på 3 % av mätvärden för kundernas engagemang (som att gilla en serie, följa en kreatör eller aktivera aviseringar om kommande program) sedan lanseringen i maj 2022.

Lösningsöversikt

Datakällorna för Amp kan brett kategoriseras som antingen streaming (nära realtid) eller batch (tidpunkt). Källdata sänds ut från Amp-ägda system eller andra Amazon-system. De två olika datatyperna är följande:

• Strömmande data – Den här typen av data består huvudsakligen av uppföljningar, aviseringar (beträffande användarnas vänner, favoritskapare eller program), aktivitetsuppdateringar, interaktioner med liveshower (inrop, medvärdar, omröstningar, chatt i appen), realtid uppdateringar om liveshowaktiviteter (livelyssnande antal, gilla-markeringar), mätvärden för liveljuduppspelning och andra mätvärden för klickströmmar från Amp-applikationen. Amp-intressenter kräver dessa data för att driva ML-processer eller prediktiva modeller, verktyg för innehållsmoderering och produkt- och programinstrumentpaneler (till exempel trendprogram). Streaming av data gör det möjligt för Amp-kunder att utföra och mäta experiment.
• Batchdata – Denna data består huvudsakligen av katalogdata, show- eller skaparmetadata och användarprofildata. Batchdata möjliggör mer tidpunktsrapportering och analys jämfört med realtid.

Följande diagram illustrerar högnivåarkitekturen.

Amps data- och analysplattform kan delas upp i tre högnivåsystem:

• Strömmande dataintag, strömbearbetning och transformation och strömlagring
• Batchdataintag, batchbearbetning och omvandling och batchlagring
• Business intelligence (BI) och analys

I de följande avsnitten diskuterar vi varje komponent mer i detalj.

Strömmande dataintag, bearbetning, transformation och lagring

Amp skapade en serverlös strömningsintagspipeline som kan utnyttja data från källor utan behov av infrastrukturhantering, som visas i följande diagram.

Pipelinen kunde ta in Amp-showkatalogdata (vilka program är tillgängliga på Amp) och skicka dem till datasjön för två olika användningsfall: en för nästan realtidsanalys och en för batchanalys.

Som en del av intagspipelinen har Amp-teamet en Amazon enkel kötjänst (Amazon SQS) kö som tar emot meddelanden från en uppströms Amazon enkel meddelandetjänst (Amazon SNS) ämne som innehåller information om ändringar av shower i katalogen. Dessa ändringar kan vara tillägg av nya shower eller justeringar av befintliga som har schemalagts.

När meddelandet tas emot av SQS-kön, utlöser det AWS Lambda funktion för att göra ett API-anrop till Amp-katalogtjänsten. Lambdafunktionen hämtar önskad showmetadata, filtrerar metadata och skickar sedan utdatametadata till Amazon Kinesis dataströmmar. Amazon Kinesis Data Firehose tar emot posterna från dataströmmen. Kinesis Data Firehose anropar sedan en sekundär Lambda-funktion för att utföra en datatransformation som plattar ut de mottagna JSON-posterna och skriver de transformerade posterna till en Amazon enkel lagringstjänst (Amazon S3) datasjö för konsumtion av Amp-intressenter.

Kinesis Data Firehose aktiverade buffring och skrivning av data till Amazon S3 var 60:e sekund. Detta hjälpte Amp-team att fatta programmeringsbeslut i nästan realtid som påverkade externa kunder.

Pipelinen för streamingintag stödde följande mål: prestanda, tillgänglighet, skalbarhet och flexibilitet för att skicka data till flera nedströmsapplikationer eller tjänster:

• Kinesis Data Streams hanterar strömmande dataintag vid behov. Kinesis Data Streams stödde dessa mål genom att göra det möjligt för Amp-teamet att snabbt få in data för analys med minimal driftsbelastning. Som en helt hanterad tjänst minskade den driftskostnader och Amp kunde skala med produktbehoven.
• Lambda gjorde det möjligt för teamet att skapa lättviktsfunktioner för att köra API-anrop och utföra datatransformationer.
• Eftersom Kinesis Data Firehose är en hanterad tjänst, kunde den hantera alla skalnings-, skärnings- och övervakningsbehov för strömmande data utan att teamet hörde något extra.

Batchdataintag, bearbetning, transformation och lagring

Amp skapade en övergående batch-(tidpunkt)-intagspipeline som klarar av dataintag, bearbetning och transformation och lagring, som visas i följande diagram.

En transient extrahera, transformera och ladda (ETL) och extrahera, ladda och transformera (ELT) jobbmetod implementerades på grund av dessa arbetsbelastningars batchkaraktär och okända datavolymer. Som en del av automatiseringen av arbetsflödet användes Amazon SQS för att trigga en Lambda-funktion. Lambdafunktionen aktiverade sedan AWS Glue-sökroboten för att härleda schemat och datatyperna. Sökroboten skrev schemats metadata till AWS Glue Data Catalog, vilket gav ett enhetligt metadatalager för datadelning.

ETL- och ELT-jobben var tvungna att köras enligt antingen ett fastställt schema eller händelsedrivet arbetsflöde. För att hantera dessa behov använde Amp Amazon Managed Workflows för Apache Airflow (Amazon MWAA). Apache Airflow är en Python-baserad plattform för hantering av arbetsflöden med öppen källkod. Amazon MWAA är en helt hanterad tjänst som automatiskt hanterar skalning. Den tillhandahåller sekvensering, felhantering, försök igen logik och tillstånd. Med Amazon MWAA kunde Amp dra fördel av fördelarna med Airflow för jobborkestrering samtidigt som de inte behövde hantera eller underhålla dedikerade Airflow-servrar. Dessutom, genom att använda Amazon MWAA, kunde Amp skapa ett kodlager och arbetsflödespipeline lagrad i Amazon S3 som Amazon MWAA kunde komma åt. Pipelinen gjorde det möjligt för Amps dataingenjörer att enkelt distribuera Airflow DAGs eller PySpark-skript i flera miljöer.

Förstärkare använd Amazon EMR on Amazon Elastic Kubernetes-tjänst (Amazon EKS) för att konfigurera och hantera behållare för deras databearbetnings- och transformationsjobb. På grund av Amp-tjänstens unika karaktär var de initiala förväntade datavolymerna som skulle behandlas relativt okända. För att ge flexibilitet i takt med att tjänsten utvecklades, beslutade teamet att gå med Amazon EMR på EKS för att eliminera alla onödiga operativa hörda som krävs för att starta och skala Amazon EMR för databehandling. Detta tillvägagångssätt gjorde det möjligt för dem att köra transienta hybrid EMR-kluster uppbackade av en blandning av AWS Fargate och Amazon Elastic Compute Cloud (Amazon EC2) noder, där alla systemuppgifter och arbetsbelastningar överfördes till Fargate, medan Amazon EC2 hanterade all Apache Spark-bearbetning och transformation. Detta gav flexibiliteten att ha ett kluster med en nod igång, medan Amazon EKS auto scaler dynamiskt instansierade och startade upp alla ytterligare EC2-noder som krävdes för jobbet. När jobbet var klart raderades de automatiskt av klustrets automatiska skalare. Detta mönster eliminerade behovet för teamet att hantera någon av klustrets bootstrap-åtgärder eller skalning som krävs för att svara på föränderliga arbetsbelastningar.

Amazon S3 användes som den centrala datasjön och data lagrades i Apache Parquet-format (Parquet). Parkett är ett kolumnformat, som snabbar upp datahämtning och ger effektiv datakomprimering. Amazon S3 tillhandahöll flexibilitet, skalbarhet och säkerhetsbehov för Amp. Med Amazon S3 kunde Amp-teamet centralisera datalagring på en plats och sammanföra åtkomst till data praktiskt taget över alla tjänster eller verktyg inom eller utanför AWS. Datasjön delades upp i två S3-buckets: en för rådataintag och en för transformerad datautmatning. Amazon EMR utförde omvandlingen från rådata till transformerad data. Med Amazon S3 som den centrala datasjön kunde Amp säkert exponera och dela data med andra team över Amp och Amazon.

För att förenkla datadefinition, tillhandahållande av tabellåtkomst och tillägg och borttagning av tabeller använde de AWS Glue-sökrobotar och AWS Glue Data Catalog. Eftersom Amp är en ny tjänst och ständigt utvecklas, behövde teamet ett sätt att enkelt definiera, komma åt och hantera tabellerna i datasjön. Sökrobotarna hanterade datadefinition (inklusive schemaändringar) och tillägg och borttagning av tabeller, medan datakatalogen fungerade som ett enhetligt metadatalager.

Business intelligence och analys

Följande diagram illustrerar arkitekturen för BI- och analyskomponenten.

Amp valde att lagra datan i S3-datasjön, och inte i datalagret. Detta gjorde det möjligt för dem att komma åt den på ett enhetligt sätt genom AWS Glue Data Catalog och gav större flexibilitet för datakonsumenter. Detta resulterade i snabbare dataåtkomst över en mängd olika tjänster eller verktyg. Med data som lagras i Amazon S3 minskade det också kostnaderna för datalagerinfrastrukturen, eftersom kostnaderna är en funktion av beräkningstypen och mängden lagrad data.

Smakämnen Amazon RedShift RA3-nodtyp användes som beräkningsskikt för att göra det möjligt för intressenter att fråga efter data lagrad i Amazon S3. Amazon Redshift RA3-noder frikopplar lagring och beräkning, och är designade för ett åtkomstmönster genom AWS Glue Data Catalog. RA3-noder introducerar Amazon Redshift Managed Storage, som stöds av Amazon S3. Kombinationen av dessa funktioner gjorde det möjligt för Amp att anpassa klustren till rätt storlek och ge bättre frågeprestanda för sina kunder samtidigt som kostnaderna minimerades.

Amazon Redshift-konfigurationen automatiserades med en Lambda-funktion, som kopplades till ett givet kluster och körde parameteriserade SQL-satser. SQL-satserna innehöll logiken för att distribuera scheman, användargrupper och användare, medan AWS Secrets Manager användes för att automatiskt generera, lagra och rotera Amazon Redshift-användarlösenord. De underliggande konfigurationsvariablerna lagrades i Amazon DynamoDB. Lambdafunktionen hämtade variablerna och begärde tillfälliga Amazon Redshift-referenser för att utföra konfigurationen. Denna process gjorde det möjligt för Amp-teamet att sätta upp Amazon Redshift-kluster på ett konsekvent sätt.

Affärsresultat

Amp kunde uppnå följande affärsresultat:

• Företagsrapportering – Standardrapportering som krävs för att driva verksamheten, såsom dagliga flashrapporter, sammanställda affärsgranskningsmekanismer eller projekt- och programuppdateringar.
• Produktrapportering – Specifik rapportering som krävs för att möjliggöra inspektion eller mätning av nyckelprodukt-KPI:er och mätvärden. Detta inkluderade visuella rapporter via instrumentpaneler som effektivitet i marknadsföringskampanjer, mätvärden för appengagemang och trendiga program.
• ML-experiment – Aktiverade nedströms Amazon-team att använda denna data för att stödja experiment eller generera förutsägelser och rekommendationer. Till exempel hjälpte ML-experiment som en personlig rekommendationslista för program, kategorisering av program och moderering av innehåll till Amps användarbehållning.

De viktigaste fördelarna

Genom att implementera en skalbar, kostnadseffektiv arkitektur kunde Amp uppnå följande:

• Begränsad operativ komplexitet – De byggde ett flexibelt system som använde AWS-hanterade tjänster där det var möjligt.
• Använd dataspråken – Amp kunde stödja de två vanligaste datamanipuleringsspråken, Python och SQL, för att utföra plattformsoperationer, utföra ML-experiment och generera analyser. Med detta stöd kunde utvecklarna med Amp använda språk de var bekanta med.
• Aktivera experiment och mätning – Amp gjorde det möjligt för utvecklare att snabbt generera de datauppsättningar som behövs för att utföra experiment och mäta resultaten. Detta hjälper till att optimera Amp-kundupplevelsen.
• Bygg för att lära dig men designa efter skala – Amp är en ny produkt som finner sin marknadspassform och kunde fokusera sin initiala energi på att bygga precis tillräckligt med funktioner för att få feedback. Detta gjorde det möjligt för dem att vända sig mot rätt produktmarknadspassning vid varje lansering. De kunde bygga stegvis, men planerar på lång sikt.

Slutsats

I det här inlägget såg vi hur Amp skapade sin dataanalysplattform med hjälp av användarbeteendedata från streaming- och batchdatakällor. Nyckelfaktorerna som drev implementeringen var behovet av att tillhandahålla en flexibel, skalbar, kostnadseffektiv och ansträngningseffektiv dataanalysplattform. Designval gjordes för att utvärdera olika AWS-tjänster.

del 2 i den här serien visar hur vi använde denna data och byggde ut den personliga rekommendationslistan för show med SageMaker.

Som nästa steg rekommenderar vi att du gör en djupdykning i varje steg i ditt datapipelinesystem och gör designval som skulle vara kostnadseffektiva och skalbara för dina behov. För mer information kan du också kolla in andra kundanvändningsfall i AWS Analytics-blogg.

Om du har feedback om det här inlägget, skicka in det i kommentarsfältet.

---

Om författarna

Tulpan Gupta är en lösningsarkitekt på Amazon Web Services. Hon arbetar med Amazon för att designa, bygga och distribuera tekniska lösningar på AWS. Hon hjälper kunderna att ta till sig bästa praxis när hon implementerar lösningar i AWS och är en Analytics- och ML-entusiast. På fritiden tycker hon om att simma, vandra och spela brädspel.

David Kuo är en lösningsarkitekt på Amazon Web Services. Han arbetar med AWS-kunder för att designa, bygga och distribuera tekniska lösningar på AWS. Han arbetar med media- och underhållningskunder och har intressen för maskininlärningsteknik. På fritiden undrar han vad han ska göra med sin fritid.

Manolya McCormick är en Sr Software Development Engineer för Amp på Amazon. Hon designar och bygger distribuerade system med hjälp av AWS för att betjäna kundinriktade applikationer. Hon tycker om att läsa och laga nya recept på fritiden.

Jeff Christophersen är Sr. Data Engineer för Amp på Amazon. Han arbetar med att designa, bygga och distribuera Big Data-lösningar på AWS som driver handlingskraftiga insikter. Han hjälper interna team att ta till sig skalbara och automatiserade lösningar och är en Analytics- och Big Data-entusiast. På fritiden, när han inte är på ett par skidor kan du hitta honom på sin mountainbike.