Analyser Amazon SageMaker-forbruk og avgjør kostnadsoptimaliseringsmuligheter basert på bruk, del 3: Behandling og data Wrangler-jobber

Publisert av Platon

Følgere: 0

I 2021 lanserte vi AWS-støtte proaktive tjenester som en del av AWS Enterprise Support plan. Siden introduksjonen har vi hjulpet hundrevis av kunder med å optimalisere arbeidsbelastningen, sette rekkverk og forbedre synligheten av maskinlæringsarbeidsbelastningens kostnader og bruk.

I denne serien med innlegg deler vi erfaringer om å optimalisere kostnader i Amazon SageMaker. I dette innlegget fokuserer vi på dataforbehandling ved hjelp av Amazon SageMaker-prosessering og Amazon SageMaker Data Wrangler arbeidsplasser.

Dataforbehandling har en sentral rolle i en datasentrisk AI-tilnærming. Men å forberede rådata for ML-trening og -evaluering er ofte en kjedelig og krevende oppgave når det gjelder dataressurser, tid og menneskelig innsats. Dataforberedelse må vanligvis integreres fra forskjellige kilder og håndtere manglende eller støyende verdier, uteliggere og så videre.

I tillegg til vanlige uttrekks-, transformasjons- og lastoppgaver (ETL), krever ML-team av og til mer avanserte evner som å lage raske modeller for å evaluere data og produsere funksjonsviktighetspoeng eller evaluering av modeller etter trening som en del av en MLOps-pipeline.

SageMaker tilbyr to funksjoner spesielt utviklet for å hjelpe med disse problemene: SageMaker Processing og Data Wrangler. SageMaker Processing lar deg enkelt kjøre forbehandling, etterbehandling og modellevaluering på en fullstendig administrert infrastruktur. Data Wrangler reduserer tiden det tar å samle og forberede data ved å forenkle prosessen med datakildeintegrering og funksjonsutvikling ved å bruke et enkelt visuelt grensesnitt og et fullt distribuert databehandlingsmiljø.

Begge SageMaker-funksjonene gir stor fleksibilitet med flere alternativer for I/O, lagring og beregning. Men å sette disse alternativene feil kan føre til unødvendige kostnader, spesielt når det gjelder store datasett.

I dette innlegget analyserer vi prisfaktorene og gir kostnadsoptimaliseringsveiledning for SageMaker Processing og Data Wrangler-jobber.

SageMaker-behandling

SageMaker Processing er en administrert løsning for å kjøre databehandling og modellevaluering. Du kan bruke den i databehandlingstrinn som funksjonsutvikling, datavalidering, modellevaluering og modelltolkning i ML-arbeidsflyter. Med SageMaker Processing kan du ta med dine egne tilpassede behandlingsskript og velge å bygge en tilpasset beholder eller bruke en SageMaker administrert beholder med vanlige rammeverk som scikit-learn, Lime, Spark og mer.

SageMaker Processing belaster deg for forekomsttypen du velger, basert på bruksvarigheten og klargjort lagring som er knyttet til den forekomsten. I del 1 viste vi hvordan du kommer i gang med å bruke AWS Cost Explorer for å identifisere kostnadsoptimeringsmuligheter i SageMaker.

Du kan filtrere behandlingskostnader ved å bruke et filter på brukstypen. Navnene på disse brukstypene 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 å vurdere SageMaker-behandlingskostnadene dine i Cost Explorer, start med å filtrere med SageMaker for Service, Og for Brukstype, kan du velge alle behandlingsforekomster som kjører timer ved å skrive inn processing:ml prefiks og velge listen på menyen.

Unngå kostnader ved prosessering og utvikling av rørledninger

Før riktig størrelse og optimalisering av en SageMaker Processing-jobbs kjøretid, ser vi etter målinger på høyt nivå om historiske jobbkjøringer. Du kan velge mellom to metoder for å gjøre dette.

Først kan du få tilgang til i prosess siden på SageMaker-konsollen.

Alternativt kan du bruke list_processing_jobs API.

En Behandlingsjobbstatus kan være InProgress, Completed, Failed, Stoppingeller Stopped.

Et høyt antall mislykkede jobber er vanlig ved utvikling av nye MLOps-rørledninger. Du bør imidlertid alltid teste og gjøre alt du kan for å validere jobber før du lanserer dem på SageMaker fordi det er kostnader for ressurser som brukes. Til det formålet kan du bruke SageMaker Processing i lokal modus. Lokal modus er en SageMaker SDK-funksjon som lar deg lage estimatorer, prosessorer og pipelines, og distribuere dem til ditt lokale utviklingsmiljø. Dette er en fin måte å teste skriptene dine på før du kjører dem i et SageMaker-administrert miljø. Lokal modus støttes av SageMaker administrerte containere og de du leverer selv. For å lære mer om hvordan du bruker lokal modus med Amazon SageMaker-rørledninger, referere til Lokal modus.

Optimaliser I/O-relaterte kostnader

SageMaker Processing-jobber gir tilgang til tre datakilder som en del av den administrerte behandle input: Amazon enkel lagringstjeneste (Amazon S3), Amazonas Athenaog Amazon RedShift. For mer informasjon, se ProcessingS3Input, AthenaDatasetDefinitionog RedshiftDatasetDefinitionHhv.

Før du ser nærmere på optimalisering, er det viktig å merke seg at selv om SageMaker Processing-jobber støtter disse datakildene, er de ikke obligatoriske. I behandlingskoden din kan du implementere hvilken som helst metode for å laste ned tilgangsdataene fra en hvilken som helst kilde (forutsatt at behandlingsforekomsten har tilgang til dem).

For å få bedre innsikt i behandlingsytelse og oppdage optimaliseringsmuligheter, anbefaler vi å følge med beste fremgangsmåter for logging i behandlingsskriptet ditt. SageMaker publiserer behandlingsloggene dine til Amazon CloudWatch.

I følgende eksempeljobblogg ser vi at skriptbehandlingen tok 15 minutter (mellom Start custom script og End custom script).

På SageMaker-konsollen ser vi imidlertid at jobben tok ytterligere 4 minutter (nesten 25 % av jobbens totale kjøretid).

Dette skyldes det faktum at i tillegg til tiden vårt behandlingsskript tok, tok SageMaker-administrerte datanedlasting og opplasting også tid (4 minutter). Hvis dette viser seg å være en stor del av kostnadene, bør du vurdere alternative måter å øke nedlastingstiden på, for eksempel å bruke Boto3 API med multiprosessering for å laste ned filer samtidig, eller bruke tredjepartsbiblioteker som WebDataset eller s5cmd for raskere nedlasting fra Amazon S3 . For mer informasjon, se Parallelliserer S3-arbeidsbelastninger med s5cmd. Merk at slike metoder kan introdusere avgifter i Amazon S3 pga data overføring.

Behandlingsjobber støtter også Rørmodus. Med denne metoden strømmer SageMaker inndata fra kilden direkte til behandlingsbeholderen din til navngitte rør uten å bruke ML-lagringsvolumet, og eliminerer dermed datanedlastingstiden og et mindre diskvolum. Dette krever imidlertid en mer komplisert programmeringsmodell enn bare å lese fra filer på en disk.

Som nevnt tidligere støtter SageMaker Processing også Athena og Amazon Redshift som datakilder. Når du setter opp en behandlingsjobb med disse kildene, kopierer SageMaker automatisk dataene til Amazon S3, og behandlingsforekomsten henter dataene fra Amazon S3-lokasjonen. Men når jobben er fullført, er det ingen administrert oppryddingsprosess, og dataene som kopieres vil fortsatt forbli i Amazon S3 og kan medføre uønskede lagringskostnader. Derfor, når du bruker Athena og Amazon Redshift-datakilder, sørg for å implementere en oppryddingsprosedyre, for eksempel en Lambda-funksjon som kjører etter en tidsplan eller i en Lambda Step som en del av en SageMaker-pipeline.

I likhet med nedlasting kan opplasting av behandlingsartefakter også være en mulighet for optimalisering. Når en behandlingsjobbs utdata er konfigurert ved hjelp av ProcessingS3Output parameter, kan du spesifisere hvilken S3UploadMode å bruke. De S3UploadMode parameterens standardverdi er EndOfJob, som vil få SageMaker til å laste opp resultatene etter at jobben er fullført. Hvis behandlingsjobben din produserer flere filer, kan du imidlertid angi S3UploadMode til Continuous, og muliggjør dermed opplasting av artefakter samtidig som behandlingen fortsetter, og reduserer jobbens kjøretid.

Behandlingsjobbforekomster i riktig størrelse

Å velge riktig forekomsttype og -størrelse er en viktig faktor for å optimalisere kostnadene for SageMaker Processing-jobber. Du kan justere størrelsen på en forekomst ved å migrere til en annen versjon innenfor samme forekomstfamilie eller ved å migrere til en annen forekomstfamilie. Når du migrerer innenfor samme forekomstfamilie, trenger du bare å vurdere CPU/GPU og minne. For mer informasjon og generell veiledning om valg av riktig behandlingsressurs, se Sørg for effektive dataressurser på Amazon SageMaker.

For å finjustere forekomstvalg starter vi med å analysere Processing job-metrics i CloudWatch. For mer informasjon, se Overvåk Amazon SageMaker med Amazon CloudWatch.

CloudWatch samler inn rådata fra SageMaker og behandler dem til lesbare, nesten sanntidsmålinger. Selv om denne statistikken oppbevares i 15 måneder, begrenser CloudWatch-konsollen søket til beregninger som ble oppdatert i løpet av de siste 2 ukene (dette sikrer at kun nåværende jobber vises). Behandlingsjobbberegninger kan finnes i /aws/sagemaker/ProcessingJobs navneområdet, og beregningene som samles inn er CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationog DiskUtilization.

Følgende skjermbilde viser et eksempel i CloudWatch på behandlingsjobben vi så tidligere.

I dette eksemplet ser vi gjennomsnittlig CPU og minneverdier (som er standard i CloudWatch): gjennomsnittlig CPU-bruk er 0.04 %, minne 1.84 % og diskbruk 13.7 %. For å justere størrelsen bør du alltid vurdere maksimal CPU- og minnebruk (i dette eksemplet var maksimal CPU-utnyttelse 98 % i løpet av de første 3 minuttene). Som en generell regel, hvis maksimal CPU- og minnebruk konsekvent er mindre enn 40 %, kan du trygt kutte maskinen i to. Hvis du for eksempel brukte en ml.c5.4xlarge-forekomst, kan du flytte til en ml.c5.2xlarge, noe som kan redusere kostnadene med 50 %.

Data Wrangler kontaktinformasjon management

Data Wrangler er en funksjon av Amazon SageMaker Studio som gir en repeterbar og skalerbar løsning for datautforskning og -behandling. Du bruker Data Wrangler-grensesnittet til interaktivt å importere, analysere, transformere og presentere dataene dine. Disse trinnene er fanget opp i en oppskrift (en .flow-fil) som du deretter kan bruke i en Data Wrangler-jobb. Dette hjelper deg med å bruke de samme datatransformasjonene på nytt på dataene dine og også skalere til en distribuert batch-databehandlingsjobb, enten som en del av en ML-pipeline eller uavhengig.

For veiledning om optimalisering av Data Wrangler-appen i Studio, se del 2 i denne serien.

I denne delen fokuserer vi på å optimalisere Data Wrangler-jobber.

Data Wrangler bruker SageMaker Spark prosesseringsjobber med en Data Wrangler-administrert beholder. Denne beholderen kjører instruksjonene fra .flow-filen i jobben. Som alle behandlingsjobber, belaster Data Wrangler deg for forekomstene du velger, basert på bruksvarigheten og klargjort lagring som er knyttet til den forekomsten.

I Cost Explorer kan du filtrere Data Wrangler-jobbkostnadene ved å bruke et filter på brukstypen. Navnene på disse brukstypene 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 å se dine Data Wrangler-kostnader i Cost Explorer, filtrer tjenesten for å bruke SageMaker og for Brukstype, Velg processing_DW prefiks og velg listen på menyen. Dette vil vise deg både forekomstbruk (timer) og lagringsvolum (GB) relaterte kostnader. (Hvis du vil se Studio Data Wrangler-kostnadene, kan du filtrere brukstypen etter Studio_DW prefiks.)

Riktig størrelse og planlegg Data Wrangler-jobbforekomster

For øyeblikket støtter Data Wrangler bare m5-forekomster med følgende forekomststørrelser: ml.m5.4xlarge, ml.m5.12xlarge og ml.m5.24xlarge. Du kan bruke funksjonen for distribuert jobb til å finjustere jobbkostnadene. Anta for eksempel at du må behandle et datasett som krever 350 GiB i RAM. 4xlarge (128 GiB) og 12xlarge (256 GiB) kan kanskje ikke behandles og vil føre deg til å bruke m5.24xlarge-forekomsten (768 GiB). Du kan imidlertid bruke to m5.12xlarge forekomster (2 * 256 GiB = 512 GiB) og redusere kostnadene med 40 % eller tre m5.4xlarge forekomster (3 * 128 GiB = 384 GiB) og spare 50 % av m5.24xlarge forekomstkostnad. Du bør merke deg at dette er estimater og at distribuert behandling kan introdusere noen overhead som vil påvirke den totale kjøretiden.

Når du endrer forekomsttype, sørg for at du oppdaterer Gnistkonfig tilsvarende. For eksempel, hvis du har en innledende ml.m5.4xlarge forekomstjobb konfigurert med egenskaper spark.driver.memory satt til 2048 og spark.executor.memory satt til 55742, og senere skaleres opp til ml.m5.12xlarge, må disse konfigurasjonsverdiene økes, ellers vil de være flaskehalsen i prosesseringsjobben. Du kan oppdatere disse variablene i Data Wrangler GUI eller i en konfigurasjonsfil som er lagt til konfigurasjonsbanen (se følgende eksempler).

En annen overbevisende funksjon i Data Wrangler er muligheten til angi en planlagt jobb. Hvis du behandler data med jevne mellomrom, kan du opprette en tidsplan for å kjøre behandlingsjobben automatisk. Du kan for eksempel opprette en tidsplan som kjører en behandlingsjobb automatisk når du får nye data (for eksempler, se Eksporter til Amazon S3 or Eksporter til Amazon SageMaker Feature Store). Du bør imidlertid merke deg at når du oppretter en tidsplan, oppretter Data Wrangler en eventRule i EventBridge. Dette betyr at du også blir belastet for hendelsesreglene du oppretter (samt forekomstene som brukes til å kjøre behandlingsjobben). For mer informasjon, se Amazon EventBridge-priser.

konklusjonen

I dette innlegget ga vi veiledning om kostnadsanalyse og beste praksis ved forbehandling

data ved hjelp av SageMaker Processing og Data Wrangler-jobber. I likhet med forbehandling er det mange alternativer og konfigurasjonsinnstillinger i å bygge, trene og kjøre ML-modeller som kan føre til unødvendige kostnader. Derfor, ettersom maskinlæring etablerer seg som et kraftig verktøy på tvers av bransjer, må ML-arbeidsmengder forbli kostnadseffektive.

SageMaker tilbyr et bredt og dypt funksjonssett for å forenkle hvert trinn i ML-pipelinen.

Denne robustheten gir også muligheter for kontinuerlig kostnadsoptimalisering uten at det går på bekostning av ytelse eller smidighet.

Om forfatterne

Analyser Amazon SageMakers forbruk og finn kostnadsoptimaliseringsmuligheter basert på bruk, del 3: Behandling og data Wrangler-jobber | Amazon Web Services PlatoBlockchain Data Intelligence. Vertikalt søk. Ai. Deepali Rajale er senior AI/ML-spesialist hos AWS. Hun jobber med bedriftskunder som gir teknisk veiledning med beste praksis for distribusjon og vedlikehold av AI/ML-løsninger i AWS-økosystemet. Hun har jobbet med et bredt spekter av organisasjoner på ulike brukssaker for dyp læring som involverer NLP og datasyn. Hun brenner for å gi organisasjoner mulighet til å utnytte generativ AI for å forbedre brukeropplevelsen deres. På fritiden liker hun film, musikk og litteratur.

Uri Rosenberg er AI & ML Specialist Technical Manager for Europa, Midtøsten og Afrika. Basert fra Israel, jobber Uri for å gi bedriftskunder i stand til å designe, bygge og drive i stor skala på alt innen ML. På fritiden liker han å sykle, gå på fotturer og se på solnedganger (minst en gang om dagen).