Bygg och träna ML-modeller med hjälp av en datanätarkitektur på AWS: Del 1

Organisationer inom olika branscher använder artificiell intelligens (AI) och maskininlärning (ML) för att lösa affärsutmaningar som är specifika för deras bransch. Till exempel, inom finansbranschen kan du använda AI och ML för att lösa utmaningar kring bedrägeriupptäckt, kreditriskförutsägelse, direktmarknadsföring och många andra.

Stora företag inrättar ibland ett kompetenscentrum (CoE) för att ta itu med behoven hos olika branscher (LoBs) med innovativa analyser och ML-projekt.

För att generera högkvalitativa och presterande ML-modeller i stor skala måste de göra följande:

• Tillhandahålla ett enkelt sätt att komma åt relevant data till deras analys och ML CoE
• Skapa ansvarighet på dataleverantörer från enskilda LoBs för att dela kurerade datatillgångar som är upptäckbara, begripliga, interoperabla och pålitliga

Detta kan minska den långa cykeltiden för att konvertera ML-användningsfall från experiment till produktion och generera affärsvärde i hela organisationen.

En datanätarkitektur strävar efter att lösa dessa tekniska och organisatoriska utmaningar genom att introducera ett decentraliserat sociotekniskt tillvägagångssätt för att dela, komma åt och hantera data i komplexa och storskaliga miljöer – inom eller mellan organisationer. Designmönstret för datanät skapar en modell för ansvarsfull datadelning som är i linje med den organisatoriska tillväxten för att uppnå det slutliga målet att öka avkastningen på affärsinvesteringar i datateamen, processen och tekniken.

I den här tvådelade serien ger vi vägledning om hur organisationer kan bygga en modern dataarkitektur med hjälp av ett datanätdesignmönster på AWS och möjliggöra för en analys och ML CoE att bygga och träna ML-modeller med data över flera LoBs. Vi använder ett exempel på en finansiell tjänsteorganisation för att ställa in sammanhanget och användningsfallet för denna serie.

I det här första inlägget visar vi procedurerna för att ställa in en datanätarkitektur med flera AWS-dataproducent- och konsumentkonton. Sedan fokuserar vi på en dataprodukt, som ägs av en LoB inom den finansiella organisationen, och hur den kan delas in i en datanätmiljö för att tillåta andra LoBs att konsumera och använda denna dataprodukt. Detta är främst inriktat på data steward-personen, som ansvarar för att effektivisera och standardisera processen för att dela data mellan dataproducenter och konsumenter och säkerställa efterlevnad av datastyrningsregler.

I det andra inlägget visar vi ett exempel på hur en analys och ML CoE kan konsumera dataprodukten för ett användningsfall för riskprediktion. Detta är främst inriktat på dataforskarens persona, som är ansvarig för att använda både organisationsövergripande och tredjepartsdatatillgångar för att bygga och träna ML-modeller som extraherar affärsinsikter för att förbättra upplevelsen för kunder med finansiella tjänster.

Datanätöversikt

Grundaren av datanätmönstret, Zhamak Dehghani i sin bok Datanät som levererar datadrivet värde i skala, definierade fyra principer mot målet med datanätet:

• Distribuerat domänägande – Att driva ett organisatoriskt skifte från centraliserat ägande av data av specialister som driver dataplattformsteknologierna till en decentraliserad dataägandemodell, vilket driver tillbaka ägandet och ansvarsskyldigheten för data till de LoBs där data produceras (källanpassade domäner) eller konsumeras ( konsumtionsanpassade domäner).
• Data som produkt – Att driva uppströms ansvarsskyldigheten för att dela utvalda, högkvalitativa, interoperabla och säkra datatillgångar. Därför är dataproducenter från olika LoB ansvariga för att göra data i en förbrukningsbar form direkt vid källan.
• Självbetjäningsanalys – Att effektivisera upplevelsen för dataanvändare av analytics och ML så att de kan upptäcka, komma åt och använda dataprodukter med sina föredragna verktyg. Dessutom för att effektivisera upplevelsen av LoB-dataleverantörer att bygga, distribuera och underhålla dataprodukter via recept och återanvändbara komponenter och mallar.
• Federerad beräkningsstyrning – Att sammanföra och automatisera beslutsfattandet som är involverat i att hantera och kontrollera dataåtkomst för att vara på nivån för dataägare från de olika LoBs, vilket fortfarande är i linje med den bredare organisationens juridiska, efterlevnads- och säkerhetspolicyer som i slutändan upprätthålls genom nätet.

AWS presenterade sin vision för att bygga ett datanät ovanpå AWS i olika inlägg:

• Först fokuserade vi på den organisatoriska delen associerad med distribuerat domänägande och data som produktprinciper. Författarna beskrev visionen att anpassa flera LOB:er över hela organisationen mot en dataproduktstrategi som förser de konsumtionsanpassade domänerna med verktyg för att hitta och få den data de behöver, samtidigt som den garanterar den nödvändiga kontrollen kring användningen av dessa data genom att införa ansvar för de källanpassade domänerna för att tillhandahålla dataprodukter redo att användas direkt vid källan. För mer information, se Hur JPMorgan Chase byggde en datanätarkitektur för att skapa betydande värde för att förbättra deras företagsdataplattform.
• Sedan fokuserade vi på den tekniska delen i samband med att bygga dataprodukter, självbetjäningsanalyser och federerade principer för beräkningsstyrning. Författarna beskrev de kärnanpassade AWS-tjänsterna som ger de källanpassade domänerna möjlighet att bygga och dela dataprodukter, ett brett utbud av tjänster som kan göra det möjligt för konsumentanpassade domäner att konsumera dataprodukter på olika sätt baserat på deras föredragna verktyg och de användningsfall de arbetar mot, och slutligen, AWS-tjänsterna som styr datadelningsproceduren genom att upprätthålla policyer för dataåtkomst. För mer information, se Designa en datanätarkitektur med AWS Lake Formation och AWS Glue.
• Vi visade också en lösning för att automatisera dataupptäckt och åtkomstkontroll genom ett centraliserat datanätgränssnitt. För mer information, se Bygg ett arbetsflöde för datadelning med AWS Lake Formation för ditt datanät.

Användningsfall för finansiella tjänster

Vanligtvis har stora finansiella tjänsteorganisationer flera LoBs, såsom konsumentbanker, investeringsbanker och kapitalförvaltning, och även ett eller flera analys- och ML CoE-team. Varje LoB tillhandahåller olika tjänster:

• Consumer Banking LoB tillhandahåller en mängd olika tjänster till konsumenter och företag, inklusive kredit och bolån, kontanthantering, betalningslösningar, inlånings- och investeringsprodukter och mer
• LoB för kommersiella eller investeringsbanker erbjuder omfattande finansiella lösningar, såsom utlåning, konkursrisk och grossistbetalningar till kunder, inklusive småföretag, medelstora företag och stora företag
• Kapitalförvaltningen LoB tillhandahåller pensionsprodukter och investeringstjänster över alla tillgångsklasser

Varje LoB definierar sina egna dataprodukter, som kureras av personer som förstår data och är bäst lämpade för att specificera vem som är behörig att använda den och hur den kan användas. Däremot är andra LoBs och applikationsdomäner som analytics och ML CoE intresserade av att upptäcka och konsumera kvalificerade dataprodukter, blanda ihop det för att generera insikter och fatta datadrivna beslut.

Följande illustration visar några LoBs och exempel på dataprodukter som de kan dela. Den visar också konsumenterna av dataprodukter som analytics och ML CoE, som bygger ML-modeller som kan distribueras till kundnära applikationer för att ytterligare förbättra slutkundens upplevelse.

Efter det sociotekniska konceptet för datanätet börjar vi med den sociala aspekten med en uppsättning organisatoriska steg, såsom följande:

• Använda domänexperter för att definiera gränser för varje domän, så att varje dataprodukt kan mappas till en specifik domän
• Identifiera ägare för dataprodukter som tillhandahålls från varje domän, så att varje dataprodukt har en strategi definierad av sin ägare
• Identifiera förvaltningspolicyer från globala och lokala eller federerade incitament, så när datakonsumenter får tillgång till en specifik dataprodukt kan åtkomstpolicyn som är kopplad till produkten automatiskt upprätthållas genom ett centralt datastyrningslager

Sedan går vi till den tekniska aspekten, som inkluderar följande end-to-end-scenario som definieras i föregående diagram:

1. Ge konsumentbankernas LoB verktyg för att bygga en färdig att använda konsumentkreditprofildataprodukt.
2. Tillåt konsumentbankernas LoB att dela dataprodukter till det centrala styrningsskiktet.
3. Bädda in globala och federerade definitioner av dataåtkomstpolicyer som bör tillämpas samtidigt som du får åtkomst till konsumentkreditprofilens dataprodukt via den centrala datastyrningen.
4. Tillåt analysen och ML CoE att upptäcka och komma åt dataprodukten genom det centrala styrningsskiktet.
5. Ge analytics och ML CoE verktyg för att använda dataprodukten för att bygga och träna en modell för kreditriskprognoser. Vi täcker inte de sista stegen (6 och 7 i föregående diagram) i den här serien. Men för att visa vilket affärsvärde en sådan ML-modell kan tillföra organisationen i ett helhetsscenario, illustrerar vi följande:
6. Denna modell skulle senare kunna distribueras tillbaka till kundinriktade system som en webbportal för konsumentbanker eller mobilapplikationer.
7. Den kan specifikt användas inom låneansökan för att bedöma riskprofilen för kredit- och bolåneförfrågningar.

Därefter beskriver vi de tekniska behoven för var och en av komponenterna.

Djupdyka i tekniska behov

För att göra dataprodukter tillgängliga för alla måste organisationer göra det enkelt att dela data mellan olika enheter över hela organisationen samtidigt som de behåller lämplig kontroll över det, eller med andra ord balansera smidighet med korrekt styrning.

Datakonsument: Analytics och ML CoE

Datakonsumenterna som datavetare från analytics och ML CoE behöver kunna göra följande:

• Upptäck och få tillgång till relevanta datauppsättningar för ett givet användningsfall
• Var säker på att datauppsättningar de vill komma åt redan är kurerade, uppdaterade och har robusta beskrivningar
• Begär tillgång till datauppsättningar av intresse för deras affärscase
• Använd deras föredragna verktyg för att fråga och bearbeta sådana datamängder i sin miljö för ML utan att behöva replikera data från den ursprungliga fjärrplatsen eller för att oroa sig för tekniska eller infrastrukturkomplexiteter förknippade med bearbetning av data som fysiskt lagras på en fjärrplats
• Få information om eventuella datauppdateringar gjorda av dataägarna

Dataproducent: Domänägande

Dataproducenterna, såsom domänteam från olika LoBs i finanstjänstorganisationen, behöver registrera och dela utvalda datauppsättningar som innehåller följande:

• Tekniska och operativa metadata, såsom databas- och tabellnamn och storlekar, kolumnscheman och nycklar
• Affärsmetadata såsom databeskrivning, klassificering och känslighet
• Spåra metadata som schemautveckling från källan till målformen och eventuella mellanformer
• Datakvalitetsmetadata såsom korrekthets- och fullständighetsförhållanden och databias
• Åtkomst till policyer och procedurer

Dessa behövs för att datakonsumenter ska kunna upptäcka och komma åt data utan att förlita sig på manuella procedurer eller att behöva kontakta dataproduktens domänexperter för att få mer kunskap om innebörden av datan och hur den kan nås.

Datastyrning: Upptäckbarhet, tillgänglighet och granskning

Organisationer måste balansera de flexibiliteter som illustreras tidigare med korrekt minskning av riskerna i samband med dataläckor. Särskilt i reglerade branscher som finansiella tjänster finns det ett behov av att upprätthålla central datastyrning för att ge övergripande dataåtkomst och revisionskontroll samtidigt som lagringsutrymmet minskar genom att undvika flera kopior av samma data på olika platser.

I traditionella centraliserade datasjöarkitekturer publicerar dataproducenterna ofta rådata och överför ansvaret för datakurering, datakvalitetshantering och åtkomstkontroll till data- och infrastrukturingenjörer i ett centraliserat dataplattformsteam. Dessa dataplattformsteam kan dock vara mindre bekanta med de olika datadomänerna och fortfarande förlita sig på stöd från dataproducenterna för att korrekt kunna kurera och styra åtkomst till data enligt de policyer som tillämpas på varje datadomän. Däremot är datatillverkarna själva bäst positionerade för att tillhandahålla kurerade, kvalificerade datatillgångar och är medvetna om de domänspecifika åtkomstpolicyer som måste upprätthållas när de får åtkomst till datatillgångar.

Lösningsöversikt

Följande diagram visar högnivåarkitekturen för den föreslagna lösningen.

Vi adresserar datakonsumtion av analytics och ML CoE med Amazonas Athena och Amazon SageMaker in del 2 av den här serien.

I det här inlägget fokuserar vi på dataintroduktionsprocessen i datanätet och beskriver hur en enskild LoB såsom konsumentbanksdomändatateamet kan använda AWS-verktyg som t.ex. AWS-lim och AWS Lim DataBrew att förbereda, kurera och förbättra kvaliteten på sina dataprodukter och sedan registrera dessa dataprodukter i det centrala datastyrningskontot genom AWS Lake Formation.

Consumer Banking LoB (dataproducent)

En av kärnprinciperna för datanät är begreppet data som en produkt. Det är mycket viktigt att datateamet för konsumentbanksdomäner arbetar med att förbereda dataprodukter som är redo att användas av datakonsumenter. Detta kan göras genom att använda AWS extrahera, transformera och ladda (ETL) verktyg som AWS Glue för att bearbeta rådata som samlats in på Amazon enkel lagringstjänst (Amazon S3), eller alternativt ansluta till de operativa datalagren där datan produceras. Du kan också använda DataBrew, som är ett kodfritt verktyg för visuell dataförberedelse som gör det enkelt att rengöra och normalisera data.

Till exempel, medan man förbereder konsumentkreditprofildataprodukten, kan konsumentbanksdomänens datateam göra en enkel kuration för att översätta attributnamnen för rådata som hämtats från datauppsättningen med öppen källkod från tyska till engelska Statlog tyska kredituppgifter, som består av 20 attribut och 1,000 XNUMX rader.

Datastyrning

Kärnan i AWS-tjänsten för att möjliggöra styrning av datanät är Lake Formation. Lake Formation erbjuder möjligheten att genomdriva datastyrning inom varje datadomän och över domäner för att säkerställa att data är lätt att upptäcka och säkra. Den tillhandahåller en federerad säkerhetsmodell som kan administreras centralt, med bästa praxis för dataupptäckt, säkerhet och efterlevnad, samtidigt som den tillåter hög smidighet inom varje domän.

Lake Formation erbjuder ett API för att förenkla hur data tas in, lagras och hanteras, tillsammans med säkerhet på radnivå för att skydda din data. Det ger också funktioner som granulär åtkomstkontroll, styrda tabeller och lagringsoptimering.

Dessutom erbjuder Lake Formations en Datadelning API som du kan använda för att dela data på olika konton. Detta gör att analytiker- och ML CoE-konsumenten kan köra Athena-frågor som frågar och sammanfogar tabeller över flera konton. För mer information, se Utvecklarguide för AWS Lake Formation.

AWS Resource Access Manager (AWS RAM) ger ett säkert sätt att dela resurser via AWS Identity and Access Manager (IAM) roller och användare över AWS-konton inom en organisation eller organisationsenheter (OUs) i AWS-organisationer.

Lake Formation tillsammans med AWS RAM ger ett sätt att hantera datadelning och åtkomst över AWS-konton. Vi hänvisar till detta tillvägagångssätt som RAM-baserad åtkomstkontroll. För mer information om detta tillvägagångssätt, se Bygg ett arbetsflöde för datadelning med AWS Lake Formation för ditt datanät.

Lake Formation erbjuder också ett annat sätt att hantera datadelning och åtkomst med hjälp av Lake Formation taggar. Vi hänvisar till detta tillvägagångssätt som taggbaserad åtkomstkontroll. För mer information, se Bygg en modern dataarkitektur och datanätmönster i skala med AWS Lake Formation-taggbaserad åtkomstkontroll.

Under hela det här inlägget använder vi den taggbaserade åtkomstkontrollmetoden eftersom den förenklar skapandet av policyer på ett mindre antal logiska taggar som vanligtvis finns i olika LoBs istället för att specificera policyer för namngivna resurser på infrastrukturnivå.

Förutsättningar

För att ställa in en datanätarkitektur behöver du minst tre AWS-konton: ett producentkonto, ett centralt konto och ett konsumentkonto.

Distribuera datanätmiljön

För att distribuera en datanätmiljö kan du använda följande GitHub repository. Detta förråd innehåller tre AWS molnformation mallar som distribuerar en datanätmiljö som inkluderar vart och ett av kontona (producent, central och konsument). Inom varje konto kan du köra dess motsvarande CloudFormation-mall.

Centralt konto

I det centrala kontot, slutför följande steg:

1. Starta CloudFormation-stacken:
   
2. Skapa två IAM-användare:
   1. DataMeshOwner
   2. ProducerSteward
3. Grant DataMeshOwner som administratör för Lake Formation.
4. Skapa en IAM-roll:
   1. LFRegisterLocationServiceRole
5. Skapa två IAM-policyer:
   1. ProducerStewardPolicy
   2. S3DataLakePolicy
6. Skapa databasen kreditkort för ProducerSteward på producentkontot.
7. Dela dataplatsbehörigheten till producentkontot.

Producentkonto

I producentkontot, slutför följande steg:

1. Starta CloudFormation-stacken:
   
2. Skapa S3-skopan credit-card, som håller bordet credit_card.
3. Tillåt S3-bucket-åtkomst för tjänstrollen Lake Formation i centralkontot.
4. Skapa AWS Glue-sökroboten creditCrawler-<ProducerAccountID>.
5. Skapa en tjänstroll för AWS Glue Crawler.
6. Bevilja behörigheter för S3-skopans plats credit-card-<ProducerAccountID>-<aws-region> till AWS Glue crawler-rollen.
7. Skapa en IAM-användare för producent.

Konsumentkonto

På konsumentkontot utför du följande steg:

1. Starta CloudFormation-stacken:
   
2. Skapa S3-skopan <AWS Account ID>-<aws-region>-athena-logs.
3. Skapa Athena-arbetsgruppen consumer-workgroup.
4. Skapa IAM-användaren ConsumerAdmin.

Lägg till en databas och prenumerera på konsumentkontot på den

När du har kört mallarna kan du gå igenom Steg för steg guide att lägga till en produkt i datakatalogen och låta konsumenten prenumerera på den. Guiden börjar med att skapa en databas där producenten kan placera sina produkter och förklarar sedan hur konsumenten kan prenumerera på den databasen och få tillgång till data. Allt detta utförs under användning LF-taggar, vilken är taggbaserad åtkomstkontroll för sjöbildning.

Data produktregistrering

Följande arkitektur beskriver de detaljerade stegen för hur LoB-teamet för konsumentbanker som agerar som dataproducenter kan registrera sina dataprodukter i det centrala datastyrningskontot (dataprodukter ombord till organisationens datanät).

De allmänna stegen för att registrera en dataprodukt är följande:

1. Skapa en måldatabas för dataprodukten i det centrala styrningskontot. Som ett exempel skapar CloudFormation-mallen från det centrala kontot redan måldatabasen credit-card.
2. Dela den skapade måldatabasen med ursprunget i producentkontot.
3. Skapa en resurslänk för den delade databasen i producentkontot. I följande skärmdump ser vi på Lake Formation-konsolen i producentkontot att rl_credit-card är resurslänken till credit-card databas.
   
4. Fyll i tabeller (med data kurerad i producentkontot) i resurslänkdatabasen (rl_credit-card) med hjälp av en AWS Glue-crawler i producentkontot.
   

Den skapade tabellen visas automatiskt i det centrala förvaltningskontot. Följande skärmdump visar ett exempel på tabellen i Lake Formation i det centrala kontot. Detta är efter att ha utfört de tidigare stegen för att fylla resurslänkdatabasen rl_credit-card på producentkontot.

Slutsats

I del 1 av den här serien diskuterade vi finansiella tjänsteorganisationers mål att uppnå mer smidighet för sina analys- och ML-team och minska tiden från data till insikter. Vi fokuserade också på att bygga en datanätarkitektur på AWS, där vi har introducerat lättanvända, skalbara och kostnadseffektiva AWS-tjänster som AWS Glue, DataBrew och Lake Formation. Dataproducerande team kan använda dessa tjänster för att bygga och dela utvalda, högkvalitativa, interoperabla och säkra dataprodukter som är redo att användas av olika datakonsumenter för analytiska ändamål.

In del 2, fokuserar vi på analys- och ML CoE-team som konsumerar dataprodukter som delas av konsumentbankernas LoB för att bygga en kreditriskprediktionsmodell med hjälp av AWS-tjänster som Athena och SageMaker.

---

Om författarna

Karim Hammouda är en specialistlösningsarkitekt för Analytics på AWS med en passion för dataintegration, dataanalys och BI. Han arbetar med AWS-kunder för att designa och bygga analyslösningar som bidrar till deras affärstillväxt. På fritiden tittar han gärna på tv-dokumentärer och spelar tv-spel med sin son.

Hasan Poonawala är Senior AI/ML Specialist Solutions Architect på AWS, Hasan hjälper kunder att designa och distribuera maskininlärningsapplikationer i produktion på AWS. Han har över 12 års arbetslivserfarenhet som datavetare, maskininlärningsutövare och mjukvaruutvecklare. På sin fritid älskar Hasan att utforska naturen och umgås med vänner och familj.

Benoit de Patoul är en AI/ML Specialist Solutions Architect på AWS. Han hjälper kunder genom att ge vägledning och teknisk assistans för att bygga lösningar relaterade till AI/ML med hjälp av AWS. På fritiden gillar han att spela piano och umgås med vänner.