När företagsföretag anammar maskininlärning (ML) i sina organisationer tenderar manuella arbetsflöden för att bygga, utbilda och implementera ML-modeller att bli flaskhalsar för innovation. För att övervinna detta måste företag forma en tydlig verksamhetsmodell som definierar hur flera personer, såsom datavetare, dataingenjörer, ML-ingenjörer, IT och affärsintressenter, ska samarbeta och interagera; hur man kan separera bekymmer, ansvar och färdigheter; och hur man använder AWS-tjänster optimalt. Denna kombination av ML och operations (MLOps) hjälper företag att effektivisera sin end-to-end ML-livscykel och öka produktiviteten för datavetare samtidigt som de bibehåller hög modellnoggrannhet och förbättrar säkerhet och efterlevnad.
I det här inlägget lär du dig om nyckelfaserna för att bygga en MLOps-stiftelse, hur flera personer arbetar tillsammans på den här grunden, och Amazon SageMaker specialbyggda verktyg och inbyggda integrationer med andra AWS-tjänster som kan påskynda införandet av ML i en företagsverksamhet.
MLOps mognadsmodell
Att bygga en MLOps-grund som kan täcka företagskunders verksamhet, människor och teknologibehov är utmanande. Därför definierar vi följande mognadsmodell som definierar de nödvändiga kapaciteterna hos MLOps i fyra nyckelfaser.
- Inledande fas: Under denna fas kan dataforskarna experimentera och bygga, träna och distribuera modeller på AWS med SageMaker-tjänster. Den föreslagna utvecklingsmiljön är Amazon SageMaker Studio, där dataforskarna kan experimentera och samarbeta baserat på Studio-anteckningsböcker.
- Upprepningsbar fas – Med möjligheten att experimentera på AWS är nästa steg att skapa automatiska arbetsflöden för att förbehandla data och bygga och träna modeller (ML pipelines). Dataforskare samarbetar med ML-ingenjörer i en separat miljö för att bygga robusta och produktionsklara algoritmer och källkod, orkestrerad med Amazon SageMaker-rörledningar. De genererade modellerna lagras och benchmarkas i Amazon SageMakers modellregister.
- Pålitlig fas – Även om modellerna har genererats via ML-pipelines måste de testas innan de flyttas till produktion. Därför, i denna fas, introduceras den automatiska testmetoden, för både modellen och triggande infrastruktur, i en isolerad stadiemiljö (förproduktion) som simulerar produktion. Efter en framgångsrik körning av testet distribueras modellerna till den isolerade produktionsmiljön. För att marknadsföra modellerna bland de flera miljöerna krävs manuell utvärdering och godkännanden.
- Skalbar fas – Efter produktionen av den första ML-lösningen är det nödvändigt att skala MLOps-grunden för att stödja flera datavetenskapliga team för att samarbeta och producera tiotals eller hundratals ML-användningsfall. I denna fas introducerar vi malliseringen av lösningarna, vilket ger hastighet till värde genom att minska utvecklingstiden för nya produktionslösningar från veckor till dagar. Dessutom automatiserar vi instansieringen av säkra MLOps-miljöer för att göra det möjligt för flera team att arbeta på sina data, vilket minskar beroendet och overhead till IT.
I följande avsnitt visar vi hur man bygger en MLOps-grund baserat på den föregående mognadsmodellen och följande principer:
- Flexibilitet – Dataforskare kan hantera vilket ramverk som helst (som TensorFlow eller PyTorch)
- reproducerbarhet – Dataforskare kan återskapa eller observera tidigare experiment (kod, data och resultat)
- reus Förmåga – Dataforskare och ML-ingenjörer kan återanvända källkod och ML-pipelines, vilket undviker inkonsekvenser och kostnader
- skalbarhet – Datavetare och ML-ingenjörer kan skala resurser och tjänster på begäran
- gransking – Datavetare, IT och juridiska avdelningar kan granska loggar, versioner och beroenden av artefakter och data
- Konsistens – Eftersom MLOps består av flera miljöer måste grunden eliminera variationer mellan miljöer
Inledande fas
I den inledande fasen är målet att skapa en säker experimentmiljö där dataforskaren får ögonblicksbilder av data och experiment med SageMaker-anteckningsböcker för att bevisa att ML kan lösa ett specifikt affärsproblem. För att uppnå detta rekommenderas en Studio-miljö med skräddarsydd tillgång till tjänster via VPC-slutpunkter. Källkoden för referensarkitekturen är tillgänglig i exemplen som tillhandahålls av SageMaker-teamet på Säker datavetenskap med Amazon SageMaker Studio Reference Architecture GitHub -repo.
Utöver SageMakers tjänster kan datavetare använda andra tjänster för att bearbeta uppgifterna, som t.ex Amazon EMR, Amazonas Athenaoch AWS-lim, med anteckningsböcker lagrade och versionerade i AWS CodeCommit repositories (se följande figur).
Upprepningsbar fas
Efter att dataforskarna har bevisat att ML kan lösa affärsproblemet och är bekanta med SageMakers experiment, utbildning och implementering av modeller, är nästa steg att börja producera ML-lösningen. Följande figur illustrerar denna arkitektur.
I detta skede är det nödvändigt med separation av oro. Vi delar upp miljön i flera AWS-konton:
- Datasjön – Lagrar all intagen data från lokaler (eller andra system) till molnet. Dataingenjörer kan skapa extrahera, transformera och ladda (ETL) pipelines som kombinerar flera datakällor och förbereda nödvändiga datauppsättningar för ML-användningsfallen. Data katalogiseras via AWS Glue Data Catalog och delas med andra användare och konton via AWS Lake Formation (datastyrningsskiktet). På samma konto, Amazon SageMaker Feature Store kan vara värd, men vi täcker det inte detta inlägg. För mer information, se Aktivera återanvändning av funktioner över konton och team med Amazon SageMaker Feature Store.
- Experimenterande – Gör det möjligt för datavetare att bedriva sin forskning. Den enda skillnaden är att ursprunget för dataögonblicksbilderna är datasjön. Dataforskare har endast åtkomst till specifika datamängder, som kan anonymiseras i händelse av GDPR eller andra datasekretessbegränsningar. Dessutom kan experimentkontot ha tillgång till internet för att göra det möjligt för datavetare att använda nya datavetenskapliga ramverk eller tredjepartsbibliotek med öppen källkod. Därför betraktas experimentkontot som en del av icke-produktionsmiljön.
- Utveckling (dev) – Det första steget i produktionsmiljön. Dataforskarna flyttar från bärbara datorer till en värld av automatiska arbetsflöden och SageMaker Pipelines. De måste samarbeta med ML-ingenjörer för att abstrahera sin kod och säkerställa täckning av testning, felhantering och kodkvalitet. Målet är att utveckla ML-pipelines, som är automatiska arbetsflöden som förbearbetar, tränar, utvärderar och registrerar modeller till SageMakers modellregister. Utplaceringen av ML-pipelines drivs endast via CI/CD-pipelines, och tillgången till AWS Management Console är begränsad. Internetanslutning är inte tillåten eftersom ML-pipeline har tillgång till produktionsdata i datasjön (skrivskyddad).
- Verktyg (eller automatisering) – Värd för CodeCommit-arkiven, AWS CodePipeline CI/CD-pipelines, SageMaker-modellregistret och Amazon ECR för att vara värd för anpassade behållare. Eftersom datasjön är den enda sanningspunkten för data, är verktygskontot för koden, behållarna och producerade artefakter.
Observera att den här kontonamnskonventionen och strategin för flera konton kan variera beroende på dina affärsbehov, men den här strukturen är avsedd att visa de rekommenderade nivåerna av isolering. Du kan till exempel byta namn på utvecklingskontot till modellutbildnings- eller byggkontot.
För att uppnå automatisk distribution är det viktigt att förstå hur man går från bärbara datorer till ML-pipelines och standardiserar kodförråden och datastrukturen, vilket vi diskuterar i följande avsnitt.
Från bärbara datorer till ML pipelines
Målet med utvecklingsmiljön är att omstrukturera, utöka, förbättra och skala koden i bärbara datorer och flytta den till ML-pipelines. En ML-pipeline är en uppsättning steg som ansvarar för förbearbetning av data, utbildning eller användning av modeller och efterbearbetning av resultaten. Varje steg ska utföra en exakt uppgift (en specifik transformation) och vara tillräckligt abstrakt (till exempel skicka kolumnnamn som indataparametrar) för att möjliggöra återanvändning. Följande diagram illustrerar ett exempel på pipeline.
För att implementera ML-pipelines använder datavetare (eller ML-ingenjörer) SageMaker Pipelines. En SageMaker-pipeline är en serie sammankopplade steg (SageMaker-bearbetningsjobb, utbildning, HPO) som definieras av en JSON-pipelinedefinition med en Python SDK. Denna pipelinedefinition kodar en pipeline med hjälp av en Directed Acyclic Graph (DAG). Denna DAG ger information om kraven för och relationerna mellan varje steg i din ML-pipeline.
Beroende på användningsfallet kan du dela upp ML-pipeline i två huvudtyper: utbildning och batch-inferens.
Följande figur illustrerar träningsflödet för ML-pipeline.
Förbehandlingsfasen kan bestå av flera steg. Vanliga datavetenskapliga transformationer är datadelning och sampling (tåg, validering, testset), en-hot-kodning eller vektorisering, binning och skalning. Modellträningssteget kan vara antingen ett träningsjobb, om dataforskaren är medveten om den bästa modellkonfigurationen, eller ett hyperparameteroptimeringsjobb (HPO), där AWS definierar de bästa hyperparametrarna för modellen (bayesiansk metod) och producerar motsvarande modellartefakt. I utvärderingssteget används den producerade modellartefakten för att göra slutledning till valideringsdatauppsättningen. Sedan kontrollerar ML-pipelinen om de producerade noggrannhetsmåtten (som F1, precision och förstärkningsdeciler) passerar de nödvändiga tröskelvärdena. Om detta steg lyckas flyttas modellartefakter och metadata till modellregistret för produktion. Observera att exportbaslinjesteget utnyttjar Amazon SageMaker modellmonitor funktionalitet, som producerar ett JSON-objekt med statistiken som senare används för att detektera modelldrift och som kan lagras i SageMakers modellregister som modellmetadata.
Vid batch-inferens kan dataforskarna skapa liknande pipelines, som illustreras i följande figur.
Förbearbetningssteget för batch-inferens är ofta detsamma som träning genom att utesluta datasampling och kolumnen för grundsanning. Batch-inferens är steget som skickar data i batcher för slutledning till motsvarande slutpunkt, och kan implementeras genom att använda batch-omvandling. Efterbearbetningssteget producerar ytterligare statistik, såsom resultatfördelning, eller sammanfogar resultaten med externa ID:n. Sedan kan ett modellövervakningssteg jämföra baslinjestatistiken för data som används för träning (modell JSON-metadata i modellregistret) med nya inkommande data för slutledning.
Du kan hoppa över förbearbetningsstegen om dataforskarna skapar pipelinemodeller som kan lagras i SageMakers modellregister. För mer information, se Värdmodeller tillsammans med förbearbetningslogik som seriell slutledningspipeline bakom en slutpunkt.
Standardisera förråd
För att möjliggöra samarbetet mellan datavetare och ML-ingenjörer är standardiseringen av kodförrådets struktur nödvändig. Dessutom är standardisering fördelaktigt för CI/CD-pipelinestrukturen, vilket möjliggör inkorporering av automatisk validering, byggnad (som anpassad containerbyggnad) och teststeg.
Följande exempel illustrerar uppdelningen av ML-lösningarna i två förråd: ett byggnads- och utbildningsförråd för utbildning (och eventuellt pipelinemodell) och distribution för att främja batch-inferenspipelinemodellerna eller instansiera realtidsslutpunkterna:
Byggnads-/träningsförråd
Distributionsförråd
Byggnads- och utbildningsförvaret är uppdelat i tre huvudmappar:
- Algoritmer – Dataforskare utvecklar koden för varje steg i ML-pipelines i algoritmernas rotmapp. Stegen kan grupperas i förbearbetning, utbildning, batch slutledning och efterbearbetning (utvärdering). I varje grupp kan flera steg definieras i motsvarande undermappar, som innehåller en mapp för enhetstesterna (inklusive valfria ingångar och utgångar), huvudfunktionerna, readme och en Docker-fil vid behov av en anpassad container. Förutom main kan flera kodfiler lagras i samma mapp. Gemensamma hjälpbibliotek för alla steg kan lagras i en delad biblioteksmapp. Dataforskarna är ansvariga för utvecklingen av enhetstesterna eftersom de äger logiken i stegen, och ML-ingenjörer ansvarar för förbättringen av felhanteringen och rekommendationen för testtäckning. CI/CD-pipelinen ansvarar för att köra testerna, bygga behållarna automatiskt (om nödvändigt) och paketera de flera källkodsfilerna.
- ML pipelines – När du har utvecklat källkoden och testerna för varje steg är nästa steg att definiera SageMaker-pipelines i en annan rotmapp. Varje ML-pipelinedefinition placeras i en undermapp som innehåller .py-filen och en JSON- eller .yaml-fil för indataparametrar, såsom hyperparameterintervall. En readme-fil för att beskriva ML-pipelines är nödvändig.
- bärbara datorer – Den här mappen är värd för ursprungsanteckningsböckerna som dataforskaren använde under experiment.
Utbyggnadsförrådet består av tre huvuddelar:
- Slutledningskonfiguration – Innehåller konfigurationen av realtidsslutpunkter eller batchinferens per utvecklingsmiljö, såsom instanstyper.
- Applikationsinfrastruktur – Värd för källkoden för den infrastruktur som krävs för att köra slutledningen, om det behövs. Detta kan vara en utlösande mekanism via Amazon EventBridge, Amazon API Gateway, AWS Lambda funktioner eller SageMaker Pipelines.
- Tester – Består av flera undermappar beroende på kundens testmetod. Som den minsta uppsättningen av tester föreslår vi ett integrationstest (end-to-end körning av slutledning inklusive applikationsinfrastruktur), stresstest (undersök kantfall) och ML-tester (som fördelningen av konfidenspoäng eller sannolikheter).
Genom att utföra ändringar i byggnads- och utbildningsförvaret ansvarar en CI/CD-pipeline för att validera förvarsstrukturen, utföra testerna och distribuera och köra ML-pipelines. En annan CI/CD-pipeline är ansvarig för att marknadsföra modellerna, vilket vi undersöker i följande avsnitt.
Standardisera repository branching och CI/CD
För att säkerställa robustheten hos ML-pipelines i utvecklarkontot, föreslås en strategi för flera grenar, medan distributionen endast utförs via CI/CD-pipelines. Dataforskare bör använda en funktionsgren för att utveckla sin nya funktionalitet (källkod). När de är redo att distribuera motsvarande ML-pipelines kan de skicka detta till utvecklingsgrenen. Ett alternativ till detta tillvägagångssätt är att tillåta distribution av ML-pipelines per funktionsgren. För mer information, se Förbättra ditt datavetenskapliga arbetsflöde med en MLOps-pipeline med flera grenar med AWS.
Följande figur illustrerar förgreningsstrategin och de nödvändiga CI/CD-pipeline-stegen som vi kör i utvecklingsmiljön för ML-pipeline- och modellbyggnad.
Kodexemplet på tillvägagångssättet med flera grenar är tillgängligt i Multi-Branch MLOps utbildning pipeline. Vi kan lagra modellerna som produceras av en funktionsgrenbaserad ML-pipeline i en separat funktionsmodellgrupp och avveckla dem under en sammanslagningsförfrågan med huvudgrenen. Modellerna i huvudmodellgruppen är de som främjas till produktion.
Standardisering av datastruktur
Lika viktigt för källkodsstandardisering är strukturstandardiseringen av data, vilket gör det möjligt för datavetare och ML-ingenjörer att felsöka, granska och övervaka ursprunget och historiken för modellerna och ML-pipelines. Följande diagram illustrerar ett sådant exempel.
För enkelhetens skull, låt oss anta att indata historiska data hamnar i en hink av utvecklingskontot under inmatningsundernyckeln (normalt ligger denna i datasjön). För varje ML-användningsfall måste en separat undernyckel skapas. För att trigga en ny ML-pipeline att köra, bör dataforskaren utföra en git-commit och push, vilket triggar CI/CD-pipelinen. Sedan skapar CI/CD-pipelinen en undernyckel genom att kopiera kodartefakterna (den code
undernyckel) och indata (den input
undernyckel) under en underpartition av bygg-ID:t. Som ett exempel, bygg-ID cvara en kombination av datum-tid och git-hash, eller ett SageMaker pipeline-körnings-ID. Den här strukturen gör det möjligt för dataforskaren att granska och fråga efter tidigare implementeringar och körningar. Efter detta distribuerar CI/CD-pipeline och triggar ML-pipeline. Medan ML-pipelinen körs exporterar varje steg mellanresultaten till ml-pipeline-outputs
. Det är viktigt att komma ihåg att olika funktionsgrenar distribuerar och kör en ny instans av ML Pipeline och att var och en behöver exportera de mellanliggande resultaten till olika undermapp med en ny undernyckel och/eller ett standardiserat prefix eller suffix som inkluderar funktionsgren-id.
Detta tillvägagångssätt stöder fullständig granskningsbarhet för varje experiment. Utvecklingsstrategins multi-branching approach genererar dock en stor mängd data. Därför är en datalivscykelstrategi nödvändig. Vi föreslår att du tar bort åtminstone data för varje funktionsgren ML-pipeline i varje framgångsrik pull/merge-begäran. Men detta beror på vilken verksamhetsmodell och granularitet som ditt företag behöver stödja. Du kan använda ett liknande tillvägagångssätt i ML-pipelines för batchinferens
Pålitlig fas
Efter den första separationen av bekymmer mellan datavetare, ML-ingenjörer och dataingenjörer genom att använda flera konton, är nästa steg att marknadsföra de producerade modellerna från modellregistret till en isolerad miljö för att utföra slutledningar. Vi måste dock säkerställa robustheten hos de utplacerade modellerna. Därför är en simulering av den utplacerade modellen till en spegelmiljö av produktion obligatorisk, nämligen förproduktion (eller iscensättning).
Följande figur illustrerar denna arkitektur.
Marknadsföringen av en modell- och slutpunktsdistribution i förproduktionsmiljön utförs med hjälp av modellregistrets statusuppdateringshändelser (eller git push på distributionsförrådet), vilket utlöser en separat CI/CD-pipeline genom att använda EventBridge-händelser. Det första steget i CI/CD-pipelinen kräver ett manuellt godkännande av den ledande dataforskaren (och eventuellt produktägaren, affärsanalytikern eller andra ledande dataforskare). Godkännaren måste validera prestanda-KPI:erna för modellen och QA för koden i distributionsförrådet. Efter godkännandet kör CI/CD-pipeline testkoden till distributionsförvaret (integrationstest, stresstest, ML-test). Utöver modellens slutpunkt testar CI/CD även den utlösande infrastrukturen, såsom EventBridge, Lambda-funktioner eller API Gateway. Följande diagram visar denna uppdaterade arkitektur.
Efter framgångsrik körning av testerna meddelar CI/CD-pipelinen de nya (eller samma) godkännarna att en modell är redo att marknadsföras till produktion. I detta skede kanske affärsanalytikern vill utföra några ytterligare statistiska hypoteser på resultaten av modellen. Efter godkännandet sätts modellerna och den utlösande infrastrukturen ut i produktionen. Flera distributionsmetoder stöds av SageMaker, såsom blå/grön, kanariefågel och A/B-testning (se mer i Utsättningsskyddsräcken). Om CI/CD-pipelinen misslyckas, återställer en återställningsmekanism systemet till det senaste robusta tillståndet.
Följande diagram illustrerar huvudstegen i CI/CD-pipelinen för att främja en modell och infrastrukturen för att trigga modellens slutpunkt, såsom API Gateway, Lambda-funktioner och EventBridge.
Data Lake och MLOps integration
Vid det här laget är det viktigt att förstå datakraven per utvecklingsstadium eller konto, och sättet att integrera MLOps med en centraliserad datasjö. Följande diagram illustrerar MLOps- och datasjöskikten.
I datasjön är dataingenjörerna ansvariga för att sammanfoga flera datakällor och skapa motsvarande datamängder (till exempel en enda tabell med strukturdata, eller en enda mapp med PDF-filer eller bilder) för ML-användningsfallen genom att bygga ETL pipelines enligt definitionen av dataforskarna (under analysfasen av prospekteringsdata). Dessa datamängder kan delas upp i historiska data och data för slutledning och testning. All data är katalogiserad (till exempel med AWS Glue Data Catalog) och kan delas med andra konton och användare genom att använda Lake Formation som ett datastyrningslager (för strukturerad data). När detta skrivs är Lake Formation endast kompatibel med Athena-frågor, AWS Glue-jobb och Amazon EMR.
Å andra sidan behöver MLOps-miljön bevattna ML-pipelines med specifika datauppsättningar som finns i lokala hinkar i dev, pre-prod och prod. Utvecklingsmiljön ansvarar för att bygga och träna modellerna på begäran med hjälp av SageMaker-pipelines som hämtar data från datasjön. Därför föreslår vi som det första steget i pipelinen att antingen ha ett Athena-steg, där endast datasampling och sökning krävs, eller ett Amazon EMR-steg, om mer komplexa transformationer krävs. Alternativt kan du använda ett AWS Glue-jobb via ett återuppringningssteg, men ännu inte som ett inbyggt steg med SageMaker Pipelines.
Pre-prod och prod är ansvariga för att antingen testa eller genomföra realtids- och batch slutledning. I fallet med realtidsinferens är det inte nödvändigt att skicka data till MLOps pre-prod och prod konton eftersom indata för slutledning kan piggy-back på nyttolasten för API Gateway-begäran. I fallet med batch-inferens (eller indata av stor storlek), måste nödvändiga datauppsättningar, antingen testdata eller data för slutledning, hamna i de lokala ML-datahinkarna (pre-prod eller prod). Du har två alternativ för att flytta data till pre-prod och prod: antingen genom att trigga Athena eller Amazon EMR och dra data från datasjön, eller skicka data från datasjön till dessa MLOps-konton. Det första alternativet kräver utveckling av ytterligare mekanismer i MLOps-kontona, till exempel skapa schemalagda EventBridge-händelser (utan att veta om data i datasjön har uppdaterats) eller on-data ankomst i S3 EventBridge-händelser i datasjön (för mer detaljer, se Förenkla åtkomst över flera konton med Amazon EventBridge resurspolicyer). Efter att ha fångat händelsen på MLOps-sidan kan en Athena-fråga eller Amazon EMR hämta data lokalt och utlösa asynkron slutledning or batch-omvandling. Detta kan lindas in i en SageMaker-pipeline för enkelhetens skull. Det andra alternativet är att i det sista steget av ETL-pipelinen lägga till funktionen att skicka data till MLOps-buckets. Detta tillvägagångssätt blandar dock ansvarsområden (datasjön utlöser slutledning) och kräver att Lake Formation ger åtkomst till datasjön för att skriva i MLOps-hinkarna.
Det sista steget är att flytta slutledningsresultaten tillbaka till datasjön. För att katalogisera data och göra den tillgänglig för andra användare bör data återgå som en ny datakälla tillbaka till landningshinken.
Skalbar fas
Efter utvecklingen av MLOps-grunden och end-to-end-produktionen av det första ML-användningsfallet, har infrastrukturen för dev, pre-prod, prod och arkivet, CI/CD-pipeline och datastruktur testats och slutförts . Nästa steg är att ta med nya ML-användningsfall och team till plattformen. För att säkerställa hastighet till värde låter SageMaker dig skapa anpassade SageMaker-projektmallar, som du kan använda för att instansiera malllager och CI/CD-pipelines automatiskt. Med sådana SageMaker-projektmallar är de ledande dataforskarna ansvariga för att instansiera nya projekt och tilldela ett dedikerat team per nya ML-användningsfall.
Följande diagram illustrerar denna process.
Problemet blir mer komplext om olika dataforskarteam (eller flera affärsenheter som behöver producera ML) har tillgång till olika konfidentiell data, och flera produktägare är ansvariga för att betala en separat räkning för utbildning, driftsättning och drift av modellerna . Därför krävs en separat uppsättning MLOps-konton (experiment, dev, pre-prod och prod) per team. För att göra det enkelt att skapa nya MLOps-konton introducerar vi ett annat konto, det avancerade analytics-styrningskontot, som är tillgängligt för IT-medlemmar och låter dem katalogisera, instansiera eller avveckla MLOps-konton på begäran. Specifikt är detta konto värd för repositories med infrastrukturkoden för MLOps-kontona (VPC, undernät, slutpunkter, hinkar, AWS identitets- och åtkomsthantering (IAM) roller och policyer, AWS molnformation staplar), en AWS servicekatalog produkt för att automatiskt distribuera CloudFormation-stackarna i infrastrukturen till flera konton med ett klick och en Amazon DynamoDB tabell för att katalogisera metadata, till exempel vilket team som är ansvarigt för varje uppsättning konton. Med denna förmåga instansierar IT-teamet MLOps-konton på begäran och allokerar nödvändiga användare, dataåtkomst per konto och konsekventa säkerhetsbegränsningar.
Baserat på detta scenario separerar vi kontona till tillfälliga och hållbara. Datasjö och verktyg är hållbara konton och spelar rollen som en enda sanningspunkt för data respektive källkod. MLOps-konton är för det mesta statslösa och kan instansieras eller avvecklas på begäran, vilket gör dem tillfälliga. Även om en uppsättning MLOps-konton avvecklas, kan användarna eller revisorerna kontrollera tidigare experiment och resultat eftersom de lagras i hållbara miljöer.
Om du vill använda Studio UI för MLOps är verktygskontot en del av utvecklarkontot, enligt följande figur.
Om användaren vill använda Sagemaker Studio UI för MLOps är verktygskontot en del av utvecklaren
konto enligt figuren ovan. Exempel på källkod för denna MLOPs-stiftelse finns i
Säker multi-konto MLOps foundation baserad på CDK.
Observera att Sagemaker tillhandahåller möjligheten att ersätta CodeCommit och CodePipeline med andra utvecklingsverktyg från tredje part, såsom GitHub och Jenkins (mer information finns i Skapa Amazon SageMaker-projekt använder tredjeparts källkontroll och Jenkins och Amazon SageMaker Projects MLOps Mall med GitLab och GitLab Pipelines).
Personas, verksamhet och teknik sammanfattning
Med MLOps mognadsmodell kan vi definiera en tydlig arkitekturdesign och leveransplan. Däremot måste varje person ha en tydlig bild av de viktigaste AWS-kontona och tjänsterna att interagera med och verksamheten att utföra. Följande diagram sammanfattar dessa kategorier.
Slutsats
En robust MLOps-stiftelse, som tydligt definierar interaktionen mellan flera personer och teknik, kan öka hastigheten till värde och minska kostnaderna, och göra det möjligt för datavetare att fokusera på innovationer. I det här inlägget visade vi hur man bygger en sådan grund i faser, vilket leder till en smidig MLOps-mognadsmodell för verksamheten och förmågan att stödja flera datavetenskapsteam och ML-användningsfall i produktionen. Vi definierade en verksamhetsmodell som består av flera personer med flera kompetenser och ansvarsområden. Slutligen delade vi med oss av exempel på hur man standardiserar kodutvecklingen (förråd och CI/CD-pipelines), datalagring och delning och MLOps säker infrastrukturförsörjning för företagsmiljöer. Många företagskunder har anammat detta tillvägagångssätt och kan producera sina ML-lösningar inom dagar istället för månader.
Om du har några kommentarer eller frågor, vänligen lämna dem i kommentarfältet.
Om författaren
Dr Sokratis Kartakis är en senior lösningsarkitekt för maskininlärning för Amazon Web Services. Sokratis fokuserar på att göra det möjligt för företagskunder att industrialisera sina lösningar för maskininlärning (ML) genom att utnyttja AWS-tjänster och forma deras verksamhetsmodell, dvs. MLOps-grunden, och transformationsfärdplan som utnyttjar bästa utvecklingsmetoder. Han har ägnat 15+ år åt att uppfinna, designa, leda och implementera innovativa end-to-end produktionsnivå ML och Internet of Things (IoT) lösningar inom områdena energi, detaljhandel, hälsa, finans/bank, motorsport etc. Sokratis gillar att tillbringa sin fritid med familj och vänner, eller att åka motorcykel.
Georgios Schinas är en specialistlösningsarkitekt för AI/ML i EMEA-regionen. Han är baserad i London och arbetar nära kunder i Storbritannien och Irland. Georgios hjälper kunder att designa och distribuera maskininlärningsapplikationer i produktion på AWS med ett särskilt intresse för MLOps-praxis och gör det möjligt för kunder att utföra maskininlärning i stor skala. På fritiden tycker han om att resa, laga mat och umgås med vänner och familj.
Giuseppe Angelo Porcelli är en huvudsaklig maskininlärningsspecialistlösningsarkitekt för Amazon Web Services. Med flera års mjukvaruutveckling och ML-bakgrund arbetar han med kunder av alla storlekar för att på djupet förstå deras affärsbehov och tekniska behov och designa AI- och Machine Learning-lösningar som utnyttjar AWS Cloud och Amazon Machine Learning-stacken på bästa sätt. Han har arbetat med projekt inom olika domäner, inklusive MLOps, Computer Vision, NLP och involverat en bred uppsättning AWS-tjänster. På fritiden tycker Giuseppe om att spela fotboll.
Shelbee Eigenbrode är en huvudarkitekt för AI och Machine Learning Specialist Solutions på Amazon Web Services (AWS). Hon har varit inom teknik i 24 år och spänner över flera branscher, teknologier och roller. Hon fokuserar för närvarande på att kombinera sin DevOps- och ML-bakgrund i MLOps-domänen för att hjälpa kunder att leverera och hantera ML-arbetsbelastningar i stor skala. Med över 35 patent beviljade inom olika teknikdomäner har hon en passion för kontinuerlig innovation och att använda data för att driva affärsresultat. Shelbee är en medskapare och instruktör för specialiseringen Practical Data Science på Coursera. Hon är också meddirektör för Women In Big Data (WiBD), kapitel i Denver. På fritiden spenderar hon gärna tid med sin familj, sina vänner och överaktiva hundar.
- "
- 100
- a
- förmåga
- Om oss
- SAMMANDRAG
- accelerera
- tillgång
- tillgänglig
- rymma
- Konto
- Uppnå
- tvärs
- Dessutom
- Annat
- Antagande
- avancerat
- mot
- AI
- algoritmer
- Alla
- tillåter
- alternativ
- amason
- Amazon Web Services
- bland
- mängd
- analys
- analytiker
- analytics
- Annan
- api
- Ansökan
- tillämpningar
- tillvägagångssätt
- arkitektur
- revision
- automatisera
- Automat
- automatiskt
- Automation
- tillgänglig
- undvika
- AWS
- bakgrund
- Baslinje
- därför att
- blir
- innan
- bakom
- fördelaktigt
- BÄST
- mellan
- Stora data
- Bill
- lyft
- SLUTRESULTAT
- Byggnad
- inbyggd
- företag
- företag
- kapacitet
- Vid
- fall
- centraliserad
- utmanande
- Kapitel
- Kontroller
- klassiska
- cloud
- koda
- samarbeta
- samverkan
- Kolumn
- kombination
- kommentarer
- förbinda
- Gemensam
- Företag
- kompatibel
- fullborda
- komplex
- Efterlevnad
- dator
- Genomför
- ledande
- förtroende
- konfiguration
- anslutning
- konsekvent
- Behållare
- Behållare
- innehåller
- kontroll
- kopiering
- Motsvarande
- kunde
- täcka
- skapa
- skapas
- skapar
- Skapa
- skapande
- För närvarande
- beställnings
- kund
- Kunder
- datum
- datatillgång
- dataanalys
- dataintegritet
- datavetenskap
- datavetare
- datalagring
- Dagar
- dedicerad
- leverans
- Efterfrågan
- Denver
- beroende
- beror
- distribuera
- utplacerade
- utplacera
- utplacering
- distributioner
- vecklas ut
- beskriva
- Designa
- design
- detaljer
- Detektering
- dev
- utveckla
- Utveckling
- utvecklings verktyg
- Skillnaden
- olika
- diskutera
- fördelning
- Hamnarbetare
- domän
- domäner
- driv
- driven
- under
- varje
- kant
- eliminera
- omfamna
- möjliggöra
- möjliggör
- möjliggör
- början till slut
- Slutpunkt
- energi
- Teknik
- Ingenjörer
- Företag
- företag
- Miljö
- etc
- utvärdera
- utvärdering
- händelse
- händelser
- exakt
- exempel
- exempel
- exklusive
- experimentera
- bedrifter
- utforskning
- familj
- Leverans
- Figur
- Slutligen
- Förnamn
- flöda
- Fokus
- fokuserar
- fokusering
- efter
- fotboll
- bildning
- hittade
- fundament
- Stiftelser
- Ramverk
- ramar
- Fri
- från
- funktionalitet
- funktioner
- Vidare
- nätbryggan
- GDPR
- genereras
- gå
- GitHub
- Målet
- styrning
- beviljats
- Grupp
- Arbetsmiljö
- hash
- Hälsa
- hjälpa
- hjälpa
- hjälper
- Hög
- historisk
- historia
- värd
- Hur ser din drömresa ut
- How To
- Men
- HTTPS
- Hundratals
- Identitet
- bilder
- genomföra
- genomföras
- genomföra
- med Esport
- förbättra
- innefattar
- Inklusive
- Öka
- industrier
- informationen
- Infrastruktur
- Innovation
- innovationer
- innovativa
- ingång
- exempel
- integrering
- integrationer
- interaktion
- intresse
- Gränssnitt
- Internet
- sakernas Internet
- iot
- irland
- isolering
- IT
- Jobb
- Lediga jobb
- sammanfogning
- Fogar
- Ha kvar
- Nyckel
- kunskap
- Large
- senaste
- lager
- leda
- ledande
- LÄRA SIG
- inlärning
- Lämna
- Adress
- nivåer
- hävstångs
- Bibliotek
- läsa in
- lokal
- lokalt
- london
- Maskinen
- maskininlärning
- göra
- Framställning
- hantera
- ledning
- obligatoriskt
- manuell
- förfall
- mekanism
- Medlemmar
- Sammanfoga
- Metodik
- metoder
- Metrics
- kanske
- emot
- minsta
- spegel
- ML
- modell
- modeller
- Övervaka
- månader
- mer
- motorsports
- flytta
- rörliga
- multipel
- nämligen
- namn
- namngivning
- nödvändigt för
- behov
- Nästa
- normalt
- driva
- drift
- Verksamhet
- optimering
- Alternativet
- Tillbehör
- beställa
- organisationer
- ursprungliga
- Övriga
- egen
- ägaren
- ägare
- del
- särskilt
- parti
- brinner
- Patent
- Personer
- prestanda
- utför
- fas
- plattform
- Spela
- i
- snälla du
- Punkt
- Strategier
- Förbered
- Principal
- privatpolicy
- Problem
- process
- bearbetning
- producerad
- Produkt
- Produktion
- produktivitet
- projektet
- projekt
- främja
- främjande
- ge
- förutsatt
- ger
- dra
- kvalitet
- RE
- realtid
- minska
- reducerande
- region
- registrera
- Förhållanden
- pålitlig
- Repository
- begära
- förfrågningar
- Obligatorisk
- Krav
- Kräver
- forskning
- resurs
- Resurser
- ansvar
- ansvarig
- Resultat
- detaljhandeln
- avkastning
- återgår
- färdplan
- robusthet
- Roll
- rot
- Körning
- rinnande
- Samma
- skalbar
- Skala
- skalning
- planerad
- Vetenskap
- Forskare
- vetenskapsmän
- sDK
- säkra
- säkerhet
- seriell
- Serier
- service
- Tjänster
- in
- inställning
- flera
- Forma
- delas
- delning
- show
- liknande
- simulering
- enda
- Storlek
- färdigheter
- Mjukvara
- mjukvaruutveckling
- lösning
- Lösningar
- LÖSA
- några
- källkod
- specialist
- specifik
- specifikt
- fart
- spendera
- Spendera
- delas
- stapel
- Etapp
- stadier
- starta
- Ange
- statistisk
- statistik
- status
- förvaring
- lagra
- lagrar
- Strategi
- effektivisera
- påkänning
- strukturerade
- studio
- framgångsrik
- stödja
- Som stöds
- Stöder
- system
- System
- grupp
- lag
- Teknisk
- Tekniken
- Teknologi
- mallar
- testa
- Testning
- tester
- Smakämnen
- källan
- världen
- därför
- saker
- tredje part
- tre
- tid
- tillsammans
- verktyg
- Tåg
- Utbildning
- Förvandla
- Transformation
- transformationer
- Traveling
- typer
- ui
- Uk
- under
- förstå
- enheter
- Uppdatering
- användning
- användare
- utnyttja
- godkännande
- värde
- olika
- utsikt
- syn
- webb
- webbservice
- medan
- inom
- utan
- Kvinnor
- Arbete
- arbetade
- arbetsflöden
- fungerar
- världen
- skrivning
- år
- Din