Bygge maskinlæringsrørledninger ved hjelp av Snowflake and Dask
I dette innlegget vil jeg dele noen av verktøyene jeg har utforsket nylig og vise deg hvordan jeg bruker dem og hvordan de bidro til å forbedre effektiviteten til arbeidsflyten min. De to jeg skal snakke om spesielt er Snowflake og Dask. To svært forskjellige verktøy, men som utfyller hverandre godt, spesielt som en del av ML-livssyklusen.
By Daniel Foley, Dataforsker
Introduksjon
I det siste har jeg prøvd å finne bedre måter å forbedre arbeidsflyten min som dataforsker på. Jeg pleier å bruke en anstendig del av tiden min på å modellere og bygge ETL-er i jobben min. Dette har ført til at jeg mer og mer trenger å stole på verktøy for å håndtere store datasett pålitelig og effektivt. Jeg innså raskt at bruk av pandaer for å manipulere disse datasettene ikke alltid er en god tilnærming, og dette fikk meg til å se på andre alternativer.
I dette innlegget vil jeg dele noen av verktøyene jeg har utforsket nylig og vise deg hvordan jeg bruker dem og hvordan de bidro til å forbedre effektiviteten til arbeidsflyten min. De to jeg skal snakke om spesielt er Snowflake og Dask. To svært forskjellige verktøy, men som utfyller hverandre godt, spesielt som en del av ML-livssyklusen. Mitt håp er at du etter å ha lest dette innlegget vil ha en god forståelse av hva Snowflake og Dask er, hvordan de kan brukes effektivt og være i stand til å komme i gang med dine egne brukstilfeller.
Mer spesifikt vil jeg vise deg hvordan du kan bygge en ETL-pipeline ved å bruke Snowflake og Python for å generere treningsdata for en maskinlæringsoppgave. Jeg vil da introdusere Dask og Saturn sky og viser deg hvordan du kan dra nytte av parallell prosessering i skyen for å virkelig få fart på ML-treningsprosessen slik at du kan øke produktiviteten din som dataforsker.
Bygge ETL-er i Snowflake og Python
Før vi går inn i koding bør jeg kort forklare hva Snowflake er. Dette er et spørsmål jeg nylig stilte da teamet mitt bestemte seg for å begynne å bruke det. På et høyt nivå er det et datavarehus i skyen. Etter å ha lekt med den en stund innså jeg hvor kraftig den var. Jeg tror for meg er en av de mest nyttige funksjonene de virtuelle varehusene du kan bruke. Et virtuelt lager gir deg tilgang til de samme dataene, men er helt uavhengig av andre virtuelle varehus, slik at dataressurser ikke deles på tvers av team. Dette har vist seg veldig nyttig ettersom det fjerner ethvert potensial for ytelsesproblemer forårsaket av andre brukere som utfører spørringer i løpet av dagen. Dette har resultert i mindre frustrasjon og bortkastet tid på å vente på at spørringene skal kjøre.
Siden vi skal bruke Snowflake vil jeg kort skissere hvordan du kan sette det opp og begynne å eksperimentere med det selv. Vi må gjøre følgende:
- Få en Snowflake-konto satt opp
- Få dataene våre inn i Snowflake
- Skriv og test søkene våre ved å bruke SQL og Snowflake-grensesnittet
- Skriv en Python-klasse som kan utføre spørringene våre for å generere vårt endelige datasett for modellering
Å sette opp en konto er like enkelt som å registrere seg for en gratis prøveversjon på deres nettsted. Når du har gjort det kan du laste ned snowsql CLI her.. Dette vil gjøre det enkelt å legge til data til Snowflake. Etter å ha fulgt disse trinnene kan vi prøve å koble til Snowflake ved å bruke legitimasjonen vår og kommandolinjen.
snowsql -a <account_name> -u <user_name>
Du finner kontonavnet ditt i URL-en når du logger på Snowflake-grensesnittet. Det skal se omtrent slik ut: xxxxx.europe-west2.gcp. Ok, la oss gå videre til neste trinn og få dataene våre inn i Snowflake. Det er noen få trinn vi må følge her, nemlig:
- Lag vårt virtuelle lager
- Lag en database
- Definer og lag våre tabeller
- Lag en oppsamlingstabell for CSV-filene våre
- Kopierer dataene til tabellene våre
Heldigvis er dette ikke så vanskelig, og vi kan gjøre dette helt ved å bruke snowsql CLI. For dette prosjektet vil jeg bruke et mindre datasett enn jeg ønsker, men jeg kan dessverre ikke bruke noen av dataene til selskapet mitt, og det kan være ganske vanskelig å finne store passende datasett på nettet. Jeg fant imidlertid noen transaksjonsdata fra Dunnhumby som er fritt tilgjengelig på kaggle. Bare for kick, selv om jeg lager et mye større syntetisk datasett ved å bruke disse dataene for å teste hvor godt Dask takler utfordringen sammenlignet med sklearn.
Først av alt må vi sette opp et virtuelt lager og en database ved å bruke følgende kommandoer i Snowflake UI.
skape or erstatte lageranalyse_wh med
warehouse_size="X-SMALL"
auto_suspend=180
auto_resume=true
initially_suspended=true;
skape or erstatte database dunnhumby;
Dataene våre består av 6 CSV-er som vi vil konvertere til 6 tabeller. Jeg vil ikke bruke for mye tid på å gå gjennom datasettet da dette innlegget handler mer om å bruke Snowflake og Dask i stedet for å tolke data.
Nedenfor er kommandoene vi kan bruke til å lage tabellene våre. Alt du trenger å vite på forhånd er hvilke kolonner og datatyper du skal jobbe med.
create or replace table campaign_desc ( description string, campaign number,
start_day number,
end_day number ); create or replace table campaign_table ( description string, Household_key number, campaign number ); create or replace table coupon ( COUPON_UPC number, product_id number, campaign number ); create or replace table coupon_redempt ( household_key number, day number, coupon_upc number, campaign number ); create or replace table transactions ( household_key number, BASKET_ID number, day number, product_id number, quantity number, sales_value number, store_id number, retail_disc decimal, trans_time number, week_no number, coupon_disc decimal, coupon_match_disc decimal ); create or replace table demographic_data ( age_dec string, marital_status_code string, income_desc string, homeowner_desc string, hh_comp_desc string, household_size_desc string, kid_category_desc string, Household_key number);
Nå som vi har laget tabellene våre, kan vi begynne å tenke på hvordan vi får data inn i dem. For dette må vi iscenesette CSV-filene våre. Dette er i bunn og grunn bare et mellomtrinn, slik at Snowflake kan laste inn filene fra scenen vår direkte til bordene våre. Vi kan bruke PUT kommandoen for å legge lokale filer i scenen vår og deretter KOPIER INN I kommando for å instruere Snowflake hvor disse dataene skal plasseres.
use database dunnhumby; create or replace stage dunnhumby_stage; PUT file://campaigns_table.csv @dunnhumby.public.dunnhumby_stage; PUT file://campaigns_desc.csv @dunnhumby.public.dunnhumby_stage; PUT file://coupon.csv @dunnhumby.public.dunnhumby_stage; PUT file://coupon_d=redempt.csv @dunnhumby.public.dunnhumby_stage; PUT file://transaction_data.csv @dunnhumby.public.dunnhumby_stage; PUT file://demographics.csv @dunnhumby.public.dunnhumby_stage;
Som en rask sjekk kan du kjøre denne kommandoen for å sjekke hva som er i oppsamlingsområdet.
ls @dunnhumby.public.dunnhumby_stage;
Nå trenger vi bare å kopiere dataene inn i tabellene våre ved å bruke spørringene nedenfor. Du kan utføre disse enten i Snowflake UI eller på kommandolinjen etter å ha logget på Snowflake.
copy into campaign_table from @dunnhumby.public.dunnhumby_stage/campaigns_table.csv.gz file_format = ( type = csv
skip_header=1 error_on_column_count_mismatch = false field_optionally_enclosed_by=’”’); copy into campaign_desc from @dunnhumby.public.dunnhumby_stage/campaign_desc.csv.gz file_format = ( type = csv
skip_header=1 error_on_column_count_mismatch = false field_optionally_enclosed_by=’”’); copy into coupon from @dunnhumby.public.dunnhumby_stage/coupon.csv.gz file_format = ( type = csv
skip_header=1 error_on_column_count_mismatch = false field_optionally_enclosed_by=’”’); copy into coupon_redempt from @dunnhumby.public.dunnhumby_stage/coupon_redempt.csv.gz file_format = ( type = csv
skip_header=1 error_on_column_count_mismatch = false field_optionally_enclosed_by=’”’); copy into transactions from @dunnhumby.public.dunnhumby_stage/transaction_data.csv.gz file_format = ( type = csv
skip_header=1 error_on_column_count_mismatch = false field_optionally_enclosed_by=’”’); copy into demographic_data from @dunnhumby.public.dunnhumby_stage/demographics.csv.gz file_format = ( type = csv skip_header=1 error_on_column_count_mismatch = false field_optionally_enclosed_by=’”’);
Ok flott, med noe hell har vi dataene våre i tabellene våre første forsøk. Åh, hvis det bare var så enkelt, tok hele denne prosessen meg noen forsøk på å få det riktig (pass opp for å stave feil). Forhåpentligvis kan du følge med på dette og være i gang. Vi kommer nærmere de interessante tingene, men trinnene ovenfor er en viktig del av prosessen, så sørg for at du forstår hvert av disse trinnene.
Skrive vår pipeline i SQL
I dette neste trinnet vil vi skrive spørringene for å generere målet vårt, funksjonene våre og til slutt produsere et treningsdatasett. En tilnærming til å lage et datasett for modellering er å lese disse dataene inn i minnet og bruke pandaer til å lage nye funksjoner og slå sammen alle datarammene. Dette er vanligvis tilnærmingen du ser på Kaggle og i andre online opplæringsprogrammer. Problemet med dette er at det ikke er veldig effektivt, spesielt når du jobber med datasett av rimelig størrelse. Av denne grunn er det en mye bedre idé å outsource tunge løft til noe som Snowflake som håndterer enorme datasett ekstremt godt og sannsynligvis vil spare deg for mye tid. Jeg kommer ikke til å bruke mye tid på å dykke ned i detaljene til datasettet vårt her, siden det egentlig ikke er avgjørende for det jeg prøver å vise. Generelt sett vil du imidlertid bruke mye tid på å utforske og forstå dataene dine før du begynner å modellere. Målet med disse spørringene vil være å forhåndsbehandle dataene og lage noen enkle funksjoner som vi senere kan bruke i våre modeller.
Måldefinisjon
Åpenbart er en viktig komponent i overvåket maskinlæring å definere et passende mål å forutsi. For vår brukssituasjon vil vi forutsi churn ved å beregne om en bruker foretar et nytt besøk innen to uker etter en avbruddsuke. Valget av 2 uker er ganske vilkårlig og vil avhenge av det spesifikke problemet vi prøver å løse, men la oss bare anta at det er greit for dette prosjektet. Generelt vil du nøye analysere kundene dine for å forstå fordelingen i gap mellom besøk for å komme frem til en passende definisjon av churn.
Hovedideen her er at for hver tabell ønsker vi å ha én rad per household_key som inneholder verdier for hver av funksjonene våre.
Kampanjefunksjoner
Transaksjonsfunksjoner
Nedenfor lager vi noen enkle beregninger basert på aggregert statistikk som gjennomsnitt, maks og standardavvik.
Demografiske funksjoner
Dette datasettet har mange manglende data, så jeg bestemte meg for å bruke imputering her. Det er mange teknikker der ute for manglende data fra å droppe de manglende dataene, til avanserte imputeringsmetoder. Jeg har nettopp gjort livet enkelt for meg selv her og erstattet manglende verdier med modusen. Jeg vil ikke nødvendigvis anbefale å ta denne tilnærmingen generelt, da det er veldig viktig å forstå hvorfor disse dataene mangler for å avgjøre hvordan de skal håndteres, men i forbindelse med dette eksemplet vil jeg gå videre og ta den enkle tilnærmingen. Vi beregner først modusen for hver av funksjonene våre og bruker deretter sammensmelting for å erstatte hver rad med modusen hvis data mangler.
Treningsdata
Til slutt bygger vi en spørring for treningsdataene våre ved å slå sammen hovedtabellene våre og ender opp med en tabell som inneholder målet vårt, kampanjen vår, transaksjoner og demografiske funksjoner som vi kan bruke til å bygge en modell.
Som en kort side, for de som er interessert i å lære mer om funksjonene og nyansene til Snowflake, vil jeg anbefale følgende bok: Snøfnugg kokebok. Jeg begynte å lese denne boken, og den er full av nyttig informasjon om hvordan du bruker Snowflake og går langt mer i detalj enn jeg gjør her.
Python-kode for ETL
Det siste stykket vi trenger for denne ETL er å skrive et skript for å utføre det. Nå er dette egentlig bare nødvendig hvis du planlegger å kjøre en ETL som dette regelmessig, men dette er god praksis og gjør det mye enklere å kjøre ETL når og når det er nødvendig.
La oss kort diskutere hovedkomponentene i vår EtlTraining-klasse. Klassen vår tar ett innspill som er cutoff-uken. Dette er på grunn av måten data er definert på i datasettet vårt, men vanligvis vil dette være i et datoformat som tilsvarer cutoff-datoen vi ønsker å velge for å generere treningsdata.
Vi initialiserer en liste over søkene våre slik at vi enkelt kan gå gjennom disse og utføre dem. Vi lager også en ordbok som inneholder parameterne våre som vi sender til Snowflake-tilkoblingen vår. Her bruker vi miljøvariabler som vi setter opp i Saturn Cloud. Her er en veiledning for hvordan du gjør dette. Det er ikke så vanskelig å koble til Snowflake, alt vi trenger å gjøre er å bruke Snowflake-kontakten og gå inn i vår legitimasjonsordbok. Vi implementerer dette i Snowflake connect-metoden og returnerer denne forbindelsen som et attributt.
For å gjøre disse spørringene litt enklere å kjøre, lagrer jeg hver spørring som en python-strengvariabel i filen ml_query_pipeline.py. execute_etl-metoden gjør akkurat det som står på tinnen. Vi går gjennom hver spørring, formaterer den, utfører den og avslutter med å lukke Snowflake-tilkoblingen.
For å kjøre denne ETL kan vi ganske enkelt skrive inn kommandoene nedenfor i terminalen. (der ml_pipeline er navnet på skriptet ovenfor.)
python -m ml_pipeline -w 102 -j ‘train’
Som et kort til side, vil du sannsynligvis ønske å kjøre en ETL som dette med jevne mellomrom. For eksempel, hvis du ønsker å lage daglige spådommer, må du generere et datasett som dette hver dag for å overføres til modellen din, slik at du kan identifisere hvilke av kundene dine som sannsynligvis vil avbryte. Jeg vil ikke gå inn på dette i detalj her, men i jobben min bruker vi Airflow til å orkestrere ETL-ene våre, så jeg vil anbefale å sjekke det ut hvis du er interessert. Faktisk kjøpte jeg nylig en bok 'Datarørledninger med Apache Airflow' som jeg synes er flott og virkelig gir noen solide eksempler og råd om hvordan man bruker luftstrøm.
Dask og modellering
Nå som vi har bygget vår datapipeline, kan vi begynne å tenke på modellering. Det andre hovedmålet jeg har for dette innlegget er å fremheve fordelene ved å bruke Dask som en del av ML-utviklingsprosessen og vise dere hvor enkelt det er å bruke.
Til denne delen av prosjektet brukte jeg også Saturn sky som er et veldig fint verktøy jeg kom over nylig som lar oss utnytte kraften til Dask på tvers av en klynge datamaskiner i skyen. De viktigste fordelene med å bruke Saturn for meg er at det er veldig enkelt å dele arbeidet ditt, superenkelt å skalere opp datamaskinen når og når du trenger den, og den har et gratis nivåalternativ. Modellutvikling generelt er en veldig god brukssak for Dask da vi vanligvis ønsker å trene en haug med forskjellige modeller og se hva som fungerer best. Jo raskere vi kan gjøre dette, desto bedre har vi mer tid til å fokusere på andre viktige aspekter ved modellutvikling. I likhet med Snowflake trenger du bare å registrere deg her. og du kan veldig raskt spinne opp en forekomst av Jupyter lab og begynne å eksperimentere med det selv.
Nå innser jeg på dette tidspunktet at jeg har nevnt Dask noen ganger, men har aldri forklart hva det er. Så la meg ta et øyeblikk til å gi deg en oversikt over Dask på et veldig høyt nivå og hvorfor jeg synes det er kjempebra. Veldig enkelt, Dask er et python-bibliotek som drar fordel av parallell databehandling for å tillate deg å behandle og utføre operasjoner på veldig store datasett. Og det beste er at hvis du allerede er kjent med Python, bør Dask være veldig grei, siden syntaksen er veldig lik.
Grafen nedenfor fremhever hovedkomponentene i Dask.
kilde: Dask-dokumentasjon
Samlinger lar oss lage en graf over oppgaver som deretter kan utføres på flere datamaskiner. Noen av disse datastrukturene høres sannsynligvis ganske kjente ut, for eksempel arrays og datarammer, og de ligner på det du finner i python, men med noen viktige forskjeller. For eksempel kan du tenke på en Dask-dataramme som en haug med panda-datarammer bygget på en slik måte at vi kan utføre operasjoner parallelt.
Går vi videre fra samlinger har vi planleggeren. Når vi har laget oppgavegrafen, håndterer planleggeren resten for oss. Den administrerer arbeidsflyten og sender disse oppgavene til enten en enkelt maskin eller distribuerer dem over en klynge. Forhåpentligvis gir det deg en veldig kort oversikt over hvordan Dask fungerer. For mer informasjon foreslår jeg å sjekke ut dokumentasjon eller dette bok. Begge er veldig gode ressurser for å grave dypere inn i dette emnet.
Python-kode for modellering
Når jeg modellerer, har jeg en tendens til å ha et lite antall go-to-algoritmer som jeg alltid vil prøve ut først. Dette vil generelt gi meg en god idé om hva som kan passe for det spesifikke problemet jeg har. Disse modellene er Logistic Regression, Random Forest og GradientBoosting. Etter min erfaring, når du arbeider med tabelldata, vil disse algoritmene vanligvis gi deg ganske gode resultater. Nedenfor bygger vi en sklearn-modelleringspipeline ved å bruke disse 3 modellene. De nøyaktige modellene vi bruker her er egentlig ikke viktige, siden rørledningen skal fungere for enhver sklearn-klassifiseringsmodell, dette er bare min preferanse.
Uten videre, la oss dykke ned i koden. Heldigvis har vi outsourcet det meste av forbehandlingen vår til Snowflake, så vi trenger ikke rote for mye med treningsdataene våre her, men vi vil legge til noen få ekstra trinn ved å bruke sklearn-rørledninger.
Den første kodebiten nedenfor viser rørledningen når du bruker sklearn. Legg merke til at datasettet vårt er en vanlig gammel panda-dataramme og alle forbehandlingstrinnene våre utføres ved hjelp av sklearn-metoder. Det er ikke noe spesielt utenom det vanlige som skjer her. Vi leser inn dataene våre fra tabellen produsert av vår Snowflake ETL og sender dette inn i en sklearn-pipeline. De vanlige modelleringstrinnene gjelder her. Vi deler opp datasettet i trene og tester og gjør litt forhåndsbehandling, nemlig tilregne manglende verdier ved å bruke medianen, skalere dataene og en-hot-kode våre kategoriske data. Jeg er en stor fan av sklearn-rørledninger og bruker dem i utgangspunktet når jeg utvikler modeller i dag, de legger virkelig til rette for ren og konsis kode.
Hvordan fungerer denne rørledningen på et datasett med omtrent 2 millioner rader? Vel, å kjøre denne modellen uten noen hyperparameterinnstilling tar omtrent 34 minutter. Uff, litt sakte. Du kan forestille deg hvor uoverkommelig lang tid dette ville ta hvis vi ønsket å gjøre en hvilken som helst type hyperparameterinnstilling. Ok, så ikke ideelt, men la oss se hvordan Dask takler utfordringen.
Dask ML Python-kode
Målet vårt her er å se om vi kan slå sklearn-rørledningen ovenfor, spoilervarsling, det kan vi definitivt. Det kule med Dask er at adgangsbarrieren når du allerede er kjent med python er ganske lav. Vi kan få denne rørledningen i gang i Dask med bare noen få endringer.
Den første endringen du sannsynligvis vil legge merke til er at vi har noen forskjellige importer. En av de viktigste forskjellene mellom denne rørledningen og den forrige er at vi vil bruke en Dask-dataramme i stedet for en panda-dataramme for å trene modellen vår. Du kan tenke på en Dask-dataramme som en haug med panda-datarammer der vi kan utføre beregninger på hver enkelt samtidig. Dette er kjernen i Dasks parallellitet og er det som kommer til å redusere treningstiden for denne rørledningen.
Legg merke til at vi bruker @dask.forsinket som dekoratør til vår load_training_data funksjon. Dette instruerer Dask om å parallellisere denne funksjonen for oss.
Vi kommer også til å importere noen forbehandlings- og rørledningsmetoder fra Dask, og viktigst av alt, vi må importere SaturnCluster som vil tillate oss å lage en klynge for opplæring av modellene våre. En annen viktig forskjell med denne koden er at vi bruker mørke.vedvarer etter vår togprøvesplitt. Før dette punktet har ingen av funksjonene våre faktisk blitt beregnet på grunn av Dasks late evaluering. Når vi først bruker persist-metoden, ber vi Dask om å sende dataene våre til arbeiderne og utføre oppgavene vi har opprettet frem til dette tidspunktet og la disse objektene være i klyngen.
Til slutt trener vi modellene våre ved å bruke forsinket metode. Igjen, dette gjør oss i stand til å lage vår pipeline på en lat måte. Rørledningen blir ikke utført før vi når denne koden:
fit_pipelines = dask.compute(*pipelines_)
Denne gangen tok det oss bare rundt 10 minutter å kjøre denne rørledningen på nøyaktig samme datasett. Det er en hastighetsøkning med en faktor på 3.4, ikke for shabby. Nå, hvis vi ville, kunne vi fremskynde dette enda mer ved å skalere opp dataressursene våre ved å trykke på en knapp i Saturn.
Utplassering av rørledningen vår
Jeg nevnte tidligere at du sannsynligvis vil kjøre en rørledning som dette ganske regelmessig ved å bruke noe som luftstrøm. Hvis du ikke vil ha det første bryet med å sette opp alt for luftstrøm, tilbyr Saturn Cloud et enkelt alternativ med Jobs. Jobber lar oss pakke sammen koden vår og kjøre den med jevne mellomrom eller etter behov. Alt du trenger å gjøre er å gå til et eksisterende prosjekt og klikke på opprett en jobb. Når vi gjør det, skal det se slik ut:
kilde: Saturn
Herfra er alt vi trenger å gjøre å sørge for at python-filene ovenfor er i katalogen i bildet, og at vi kan skrive inn python-kommandoen ovenfor
python -m ml_pipeline -w 102 -j 'train'
Vi kan også sette opp en tidsplan ved hjelp av cron-syntaks for å kjøre ETL på daglig basis hvis vi vil. For de interesserte, her er en Opplæringen som går inn i alt det nitty-gritty.
Konklusjoner og takeaways
Vel, vi har nådd slutten av prosjektet vårt på dette tidspunktet. Nå har jeg åpenbart utelatt noen viktige deler av ML-utviklingssyklusen, for eksempel justering av hyperparameter og distribusjon av modellen vår, men kanskje jeg lar det være en annen dag. Tror jeg du bør prøve Dask? Jeg er ingen ekspert på noen måte, men fra det jeg har sett så langt virker det absolutt nyttig, og jeg er veldig spent på å eksperimentere mer med det og finne flere muligheter til å inkorporere det i mitt daglige arbeid som dataforsker. Forhåpentligvis fant du dette nyttig, og du kan også se noen av fordelene med Snowflake og Dask, og du vil begynne å eksperimentere med dem på egen hånd.
Ressurser
- Datarørledninger med Apache Airflow
- Snøfnugg kokebok
- Datavitenskap i stor skala med Python og Dask
- Coursera: SQL for datavitenskap
Noen av mine andre innlegg kan du finne interessante
La oss bygge en strømmedatapipeline
Gaussisk blandingsmodellering (GMM)
En Bayesiansk tilnærming til tidsserieprognoser
Merk: Noen av lenkene i dette innlegget er tilknyttede lenker.
Bio: Daniel Foley er en tidligere økonom som ble dataforsker og jobber i mobilspillindustrien.
original. Ompostet med tillatelse.
Relatert:
Kilde: https://www.kdnuggets.com/2021/07/building-machine-learning-pipelines-snowflake-dask.html
- "
- &
- 102
- 2021
- adgang
- Logg inn
- Ytterligere
- Fordel
- råd
- Partnerskap
- algoritmer
- Alle
- Amazon
- Apache
- AREA
- rundt
- auto
- BEST
- Bit
- bygge
- Bygning
- Bunch
- Kampanje
- saker
- forårsaket
- utfordre
- endring
- kontroll
- klassifisering
- nærmere
- Cloud
- kode
- Koding
- komponent
- Beregn
- datamaskiner
- databehandling
- Coursera
- Opprette
- Credentials
- Kunder
- dato
- datavitenskap
- dataforsker
- datasett
- datalager
- Database
- dag
- avtale
- dyp læring
- demografiske
- detalj
- utvikle
- Utvikling
- gJORDE
- Regissør
- effektivitet
- Ingeniører
- Miljø
- eksperiment
- Egenskaper
- Endelig
- slutt
- Først
- Fokus
- følge
- format
- Gratis
- fullt
- funksjon
- gaming
- Gaming industri
- general
- god
- GPU
- flott
- veilede
- her.
- Høy
- Uthev
- Hvordan
- Hvordan
- HTTPS
- stort
- Tanken
- identifisere
- bilde
- Øke
- industri
- info
- informasjon
- saker
- IT
- Jobb
- Jobb
- bli medlem
- hoppe
- nøkkel
- stor
- LÆRE
- læring
- Nivå
- Bibliotek
- linje
- Liste
- laste
- lokal
- Lang
- maskinlæring
- Metrics
- millioner
- ML
- Mobil
- Mobilspilling
- modell
- flytte
- nemlig
- Nye funksjoner
- Tilbud
- på nett
- Drift
- Alternativ
- Annen
- ytelse
- Plenty
- innlegg
- makt
- Spådommer
- produsert
- produktivitet
- prosjekt
- offentlig
- Python
- Lesning
- redusere
- regresjon
- Ressurser
- REST
- Resultater
- Kjør
- rennende
- Skala
- skalering
- Vitenskap
- forskere
- Serien
- sett
- innstilling
- Del
- delt
- Enkelt
- liten
- So
- LØSE
- fart
- bruke
- utgifter
- Snurre rundt
- splittet
- SQL
- Scene
- Begynn
- startet
- statistikk
- Stories
- streaming
- Target
- test
- tenker
- tid
- topp
- berøre
- Kurs
- Transaksjonen
- Transaksjoner
- prøve
- tutorials
- ui
- us
- Brukere
- virtuelle
- Warehouse
- uke
- Hva er
- innenfor
- Arbeid
- arbeidere
- arbeidsflyt
- virker
- skriving
- X
- år