Dette innlegget presenterer og sammenligner alternativer og anbefalte fremgangsmåter for hvordan du administrerer Python-pakker og virtuelle miljøer i Amazon SageMaker Studio notatbøker. En offentlighet GitHub repo gir praktiske eksempler for hver av de presenterte tilnærmingene.
Amazon SageMaker Studio er et nettbasert, integrert utviklingsmiljø (IDE) for maskinlæring (ML) som lar deg bygge, trene, feilsøke, distribuere og overvåke ML-modellene dine. Studio gir alle verktøyene du trenger for å ta modellene dine fra dataforberedelse til eksperimentering til produksjon mens du øker produktiviteten.
Studio-notatbøker er samarbeidsbaserte Jupyter-notatbøker som du kan starte raskt fordi du ikke trenger å sette opp dataforekomster og fillagring på forhånd. Når du åpner en notatbok i Studio, blir du bedt om å sette opp miljøet ditt ved å velge et SageMaker-bilde, en kjerne, en forekomsttype og eventuelt et livssykluskonfigurasjonsskript som kjører ved bildeoppstart.
For mer informasjon om Studio-notebook-konsepter og andre aspekter av arkitekturen, se Dykk dypt inn i Amazon SageMaker Studio Notebooks-arkitekturen.
Studio-notatbøker er designet for å støtte deg i alle faser av ML-utviklingen din, for eksempel ideer, eksperimentering og operasjonalisering av en ML-arbeidsflyt. Ettromsleilighet leveres med forhåndsbygd bilder som inkluderer det siste Amazon SageMaker Python SDK og, avhengig av bildetypen, andre spesifikke pakker og ressurser, for eksempel Spark-, MXNet- eller PyTorch-rammebiblioteker, og deres nødvendige avhengigheter. Hvert bilde kan være vert for ett eller flere kjerner, som kan være forskjellige virtuelle miljøer for utvikling.
For å sikre best mulig tilpasning for utviklingsprosessen og -fasene, tilgang til spesifikke eller nyeste ML-rammeverk, eller for å oppfylle krav til datatilgang og styring, kan du tilpasse de forhåndsbygde bærbare miljøene eller lage nye miljøer ved å bruke dine egne bilder og kjerner.
Dette innlegget vurderer følgende tilnærminger for å tilpasse Studio-miljøer ved å administrere pakker og lage virtuelle Python-miljøer i Studio-notatbøker:
- Bruk et tilpasset Studio KernelGateway-appbilde
- Bruk Studio bærbare livssykluskonfigurasjoner
- Bruk Studio Amazon elastisk filsystem (Amazon EFS) volum for å vedvare Conda-miljøer
- Bruk
pip install
Studio KernelGateway-apper og bærbare kjerner
En av hovedforskjellene i Studio bærbare arkitektur sammenlignet med SageMaker notatbokforekomster er at Studio notatbokkjerner kjører i en Docker-beholder, kalt en SageMaker bildebeholder, i stedet for å være vert direkte på Amazon Elastic Compute Cloud (Amazon EC2)-forekomster, noe som er tilfellet med SageMaker-notebook-forekomster.
Følgende diagram viser relasjonene mellom KernelGateway, bærbare kjerner og SageMaker-bilder. (For mer informasjon, se Bruk Amazon SageMaker Studio Notebooks.)
På grunn av denne forskjellen er det noen detaljer om hvordan du oppretter og administrerer virtuelle miljøer i Studio-notatbøker, for eksempel bruk av Conda-miljøer eller utholdenhet av ML-utviklingsmiljøer mellom omstart av kjernen.
De følgende delene forklarer hver av fire miljøtilpasningstilnærminger i detalj, gir praktiske eksempler og anbefaler brukstilfeller for hvert alternativ.
Forutsetninger
For å komme i gang med eksemplene og prøve tilpasningsmetodene på egen hånd, trenger du et aktivt SageMaker-domene og minst én brukerprofil i domenet. Hvis du ikke har et domene, se instruksjonene i Ombord på Amazon SageMaker Domain.
Studio KernelGateway tilpassede appbilder
Et Studio KernelGateway-appbilde er en Docker-beholder som identifiserer kjernene, språkpakkene og andre avhengigheter som kreves for å kjøre en Jupyter-notatbok i Studio. Du bruker disse bildene til å lage miljøer som du deretter kjører Jupyter notatbøker på. Studio gir mange innebygde bilder for deg å bruke.
Hvis du trenger annen funksjonalitet, spesifikke rammer eller bibliotekpakker, kan du ta med dine egne tilpassede bilder (BYOI) til Studio.
Du kan lage appbilder og bildeversjoner, legge ved bildeversjoner til domenet ditt og gjøre en app tilgjengelig for alle domenebrukere eller for spesifikke brukerprofiler. Du kan administrere appbilder via SageMaker-konsollen AWS SDK for Python (Boto3), og AWS kommandolinjegrensesnitt (AWS CLI). Det tilpassede bildet må lagres i en Amazon Elastic Container Registry (Amazon ECR) depot.
Hovedfordelene med denne tilnærmingen er et høyt nivå av versjonskontroll og reproduserbarhet for et ML-kjøremiljø og umiddelbar tilgjengelighet av bibliotekpakker fordi de er installert i bildet. Du kan implementere omfattende tester, styring, sikkerhetsrekkverk og CI/CD-automatisering for å produsere tilpassede appbilder. Å ha øyeblikksbilder av utviklingsmiljøer letter og håndhever organisasjonens rekkverk og sikkerhetspraksis.
Den gitte bærbare implementerer en prosess for å lage appbilder for Conda-baserte miljøer. Notatboken viser hvordan du kan lage multimiljøbilder slik at brukerne av appen kan ha et utvalg kjerner de kan kjøre notatbøkene sine på.
Konfigurer et tilpasset appbilde
Du må kjøre denne notatboken som en SageMaker notatbokforekomst for å tillate bruk av Docker lokalt og kjøre Docker-kommandoer i notatboken. Alternativt til å bruke notatbokforekomster eller shell-skript, kan du bruke Studio Image Bygg CLI å jobbe med Docker i Studio. Studio Image Build CLI lar deg bygge SageMaker-kompatible Docker-bilder direkte fra Studio-miljøene dine ved å bruke AWS CodeBuild.
Hvis du ikke har en SageMaker notatbokforekomst, følg instruksjonene i Opprett en Amazon SageMaker Notebook-forekomst å komme i gang.
Du må også sørge for at utførelsesrollen du bruker for en notebook-forekomst har de nødvendige tillatelsene for Amazon ECR- og SageMaker-domeneoperasjoner:
For å lage et tilpasset bilde med to kjerner, hver med sitt eget virtuelle Conda-miljø, implementerer den bærbare datamaskinen følgende trinn:
- Definer Conda-miljøene. Conda-miljøet må ha en Jupyter-kjernepakke installert, for eksempel,
ipykernel
for Python-kjernen. - Definer en Dockerfile. Vurder det tilpassede SageMaker-bildet spesifikasjoner når du lager ditt eget bilde.
- Bygg et Docker-bilde som er kompatibelt med Studio og skyv bildet inn i ECR-depotet.
- Lag en SageMaker-bilde med Docker-bildet fra ECR-depotet og lag en første bildeversjon. Hver gang du oppdaterer bildet i Amazon ECR, må det opprettes en ny bildeversjon.
- Oppdater et eksisterende SageMaker-domene for å bruke dette bildet. For denne operasjonen trenger utførelsesrollen
UpdateDomain
tillatelse. Bildet er umiddelbart tilgjengelig for alle brukerprofiler på domenet. Hvis du vil gjøre bildet tilgjengelig kun for en bestemt brukerprofil, kan du brukeUpdateUserProfile
API-kall i stedet forUpdateDomain
. - Start det tilpassede bildet i Studio. Start en ny notatbok og velg det nye bildet på rullegardinmenyen for bildevalg.
Studio gjenkjenner automatisk Conda-miljøene i bildet ditt som tilsvarende kjerner i rullegardinmenyen for kjernevalg i Sett opp notatbokmiljø widget.
Viser til disse eksempel på notatbøker for flere eksempler og brukstilfeller for implementering av tilpassede appbilder.
Rydd opp
For å unngå belastninger må du stoppe de aktive SageMaker-notebook-forekomstene. For instruksjoner, se Rydd opp.
Implementer en automatisert bilderedigeringsprosess
Som allerede nevnt, kan du bruke Studio Image Bygg CLI å implementere en automatisert CI/CD-prosess for oppretting og distribusjon av appbilder med CodeBuild og sm-docker CLI. Den abstraherer oppsettet av Docker-byggmiljøene dine ved automatisk å sette opp de underliggende tjenestene og arbeidsflyten som er nødvendig for å bygge Docker-bilder.
Anbefalte brukstilfeller
Den tilpassede appbildetilnærmingen passer godt for følgende scenarier når du bruker et Studio-notebook-miljø:
- Stabile og kontrollerte miljøer for produksjon eller sensitiv utviklingsbruk
- Miljøer uten internettilgang, der du ønsker å forhåndspakke alle nødvendige ressurser og biblioteker inn i bildet
- Høy miljøgjenbruksgrad og lav endringshastighet i miljøene
- Høy skala av datavitenskapelige operasjoner, dusinvis eller hundrevis av utviklere eller team som trenger tilgang til standardiserte tilpassede miljøer
- Bruk biblioteker som ikke kan konfigureres på SageMaker førstepartsbilder
- Krav for å bruke tilpassede bilder for et annet OS eller annet programmeringsspråk
- Sentralisert styring og miljøutvikling ved hjelp av automatiserte CI/CD-pipelines
Begrensninger ved denne tilnærmingen
Denne tilnærmingen krever en flertrinns bildeopprettingsprosess inkludert tester, som kan være overkill for mindre eller svært dynamiske miljøer. Vurder dessuten følgende begrensninger ved tilnærmingen:
- En forhåndsinnsats er nødvendig for å legge til nye pakker eller lage nye versjoner av et bilde. Som redusering kan du tilpasse det eksisterende tilpassede bildet med pip, selv om det ikke er vedvarende.
- Å legge ved et nytt tilpasset bilde eller legge til en ny versjon til domenet krever
UpdateDomain
tillatelse, som vanligvis ikke er knyttet til utføringsrollen for brukerprofilen. Vi anbefaler å bruke en automatisert pipeline med en dedikert utførelsesrolle for å utføre denne operasjonen eller gi tillatelse til å oppdatere et domene til en dedikert administratorbruker eller -rolle. - En høy manuell innsats for bilderedigering er involvert. Vi anbefaler å implementere en automatisert pipeline hvis du produserer og oppdaterer tilpassede bilder ofte.
- Hvis du bruker Conda-miljøer, kan du støte på problemer med det i Docker-miljøet. For et eksempel, se Aktivering av et Conda-miljø i Dockerfilen. Ikke alle Conda-kommandoer fungerer kanskje i det virtuelle miljøet for den bærbare datamaskinen. Denne tilpasningstilnærmingen til Studio er imidlertid ikke begrenset til Conda-baserte miljøer.
- Du kan ikke manuelt bytte mellom Conda-miljøer i notisboken; du må bytte kjerner i oppsett-widgeten for notebookmiljøet.
Tenk også på at det er standard kvoter med 30 tilpassede bilder per domene og 5 bilder per brukerprofil. Dette er myke grenser og kan økes.
De neste avsnittene beskriver mer lette tilnærminger som kan passe bedre for andre brukstilfeller.
Livssykluskonfigurasjoner for Studio bærbare
studie livssykluskonfigurasjoner definere et shell-skript som kjører ved hver omstart av kjernegateway-applikasjonen og kan installere de nødvendige pakkene. Den største fordelen er at en dataforsker kan velge hvilket skript som skal kjøres for å tilpasse beholderen med nye pakker. Dette alternativet krever ikke gjenoppbygging av beholderen og krever i de fleste tilfeller ikke et tilpasset bilde i det hele tatt fordi du kan tilpasse forhåndsbygde.
Sett opp en livssykluskonfigurasjonsprosess
Denne prosessen tar rundt 5 minutter å fullføre. Innlegget demonstrerer hvordan du bruker livssykluskonfigurasjonene via SageMaker-konsollen. Den gitte bærbare viser hvordan du implementerer det samme programmatisk ved hjelp av Boto3.
- Velg på SageMaker-konsollen Livssykluskonfigurasjoner i navigasjonsruten.
- På studie kategorien, velg Opprett konfigurasjon.
Det første trinnet for å lage livssykluskonfigurasjonen er å velge type.
- For denne bruken av å installere avhengigheter hver gang en Jupyter-kjernegateway-app opprettes, velg Jupyter kernel gateway app Og velg neste.
- Til Navn, skriv inn et navn for konfigurasjonen.
- på scripts seksjon, definerer skriptet som skal kjøres når kjernen starter. For dette eksemplet vil PyArrow-biblioteket bli installert med følgende skript:
- Velg Opprett konfigurasjon.
Nå som konfigurasjonen er opprettet, må den kobles til et domene eller en brukerprofil. Når det er knyttet til domenet, arver alle brukerprofiler i det domenet det, mens når det er knyttet til en brukerprofil, er det omfattet av den spesifikke profilen. For denne gjennomgangen bruker vi Studio-domeneruten.
- Velg Domener i navigasjonsruten og åpne ditt eksisterende domene.
- På Miljø fanen, i Livssykluskonfigurasjoner for personlige Studio-apper delen velger Fest.
- Til kilde, plukke ut Eksisterende konfigurasjon.
- Velg livssykluskonfigurasjonen du opprettet og velg Fest til domene.
Nå som all konfigurasjonen er ferdig, er det på tide å teste skriptet i Studio.
- Start Studio og på Launcher fanen, finn Notatbøker og dataressurser delen, og velg Bytt miljø for å velge livssykluskonfigurasjonen du opprettet.
- Til Oppstartsskript, velg livssykluskonfigurasjonen du opprettet, og velg deretter Plukke ut.
- Velg Lag notatbok.
Du kan også angi at livssykluskonfigurasjonen skal kjøres som standard i Livssykluskonfigurasjoner for personlige Studio-apper delen av Domene side.
I den nye notatboken vil avhengighetene som er installert i oppstartsskriptet være tilgjengelige.
Anbefalte brukstilfeller
Denne tilnærmingen er lett, men også kraftig fordi den lar deg kontrollere oppsettet av ditt bærbare miljø via shell-skript. Brukstilfellene som passer best med denne tilnærmingen er følgende:
- Integrering av pakkeinstallasjoner i livssykluskonfigurasjonen for den bærbare datamaskinen som må kjøres ved hver kjernestart.
- Miljøer uten internettilgang. Bruk livssykluskonfigurasjoner for å sette opp et miljø for å få tilgang til lokale eller sikkerhetsartefakt- og pakkelager, for eksempel AWS CodeArtifact.
- Hvis du allerede bruker livssykluskonfigurasjoner, kan du utvide dem til å inkludere pakkeinstallasjon.
- Installasjon av noen få ekstra pakker på toppen av innebygde eller tilpassede appbilder.
- Når du trenger kortere tid til markedsføring enn med tilpassede appbilder.
Begrensninger ved denne tilnærmingen
De viktigste begrensningene er en stor innsats for å administrere livssykluskonfigurasjonsskript i skala og langsom installasjon av pakker. Avhengig av hvor mange pakker som er installert og hvor store de er, kan livssyklusskriptet til og med tidsavbrytes. Det er også begrensede alternativer for ad hoc-skripttilpasning av brukere, for eksempel dataforskere eller ML-ingeniører, på grunn av tillatelsene til brukerprofilens utførelsesrolle.
Referere til SageMaker Studio livssyklus konfigurasjonseksempler for flere prøver og brukstilfeller.
Vedvarende Conda-miljøer til Studio EFS-volumet
SageMaker-domener og Studio bruker et EFS-volum som et vedvarende lagringslag. Du kan lagre Conda-miljøene dine på dette EFS-volumet. Disse miljøene er vedvarende mellom omstart av kjerne, app eller Studio. Studio henter automatisk alle miljøer som KernelGateway-kjerner.
Dette er en enkel prosess for en dataforsker, men det er 1 minutts forsinkelse før miljøet vises i listen over valgbare kjerner. Det kan også være problemer med å bruke miljøer for kernel gateway-apper som har forskjellige datakrav, for eksempel et CPU-basert miljø på en GPU-basert app.
Referere til Tilpassede Conda-miljøer på SageMaker Studio for detaljerte instruksjoner. Innleggets GitHub-repo inneholder også en bærbare med trinn-for-trinn-guiden.
Lag vedvarende Conda-miljøer på et Studio EFS-volum
Denne gjennomgangen bør ta rundt 10 minutter.
- På Studio, velg Hjemprodukt i navigasjonsruten.
- Velg Åpne Launcher.
- I startprogrammet finner du Notatbøker og dataressurser seksjon.
- Sjekk at det valgte SageMaker-bildet er et Conda-støttet førsteparts kjernebilde, for eksempel "Data Science."
- Velg Åpne bildeterminalen for å åpne et terminalvindu med en ny kjerne.
En melding vises som sier "Starter bildeterminal ...", og etter noen få øyeblikk åpnes den nye terminalen i en ny fane.
- Kjør følgende kommandoer i terminalen:
Disse kommandoene vil ta ca. 3 minutter å kjøre og vil opprette en katalog på EFS-volumet for å lagre Conda-miljøene, opprette det nye Conda-miljøet og aktivere det, installere ipykernel
avhengigheter (uten denne avhengigheten vil ikke denne løsningen fungere), og til slutt oppretter du en Conda-konfigurasjonsfil (.condarc
), som inneholder referansen til den nye Conda-miljøkatalogen. Fordi dette er et nytt Conda-miljø, er ingen ekstra avhengigheter installert. For å installere andre avhengigheter, kan du endre conda install
linje eller vent til følgende kommandoer er ferdige og installer eventuelle ekstra avhengigheter mens du er inne i Conda-miljøet.
- For dette eksemplet installerer vi NumPy-biblioteket ved å kjøre følgende kommando i terminalvinduet:
Nå som Conda-miljøet er opprettet og avhengighetene er installert, kan du lage en notatbok som bruker dette Conda-miljøet på Amazon EFS.
- På Studio Launcher velger du Lag notatbok.
- Fra den nye notatboken velger du "Python 3 (Data Science)"-kjernen.
- Til Kernel, velg det nyopprettede Conda-miljøet, og velg deretter Plukke ut.
Hvis det først ikke er noe alternativ for det nye Conda-miljøet, kan dette skyldes at det tar noen minutter å forplante seg.
Tilbake i notatboken vil kjernenavnet ha endret seg i øverste høyre hjørne, og i en celle kan du teste at avhengighetene som er installert er tilgjengelige.
Anbefalte brukstilfeller
Følgende brukstilfeller passer best for denne tilnærmingen:
- Miljøer uten internettilgang, med alle avhengigheter forhåndsinstallert i de vedvarende Conda-miljøene
- Ad hoc-miljøer som trenger utholdenhet mellom kjerneøktene
- Testing av tilpassede SageMaker-bilder i Studio før du oppretter et Docker-bilde og skyver til Amazon ECR
Begrensninger ved denne tilnærmingen
Selv om denne tilnærmingen har praktisk bruk, bør du vurdere følgende begrensninger:
- Det kan være ytelsesproblemer med Amazon EFS på mange små filer, noe som er veldig vanlig når du administrerer Python-pakker.
- Det kan være utfordrende å dele vedvarende miljøer mellom Studio-brukerprofiler.
- Det kan være utfordrende å gjenbruke vedvarende miljøer.
- Det kan være utfordrende å håndtere ledelse i stor skala.
- Tilnærmingen fungerer bare med spesifikke Conda-baserte førsteparts SageMaker-bilder, for eksempel "Data Science", "Data Science 2.0" og "Data Science 3.0." For en liste over alle tilgjengelige bilder, se Tilgjengelige Amazon SageMaker-bilder.
Pip-installasjon
Du kan installere pakker direkte i standard Conda-miljøet eller standard Python-miljø.
Lag en setup.py
or requirements.txt
fil med alle nødvendige avhengigheter og kjør %pip install .-r requirement.txt
. Du må kjøre denne kommandoen hver gang du starter kjernen på nytt eller gjenskaper en app.
Denne tilnærmingen anbefales for ad hoc-eksperimentering fordi disse miljøene ikke er vedvarende.
For mer informasjon om bruk av pip install
kommando og begrensninger, se Installer eksterne biblioteker og kjerner i Amazon SageMaker Studio.
Anbefalte brukstilfeller
Denne tilnærmingen er en standard måte å installere pakker på for å tilpasse ditt bærbare miljø. De anbefalte brukstilfellene er begrenset til ikke-produksjonsbruk for ad hoc-eksperimentering i en notatbok:
- Ad hoc-eksperimentering i Studio-notatbøker
- Ikke-produktive og ikke-sensitive miljøer, sandkassemiljøer
- Miljøer med internettilgang
Begrensninger ved denne tilnærmingen
De viktigste begrensningene ved denne tilnærmingen er:
- Noen bedriftsmiljøer blokkerer alle utgående og inngående internettforbindelser, og du kan ikke bruke
pip install
for å trekke Python-pakker eller trenger å konfigurere en frakoblet modus - Lavere reproduserbarhet av miljøer
- Må vente til pakker er lastet ned og installert
- Ingen utholdenhet mellom omstart av bildet
konklusjonen
SageMaker Studio tilbyr et bredt spekter av mulig tilpasning av utviklingsmiljøer. Hver brukerrolle som en dataforsker; en ML-, MLOps- eller DevOps-ingeniør; og en administrator kan velge den mest passende tilnærmingen basert på deres behov, plass i utviklingssyklusen og bedriftens autovern.
Tabellen nedenfor oppsummerer de presenterte tilnærmingene sammen med deres foretrukne brukstilfeller og hovedbegrensninger.
Tilnærming | Utholdenhet | Best passende brukstilfeller | Begrensninger |
Ta med eget bilde | Permanent, overførbar mellom brukerprofiler og domener |
|
|
Livssykluskonfigurasjoner | Permanent, overførbar mellom brukerprofiler og domener |
|
|
Conda-miljøer på Studio EFS-volumet | Permanent, kan ikke overføres mellom brukerprofiler eller domener |
|
|
Pip-installasjon | Forbigående, ingen utholdenhet mellom bilde eller Studio omstarter, kan ikke overføres mellom brukerprofiler eller domener |
|
|
Det er fortsatt dag 1. Det virkelige virtuelle miljøet og Python-administrasjon er langt mer komplekst enn disse fire tilnærmingene, men dette innlegget hjelper deg med de første trinnene for å utvikle din egen brukssituasjon.
Du kan finne flere brukstilfeller, detaljer og praktiske eksempler i følgende ressurser:
Om forfatterne
Jevgenij Ilyin er løsningsarkitekt hos Amazon Web Services (AWS). Han har over 20 års erfaring med å jobbe på alle nivåer av programvareutvikling og løsningsarkitektur og har brukt programmeringsspråk fra COBOL og Assembler til .NET, Java og Python. Han utvikler og koder cloud native løsninger med fokus på big data, analytics og data engineering.
Alex Grace er en løsningsarkitekt hos Amazon Web Services (AWS) som tar seg av Fintech Digital Native Businesses. Basert i London, jobber Alex med noen av Storbritannias ledende Fintechs og liker å støtte deres bruk av AWS for å løse forretningsproblemer og drive fremtidig vekst. Tidligere har Alex jobbet som programvareutvikler og teknisk leder ved Fintech-startups i London og har nylig spesialisert seg på AWS sine maskinlæringsløsninger.
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang her.
- kilde: https://aws.amazon.com/blogs/machine-learning/four-approaches-to-manage-python-packages-in-amazon-sagemaker-studio-notebooks/
- :er
- $OPP
- 1
- 10
- 100
- 11
- 20 år
- 7
- 8
- a
- Om oss
- sammendrag
- adgang
- Logg inn
- Handling
- aktiv
- Ad
- Ytterligere
- adresse
- admin
- Etter
- alex
- Alle
- tillater
- allerede
- Amazon
- Amazon EC2
- Amazon SageMaker
- Amazon SageMaker Studio
- Amazon Web Services
- Amazon Web Services (AWS)
- analytics
- og
- api
- app
- vises
- Søknad
- tilnærming
- tilnærminger
- apps
- arkitektur
- ER
- rundt
- AS
- aspekter
- At
- feste
- forfatter
- Automatisert
- automatisk
- Automatisering
- tilgjengelighet
- tilgjengelig
- AWS
- basert
- BE
- fordi
- før du
- nytte
- Fordeler
- BEST
- Bedre
- mellom
- Stor
- Store data
- Blokker
- øke
- bringe
- bred
- bygge
- Bygning
- innebygd
- virksomhet
- bedrifter
- by
- ring
- som heter
- CAN
- saken
- saker
- utfordringer
- utfordrende
- Endringer
- avgifter
- Velg
- velge
- Cloud
- COBOL
- samarbeids
- Felles
- sammenlignet
- kompatibel
- fullføre
- komplekse
- omfattende
- Beregn
- konsepter
- Konfigurasjon
- Tilkoblinger
- Vurder
- anser
- Konsoll
- Container
- inneholder
- kontroll
- kontrolleres
- kontroller
- Corner
- Tilsvarende
- kunne
- skape
- opprettet
- Opprette
- skaperverket
- skikk
- tilpasning
- tilpasse
- syklus
- dato
- data tilgang
- Dataklargjøring
- datavitenskap
- dataforsker
- dag
- dedikert
- dyp
- Misligholde
- forsinkelse
- demonstrerer
- Avhengighet
- avhengig
- utplassere
- distribusjon
- beskrive
- designet
- detalj
- detaljert
- detaljer
- Utvikler
- utviklere
- utvikle
- Utvikling
- utvikler
- forskjell
- forskjeller
- forskjellig
- digitalt
- direkte
- skjermer
- Docker
- ikke
- domene
- domener
- ikke
- nedlasting
- dusinvis
- dynamisk
- hver enkelt
- effekt
- innsats
- ingeniør
- Ingeniørarbeid
- Ingeniører
- sikre
- Enter
- Enterprise
- Miljø
- miljøer
- Selv
- Hver
- eksempel
- eksempler
- gjennomføring
- eksisterende
- erfaring
- Forklar
- utvide
- utvendig
- forenkler
- Noen få
- filet
- Filer
- Endelig
- Finn
- ferdig
- fintech
- fintech oppstart
- fintechs
- Først
- første steg
- passer
- Fokus
- følge
- etter
- Til
- Rammeverk
- rammer
- ofte
- fra
- Brensel
- funksjonalitet
- Dess
- framtid
- fremtidig vekst
- gateway
- få
- GitHub
- Gi
- Gyllen
- god
- styresett
- Vekst
- veilede
- hands-on
- Ha
- å ha
- hjelper
- Høy
- vert
- vert
- Hvordan
- Hvordan
- Men
- HTML
- http
- HTTPS
- Hundrevis
- identifiserer
- bilde
- bilder
- umiddelbar
- umiddelbart
- iverksette
- gjennomføring
- implementere
- redskaper
- importere
- in
- inkludere
- Inkludert
- økt
- informasjon
- innledende
- installere
- installerte
- installere
- f.eks
- i stedet
- instruksjoner
- integrert
- Internet
- Internettilgang
- involvert
- saker
- IT
- Java
- jpg
- Språk
- språk
- stor
- siste
- lansere
- lag
- føre
- ledende
- læring
- Lar
- Nivå
- nivåer
- bibliotekene
- Bibliotek
- Livssyklus
- lettvekt
- BEGRENSE
- begrensninger
- Begrenset
- grenser
- linje
- Liste
- lokal
- lokalt
- London
- Lang
- UTSEENDE
- Lav
- maskin
- maskinlæring
- Hoved
- gjøre
- administrer
- fikk til
- ledelse
- administrerende
- håndbok
- manuelt
- mange
- marked
- nevnt
- Meny
- melding
- kunne
- minutter
- skadebegrensning
- ML
- MLOps
- modeller
- modifisere
- Moments
- Overvåke
- mer
- mest
- flere
- navn
- innfødt
- Navigasjon
- nødvendig
- Trenger
- behov
- nett
- Ny
- neste
- normalt
- bærbare
- følelsesløs
- of
- Tilbud
- offline
- on
- ONE
- åpen
- drift
- Drift
- Alternativ
- alternativer
- OS
- Annen
- egen
- pakke
- pakker
- side
- brød
- parametere
- Utfør
- ytelse
- tillatelse
- tillatelser
- utholdenhet
- personlig
- Picks
- rørledning
- Sted
- plato
- Platon Data Intelligence
- PlatonData
- mulig
- Post
- kraftig
- Praktisk
- praksis
- trekkes
- presentert
- gaver
- tidligere
- problemer
- prosess
- prosessering
- produsere
- Produksjon
- produktivitet
- Profil
- Profiler
- Programmering
- programmerings språk
- gi
- forutsatt
- gir
- offentlig
- Skyv
- Skyver
- Python
- pytorch
- raskt
- område
- Sats
- heller
- ratio
- virkelige verden
- nylig
- gjenkjenner
- anbefaler
- anbefales
- relasjoner
- Repository
- krever
- påkrevd
- behov
- Krav
- Krever
- ressurs
- Ressurser
- Rolle
- Rute
- Kjør
- rennende
- sagemaker
- samme
- sandkasse
- Spar
- Skala
- scenarier
- Vitenskap
- Forsker
- forskere
- skript
- SDK
- Seksjon
- seksjoner
- sikkerhet
- valgt
- utvalg
- sensitive
- Tjenester
- sett
- innstilling
- oppsett
- Del
- Shell
- bør
- Viser
- enkelt
- langsom
- liten
- mindre
- So
- Soft
- Software
- programvareutvikling
- løsning
- Solutions
- LØSE
- noen
- Spark
- spesialiserer seg
- spesifikk
- stabil
- Standard
- Begynn
- startet
- starter
- oppstart
- startups
- Uttalelse
- Trinn
- Steps
- Still
- Stopp
- lagring
- oppbevare
- lagret
- rett fram
- studio
- slik
- egnet
- støtte
- Støtte
- Bytte om
- bord
- Ta
- tar
- lag
- tech
- terminal
- test
- tester
- Det
- De
- deres
- Dem
- Disse
- tid
- til
- verktøy
- topp
- Tog
- Kurs
- underliggende
- Oppdater
- bruk
- bruke
- bruk sak
- Bruker
- Brukere
- versjon
- av
- virtuelle
- volum
- vente
- walkthrough
- Vei..
- web
- webtjenester
- Web-basert
- hvilken
- mens
- HVEM
- vil
- med
- innenfor
- uten
- Arbeid
- arbeidet
- arbeid
- virker
- år
- Du
- Din
- zephyrnet