Amazon SageMaker Feature Store är en ny förmåga av Amazon SageMaker som hjälper datavetare och maskininlärningsingenjörer (ML) säkert att lagra, upptäcka och dela kurerade data som används i arbetsflöden för utbildning och förutsägelse. När organisationer bygger datadrivna applikationer med hjälp av ML, samlar de och flyttar ständigt funktioner mellan fler och mer funktionella team. Denna ständiga rörelse av data kan leda till inkonsekvenser i funktioner och bli en flaskhals när man designar ML-initiativ som spänner över flera lag. Till exempel kan ett e-handelsföretag ha flera datavetenskapliga och tekniska team som arbetar med olika aspekter av sin plattform. Core Search-teamet fokuserar på förfrågningsförståelse och informationshämtningsuppgifter. Produktframgångsteamet löser problem med kundrecensioner och återkopplingssignaler. Personaliseringsteamet använder clickstream och sessionsdata för att skapa ML-modeller för personliga rekommendationer. Dessutom kan datateknikteam som Data Curation-teamet samordna och validera användarspecifik information, vilket är en viktig komponent som andra team kan använda. En Feature Store fungerar som ett enhetligt gränssnitt mellan dessa team, vilket gör det möjligt för ett team att utnyttja de funktioner som genereras av andra team, vilket minimerar den operativa kostnaden för replikering och flyttning av funktioner över lag.
Att träna en produktionsfärdig ML-modell innebär vanligtvis tillgång till olika funktioner som inte alltid ägs och underhålls av teamet som bygger modellen. En vanlig praxis för organisationer som tillämpar ML är att tänka på dessa datavetenskapsteam som enskilda grupper som arbetar självständigt med begränsat samarbete. Detta resulterar i ML-arbetsflöden utan standardiserat sätt att dela funktioner mellan team, vilket blir en avgörande begränsande faktor för datavetenskapens produktivitet och gör det svårare för datavetare att bygga nya och komplexa modeller. Med en delad funktionsbutik kan organisationer uppnå skalfördelar. När fler delade funktioner blir tillgängliga blir det enklare och billigare för team att bygga och underhålla nya modeller. Dessa modeller kan återanvända funktioner som redan är utvecklade, testade och erbjuds med hjälp av en centraliserad funktionsbutik.
Det här inlägget fångar de väsentliga arkitektoniska mönstren över konton för Feature Store som kan implementeras i en organisation med många datateknik- och datavetenskapsteam som arbetar i olika AWS-konton. Vi delar hur du möjliggör delning av funktioner mellan konton genom ett steg-för-steg-exempel, som du själv kan prova med koden i vår GitHub repo.
SageMaker Feature Store översikt
Som standard är en SageMaker Feature Store lokal för kontot där den skapas, men den kan också centraliseras och delas av många konton. En organisation med flera team kan ha en centraliserad funktionsbutik som delas över team samt separata funktionsbutiker för användning av enskilda team. De separata butikerna kan antingen innehålla funktionsgrupper som är av känslig natur eller som är specifika för en unik ML-arbetsbelastning.
I det här inlägget lär du dig först om centraliserad funktionsbutik mönster. Detta mönster föreskriver ett centralt gränssnitt genom vilket team kan skapa och publicera nya funktioner, och från vilka andra team (eller system) kan konsumera funktioner. Det säkerställer också att du har en enda källa till sanning för funktionsdata i hela din organisation och förenklar resurshantering.
Därefter lär du dig om kombinerad funktionsbutik mönster, vilket gör att lag kan behålla sina egna funktionsbutiker lokalt till sitt konto, samtidigt som de fortfarande kan komma åt delade funktioner från den centraliserade funktionsbutiken. Dessa lokala funktionsbutiker är vanligtvis byggda för datavetenskapsexperiment. Genom att kombinera delade funktioner från den centraliserade butiken med lokala funktioner kan team hämta nya förbättrade funktioner som kan hjälpa till när de bygger mer komplexa ML-modeller. Du kan också använda de lokala butikerna för att lagra känslig data som inte kan delas över hela organisationen av reglerings- och efterlevnadsskäl.
Slutligen täcker vi kort ett mindre vanligt mönster med replikering av funktionsdata.
Centraliserad funktionsbutik
Organisationer kan maximera fördelarna med en funktionsbutik när den är centraliserad. De centraliserad funktionsbutik mönster visar hur funktionsrörledningar från flera konton kan skriva till en centraliserad funktionsbutik och hur flera andra konton kan konsumera dessa funktioner. Detta är ett vanligt mönster bland medelstora och stora företag där flera team hanterar olika typer av data eller olika delar av en applikation.
Processen att hypotesera, välja och omvandla dataingångar till en användbar form som är lämplig för ML-modeller kallas funktionsteknik. En rörledning inkapslar alla steg i funktionsteknikprocessen som behövs för att konvertera rådata till användbara funktioner som ML-modeller tar som input för förutsägelser. Att underhålla funktionsrörledningar är en dyr, tidskrävande och felbenägen process. Replikering av funktionsrecept och transformationer över konton kan också leda till inkonsekvenser och snedvrida funktionsegenskaper. Eftersom en centraliserad funktionsbutik underlättar kunskapsdelning behöver lag inte återskapa funktionsrecept och skriva om pipelines från grunden i varje projekt.
I det här mönstret, istället för att skriva funktioner lokalt till en kontospecifik funktionsbutik, skrivs funktioner till en central funktionsbutik. Den centraliserade butiken fungerar som det centrala valvet och skapar ett standardiserat sätt att komma åt och underhålla funktioner för teamövergripande samarbete. Det fungerar som en möjliggörare och accelerator för AI-antagande, vilket minskar tiden för marknadsföring av ML-lösningar och möjliggör central styrning och åtkomstkontroll till ML-funktioner. Du kan ge åtkomst till externa konton, användare eller roller för att läsa och skriva enskilda funktionsgrupper i enlighet med dina dataåtkomstpolicyer. AWS rekommenderar att endast åtkomst till de funktionsgrupper som du behöver för din jobbfunktion ska tillämpas. Detta hanteras av den underliggande AWS identitets- och åtkomsthantering (IAM) policyer. Du kan ytterligare förfina åtkomstkontrollen med funktionsgruppstaggar och IAM-förhållanden för att bestämma vilka rektorer som kan utföra specifika åtgärder. När du använder en centraliserad butik i skala är det viktigt att också implementera korrekt funktionsstyrning för att säkerställa att funktionsgrupper är väl utformade, har funktionsrörledningar som dokumenteras och stöds och att processer är på plats för att säkerställa funktionskvalitet. Denna typ av styrning hjälper till att tjäna det förtroende som krävs för återanvändning av funktioner över lag.
Innan vi går igenom ett exempel, låt oss identifiera några viktiga funktionsbutikskoncept. Först, funktionsgrupper är logiska grupper av funktioner som vanligtvis kommer från samma funktionsrörledning. En offline butik innehåller stora volymer historiska funktionsdata som används för att skapa tränings- och testdata för modellutveckling eller av batchapplikationer för modellpoäng. Syftet med Online Store är att tjäna samma funktioner i realtid med låg latens. Till skillnad från offlinebutiken, som endast är tillagd, är målet med onlinebutiken att betjäna de senaste funktionsvärdena. Bakom kulisserna utför Feature Store automatiskt datasynkronisering mellan de två butikerna. Om du matar in nya funktionsvärden i onlinebutiken läggs de automatiskt till i offlinebutiken. Men du kan också skapa offline och online s
slits separat om detta är ett krav för ditt team eller projekt.
Följande diagram visar tre funktionella team, var och en med sin egen funktionsrörledning som skriver till en funktionsgrupp i en centraliserad funktionsbutik.
Anpassningskontot hanterar användarsessionsdata som samlats in från en kundinriktad applikation och äger en funktionsrörledning som producerar en funktionsgrupp som heter Sessions med funktioner härledda från sessionsdata. Denna pipeline skriver de genererade funktionsvärdena till den centraliserade funktionsbutiken. På samma sätt ansvarar en funktionsrörledning i Product Success-kontot för att producera funktioner i gruppen Funktionsrecensioner och Data Curation-kontot producerar funktioner i funktionsgruppen Användare.
Det centraliserade funktionsbutikskontot innehåller alla funktioner som tas emot från de tre producentkontona, mappad till tre funktionsgrupper: sessioner, recensioner och användare. Funktionsrörledningar kan skriva till den centraliserade funktionsbutiken genom att anta en specifik IAM-roll som skapas i det centraliserade butikskontot. Vi diskuterar hur du aktiverar denna roll över konton senare i det här inlägget. Externa konton kan också fråga funktioner från funktionsgrupperna i den centraliserade butiken för utbildning eller inferens, som visas i föregående arkitekturdiagram. För utbildning kan du anta IAM-rollen från den centraliserade butiken och köra tvärkontot Amazonas Athena frågor (som visas i diagrammet) eller initiera en Amazon EMR or SageMaker-bearbetning jobb för att skapa träningsdatamängder. Vid realtidsavledning kan du läsa onlinefunktioner direkt via samma antagna IAM-roll för åtkomst över flera konton.
I den här modellen finns den centraliserade funktionsbutiken vanligtvis i ett produktionskonto. Applikationer som använder den här butiken kan antingen bo på det här kontot eller på andra konton med åtkomst över flera konton till den centraliserade funktionsbutiken. Du kan replikera hela denna struktur i lägre miljöer, till exempel utveckling eller iscensättning, för att testa infrastrukturförändringar innan du marknadsför dem till produktion.
Kombinerad funktionsbutik
I detta avsnitt diskuterar vi en variant av det centraliserade funktionsbutiksmönstret som kallas kombinerad funktionsbutik mönster. I funktionsteknik är en vanlig praxis att kombinera befintliga funktioner för att få nya funktioner. När team kombinerar delade funktioner från den centraliserade butiken med lokala funktioner i sin egen funktionsbutik kan de hämta nya förbättrade funktioner för att bygga mer komplexa datamodeller. Vi vet från föregående avsnitt att den centraliserade butiken gör det enkelt för alla datavetenskapsteam att få tillgång till externa funktioner och använda dem med sin befintliga pool av funktioner för att sammansätta och utveckla nya funktioner.
Säkerhet och efterlevnad är ett annat användningsfall för team att upprätthålla en lagspecifik funktionsbutik förutom att komma åt funktioner från den centraliserade butiken. Många lag kräver specifika åtkomsträttigheter som inte beviljas alla i organisationen. Det kan till exempel inte vara möjligt att publicera funktioner som extraheras från känslig data till en centraliserad funktionsbutik inom organisationen.
I följande arkitekturdiagram är den centraliserade funktionsbutiken kontot som samlar in och katalogiserar alla funktioner som tas emot från flera funktionsrörledningar till ett centralt arkiv. I det här exemplet tillhör kontot för den kombinerade butiken Core Search-teamet. Detta konto är konsumenten av de delningsbara funktionerna från den centraliserade butiken. Dessutom hanterar detta konto användarnyckelordsdata som samlats in via en kundinriktad sökapplikation.
Detta konto har sina egna lokala offline- och onlinebutiker. Dessa lokala butiker fylls av en funktionsrörledning som är inställd lokalt för att ta in användarfråge nyckelordsdata och generera funktioner. Dessa funktioner är grupperade under en funktionsgrupp som heter Nyckelord. Funktionsbutik skapar automatiskt en AWS-lim tabell för denna funktionsgrupp, som är registrerad i AWS Lim Data Catalog i detta konto. Metadata i denna tabell pekar på Amazon S3-platsen för funktionsgruppen i detta kontos offlinebutik.
Det kombinerade butikskontot kan också få åtkomst till funktionsgrupper Sessioner, recensioner och användare från den centraliserade butiken. Du kan aktivera åtkomst över flera konton per roll, vilket vi diskuterar i nästa avsnitt. Dataforskare och forskare kan använda Athena för att fråga om funktionsgrupper som skapats lokalt och gå med i dessa interna funktioner med externa funktioner som härrör från den centraliserade butiken för datavetenskapsexperiment.
Översikt över åtkomst över flera konton
Detta avsnitt ger en översikt över hur du möjliggör åtkomst över flera konton för Feature Store mellan två konton som använder en antagen roll via AWS Security Token Service (AWS STS). AWS STS är en webbtjänst som gör att du kan begära tillfälliga behörighetsuppgifter för IAM-användare. AWS STS returnerar en uppsättning tillfälliga säkerhetsuppgifter som du kan använda för att komma åt AWS-resurser som du normalt inte har tillgång till. Dessa tillfälliga referenser består av ett åtkomstnyckel-ID, hemlig åtkomstnyckel och säkerhetstoken.
För att demonstrera denna process antar vi att vi har två konton, A och B, som visas i följande diagram.
Konto B har en centraliserad online- och offlinefunktionsbutik. Konto A behöver åtkomst till både online- och offlinebutiker som finns i konto B. För att aktivera detta skapar vi en roll i konto B och låter konto A anta den rollen med hjälp av AWS STS. Detta gör att konto A kan bete sig som konto B, med behörighet att utföra specifika åtgärder som identifieras av rollen. AWS-tjänster som SageMaker (bearbetnings- och utbildningsjobb, slutpunkter) och AWS Lambda används från konto A kan anta den IAM-roll som skapats i konto B med hjälp av en AWS STS-klient (se kodblock senare i detta inlägg). Detta ger dem de nödvändiga behörigheterna för att få tillgång till resurser som Amazon S3, Athena och AWS-limdatakatalogen inom konto B. Efter att tjänsterna i konto A förvärvat de nödvändiga behörigheterna till resurserna kan de komma åt både offline och onlinebutiken i konto B. Beroende på valet av din tjänst måste du också lägga till IAM-körningsrollen för den tjänsten i den betrodda policyn för IAM-rollen över kontot i konto B. Vi diskuterar detta i detalj i följande avsnitt.
Föregående arkitekturdiagram visar hur konto A tar en roll från konto B för att läsa och skriva till både online- och offlinebutiker som finns i konto B. De sju stegen i diagrammet är följande:
- Konto B skapar en roll som kan antas av andra (för vårt användningsfall, konto A).
- Konto A antar IAM-rollen från konto B med AWS STS. Konto A kan nu generera tillfälliga referenser som kan användas för att skapa AWS-tjänstklienter som beter sig som om de befinner sig i konto B.
- På konto A, SageMaker och annan tjänst
klienter (som Amazon S3 och Athena) skapas med hjälp av de tillfälliga referenserna via den antagna rollen. - Serviceklienterna i konto A kan nu skapa funktionsgrupper och fylla in funktionsvärden i konto B: s centralbutik med AWS SDK.
- Onlinebutiken i konto B synkroniseras automatiskt med offlinebutiken, även i konto B.
- Athena-tjänsteklienten i konto A kör frågor över flera konton för att läsa, gruppera och materialisera funktionsuppsättningar med Athena-tabeller i konto B. Eftersom offlinebutiken finns i konto B, motsvarande AWS-limtabeller, metadatakatalogposter och S3-objekt alla finns inom konto B. Konto A kan använda AWS STS-rollen för att fråga offlinefunktionerna (S3-objekt) inuti konto B.
- Athenas sökresultat returneras som funktionsdatauppsättningar till konto A: s S3-hink.
Tillfälliga referenser använder AWS STS GetSessionToken API och är begränsade till 1 timme. Du kan förlänga sessionens varaktighet genom att använda RefreshableCredentials, en Botocore-klass som automatiskt kan uppdatera referenserna för att fungera med dina långvariga applikationer utöver tidsperioden på 1 timme. En exempel anteckningsbok visar att detta är tillgängligt i vårt GitHub repo.
Skapa åtkomst över flera konton
Detta avsnitt beskriver alla steg för att skapa åtkomstroller, policyer och behörigheter för flera konton för att möjliggöra delning av funktioner mellan konton A och B enligt vår arkitektur.
Skapa en åtkomstroll för Feature Store
Från konto B skapar vi en åtkomstroll för Feature Store. Det här är den roll som AWS-tjänster inom konto A tar för att få tillgång till resurser i konto B.
- I navigationsfönstret väljer du på IAM-konsolen roller.
- Välja Skapa roll.
- Välja Ett annat AWS-konto.
- För konto-id, ange det 12-siffriga konto-ID för konto B.
- Välja Nästa: Behörigheter.
- I behörigheter avsnitt, sök efter och bifoga följande AWS-hanterade policyer:
AmazonSageMakerFullAccess
(du kan ytterligare begränsa detta till minst privilegier baserat på ditt användningsfall)AmazonSageMakerFeatureStoreAccess
- Skapa och bifoga en anpassad policy till den här nya rollen (ange S3-skopnamnet i konto A där Athena-sökresultaten som samlats in i konto B skrivs):
När du använder den här nya AWS STS-kontoöverskridande rollen från konto A kan den köra Athena-frågor mot offlinebutikinnehållet i konto B. Den anpassade policyn gör det möjligt för Athena (inuti konto B) att skriva tillbaka resultaten till en resultatskopa i konto A. Se till att resultatresultatet skapas i konto A innan du skapar föregående policy.
Alternativt kan du låta den centraliserade funktionsbutiken i konto B behålla alla Athena-sökresultaten i en S3-hink. I det här fallet måste du ställa in läsåtkomstpolicyer för Amazon S3 för flera konton för externa konton för att läsa de sparade resultaten (S3-objekt).
- När du har bifogat policyerna väljer du Nästa.
- Ange ett namn för den här rollen (till exempel roll över antagande-roll).
- På Sammanfattning sida för den skapade rollen, under Förtroendeförhållandenväljer Redigera förtroendeförhållandet.
- Redigera åtkomstkontrollpolicy som visas i följande kod:
Den föregående koden lägger till SageMaker och Athena som tjänster i Principal-avsnittet. Om du vill att fler externa konton eller roller ska ta denna roll kan du lägga till motsvarande ARN i detta avsnitt.
Skapa en SageMaker anteckningsbokinstans
Från konto A skapar du en SageMaker-anteckningsbokinstans med en IAM-körningsroll. Den här rollen ger SageMaker-anteckningsboken i konto A de nödvändiga behörigheterna för att köra åtgärder i funktionsbutiken i konto B. Alternativt, om du inte använder en SageMaker-anteckningsbok och använder Lambda istället måste du skapa en roll för Lambda med samma bifogade policyer som visas i detta avsnitt.
Som standard bifogas följande principer när du skapar en ny utföringsroll för en SageMaker-anteckningsbok:
AmazonSageMaker-ExecutionPolicy
AmazonSageMakerFullAccess
Vi måste skapa och bifoga ytterligare två anpassade policyer. Skapa först en anpassad policy med följande kod, som tillåter körningsrollen i konto A att utföra vissa S3-åtgärder som behövs för att interagera med offlinebutiken i konto B:
Du kan också bifoga AWS-hanterade policy AmazonSageMakerFeatureStoreAccess
, om ditt offline-butik S3-skopnamn innehåller SageMaker
nyckelord.
För det andra, skapa följande anpassade policy, som gör att SageMaker-anteckningsboken i konto A kan ta rollen (cross-account-assume-role
) skapad i konto B:
Vi vet att konto A kan komma åt online- och offlinebutiken i konto B. När konto A tar på sig AWS STS-rollen för flera konton som konto B, kan det köra Athena-frågor i konto B mot dess offlinebutik. Resultaten av dessa frågor (funktionsdatauppsättningar) måste dock sparas i konto A:s S3-bucket för att möjliggöra modellträning. Därför måste vi skapa en hink i konto A som kan lagra Athena-frågeresultaten samt skapa en hinkpolicy (se följande kod). Denna policy tillåter AWS STS-rollen över flera konton att skriva och läsa objekt i denna
hink:
Ändra policyn för förtroendeförhållanden
Eftersom vi skapade en IAM-körningsroll i konto A använder vi ARN för den här rollen för att ändra förtroendeförhållandepolicyn för rollöverskridande roll i konto B:
Validera installationsprocessen
När du har konfigurerat alla roller och tillhörande policyer kan du validera installationen genom att köra anteckningsböckerna i GitHub repo. Följande kodblock är ett utdrag från anteckningsboken och måste köras i en SageMaker-anteckningsbok som körs inom konto A. Det visar hur du kan ta rollen över kontot från konto B med AWS STS via Antag roll API-samtal. Det här samtalet returnerar en uppsättning tillfälliga referenser som konto A kan använda för att skapa alla serviceklienter. När du använder dessa klienter använder din kod behörigheterna för den antagna rollen och fungerar som om den tillhör konto B. Mer information finns i anta_roll i AWS SDK för Python (Boto 3) dokumentation.
När du har skapat SageMaker-klienterna enligt föregående kodexempel i konto A kan du skapa funktionsgrupper och fylla i funktioner i konto B: s centraliserade online- och offlinebutik. Mer information om hur du skapar, beskriver och tar bort funktionsgrupper finns i skapa_funktionsgrupp i Boto3-dokumentationen. Du kan också använda Feature Store runtime-klient att sätta och få funktionsregister till och från funktionsgrupper.
Offline butiksreplikering
Reproducerbarhet är möjligheten att återskapa en ML-modell exakt, så om du använder samma funktioner som input, returnerar modellen samma output som den ursprungliga modellen. Detta är i huvudsak vad vi strävar efter att uppnå mellan modellerna vi utvecklar i en forskningsmiljö och distribuerar i en produktionsmiljö. Replikering av funktionsteknikledningar över konton är en komplex och tidskrävande process som kan införa modellavvikelser om de inte implementeras korrekt. Om funktionsuppsättningen som används för att träna en modell ändras efter träningsfasen kan det vara svårt eller omöjligt att reproducera en modell.
Applikationer som finns på AWS har vanligtvis flera olika miljöer och konton, såsom utveckling, testning, iscensättning och produktion. För att uppnå automatisk distribution av applikationen i olika miljöer använder vi CI / CD-rörledningar. Organisationer behöver ofta behålla isolerade arbetsmiljöer och flera kopior av data i samma eller olika AWS-regioner eller över olika AWS-konton. Inom ramen för Feature Store kanske vissa företag vill kopiera offline-funktionsbutikdata. Offline butiksreplikering via Amazon S3-replikering kan vara ett användbart mönster i det här fallet. Detta mönster gör det möjligt för isolerade miljöer och konton att omskola ML-modeller med fullständiga funktionsuppsättningar utan att använda roller eller behörigheter över flera konton.
Slutsats
I det här inlägget demonstrerade vi olika arkitekturmönster som den centraliserade funktionsbutiken, kombinerade funktionsbutiken och andra designhänsyn för SageMaker Feature Store som är väsentliga för tvärfunktionellt datavetenskapligt samarbete. Vi visade också hur man ställer in åtkomst över flera konton med AWS STS.
Mer information om Feature Store-funktioner och användningsfall finns i Förstå de viktigaste funktionerna i Amazon SageMaker Feature Store och Använda streaming-intag med Amazon SageMaker Feature Store för att fatta ML-stödda beslut i nästan realtid.
Om du har några kommentarer eller frågor, vänligen lämna dem i kommentarfältet.
Om författarna
Arunprasath Shankar är en artificiell intelligens och maskininlärning (AI / ML) specialistlösningsarkitekt med AWS, som hjälper globala kunder att skala sina AI-lösningar effektivt och effektivt i molnet. På fritiden tycker Arun om att titta på sci-fi-filmer och lyssna på klassisk musik.
Mark Roy är en huvudsaklig maskininlärningsarkitekt för AWS, som hjälper AWS-kunder att designa och bygga AI / ML-lösningar. Marks arbete täcker ett brett spektrum av ML-användningsfall, med ett primärt intresse för datorsyn, djupinlärning och skalning av ML över hela företaget. Han har hjälpt företag i många branscher, inklusive försäkringar, finansiella tjänster, media och underhållning, sjukvård, verktyg och tillverkning. Mark har 6 AWS-certifieringar, inklusive ML-specialcertifiering. Innan Mark började i AWS var han arkitekt, utvecklare och teknologiledare i över 25 år, inklusive 19 år inom finansiella tjänster.
Stefan Natu är Sr. AI / ML Specialist Solutions Architect på Amazon Web Services. Han är fokuserad på att hjälpa finansiella tjänster att bygga helhetslösningar för maskininlärning på AWS. På fritiden tycker han om att läsa maskininlärningsbloggar, spela gitarr och utforska matscenen i New York City.
- accelerator
- tillgång
- Konto
- Handling
- Annat
- Antagande
- AI
- AI-antagande
- amason
- Amazon SageMaker
- Amazon Web Services
- bland
- api
- Ansökan
- tillämpningar
- arkitektur
- artificiell intelligens
- Konstgjord intelligens och maskininlärning
- Automatiserad
- AWS
- bakom kulisserna
- bloggar
- SLUTRESULTAT
- Byggnad
- Ring
- fall
- certifiering
- Stad
- klienter
- cloud
- koda
- samverkan
- kommentarer
- Gemensam
- Företag
- företag
- Efterlevnad
- komponent
- Luktämne
- Datorsyn
- konsumera
- Konsumenten
- innehåll
- referenser
- Kunder
- datum
- datatillgång
- datavetenskap
- djupt lärande
- Designa
- detalj
- utveckla
- Utvecklare
- Utveckling
- e-handel
- Teknik
- Ingenjörer
- Företag
- Underhållning
- Miljö
- utförande
- Leverans
- Funktioner
- finansiella
- finansiella tjänster
- Förnamn
- livsmedelsproduktion
- formen
- full
- fungera
- GitHub
- Välgörenhet
- styrning
- bidrag
- Grupp
- hälso-och sjukvård
- hålla
- Hur ser din drömresa ut
- How To
- HTTPS
- IAM
- identifiera
- Identitet
- Inklusive
- industrier
- informationen
- Infrastruktur
- försäkring
- Intelligens
- intresse
- IT
- Jobb
- Lediga jobb
- delta
- hålla
- Nyckel
- kunskap
- Large
- leda
- LÄRA SIG
- inlärning
- Hävstång
- Begränsad
- Lista
- Lyssna
- lokal
- lokalt
- läge
- maskininlärning
- ledning
- Produktion
- markera
- marknad
- Media
- ML
- modell
- Filmer
- Musik
- Navigering
- ny funktion
- Nya funktioner
- New York
- new york city
- bärbara datorer
- nätet
- Online Store
- drift
- beställa
- Övriga
- Övrigt
- Mönster
- personalisering
- plattform
- Strategier
- policy
- poolen
- förutsägelse
- Förutsägelser
- producent
- Produkt
- Produktion
- produktivitet
- projektet
- publicera
- Python
- kvalitet
- område
- Raw
- rådata
- Läsning
- realtid
- skäl
- recept
- register
- Förhållanden
- forskning
- resurs
- Resurser
- Resultat
- återgår
- Omdömen
- Körning
- rinnande
- sagemaker
- Skala
- skalning
- Vetenskap
- vetenskapsmän
- sDK
- Sök
- säkerhet
- Tjänster
- in
- Dela
- delas
- So
- Lösningar
- .
- lagra
- lagrar
- streaming
- framgång
- Som stöds
- System
- Teknologi
- temporär
- Testning
- tid
- token
- Utbildning
- Litar
- användare
- verktyg
- syn
- gående
- webb
- webbservice
- inom
- Arbete
- fungerar
- skrivning
- år