Byg maskinlæringsrørledninger ved hjælp af Snowflake og Dask
I dette indlæg vil jeg dele nogle af de værktøjer, som jeg har udforsket for nylig, og vise dig, hvordan jeg bruger dem, og hvordan de hjalp med at forbedre effektiviteten af min arbejdsgang. De to jeg især vil tale om er Snowflake og Dask. To meget forskellige værktøjer, men som komplementerer hinanden godt, især som en del af ML Lifecycle.
By Daniel Foley, dataforsker
Introduktion
For nylig har jeg forsøgt at finde bedre måder at forbedre min arbejdsgang som dataforsker på. Jeg har en tendens til at bruge en anstændig del af min tid på at modellere og bygge ETL'er i mit job. Det har betydet, at jeg mere og mere er nødt til at stole på værktøjer til pålideligt og effektivt at håndtere store datasæt. Jeg indså hurtigt, at det ikke altid er en god tilgang at bruge pandaer til at manipulere disse datasæt, og det fik mig til at undersøge andre alternativer.
I dette indlæg vil jeg dele nogle af de værktøjer, som jeg har udforsket for nylig, og vise dig, hvordan jeg bruger dem, og hvordan de hjalp med at forbedre effektiviteten af min arbejdsgang. De to jeg især vil tale om er Snowflake og Dask. To meget forskellige værktøjer, men som komplementerer hinanden godt, især som en del af ML Lifecycle. Mit håb er, at du efter at have læst dette indlæg vil have en god forståelse af, hvad Snowflake og Dask er, hvordan de kan bruges effektivt og være i stand til at komme i gang med dine egne use cases.
Mere specifikt vil jeg vise dig, hvordan du kan bygge en ETL-pipeline ved hjælp af Snowflake og Python til at generere træningsdata til en maskinlæringsopgave. Jeg vil så introducere Dask og Saturn Sky og vise dig, hvordan du kan drage fordel af parallel bearbejdning i skyen til virkelig at fremskynde ML-træningsprocessen, så du kan øge din produktivitet som dataforsker.
Opbygning af ETL'er i Snowflake og Python
Før vi hopper ind i kodning, må jeg hellere kort forklare, hvad Snowflake er. Dette er et spørgsmål, jeg for nylig stillede, da mit team besluttede at begynde at bruge det. På et højt niveau er det et datavarehus i skyen. Efter at have leget med det et stykke tid indså jeg, hvor kraftfuldt det var. Jeg tror for mig, at en af de mest nyttige funktioner er de virtuelle varehuse, som du kan bruge. Et virtuelt lager giver dig adgang til de samme data, men er fuldstændig uafhængigt af andre virtuelle varehuse, så computerressourcer deles ikke på tværs af teams. Dette har vist sig meget nyttigt, da det fjerner ethvert potentiale for ydeevneproblemer forårsaget af andre brugere, der udfører forespørgsler i løbet af dagen. Dette har resulteret i mindre frustration og spildtid på at vente på, at forespørgsler skal køre.
Da vi skal bruge Snowflake, vil jeg kort skitsere, hvordan du kan sætte det op og begynde at eksperimentere med det selv. Vi skal gøre følgende:
- Få en Snowflake-konto oprettet
- Få vores data ind i Snowflake
- Skriv og test vores forespørgsler ved hjælp af SQL og Snowflake UI
- Skriv en Python-klasse, der kan udføre vores forespørgsler for at generere vores endelige datasæt til modellering
Det er lige så nemt at oprette en konto som at tilmelde sig en gratis prøveperiode på deres hjemmeside. Når du har gjort det, kan du downloade snowsql CLI link.. Dette vil gøre det nemt at tilføje data til Snowflake. Efter at have fulgt disse trin kan vi prøve at oprette forbindelse til Snowflake ved hjælp af vores legitimationsoplysninger og kommandolinjen.
snowsql -a <account_name> -u <user_name>
Du kan finde dit kontonavn i URL'en, når du logger ind på Snowflake UI. Det skulle se nogenlunde sådan ud: xxxxx.europe-west2.gcp. Ok, lad os gå videre til næste trin og få vores data ind i Snowflake. Der er et par trin, vi skal følge her, nemlig:
- Opret vores virtuelle lager
- Opret en database
- Definer og opret vores tabeller
- Opret en iscenesættelsestabel til vores CSV-filer
- Kopiering af data til vores tabeller
Heldigvis er dette ikke for svært, og vi kan gøre dette udelukkende ved hjælp af snowsql CLI. Til dette projekt vil jeg bruge et mindre datasæt, end jeg kunne tænke mig, men desværre kan jeg ikke bruge nogen af min virksomheds data, og det kan være ret svært at finde store passende datasæt online. Jeg fandt dog nogle transaktionsdata fra Dunnhumby, som er frit tilgængelige på Kaggle. Bare for kick, selvom jeg opretter et meget større syntetisk datasæt ved hjælp af disse data for at teste, hvor godt Dask håndterer udfordringen sammenlignet med sklearn.
Først og fremmest skal vi konfigurere et virtuelt lager og en database ved hjælp af følgende kommandoer i Snowflake UI.
skabe or erstatte lageranalyse_wh med
warehouse_size="X-SMALL"
auto_suspend=180
auto_resume=sand
initially_suspended=sand;
skabe or erstatte database dunnhumby;
Vores data består af 6 CSV'er, som vi konverterer til 6 tabeller. Jeg vil ikke bruge for meget tid på at gennemgå datasættet, da dette indlæg handler mere om at bruge Snowflake og Dask i stedet for at fortolke data.
Nedenfor er de kommandoer, vi kan bruge til at oprette vores tabeller. Alt du skal vide på forhånd er, hvilke kolonner og datatyper du vil arbejde 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);
Nu hvor vi har lavet vores tabeller, kan vi begynde at tænke på, hvordan vi får data ind i dem. Til dette skal vi iscenesætte vores CSV-filer. Dette er dybest set kun et mellemtrin, så Snowflake direkte kan indlæse filerne fra vores scene til vores borde. Vi kan bruge PUT kommando til at lægge lokale filer i vores scene og derefter KOPIERE IND kommando for at instruere Snowflake, hvor disse data skal placeres.
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 et hurtigt tjek kan du køre denne kommando for at kontrollere, hvad der er i iscenesættelsesområdet.
ls @dunnhumby.public.dunnhumby_stage;
Nu mangler vi bare at kopiere dataene ind i vores tabeller ved hjælp af forespørgslerne nedenfor. Du kan udføre disse enten i Snowflake UI eller på kommandolinjen efter at have 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=’”’);
Okay fantastisk, med lidt held har vi vores data i vores tabeller første forsøg. Åh, hvis det bare var så enkelt, så tog hele denne proces mig et par forsøg på at få ret (pas på med at stave forkert). Forhåbentlig kan du følge med i dette og være god til at gå. Vi kommer tættere på de interessante ting, men ovenstående trin er en vigtig del af processen, så sørg for, at du forstår hvert af disse trin.
At skrive vores pipeline i SQL
I dette næste trin vil vi skrive forespørgslerne for at generere vores mål, vores funktioner og til sidst producere et træningsdatasæt. En tilgang til at skabe et datasæt til modellering er at læse disse data ind i hukommelsen og bruge pandaer til at skabe nye funktioner og samle alle datarammerne. Dette er typisk den tilgang, du ser på Kaggle og i andre online tutorials. Problemet med dette er, at det ikke er særlig effektivt, især når du arbejder med nogen rimelig størrelse datasæt. Af denne grund er det en meget bedre idé at outsource de tunge løft til noget som Snowflake, som håndterer massive datasæt ekstremt godt og sandsynligvis vil spare dig for en enorm mængde tid. Jeg vil ikke bruge meget tid på at dykke ned i detaljerne i vores datasæt her, da det egentlig ikke er afgørende for det, jeg forsøger at vise. Generelt vil du dog gerne bruge en betydelig mængde tid på at udforske og forstå dine data, før du begynder at modellere. Målet med disse forespørgsler vil være at forbehandle dataene og skabe nogle simple funktioner, som vi senere kan bruge i vores modeller.
Definition af mål
Det er klart, at en vital komponent i overvåget maskinlæring er at definere et passende mål at forudsige. For vores brugssag vil vi forudsige afgang ved at beregne, om en bruger besøger igen inden for to uger efter en cutoff-uge. Valget af 2 uger er ret vilkårligt og vil afhænge af det specifikke problem, vi forsøger at løse, men lad os bare antage, at det er fint til dette projekt. Generelt vil du omhyggeligt analysere dine kunder for at forstå fordelingen i huller mellem besøgene for at nå frem til en passende definition af churn.
Hovedideen her er, at vi for hver tabel ønsker at have en række pr. household_key, der indeholder værdier for hver af vores funktioner.
Kampagnefunktioner
Transaktionsfunktioner
Nedenfor laver vi nogle simple metrics baseret på aggregerede statistikker såsom gennemsnittet, maks. og standardafvigelse.
Demografiske funktioner
Dette datasæt har masser af manglende data, så jeg besluttede at bruge imputation her. Der er masser af teknikker derude til manglende data fra at droppe de manglende data til avancerede imputeringsmetoder. Jeg har lige gjort livet nemt for mig selv her og erstattet manglende værdier med tilstanden. Jeg vil ikke nødvendigvis anbefale at tage denne tilgang generelt, da det er virkelig vigtigt at forstå, hvorfor disse data mangler, for at beslutte, hvordan man skal håndtere det, men i forbindelse med dette eksempel vil jeg gå videre og tage den nemme tilgang. Vi beregner først tilstanden for hver af vores funktioner og bruger derefter sammensmeltning til at erstatte hver række med tilstanden, hvis data mangler.
Træningsdata
Til sidst bygger vi en forespørgsel til vores træningsdata ved at samle vores hovedtabeller og ender med en tabel, der indeholder vores mål, vores kampagne, transaktioner og demografiske funktioner, som vi kan bruge til at bygge en model.
Som en kort side, for dem, der er interesseret i at lære mere om funktionerne og nuancerne ved Snowflake, vil jeg anbefale følgende bog: Snefnug kogebog. Jeg begyndte at læse denne bog, og den er fuld af virkelig nyttige oplysninger om, hvordan man bruger Snowflake og går langt mere i detaljer, end jeg gør her.
Python-kode til ETL
Det sidste stykke, vi har brug for til denne ETL, er at skrive et script til at udføre det. Nu er dette kun påkrævet, hvis du planlægger at køre en ETL som denne regelmæssigt, men dette er god praksis og gør det meget nemmere at køre ETL, når og når det er nødvendigt.
Lad os kort diskutere hovedkomponenterne i vores EtlTraining-klasse. Vores klasse tager ét input, som er cutoff-ugen. Dette skyldes den måde, data defineres på i vores datasæt, men normalt ville dette være i et datoformat, der svarer til den skæringsdato, vi ønsker at vælge til generering af træningsdata.
Vi initialiserer en liste over vores forespørgsler, så vi nemt kan gå igennem disse og udføre dem. Vi opretter også en ordbog, der indeholder vores parametre, som vi videregiver til vores Snowflake-forbindelse. Her bruger vi miljøvariabler, som vi opsætter i Saturn Cloud. Her er en guide til, hvordan du gør dette. Det er ikke for svært at oprette forbindelse til Snowflake, alt hvad vi skal gøre er at bruge Snowflake-stikket og videregive vores legitimationsordbog. Vi implementerer dette i Snowflake connect-metoden og returnerer denne forbindelse som en attribut.
For at gøre disse forespørgsler en smule lettere at køre, gemmer jeg hver forespørgsel som en python-strengvariabel i filen ml_query_pipeline.py. execute_etl metoden gør præcis, hvad der står på tin. Vi går gennem hver forespørgsel, formaterer den, udfører den og afslutter med at lukke Snowflake-forbindelsen.
For at køre denne ETL kan vi blot skrive kommandoerne nedenfor i terminalen. (hvor ml_pipeline er navnet på scriptet ovenfor.)
python -m ml_pipeline -w 102 -j ‘train’
Som en kort side vil du sikkert gerne køre en ETL som denne med jævne mellemrum. For eksempel, hvis du vil lave daglige forudsigelser, skal du generere et datasæt som dette hver dag for at videregive til din model, så du kan identificere, hvilke af dine kunder, der sandsynligvis vil frafalde. Jeg vil ikke gå i detaljer her, men i mit job bruger vi Airflow til at orkestrere vores ETL'er, så jeg vil anbefale at tjekke det ud, hvis du er interesseret. Faktisk købte jeg for nylig en bog 'Datarørledninger med Apache Airflow' hvilket jeg synes er fantastisk og virkelig giver nogle solide eksempler og råd om, hvordan man bruger luftstrøm.
Dask og modellering
Nu hvor vi har bygget vores datapipeline, kan vi begynde at tænke på modellering. Det andet hovedmål, jeg har med dette indlæg, er at fremhæve fordelene ved at bruge Dask som en del af ML-udviklingsprocessen og vise jer, hvor nemt det er at bruge.
Til denne del af projektet brugte jeg også Saturn Sky hvilket er et rigtig godt værktøj, jeg stødte på for nylig, som giver os mulighed for at udnytte kraften i Dask på tværs af en klynge af computere i skyen. De vigtigste fordele ved at bruge Saturn for mig er, at det er virkelig nemt at dele dit arbejde, super nemt at skalere din computer op, når og når du har brug for det, og det har en gratis niveaumulighed. Modeludvikling generelt er en rigtig god use case for Dask, da vi normalt vil træne en masse forskellige modeller og se, hvad der virker bedst. Jo hurtigere vi kan gøre dette, jo bedre, da vi har mere tid til at fokusere på andre vigtige aspekter af modeludvikling. I lighed med Snowflake skal du blot tilmelde dig link. og du kan meget hurtigt lave en instans af Jupyter lab og begynde at eksperimentere med det selv.
Nu indser jeg på dette tidspunkt, at jeg har nævnt Dask et par gange, men jeg har aldrig rigtig forklaret, hvad det er. Så lad mig bruge et øjeblik på at give dig et overblik over Dask på meget højt niveau, og hvorfor jeg synes, det er fantastisk. Meget enkelt er Dask et python-bibliotek, der udnytter parallel computing til at give dig mulighed for at behandle og udføre operationer på meget store datasæt. Og det bedste er, hvis du allerede er bekendt med Python, så burde Dask være meget ligetil, da syntaksen er meget ens.
Grafen nedenfor fremhæver hovedkomponenterne i Dask.
Kilde: Dask dokumentation
Samlinger giver os mulighed for at oprette en graf over opgaver, som derefter kan udføres på tværs af flere computere. Nogle af disse datastrukturer lyder sandsynligvis ret velkendte, såsom arrays og datarammer, og de ligner det, du ville finde i python, men med nogle vigtige forskelle. For eksempel kan du tænke på en Dask-dataramme som en flok panda-datarammer bygget på en sådan måde, at vi kan udføre operationer parallelt.
Går vi videre fra samlinger har vi skemalæggeren. Når vi har oprettet opgavegrafen, håndterer planlæggeren resten for os. Den styrer arbejdsgangen og sender disse opgaver til enten en enkelt maskine eller distribuerer dem på tværs af en klynge. Forhåbentlig giver det dig et meget kort overblik over, hvordan Dask fungerer. For mere information foreslår jeg, at du tjekker ud dokumentation eller dette bog. Begge er meget gode ressourcer til at grave dybere ned i dette emne.
Python-kode til modellering
Når jeg modellerer, har jeg en tendens til at have et lille antal go-to-algoritmer, som jeg altid vil prøve først. Dette vil generelt give mig en god idé om, hvad der kan passe til det specifikke problem, jeg har. Disse modeller er Logistic Regression, Random Forest og GradientBoosting. Efter min erfaring vil disse algoritmer normalt give dig ret gode resultater, når du arbejder med tabeldata. Nedenfor bygger vi en sklearn-modelleringspipeline ved hjælp af disse 3 modeller. De nøjagtige modeller, vi bruger her, er ikke rigtig vigtige, da pipelinen burde fungere for enhver sklearn-klassifikationsmodel, dette er bare min præference.
Lad os uden videre dykke ned i koden. Heldigvis har vi outsourcet det meste af vores forbehandling til Snowflake, så vi ikke skal rode for meget med vores træningsdata her, men vi vil tilføje et par ekstra trin ved hjælp af sklearn-pipelines.
Det første kodestykke nedenfor viser pipelinen, når du bruger sklearn. Bemærk, at vores datasæt er en almindelig gammel panda-dataramme, og vores forbehandlingstrin udføres alle ved hjælp af sklearn-metoder. Der foregår ikke noget særligt ud over det sædvanlige her. Vi læser vores data fra tabellen produceret af vores Snowflake ETL og sender dette ind i en slær pipeline. De sædvanlige modelleringstrin gælder her. Vi opdeler datasættet i tog og tester og laver nogle forbehandlinger, nemlig imputer manglende værdier ved hjælp af medianen, skalerer dataene og en-hot-kodning af vores kategoriske data. Jeg er en stor fan af sklearn pipelines og bruger dem dybest set, når jeg udvikler modeller i dag, de letter virkelig ren og kortfattet kode.
Hvordan fungerer denne pipeline på et datasæt med omkring 2 millioner rækker? Nå, det tager omkring 34 minutter at køre denne model uden nogen form for hyperparameterjustering. Uh, lidt langsomt. Du kan forestille dig, hvor uoverkommeligt lang tid dette ville tage, hvis vi ønskede at lave en hvilken som helst type hyperparameterjustering. Ok, så ikke ideelt, men lad os se, hvordan Dask håndterer udfordringen.
Dask ML Python-kode
Vores mål her er at se, om vi kan slå sklearn-pipelinen ovenfor, spoiler alert, det kan vi helt sikkert. Det fede ved Dask er, at adgangsbarrieren, når du allerede er fortrolig med python, er ret lav. Vi kan få denne pipeline op at køre i Dask med kun få ændringer.
Den første ændring du sikkert vil bemærke er, at vi har nogle forskellige importer. En af de vigtigste forskelle mellem denne pipeline og den forrige er, at vi vil bruge en Dask-dataramme i stedet for en panda-dataramme til at træne vores model. Du kan tænke på en Dask-dataramme som en flok panda-datarammer, hvor vi kan udføre beregninger på hver enkelt på samme tid. Dette er kernen i Dasks parallelitet og er det, der kommer til at reducere træningstiden for denne pipeline.
Bemærk vi bruger @dask.forsinket som dekoratør til vores indlæs_træningsdata fungere. Dette instruerer Dask om at parallelisere denne funktion for os.
Vi skal også importere nogle forbehandlings- og pipelinemetoder fra Dask, og vigtigst af alt bliver vi nødt til at importere SaturnCluster, som vil give os mulighed for at oprette en klynge til træning af vores modeller. En anden vigtig forskel med denne kode er, at vi bruger mørke.vedvarer efter vores togtest split. Før dette tidspunkt er ingen af vores funktioner faktisk blevet beregnet på grund af Dasks dovne evaluering. Når vi først bruger persist-metoden, fortæller vi Dask om at sende vores data til arbejderne og udføre de opgaver, vi har oprettet indtil dette tidspunkt, og efterlade disse objekter i klyngen.
Til sidst træner vi vores modeller ved hjælp af den forsinkede metode. Igen gør dette os i stand til at skabe vores pipeline på en doven måde. Pipelinen bliver ikke eksekveret, før vi når denne kode:
fit_pipelines = dask.compute(*pipelines_)
Denne gang tog det os kun omkring 10 minutter at køre denne pipeline på nøjagtig det samme datasæt. Det er en fremskyndelse med en faktor på 3.4, ikke for lurvet. Nu, hvis vi ville, kunne vi fremskynde dette endnu mere ved at opskalere vores computerressourcer ved at trykke på en knap i Saturn.
Udrulning af vores pipeline
Jeg nævnte tidligere, at du sandsynligvis vil køre en rørledning som denne ret regelmæssigt ved hjælp af noget som luftstrøm. Det sker bare sådan, at hvis du ikke vil have det indledende besvær med at indstille alt til luftstrøm, tilbyder Saturn Cloud et simpelt alternativ med Jobs. Jobs giver os mulighed for at pakke vores kode og køre den med jævne mellemrum eller efter behov. Alt du skal gøre er at gå til et eksisterende projekt og klikke på opret et job. Når vi gør det, skulle det se sådan ud:
Kilde: Saturn
Herfra er alt, hvad vi skal gøre, at sikre, at vores python-filer ovenfor er i mappen i billedet, og vi kan indtaste vores python-kommando ovenfor
python -m ml_pipeline -w 102 -j 'train'
Vi kan også oprette en tidsplan ved hjælp af cron-syntaks til at køre ETL på daglig basis, hvis vi vil. For de interesserede er her en tutorial der går ind i alt det nitty-gritty.
Konklusioner og takeaways
Nå, vi er nået til slutningen af vores projekt på dette tidspunkt. Nu har jeg åbenbart udeladt nogle vigtige dele af ML-udviklingscyklussen, såsom justering af hyperparameter og implementering af vores model, men måske vil jeg lade det ligge en anden dag. Synes jeg du skal prøve Dask? Jeg er på ingen måde ekspert, men ud fra det, jeg har set indtil videre, virker det bestemt virkelig nyttigt, og jeg er super spændt på at eksperimentere mere med det og finde flere muligheder for at inkorporere det i mit daglige arbejde som data scientist. Forhåbentlig fandt du dette nyttigt, og du kan også se nogle af fordelene ved Snowflake og Dask, og du vil begynde at eksperimentere med dem på egen hånd.
Ressourcer
- Datarørledninger med Apache Airflow
- Snefnug kogebog
- Datavidenskab i skala med Python og Dask
- Coursera: SQL for Data Science
Nogle af mine andre indlæg kan du finde interessante
Lad os bygge en streamingdatapipeline
Gaussisk blandingsmodellering (GMM)
En Bayesiansk tilgang til tidsserieprognoser
Bemærk: Nogle af linkene i dette indlæg er affiliate links.
Bio: Daniel Foley er en tidligere økonom, der blev dataforsker, og arbejder i mobilspilindustrien.
Original. Genopslået med tilladelse.
Relateret:
Kilde: https://www.kdnuggets.com/2021/07/building-machine-learning-pipelines-snowflake-dask.html
- "
- &
- 102
- 2021
- adgang
- Konto
- Yderligere
- Fordel
- rådgivning
- Affiliate
- algoritmer
- Alle
- Amazon
- Apache
- OMRÅDE
- omkring
- auto
- BEDSTE
- Bit
- bygge
- Bygning
- Bunch
- Kampagne
- tilfælde
- forårsagede
- udfordre
- lave om
- kontrol
- klassificering
- tættere
- Cloud
- kode
- Kodning
- komponent
- Compute
- computere
- computing
- Coursera
- Oprettelse af
- Legitimationsoplysninger
- Kunder
- data
- datalogi
- dataforsker
- datasæt
- datalager
- Database
- dag
- deal
- dyb læring
- demografiske
- detail
- udvikle
- Udvikling
- DID
- Direktør
- effektivitet
- Ingeniører
- Miljø
- eksperiment
- Funktionalitet
- Endelig
- ende
- Fornavn
- Fokus
- følger
- format
- Gratis
- fuld
- funktion
- spil
- Spillebranchen
- Generelt
- godt
- GPU'er
- stor
- vejlede
- link.
- Høj
- Fremhæv
- Hvordan
- How To
- HTTPS
- kæmpe
- idé
- identificere
- billede
- Forøg
- industrien
- info
- oplysninger
- spørgsmål
- IT
- Job
- Karriere
- deltage
- hoppe
- Nøgle
- stor
- LÆR
- læring
- Niveau
- Bibliotek
- Line (linje)
- Liste
- belastning
- lokale
- Lang
- machine learning
- Metrics
- million
- ML
- Mobil
- Mobil spil
- model
- bevæge sig
- nemlig
- Nye funktioner
- Tilbud
- online
- Produktion
- Option
- Andet
- ydeevne
- Masser
- Indlæg
- magt
- Forudsigelser
- produceret
- produktivitet
- projekt
- offentlige
- Python
- Læsning
- reducere
- regression
- Ressourcer
- REST
- Resultater
- Kør
- kører
- Scale
- skalering
- Videnskab
- forskere
- Series
- sæt
- indstilling
- Del
- delt
- Simpelt
- lille
- So
- SOLVE
- hastighed
- tilbringe
- udgifterne
- Spin
- delt
- SQL
- Stage
- starte
- påbegyndt
- statistik
- Historier
- streaming
- mål
- prøve
- Tænker
- tid
- top
- Kurser
- transaktion
- Transaktioner
- retssag
- tutorials
- ui
- us
- brugere
- Virtual
- Warehouse
- uge
- Hvad er
- inden for
- Arbejde
- arbejdere
- workflow
- virker
- skrivning
- X
- år