Bygga rörledningar för maskininlärning med Snowflake och Dask
I det här inlägget vill jag dela några av de verktyg som jag har utforskat nyligen och visa dig hur jag använder dem och hur de hjälpte till att förbättra effektiviteten i mitt arbetsflöde. De två jag kommer att prata om speciellt är Snowflake och Dask. Två väldigt olika verktyg men som kompletterar varandra väl, särskilt som en del av ML Lifecycle.
By Daniel Foley, Datavetare
Beskrivning
På senare tid har jag försökt hitta bättre sätt att förbättra mitt arbetsflöde som dataforskare. Jag brukar spendera en anständig del av min tid med att modellera och bygga ETL i mitt jobb. Detta har inneburit att jag mer och mer behöver förlita mig på verktyg för att tillförlitligt och effektivt hantera stora datamängder. Jag insåg snabbt att det inte alltid är ett bra tillvägagångssätt att använda pandor för att manipulera dessa datauppsättningar och det fick mig att undersöka andra alternativ.
I det här inlägget vill jag dela några av de verktyg som jag har utforskat nyligen och visa dig hur jag använder dem och hur de hjälpte till att förbättra effektiviteten i mitt arbetsflöde. De två jag kommer att prata om speciellt är Snowflake och Dask. Två väldigt olika verktyg men som kompletterar varandra väl, särskilt som en del av ML Lifecycle. Min förhoppning är att du efter att ha läst detta inlägg kommer att ha en god förståelse för vad Snowflake och Dask är, hur de kan användas effektivt och kunna komma igång med dina egna användningsfall.
Mer specifikt vill jag visa dig hur du kan bygga en ETL-pipeline med Snowflake och Python för att generera träningsdata för en maskininlärningsuppgift. Jag vill sedan presentera Dask och Saturnus moln och visa dig hur du kan dra fördel av parallell bearbetning i molnet för att verkligen påskynda ML-utbildningsprocessen så att du kan öka din produktivitet som datavetare.
Bygga ETL i Snowflake och Python
Innan vi går in i kodning är det bättre att kortfattat förklara vad Snowflake är. Det här är en fråga jag nyligen ställde när mitt team bestämde sig för att börja använda det. På hög nivå är det ett datalager i molnet. Efter att ha lekt med den ett tag insåg jag hur kraftfull den var. Jag tror att en av de mest användbara funktionerna för mig är de virtuella lagren som du kan använda. Ett virtuellt lager ger dig tillgång till samma data men är helt oberoende av andra virtuella lager så att beräkningsresurser inte delas mellan team. Detta har visat sig vara mycket användbart eftersom det tar bort all risk för prestandaproblem som orsakas av att andra användare kör frågor under dagen. Detta har resulterat i mindre frustration och tidsspillan på att vänta på att frågor ska köras.
Eftersom vi kommer att använda Snowflake kommer jag kortfattat att beskriva hur du kan ställa in det och börja experimentera med det själv. Vi behöver göra följande:
- Skapa ett Snowflake-konto
- Få vår data till Snowflake
- Skriv och testa våra frågor med SQL och Snowflake UI
- Skriv en Python-klass som kan köra våra frågor för att generera vår slutliga datauppsättning för modellering
Att skapa ett konto är lika enkelt som att registrera sig för en gratis provperiod på deras webbplats. När du har gjort det kan du ladda ner snowsql CLI här.. Detta gör det enkelt att lägga till data till Snowflake. Efter att ha följt dessa steg kan vi försöka ansluta till Snowflake med hjälp av våra referenser och kommandoraden.
snowsql -a <account_name> -u <user_name>
Du kan hitta ditt kontonamn i URL:en när du loggar in på Snowflake UI. Det borde se ut ungefär så här: xxxxx.europe-west2.gcp. Ok, låt oss gå vidare till nästa steg och hämta vår data till Snowflake. Det finns några steg vi måste följa här, nämligen:
- Skapa vårt virtuella lager
- Skapa en databas
- Definiera och skapa våra tabeller
- Skapa en mellanställningstabell för våra CSV-filer
- Kopiera data till våra tabeller
Lyckligtvis är detta inte alltför svårt och vi kan göra detta helt med snowsql CLI. För det här projektet kommer jag att använda en mindre datauppsättning än jag skulle vilja men tyvärr kan jag inte använda någon av mitt företags data och det kan vara ganska svårt att hitta stora lämpliga datauppsättningar online. Jag hittade dock några transaktionsdata från Dunnhumby som är fritt tillgänglig på Kaggle. Bara för kick, men jag skapar en mycket större syntetisk datauppsättning med dessa data för att testa hur väl Dask hanterar utmaningen jämfört med sklearn.
Först och främst måste vi ställa in ett virtuellt lager och en databas med hjälp av följande kommandon i Snowflake UI.
skapa or ersätta lageranalys_wh med
warehouse_size="X-SMALL"
auto_suspend=180
auto_resume=true
initially_suspended=true;
skapa or ersätta databas dunnhumby;
Vår data består av 6 CSV:er som vi konverterar till 6 tabeller. Jag kommer inte att lägga för mycket tid på att gå igenom datamängden eftersom det här inlägget handlar mer om att använda Snowflake och Dask snarare än att tolka data.
Nedan finns de kommandon vi kan använda för att skapa våra tabeller. Allt du behöver veta i förväg är vilka kolumner och datatyper du kommer att arbeta 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 när vi har skapat våra tabeller kan vi börja fundera på hur vi ska få in data i dem. För detta måste vi iscensätta våra CSV-filer. Detta är i princip bara ett mellansteg så Snowflake kan direkt ladda filerna från vår scen till våra tabeller. Vi kan använda SÄTTA kommandot för att placera lokala filer i vårt stadium och sedan KOPIERA IN TILL kommandot för att instruera Snowflake var denna data ska placeras.
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 snabb kontroll kan du köra det här kommandot för att kontrollera vad som finns i uppställningsområdet.
ls @dunnhumby.public.dunnhumby_stage;
Nu behöver vi bara kopiera data till våra tabeller med hjälp av frågorna nedan. Du kan utföra dessa antingen i Snowflake UI eller på kommandoraden efter att ha loggat in 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=’”’);
Okej bra, med lite tur har vi vår data i våra tabeller första försöket. Åh, om det bara var så enkelt, hela den här processen tog mig några försök att få rätt (se upp för att stava fel). Förhoppningsvis kan du följa med på detta och vara bra att gå. Vi närmar oss de intressanta sakerna men stegen ovan är en viktig del av processen så se till att du förstår vart och ett av dessa steg.
Att skriva vår pipeline i SQL
I det här nästa steget kommer vi att skriva frågorna för att generera vårt mål, våra funktioner och sedan slutligen producera en träningsdatauppsättning. Ett tillvägagångssätt för att skapa en datauppsättning för modellering är att läsa in dessa data i minnet och använda pandor för att skapa nya funktioner och sammanfoga alla dataramar. Detta är vanligtvis det tillvägagångssätt som du ser på Kaggle och i andra onlinehandledningar. Problemet med detta är att det inte är särskilt effektivt, särskilt när du arbetar med en rimlig storleksdatauppsättning. Av denna anledning är det en mycket bättre idé att lägga ut de tunga lyften till något som Snowflake som hanterar enorma datamängder extremt bra och kommer sannolikt att spara enormt mycket tid. Jag kommer inte att lägga mycket tid på att dyka ner i detaljerna i vår datauppsättning här eftersom den inte är riktigt viktig för det jag försöker visa. I allmänhet skulle du dock vilja spendera mycket tid på att utforska och förstå dina data innan du börjar modellera. Målet med dessa frågor kommer att vara att förbehandla data och skapa några enkla funktioner som vi senare kan använda i våra modeller.
Måldefinition
Uppenbarligen är en viktig komponent i övervakad maskininlärning att definiera ett lämpligt mål att förutsäga. För vårt användningsfall kommer vi att förutsäga churn genom att beräkna om en användare gör ett nytt besök inom två veckor efter en brytvecka. Valet av 2 veckor är ganska godtyckligt och kommer att bero på det specifika problem vi försöker lösa men låt oss bara anta att det är bra för det här projektet. I allmänhet skulle du vilja analysera dina kunder noggrant för att förstå fördelningen av gap mellan besök för att komma fram till en lämplig definition av churn.
Huvudtanken här är att vi för varje tabell vill ha en rad per hushållsnyckel som innehåller värden för var och en av våra funktioner.
Kampanjfunktioner
Transaktionsfunktioner
Nedan skapar vi några enkla mätvärden baserade på aggregerad statistik som medel, max och standardavvikelse.
Demografiska funktioner
Denna datauppsättning har massor av saknade data så jag bestämde mig för att använda imputation här. Det finns gott om tekniker där ute för att sakna data från att ta bort saknade data till avancerade imputeringsmetoder. Jag har precis gjort livet enkelt för mig själv här och ersatt saknade värden med läget. Jag skulle inte nödvändigtvis rekommendera att ta det här tillvägagångssättet i allmänhet eftersom det är väldigt viktigt att förstå varför denna data saknas för att bestämma hur man ska hantera det, men för detta exempel kommer jag att gå vidare och ta det enkla tillvägagångssättet. Vi beräknar först läget för var och en av våra funktioner och använder sedan sammansmältning för att ersätta varje rad med läget om data saknas.
Utbildningsdata
Slutligen bygger vi en fråga för vår träningsdata genom att sammanfoga våra huvudtabeller och slutar med en tabell som innehåller vårt mål, vår kampanj, transaktioner och demografiska funktioner som vi kan använda för att bygga en modell.
För de som är intresserade av att lära sig mer om funktionerna och nyanserna hos Snowflake skulle jag rekommendera följande bok: Snöflinga kokbok. Jag började läsa den här boken och den är full av riktigt användbar information om hur man använder Snowflake och går in mycket mer i detalj än jag gör här.
Python-kod för ETL
Den sista biten vi behöver för denna ETL är att skriva ett skript för att köra det. Nu krävs detta egentligen bara om du planerar att köra en ETL som denna regelbundet, men detta är bra praxis och gör det mycket lättare att köra ETL när och när det behövs.
Låt oss kort diskutera huvudkomponenterna i vår EtlTraining-klass. Vår klass tar en input som är cutoff-veckan. Detta beror på hur data definieras i vår datauppsättning, men vanligtvis skulle detta vara i ett datumformat som motsvarar det brytdatum vi vill välja för att generera träningsdata.
Vi initierar en lista över våra frågor så att vi enkelt kan gå igenom dessa och utföra dem. Vi skapar också en ordbok som innehåller våra parametrar som vi skickar till vår Snowflake-anslutning. Här använder vi miljövariabler som vi sätter upp i Saturn Cloud. Här är en guide för hur man gör detta. Det är inte så svårt att ansluta till Snowflake, allt vi behöver göra är att använda Snowflake-anslutningen och skicka in vår meritförteckningslexikon. Vi implementerar detta i Snowflake connect-metoden och returnerar denna anslutning som ett attribut.
För att göra dessa frågor lite lättare att köra sparar jag varje fråga som en pythonsträngvariabel i filen ml_query_pipeline.py. Metoden execute_etl gör exakt vad den säger på tin. Vi går igenom varje fråga, formaterar den, kör den och avslutar med att stänga Snowflake-anslutningen.
För att köra denna ETL kan vi helt enkelt skriva in kommandona nedan i terminalen. (där ml_pipeline är namnet på skriptet ovan.)
python -m ml_pipeline -w 102 -j ‘train’
Som ett kort åt sidan kommer du förmodligen att vilja köra en ETL som denna med jämna mellanrum. Till exempel, om du vill göra dagliga förutsägelser måste du generera en sådan datauppsättning varje dag för att passera till din modell så att du kan identifiera vilka av dina kunder som sannolikt kommer att churna. Jag kommer inte att gå in på detta i detalj här men i mitt jobb använder vi Airflow för att orkestrera våra ETL så jag skulle rekommendera att kolla upp det om du är intresserad. Faktum är att jag nyligen köpte en bok 'Datapipelines med Apache Airflow' vilket jag tycker är bra och verkligen ger några solida exempel och råd om hur man använder luftflöde.
Dask och modellering
Nu när vi har byggt vår datapipeline kan vi börja fundera på modellering. Det andra huvudmålet jag har för det här inlägget är att lyfta fram fördelarna med att använda Dask som en del av ML-utvecklingsprocessen och visa er hur lätt det är att använda.
För den här delen av projektet använde jag också Saturnus moln vilket är ett riktigt trevligt verktyg jag hittade nyligen som gör att vi kan utnyttja kraften i Dask över ett kluster av datorer i molnet. De främsta fördelarna med att använda Saturnus för mig är att det är väldigt enkelt att dela ditt arbete, superenkelt att skala upp din dator när och när du behöver det och den har ett gratis nivåalternativ. Modellutveckling överlag är ett riktigt bra användningsfall för Dask då vi oftast vill träna ett gäng olika modeller och se vad som fungerar bäst. Ju snabbare vi kan göra detta desto bättre eftersom vi har mer tid att fokusera på andra viktiga aspekter av modellutveckling. I likhet med Snowflake behöver du bara registrera dig här. och du kan mycket snabbt snurra upp en instans av Jupyter lab och börja experimentera med det själv.
Nu inser jag att jag har nämnt Dask några gånger men har aldrig riktigt förklarat vad det är. Så låt mig ta en stund för att ge dig en översikt på mycket hög nivå av Dask och varför jag tycker det är fantastiskt. Mycket enkelt är Dask ett pythonbibliotek som drar fördel av parallell beräkning för att låta dig bearbeta och utföra operationer på mycket stora datamängder. Och det bästa är att om du redan är bekant med Python, så borde Dask vara väldigt okomplicerad eftersom syntaxen är väldigt lik.
Grafen nedan visar huvudkomponenterna i Dask.
Källa: Dask dokumentation
Samlingar tillåter oss att skapa en graf över uppgifter som sedan kan köras på flera datorer. Vissa av dessa datastrukturer låter förmodligen ganska bekanta som arrayer och dataramar och de liknar vad du skulle hitta i python men med några viktiga skillnader. Till exempel kan du tänka på en Dask-dataram som ett gäng pandor-dataramar byggda på ett sådant sätt att vi kan utföra operationer parallellt.
Går vi vidare från samlingar har vi schemaläggaren. När vi väl har skapat uppgiftsdiagrammet hanterar schemaläggaren resten åt oss. Den hanterar arbetsflödet och skickar dessa uppgifter till antingen en enda maskin eller distribuerar dem över ett kluster. Förhoppningsvis ger det dig en mycket kort översikt över hur Dask fungerar. För mer information föreslår jag att du kollar in dokumentation eller detta boken. Båda är mycket bra resurser för att gräva djupare i detta ämne.
Python-kod för modellering
När jag modellerar tenderar jag att ha ett litet antal go-to-algoritmer som jag alltid kommer att testa först. Detta kommer i allmänhet att ge mig en god uppfattning om vad som kan vara lämpligt för det specifika problem jag har. Dessa modeller är Logistic Regression, Random Forest och GradientBoosting. Enligt min erfarenhet kommer dessa algoritmer vanligtvis att ge dig ganska bra resultat när du arbetar med tabelldata. Nedan bygger vi en sklearn-modelleringspipeline med dessa 3 modeller. De exakta modellerna vi använder här är inte riktigt viktiga eftersom pipelinen borde fungera för alla sklearn-klassificeringsmodeller, detta är bara min preferens.
Utan vidare, låt oss dyka in i koden. Lyckligtvis har vi lagt ut det mesta av vår förbearbetning till Snowflake så vi behöver inte bråka med vår träningsdata för mycket här men vi kommer att lägga till några ytterligare steg med hjälp av sklearn pipelines.
Det första kodavsnittet nedan visar pipelinen när du använder sklearn. Lägg märke till att vår datauppsättning är en vanlig gammal pandas-dataram och alla våra förbearbetningssteg utförs med sklearn-metoder. Det är inget speciellt utöver det vanliga som händer här. Vi läser in våra data från tabellen som producerats av vår Snowflake ETL och skickar detta in i en sklearn-pipeline. De vanliga modelleringsstegen gäller här. Vi delar upp datauppsättningen i träna och testa och göra en del förbearbetning, nämligen imputera saknade värden med medianen, skala data och en-hot-koda våra kategoriska data. Jag är ett stort fan av sklearn pipelines och använder dem i princip när jag utvecklar modeller nuförtiden, de underlättar verkligen ren och koncis kod.
Hur fungerar denna pipeline på en datauppsättning med cirka 2 miljoner rader? Tja, att köra den här modellen utan någon hyperparameterjustering tar cirka 34 minuter. Usch, lite långsam. Du kan föreställa dig hur oöverkomligt lång tid detta skulle ta om vi ville göra någon typ av hyperparameterjustering. Ok, så inte idealiskt men låt oss se hur Dask hanterar utmaningen.
Dask ML Python-kod
Vårt mål här är att se om vi kan slå sklearn pipeline ovan, spoiler alert, det kan vi definitivt. Det coola med Dask är att inträdesbarriären när du redan är bekant med python är ganska låg. Vi kan få igång denna pipeline i Dask med bara några få ändringar.
Den första förändringen du förmodligen kommer att märka är att vi har lite olika importer. En av de viktigaste skillnaderna mellan denna pipeline och den föregående är att vi kommer att använda en Dask-dataram istället för en pandas-dataram för att träna vår modell. Du kan tänka på en Dask-dataram som ett gäng pandor-dataramar där vi kan utföra beräkningar på var och en samtidigt. Detta är kärnan i Dasks parallellitet och är det som kommer att minska träningstiden för denna pipeline.
Observera att vi använder @dask.delayed som dekoratör till vår load_training_data fungera. Detta instruerar Dask att parallellisera denna funktion åt oss.
Vi kommer också att importera några förbearbetnings- och pipelinemetoder från Dask och viktigast av allt, vi kommer att behöva importera SaturnCluster som gör att vi kan skapa ett kluster för att träna våra modeller. En annan viktig skillnad med den här koden är att vi använder dask.bestå efter vår tågprovsdelning. Innan denna punkt har ingen av våra funktioner faktiskt beräknats på grund av Dasks lata utvärdering. När vi väl använder persistmetoden säger vi till Dask att skicka våra data till arbetarna och utföra de uppgifter vi har skapat fram till denna punkt och lämna dessa objekt i klustret.
Slutligen tränar vi våra modeller med den fördröjda metoden. Återigen, detta gör det möjligt för oss att skapa vår pipeline på ett lat sätt. Pipelinen exekveras inte förrän vi når denna kod:
fit_pipelines = dask.compute(*pipelines_)
Den här gången tog det oss bara cirka 10 minuter att köra denna pipeline på exakt samma datauppsättning. Det är en hastighetsökning med en faktor på 3.4, inte alltför illa. Nu, om vi ville, skulle vi kunna påskynda detta ännu mer genom att skala upp våra beräkningsresurser med en knapptryckning i Saturnus.
Utplacering av vår pipeline
Jag nämnde tidigare att du förmodligen kommer att vilja köra en sådan här pipeline ganska regelbundet med något som luftflöde. Det råkar vara så att om du inte vill ha det första krånglet med att ställa in allt för luftflödet erbjuder Saturn Cloud ett enkelt alternativ med Jobs. Jobb gör att vi kan paketera vår kod och köra den med jämna mellanrum eller efter behov. Allt du behöver göra är att gå till ett befintligt projekt och klicka på skapa ett jobb. När vi väl har gjort det borde det se ut så här:
Källa: Saturn
Härifrån behöver vi bara se till att våra python-filer ovan finns i katalogen i bilden och att vi kan ange vårt python-kommando ovan
python -m ml_pipeline -w 102 -j 'train'
Vi kan också sätta upp ett schema med cron-syntax för att köra ETL på daglig basis om vi vill. För den som är intresserad, här är en Handledning som går in i allt det nitty-gritty.
Slutsatser och takeaways
Nåväl, vi har nått slutet av vårt projekt vid det här laget. Nu har jag uppenbarligen utelämnat några viktiga delar av ML-utvecklingscykeln som justering av hyperparameter och implementering av vår modell, men jag kanske lämnar det till en annan dag. Tycker jag att du ska prova Dask? Jag är ingen expert på något sätt men vad jag har sett hittills verkar det verkligen vara användbart och jag är superglad över att experimentera mer med det och hitta fler möjligheter att införliva det i mitt dagliga arbete som dataforskare. Förhoppningsvis har du funnit det här användbart och du kan också se några av fördelarna med Snowflake och Dask och du kommer att börja experimentera med dem på egen hand.
Resurser
- Datapipelines med Apache Airflow
- Snöflinga kokbok
- Datavetenskap i skala med Python och Dask
- Coursera: SQL för datavetenskap
Några av mina andra inlägg kanske du tycker är intressanta
Låt oss bygga en strömmande datapipeline
Gaussisk blandningsmodellering (GMM)
En Bayesiansk metod för tidsserieprognoser
Obs: Vissa av länkarna i det här inlägget är affiliate-länkar.
Bio: Daniel Foley är en före detta ekonom som blev Data Scientist och arbetar inom mobilspelsindustrin.
Ursprungliga. Skickas om med tillstånd.
Relaterat:
Källa: https://www.kdnuggets.com/2021/07/building-machine-learning-pipelines-snowflake-dask.html
- "
- &
- 102
- 2021
- tillgång
- Konto
- Annat
- Fördel
- rådgivning
- Dotterbolag
- algoritmer
- Alla
- amason
- Apache
- OMRÅDE
- runt
- bil
- BÄST
- Bit
- SLUTRESULTAT
- Byggnad
- Bunch
- Kampanj
- fall
- orsakas
- utmanar
- byta
- kontroll
- klassificering
- närmare
- cloud
- koda
- Kodning
- komponent
- Compute
- datorer
- databehandling
- Coursera
- Skapa
- referenser
- Kunder
- datum
- datavetenskap
- datavetare
- datauppsättning
- datalagret
- Databas
- dag
- behandla
- djupt lärande
- demografiska
- detalj
- utveckla
- Utveckling
- DID
- Direktör
- effektivitet
- Ingenjörer
- Miljö
- experimentera
- Funktioner
- Slutligen
- änden
- Förnamn
- Fokus
- följer
- format
- Fri
- full
- fungera
- Gaming
- Spelindustrin
- Allmänt
- god
- GPUs
- stor
- styra
- här.
- Hög
- Markera
- Hur ser din drömresa ut
- How To
- HTTPS
- stor
- Tanken
- identifiera
- bild
- Öka
- industrin
- info
- informationen
- problem
- IT
- Jobb
- Lediga jobb
- delta
- hoppa
- Nyckel
- Large
- LÄRA SIG
- inlärning
- Nivå
- Bibliotek
- linje
- Lista
- läsa in
- lokal
- Lång
- maskininlärning
- Metrics
- miljon
- ML
- Mobil
- Mobilspel
- modell
- flytta
- nämligen
- Nya funktioner
- Erbjudanden
- nätet
- Verksamhet
- Alternativet
- Övriga
- prestanda
- Massor
- inlägg
- kraft
- Förutsägelser
- producerad
- produktivitet
- projektet
- allmän
- Python
- Läsning
- minska
- regression
- Resurser
- REST
- Resultat
- Körning
- rinnande
- Skala
- skalning
- Vetenskap
- vetenskapsmän
- Serier
- in
- inställning
- Dela
- delas
- Enkelt
- Small
- So
- LÖSA
- fart
- spendera
- Spendera
- Snurra
- delas
- SQL
- Etapp
- starta
- igång
- statistik
- Upplevelser för livet
- streaming
- Målet
- testa
- Tänkande
- tid
- topp
- Rör
- Utbildning
- transaktion
- Transaktioner
- rättegång
- självstudiekurser
- ui
- us
- användare
- Virtuell
- Warehouse
- vecka
- Vad är
- inom
- Arbete
- arbetare
- arbetsflöde
- fungerar
- skrivning
- X
- år