Analysera Amazon SageMakers utgifter och bestämma kostnadsoptimeringsmöjligheter baserat på användning, Del 3: Bearbetning och Data Wrangler jobb | Amazon webbtjänster

2021 lanserade vi AWS Support Proactive Services som en del av AWS Enterprise Support planen. Sedan introduktionen har vi hjälpt hundratals kunder att optimera sina arbetsbelastningar, sätta skyddsräcken och förbättra synligheten för deras maskininlärnings (ML) arbetsbelastningars kostnader och användning.

I den här serien av inlägg delar vi lärdomar om att optimera kostnader i Amazon SageMaker. I det här inlägget fokuserar vi på dataförbehandling med hjälp av Amazon SageMaker-bearbetning och Amazon SageMaker Data Wrangler jobb.

Dataförbearbetning har en central roll i en datacentrerad AI-metod. Men att förbereda rådata för ML-träning och utvärdering är ofta en tråkig och krävande uppgift när det gäller beräkningsresurser, tid och mänsklig ansträngning. Dataförberedelse behöver vanligtvis integreras från olika källor och hantera saknade eller störande värden, extremvärden och så vidare.

Dessutom, förutom vanliga extrahera, transformera och ladda (ETL) uppgifter, kräver ML-team ibland mer avancerade funktioner som att skapa snabba modeller för att utvärdera data och producera funktionsviktighetspoäng eller modellutvärdering efter träning som en del av en MLOps-pipeline.

SageMaker erbjuder två funktioner speciellt utformade för att hjälpa till med dessa problem: SageMaker Processing och Data Wrangler. SageMaker Processing gör att du enkelt kan köra förbearbetning, efterbearbetning och modellutvärdering på en helt hanterad infrastruktur. Data Wrangler minskar tiden det tar att aggregera och förbereda data genom att förenkla processen för datakällintegrering och funktionsutveckling med ett enda visuellt gränssnitt och en fullt distribuerad databehandlingsmiljö.

Båda SageMaker-funktionerna ger stor flexibilitet med flera alternativ för I/O, lagring och beräkning. Att ställa in dessa alternativ felaktigt kan dock leda till onödiga kostnader, särskilt när det gäller stora datamängder.

I det här inlägget analyserar vi prissättningsfaktorerna och ger kostnadsoptimeringsvägledning för SageMaker Processing och Data Wrangler-jobb.

SageMaker-bearbetning

SageMaker Processing är en hanterad lösning för att köra arbetsbelastningar för databearbetning och modellutvärdering. Du kan använda den i databearbetningssteg som funktionsteknik, datavalidering, modellutvärdering och modelltolkning i ML-arbetsflöden. Med SageMaker Processing kan du ta med dina egna anpassade bearbetningsskript och välja att bygga en anpassad behållare eller använda en SageMaker-hanterad behållare med vanliga ramverk som scikit-learn, Lime, Spark och mer.

SageMaker Processing debiterar dig för den instanstyp du väljer, baserat på varaktigheten av användning och tillhandahållen lagring som är kopplad till den instansen. I del 1 visade vi hur du kommer igång med att använda AWS Cost Explorer för att identifiera kostnadsoptimeringsmöjligheter i SageMaker.

Du kan filtrera bearbetningskostnader genom att använda ett filter på användningstypen. Namnen på dessa användningstyper är följande:

• REGION-Processing:instanceType (till exempel, USE1-Processing:ml.m5.large)
• REGION-Processing:VolumeUsage.gp2 (till exempel, USE1-Processing:VolumeUsage.gp2)

För att granska din SageMaker-bearbetningskostnad i Cost Explorer, börja med att filtrera med SageMaker för ServiceOch för Användningstyp, kan du välja alla bearbetningsinstansers drifttimmar genom att ange processing:ml prefix och välja listan på menyn.

Undvik kostnader för bearbetning och utveckling av pipeline

Innan du anpassar rätt storlek och optimerar ett SageMaker Processing-jobbs körlängd, kontrollerar vi om det finns mätvärden på hög nivå om historiska jobbkörningar. Du kan välja mellan två metoder för att göra detta.

Först kan du komma åt Bearbetning sidan på SageMaker-konsolen.

Alternativt kan du använda list_processing_jobs API.

En Bearbetningsjobbstatus kan vara InProgress, Completed, Failed, Stopping, eller Stopped.

Ett stort antal misslyckade jobb är vanligt när man utvecklar nya MLOps-pipelines. Du bör dock alltid testa och göra allt för att validera jobb innan du lanserar dem på SageMaker eftersom det tillkommer avgifter för resurser som används. För det ändamålet kan du använda SageMaker Processing i lokalt läge. Lokalt läge är en SageMaker SDK-funktion som låter dig skapa estimatorer, processorer och pipelines och distribuera dem till din lokala utvecklingsmiljö. Det här är ett utmärkt sätt att testa dina skript innan du kör dem i en SageMaker-hanterad miljö. Lokalt läge stöds av SageMaker-hanterade behållare och de du själv tillhandahåller. För att lära dig mer om hur du använder lokalt läge med Amazon SageMaker-rörledningar, hänvisa till Lokalt läge.

Optimera I/O-relaterade kostnader

SageMaker Processing-jobb ger tillgång till tre datakällor som en del av den hanterade bearbetning av input: Amazon enkel lagringstjänst (Amazon S3), Amazonas Athenaoch Amazon RedShift. För mer information, se ProcessingS3Input, AthenaDatasetDefinitionoch RedshiftDatasetDefinition, Respektive.

Innan du tittar på optimering är det viktigt att notera att även om SageMaker Processing-jobb stöder dessa datakällor, är de inte obligatoriska. I din bearbetningskod kan du implementera vilken metod som helst för att ladda ner åtkomstdata från vilken källa som helst (förutsatt att bearbetningsinstansen kan komma åt den).

För att få bättre insikter om bearbetningsprestanda och upptäcka optimeringsmöjligheter rekommenderar vi att du följer bästa praxis för loggning i ditt bearbetningsskript. SageMaker publicerar dina bearbetningsloggar till amazoncloudwatch.

I följande exempeljobblogg ser vi att skriptbehandlingen tog 15 minuter (mellan Start custom script och End custom script).

På SageMaker-konsolen ser vi dock att jobbet tog ytterligare 4 minuter (nästan 25 % av jobbets totala körtid).

Detta beror på att utöver den tid vårt bearbetningsskript tog, tog SageMaker-hanterade nedladdning och uppladdning av data också tid (4 minuter). Om detta visar sig vara en stor del av kostnaden, överväg alternativa sätt att påskynda nedladdningstiden, som att använda Boto3 API med multiprocessing för att ladda ner filer samtidigt, eller använda tredjepartsbibliotek som WebDataset eller s5cmd för snabbare nedladdning från Amazon S3 . För mer information, se Parallellisering av S3-arbetsbelastningar med s5cmd. Observera att sådana metoder kan införa avgifter i Amazon S3 pga dataöverföring.

Bearbetningsjobb stöder också Rörläge. Med den här metoden strömmar SageMaker indata från källan direkt till din bearbetningsbehållare till namngivna pipes utan att använda ML-lagringsvolymen, vilket eliminerar datanedladdningstiden och en mindre diskvolym. Detta kräver dock en mer komplicerad programmeringsmodell än att bara läsa från filer på en disk.

Som tidigare nämnts stöder SageMaker Processing även Athena och Amazon Redshift som datakällor. När du ställer in ett bearbetningsjobb med dessa källor, kopierar SageMaker automatiskt data till Amazon S3, och bearbetningsinstansen hämtar data från Amazon S3-platsen. Men när jobbet är klart finns det ingen hanterad rensningsprocess och den kopierade data kommer fortfarande att finnas kvar i Amazon S3 och kan medföra oönskade lagringskostnader. När du använder Athena och Amazon Redshift datakällor, se därför till att implementera en rensningsprocedur, till exempel en lambdafunktion som körs enligt ett schema eller i en Lambdasteg som en del av en SageMaker-pipeline.

Liksom nedladdning kan uppladdning av bearbetningsartefakter också vara en möjlighet till optimering. När ett bearbetningsjobbs utdata konfigureras med hjälp av ProcessingS3Output parameter kan du ange vilken S3UploadMode att använda. De S3UploadMode parameterns standardvärde är EndOfJob, vilket kommer att få SageMaker att ladda upp resultaten efter att jobbet är klart. Men om ditt bearbetningsjobb producerar flera filer kan du ställa in S3UploadMode till Continuous, vilket möjliggör uppladdning av artefakter samtidigt som bearbetningen fortsätter, och minskar jobbets körtid.

Rätt storlek bearbetningsjobbinstanser

Att välja rätt instanstyp och storlek är en viktig faktor för att optimera kostnaden för SageMaker Processing-jobb. Du kan anpassa en instans i rätt storlek genom att migrera till en annan version inom samma instansfamilj eller genom att migrera till en annan instansfamilj. När du migrerar inom samma instansfamilj behöver du bara ta hänsyn till CPU/GPU och minne. För mer information och allmän vägledning om att välja rätt bearbetningsresurser, se Säkerställ effektiva beräkningsresurser på Amazon SageMaker.

För att finjustera valet av instanser börjar vi med att analysera Processing job metrics i CloudWatch. För mer information, se Övervaka Amazon SageMaker med Amazon CloudWatch.

CloudWatch samlar in rådata från SageMaker och bearbetar den till läsbara mätvärden nästan i realtid. Även om denna statistik sparas i 15 månader, begränsar CloudWatch-konsolen sökningen till mätvärden som har uppdaterats under de senaste 2 veckorna (detta säkerställer att endast aktuella jobb visas). Mätvärden för bearbetning av jobb finns i namnutrymmet /aws/sagemaker/ProcessingJobs och mätvärdena som samlas in är CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationoch DiskUtilization.

Följande skärmdump visar ett exempel i CloudWatch på bearbetningsjobbet vi såg tidigare.

I det här exemplet ser vi de genomsnittliga CPU- och minnesvärdena (vilket är standard i CloudWatch): den genomsnittliga CPU-användningen är 0.04 %, minnet 1.84 % och diskanvändningen 13.7 %. För att göra rätt storlek, överväg alltid den maximala CPU- och minnesanvändningen (i det här exemplet var det maximala CPU-utnyttjandet 98 % under de första 3 minuterna). Som en allmän regel, om din maximala CPU- och minnesanvändning konsekvent är mindre än 40 %, kan du säkert halvera maskinen. Om du till exempel använde en ml.c5.4xlarge-instans kan du flytta till en ml.c5.2xlarge, vilket kan minska din kostnad med 50 %.

Data Wrangler kontaktinformation förvaltning

Data Wrangler är en funktion av Amazon SageMaker Studio som ger en repeterbar och skalbar lösning för datautforskning och -bearbetning. Du använder Data Wrangler-gränssnittet för att interaktivt importera, analysera, transformera och presentera dina data. Dessa steg är fångad i ett recept (en .flow-fil) som du sedan kan använda i ett Data Wrangler-jobb. Detta hjälper dig att tillämpa samma datatransformationer på dina data igen och även skala till ett distribuerat batchdatabearbetningsjobb, antingen som en del av en ML-pipeline eller oberoende.

För vägledning om hur du optimerar din Data Wrangler-app i Studio, se del 2 i den här serien.

I det här avsnittet fokuserar vi på att optimera Data Wrangler-jobb.

Data som Wrangler använder SageMaker Spark processing jobb med en Data Wrangler-hanterad behållare. Den här behållaren kör anvisningarna från .flow-filen i jobbet. Precis som alla bearbetningsjobb debiterar Data Wrangler dig för de instanser du väljer, baserat på användningstiden och den tillhandahållna lagringen som är kopplad till den instansen.

I Cost Explorer kan du filtrera Data Wrangler-jobbkostnaderna genom att använda ett filter på användningstypen. Namnen på dessa användningstyper är:

• REGION-processing_DW:instanceType (till exempel, USE1-processing_DW:ml.m5.large)
• REGION-processing_DW:VolumeUsage.gp2 (till exempel, USE1-processing_DW:VolumeUsage.gp2)

För att se din Data Wrangler-kostnad i Cost Explorer, filtrera tjänsten för att använda SageMaker och för Användningstyp, Välj den processing_DW prefix och välj listan på menyn. Detta kommer att visa dig relaterade kostnader för både instansanvändning (timmar) och lagringsvolym (GB). (Om du vill se Studio Data Wrangler-kostnader kan du filtrera användningstypen efter Studio_DW prefix.)

Rätt storlek och schemalägg Data Wrangler-jobbinstanser

För närvarande stöder Data Wrangler endast m5-instanser med följande instansstorlekar: ml.m5.4xlarge, ml.m5.12xlarge och ml.m5.24xlarge. Du kan använda den distribuerade jobbfunktionen för att finjustera din jobbkostnad. Anta till exempel att du behöver bearbeta en datauppsättning som kräver 350 GiB i RAM. 4xlarge (128 GiB) och 12xlarge (256 GiB) kanske inte kan bearbeta och kommer att leda dig att använda m5.24xlarge-instansen (768 GiB). Du kan dock använda två m5.12xlarge instanser (2 * 256 GiB = 512 GiB) och minska kostnaden med 40 % eller tre m5.4xlarge instanser (3 * 128 GiB = 384 GiB) och spara 50 % av m5.24xlarge instanskostnad. Du bör notera att detta är uppskattningar och att distribuerad bearbetning kan införa vissa overhead som kommer att påverka den totala körtiden.

När du ändrar instanstypen, se till att du uppdaterar Spark config följaktligen. Till exempel, om du har ett initialt ml.m5.4xlarge instansjobb konfigurerat med egenskaper spark.driver.memory inställd på 2048 och spark.executor.memory inställd på 55742, och senare skala upp till ml.m5.12xlarge, måste dessa konfigurationsvärden ökas, annars blir de flaskhalsen i bearbetningsjobbet. Du kan uppdatera dessa variabler i Data Wrangler GUI eller i en konfigurationsfil som läggs till konfigurationssökvägen (se följande exempel).

En annan övertygande funktion i Data Wrangler är förmågan att ställa in ett schemalagt jobb. Om du bearbetar data regelbundet kan du skapa ett schema för att köra bearbetningsjobbet automatiskt. Till exempel kan du skapa ett schema som kör ett bearbetningsjobb automatiskt när du får ny data (för exempel, se Exportera till Amazon S3 or Exportera till Amazon SageMaker Feature Store). Du bör dock notera att när du skapar ett schema skapar Data Wrangler en eventRule i EventBridge. Detta innebär att du också debiteras för händelsereglerna som du skapar (liksom de instanser som används för att köra bearbetningsjobbet). För mer information, se Amazon EventBridge-priser.

Slutsats

I det här inlägget gav vi vägledning om kostnadsanalys och bästa praxis vid förbearbetning

data med SageMaker Processing och Data Wrangler jobb. I likhet med förbearbetning finns det många alternativ och konfigurationsinställningar i att bygga, träna och köra ML-modeller som kan leda till onödiga kostnader. Därför, eftersom maskininlärning etablerar sig som ett kraftfullt verktyg över branscher, måste ML-arbetsbelastningar förbli kostnadseffektiva.

SageMaker erbjuder en bred och djup uppsättning funktioner för att underlätta varje steg i ML-pipelinen.

Denna robusthet ger också kontinuerliga kostnadsoptimeringsmöjligheter utan att kompromissa med prestanda eller smidighet.

---

Om författarna

Deepali Rajale är senior AI/ML-specialist på AWS. Hon arbetar med företagskunder och tillhandahåller teknisk vägledning med bästa praxis för att distribuera och underhålla AI/ML-lösningar i AWS-ekosystemet. Hon har arbetat med ett brett spektrum av organisationer med olika användningsfall för djupinlärning som involverar NLP och datorseende. Hon brinner för att ge organisationer möjlighet att utnyttja generativ AI för att förbättra deras användningsupplevelse. På fritiden tycker hon om film, musik och litteratur.

Uri Rosenberg är AI & ML Specialist Technical Manager för Europa, Mellanöstern och Afrika. Med utgångspunkt från Israel arbetar Uri för att ge företagskunder i allt ML möjlighet att designa, bygga och driva i stor skala. På fritiden tycker han om att cykla, vandra och titta på solnedgångar (minst en gång om dagen).

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoAiStream. Web3 Data Intelligence. Kunskap förstärkt. Tillgång här.
• Minting the Future med Adryenn Ashley. Tillgång här.
• Köp och sälj aktier i PRE-IPO-företag med PREIPO®. Tillgång här.
• Källa: https://aws.amazon.com/blogs/machine-learning/part-3-analyze-amazon-sagemaker-spend-and-determine-cost-optimization-opportunities-based-on-usage-part-3-processing-and-data-wrangler-jobs/