Analyze Amazon SageMaker Spend And Determine Cost Optimization Opportunities Based On Usage, Part 3: Processing And Data Wrangler Jobs

Genudgivet af Platon

Abonnenter: 0

I 2021 lancerede vi AWS Support Proactive Services som en del af AWS Enterprise Support plan. Siden introduktionen har vi hjulpet hundredvis af kunder med at optimere deres arbejdsbelastninger, sætte autoværn og forbedre synligheden af deres maskinlærings (ML) arbejdsbelastningers omkostninger og brug.

I denne serie af indlæg deler vi erfaringer om optimering af omkostninger i Amazon SageMaker. I dette indlæg fokuserer vi på dataforbehandling vha Amazon SageMaker-behandling , Amazon SageMaker Data Wrangler beskæftigelse.

Dataforbehandling spiller en central rolle i en datacentreret AI-tilgang. Men at forberede rådata til ML-træning og -evaluering er ofte en kedelig og krævende opgave med hensyn til computerressourcer, tid og menneskelig indsats. Dataforberedelse skal almindeligvis integreres fra forskellige kilder og håndtere manglende eller støjende værdier, afvigelser og så videre.

Ud over almindelige udtræks-, transformations- og indlæsningsopgaver (ETL) kræver ML-teams desuden lejlighedsvis mere avancerede funktioner som at skabe hurtige modeller til at evaluere data og producere karakteristika for funktioner eller evaluering af modeller efter træning som en del af en MLOps-pipeline.

SageMaker tilbyder to funktioner, der er specielt designet til at hjælpe med disse problemer: SageMaker Processing og Data Wrangler. SageMaker Processing giver dig mulighed for nemt at køre forbehandling, efterbehandling og modelevaluering på en fuldt administreret infrastruktur. Data Wrangler reducerer den tid, det tager at aggregere og forberede data ved at forenkle processen med datakildeintegration og funktionsudvikling ved hjælp af en enkelt visuel grænseflade og et fuldt distribueret databehandlingsmiljø.

Begge SageMaker-funktioner giver stor fleksibilitet med flere muligheder for I/O, lagring og beregning. Men forkert indstilling af disse muligheder kan føre til unødvendige omkostninger, især når der er tale om store datasæt.

I dette indlæg analyserer vi prissætningsfaktorerne og giver vejledning om omkostningsoptimering til SageMaker Processing og Data Wrangler job.

SageMaker-behandling

SageMaker Processing er en administreret løsning til at køre databehandling og modelevalueringsarbejdsbelastninger. Du kan bruge det i databehandlingstrin såsom funktionsudvikling, datavalidering, modelevaluering og modelfortolkning i ML-arbejdsgange. Med SageMaker Processing kan du medbringe dine egne brugerdefinerede behandlingsscripts og vælge at bygge en brugerdefineret container eller bruge en SageMaker-administreret container med fælles rammer som scikit-learn, Lime, Spark og mere.

SageMaker Processing debiterer dig for den instanstype, du vælger, baseret på varigheden af brugen og den klargjorte lagring, der er knyttet til den instans. I del 1 viste vi, hvordan du kommer i gang med at bruge AWS Cost Explorer at identificere omkostningsoptimeringsmuligheder i SageMaker.

Du kan filtrere behandlingsomkostninger ved at anvende et filter på brugstypen. Navnene på disse brugstyper er som følger:

REGION-Processing:instanceType (for eksempel, USE1-Processing:ml.m5.large)
REGION-Processing:VolumeUsage.gp2 (for eksempel, USE1-Processing:VolumeUsage.gp2)

For at gennemgå dine SageMaker-behandlingsomkostninger i Cost Explorer, start med at filtrere med SageMaker for Service, Og Brugstype, kan du vælge alle behandlingsforekomsters driftstimer ved at indtaste processing:ml præfiks og vælge listen i menuen.

Undgå omkostninger ved forarbejdning og udvikling af pipeline

Inden den rigtige størrelse og optimering af et SageMaker Processing-jobs køretid, tjekker vi for højniveau-metrics om historiske jobkørsler. Du kan vælge mellem to metoder til at gøre dette.

For det første kan du få adgang til Behandles side på SageMaker-konsollen.

Alternativt kan du bruge list_processing_jobs API.

En behandlingsjobstatus kan være InProgress, Completed, Failed, Stopping eller Stopped.

Et stort antal mislykkede job er almindeligt, når man udvikler nye MLOps-pipelines. Du bør dog altid teste og gøre alt for at validere job, før du lancerer dem på SageMaker, fordi der er gebyrer for brugte ressourcer. Til det formål kan du bruge SageMaker Processing i Lokal tilstand. Lokal tilstand er en SageMaker SDK-funktion, der giver dig mulighed for at oprette estimatorer, processorer og pipelines og implementere dem til dit lokale udviklingsmiljø. Dette er en fantastisk måde at teste dine scripts på, før du kører dem i et SageMaker-administreret miljø. Lokal tilstand understøttes af SageMaker administrerede containere og dem, du selv leverer. For at lære mere om, hvordan du bruger lokal tilstand med Amazon SageMaker Pipelines, henvise til Lokal tilstand.

Optimer I/O-relaterede omkostninger

SageMaker Processing-job giver adgang til tre datakilder som en del af det administrerede behandle input: Amazon Simple Storage Service (Amazon S3), Amazonas Athenaog Amazon rødforskydning. For mere information, se ProcessingS3Input, AthenaDatasetDefinitionog RedshiftDatasetDefinition, henholdsvis.

Før du ser nærmere på optimering, er det vigtigt at bemærke, at selvom SageMaker Processing-job understøtter disse datakilder, er de ikke obligatoriske. I din behandlingskode kan du implementere enhver metode til at downloade adgangsdata fra enhver kilde (forudsat at behandlingsforekomsten har adgang til dem).

For at få bedre indsigt i behandlingsydelse og opdage optimeringsmuligheder, anbefaler vi at følge bedste praksis for logning i dit behandlingsscript. SageMaker udgiver dine behandlingslogfiler til amazoncloudwatch.

I det følgende eksempeljoblog kan vi se, at scriptbehandlingen tog 15 minutter (mellem Start custom script , End custom script).

På SageMaker-konsollen ser vi dog, at jobbet tog yderligere 4 minutter (næsten 25 % af jobbets samlede køretid).

Dette skyldes, at ud over den tid, vores behandlingsscript tog, tog SageMaker-styret datadownload og upload også tid (4 minutter). Hvis dette viser sig at være en stor del af omkostningerne, kan du overveje alternative måder at fremskynde downloadtiden på, såsom at bruge Boto3 API med multiprocessing til at downloade filer samtidigt eller bruge tredjepartsbiblioteker som WebDataset eller s5cmd for hurtigere download fra Amazon S3 . For mere information, se Parallellering af S3-arbejdsbelastninger med s5cmd. Bemærk, at sådanne metoder kan indføre afgifter i Amazon S3 pga dataoverførsel.

Bearbejdning job understøtter også Rørtilstand. Med denne metode streamer SageMaker inputdata fra kilden direkte til din behandlingsbeholder til navngivne pipes uden at bruge ML-lagervolumen, og eliminerer derved dataoverførselstiden og en mindre diskvolumen. Dette kræver dog en mere kompliceret programmeringsmodel end blot at læse fra filer på en disk.

Som tidligere nævnt understøtter SageMaker Processing også Athena og Amazon Redshift som datakilder. Når du opsætter et behandlingsjob med disse kilder, kopierer SageMaker automatisk dataene til Amazon S3, og behandlingsforekomsten henter dataene fra Amazon S3-lokationen. Men når jobbet er færdigt, er der ingen administreret oprydningsproces, og de kopierede data vil stadig forblive i Amazon S3 og kan medføre uønskede lageromkostninger. Når du bruger Athena og Amazon Redshift-datakilder, skal du derfor sørge for at implementere en oprydningsprocedure, såsom en Lambda-funktion, der kører efter en tidsplan eller i en Lambda Step som en del af en SageMaker-pipeline.

Ligesom downloading kan upload af behandlingsartefakter også være en mulighed for optimering. Når et behandlingsjobs output er konfigureret ved hjælp af ProcessingS3Output parameter, kan du angive hvilken S3UploadMode at bruge. Det S3UploadMode parameterens standardværdi er EndOfJob, som får SageMaker til at uploade resultaterne, efter at jobbet er fuldført. Men hvis dit behandlingsjob producerer flere filer, kan du indstille S3UploadMode til Continuous, hvilket muliggør upload af artefakter, samtidig med at behandlingen fortsætter, og reducerer jobbets køretid.

Bearbejdningsjobforekomster i den rigtige størrelse

Valg af den rigtige instanstype og -størrelse er en vigtig faktor i optimering af omkostningerne ved SageMaker Processing-job. Du kan tilpasse størrelsen på en instans ved at migrere til en anden version inden for den samme instansfamilie eller ved at migrere til en anden instansfamilie. Når du migrerer inden for den samme instansfamilie, skal du kun overveje CPU/GPU og hukommelse. For mere information og generel vejledning om valg af de rigtige behandlingsressourcer henvises til Sørg for effektive computerressourcer på Amazon SageMaker.

For at finjustere instansvalg starter vi med at analysere Processing job metrics i CloudWatch. For mere information, se Overvåg Amazon SageMaker med Amazon CloudWatch.

CloudWatch indsamler rådata fra SageMaker og behandler dem til læsbare, næsten-realtids-metrikker. Selvom disse statistikker opbevares i 15 måneder, begrænser CloudWatch-konsollen søgningen til målinger, der er blevet opdateret inden for de sidste 2 uger (dette sikrer, at kun aktuelle job vises). Behandlingsjob-metrics kan findes i /aws/sagemaker/ProcessingJobs-navneområdet, og de indsamlede metrics er CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationog DiskUtilization.

Følgende skærmbillede viser et eksempel i CloudWatch på det behandlingsjob, vi så tidligere.

I dette eksempel ser vi de gennemsnitlige CPU- og hukommelsesværdier (som er standard i CloudWatch): det gennemsnitlige CPU-forbrug er 0.04%, hukommelse 1.84% og diskforbrug 13.7%. For at tilpasse størrelsen skal du altid overveje den maksimale CPU- og hukommelsesbrug (i dette eksempel var den maksimale CPU-udnyttelse 98 % i de første 3 minutter). Som en generel regel, hvis dit maksimale CPU- og hukommelsesforbrug konsekvent er mindre end 40 %, kan du roligt skære maskinen i to. Hvis du f.eks. brugte en ml.c5.4xlarge-instans, kunne du flytte til en ml.c5.2xlarge, hvilket kunne reducere dine omkostninger med 50 %.

Nyheder Data Wrangler

Data Wrangler er en funktion af Amazon SageMaker Studio der giver en gentagelig og skalerbar løsning til dataudforskning og -behandling. Du bruger Data Wrangler-grænsefladen til interaktivt at importere, analysere, transformere og fremhæve dine data. Disse trin er fanget i en opskrift (en .flow-fil), som du derefter kan bruge i et Data Wrangler-job. Dette hjælper dig med at genanvende de samme datatransformationer på dine data og også skalere til et distribueret batch-databehandlingsjob, enten som en del af en ML-pipeline eller uafhængigt.

For vejledning om optimering af din Data Wrangler-app i Studio, se del 2 i denne serie.

I dette afsnit fokuserer vi på at optimere Data Wrangler-job.

Data Wrangler bruger SageMaker Spark processing jobs med en Data Wrangler-administreret container. Denne container kører vejledningen fra .flow-filen i jobbet. Som alle andre behandlingsjob debiterer Data Wrangler dig for de instanser, du vælger, baseret på varigheden af brugen og klargjort lagerplads, der er knyttet til den instans.

I Cost Explorer kan du filtrere omkostningerne til Data Wrangler-job ved at anvende et filter på brugstypen. Navnene på disse brugstyper er:

REGION-processing_DW:instanceType (for eksempel, USE1-processing_DW:ml.m5.large)
REGION-processing_DW:VolumeUsage.gp2 (for eksempel, USE1-processing_DW:VolumeUsage.gp2)

For at se dine data Wrangler-omkostninger i Cost Explorer skal du filtrere tjenesten for at bruge SageMaker og for Brugstype, Vælg processing_DW præfiks og vælg listen i menuen. Dette vil vise dig både instansforbrug (timer) og lagervolumen (GB) relaterede omkostninger. (Hvis du vil se Studio Data Wrangler-omkostninger, kan du filtrere brugstypen efter Studio_DW præfiks.)

Tilpas den rigtige størrelse og planlæg Data Wrangler-jobforekomster

I øjeblikket understøtter Data Wrangler kun m5-instanser med følgende instansstørrelser: ml.m5.4xlarge, ml.m5.12xlarge og ml.m5.24xlarge. Du kan bruge den distribuerede jobfunktion til at finjustere dine jobomkostninger. Antag for eksempel, at du skal behandle et datasæt, der kræver 350 GiB i RAM. 4xlarge (128 GiB) og 12xlarge (256 GiB) er muligvis ikke i stand til at behandle og vil føre dig til at bruge m5.24xlarge-forekomsten (768 GiB). Du kan dog bruge to m5.12xlarge instanser (2 * 256 GiB = 512 GiB) og reducere omkostningerne med 40 % eller tre m5.4xlarge instanser (3 * 128 GiB = 384 GiB) og spare 50 % af m5.24xlarge instansomkostninger. Du skal bemærke, at disse er estimater, og at distribueret behandling kan introducere nogle overhead, der vil påvirke den samlede kørselstid.

Når du ændrer instanstypen, skal du sørge for at opdatere Spark config derfor. For eksempel, hvis du har et indledende ml.m5.4xlarge instansjob konfigureret med egenskaber spark.driver.memory sat til 2048 og spark.executor.memory indstillet til 55742, og senere skaleres til ml.m5.12xlarge, skal disse konfigurationsværdier øges, ellers vil de være flaskehalsen i forarbejdningsjobbet. Du kan opdatere disse variabler i Data Wrangler GUI eller i en konfigurationsfil, der er tilføjet til konfigurationsstien (se følgende eksempler).

En anden overbevisende funktion i Data Wrangler er evnen til indstille et planlagt job. Hvis du behandler data med jævne mellemrum, kan du oprette en tidsplan for at køre behandlingsjobbet automatisk. For eksempel kan du oprette en tidsplan, der kører et behandlingsjob automatisk, når du får nye data (for eksempler, se Eksporter til Amazon S3 or Eksporter til Amazon SageMaker Feature Store). Du skal dog bemærke, at når du opretter en tidsplan, opretter Data Wrangler en eventRule i EventBridge. Det betyder, at du også bliver opkrævet for de hændelsesregler, du opretter (samt de forekomster, der bruges til at køre behandlingsjobbet). For mere information, se Amazon EventBridge-priser.

Konklusion

I dette indlæg gav vi vejledning om omkostningsanalyse og bedste praksis ved forbehandling

data ved hjælp af SageMaker Processing og Data Wrangler job. I lighed med forbehandling er der mange muligheder og konfigurationsindstillinger i at bygge, træne og køre ML-modeller, som kan føre til unødvendige omkostninger. Derfor, da maskinlæring etablerer sig som et kraftfuldt værktøj på tværs af brancher, skal ML-arbejdsbelastninger forblive omkostningseffektive.

SageMaker tilbyder et bredt og dybt funktionssæt til at lette hvert trin i ML-pipelinen.

Denne robusthed giver også muligheder for løbende omkostningsoptimering uden at gå på kompromis med ydeevne eller smidighed.

Om forfatterne

Analyze Amazon SageMaker spend and determine cost optimization opportunities based on usage, Part 3: Processing and Data Wrangler jobs | Amazon Web Services PlatoBlockchain Data Intelligence. Vertical Search. Ai. Deepali Rajale er Senior AI/ML Specialist hos AWS. Hun arbejder med virksomhedskunder, der giver teknisk vejledning med bedste praksis for implementering og vedligeholdelse af AI/ML-løsninger i AWS-økosystemet. Hun har arbejdet med en bred vifte af organisationer på forskellige deep learning use cases, der involverer NLP og computervision. Hun brænder for at give organisationer mulighed for at udnytte generativ AI til at forbedre deres brugsoplevelse. I sin fritid nyder hun film, musik og litteratur.

Uri Rosenberg er AI & ML Specialist Technical Manager for Europa, Mellemøsten og Afrika. Med base i Israel arbejder Uri på at give virksomhedskunder i stand til at designe, bygge og drive i stor skala, hvad angår ML. I sin fritid nyder han at cykle, vandre og se solnedgange (minimum én gang om dagen).