Byg og træne ML-modeller ved hjælp af en datamesh-arkitektur på AWS: Del 1

Organisationer på tværs af forskellige brancher bruger kunstig intelligens (AI) og machine learning (ML) til at løse forretningsmæssige udfordringer, der er specifikke for deres branche. For eksempel kan du i industrien for finansielle tjenesteydelser bruge AI og ML til at løse udfordringer omkring opdagelse af svindel, forudsigelse af kreditrisiko, direkte markedsføring og mange andre.

Store virksomheder opretter nogle gange et center of excellence (CoE) for at imødekomme behovene i forskellige brancher (LoBs) med innovative analyser og ML-projekter.

For at generere højkvalitets og ydeevne ML-modeller i stor skala, skal de gøre følgende:

• Giv en nem måde at få adgang til relevante data til deres analyser og ML CoE
• Skab ansvarlighed på dataudbydere fra individuelle LoB'er for at dele kuraterede dataaktiver, der er opdagelige, forståelige, interoperable og troværdige

Dette kan reducere den lange cyklustid for konvertering af ML use cases fra eksperiment til produktion og generere forretningsværdi på tværs af organisationen.

En data mesh-arkitektur stræber efter at løse disse tekniske og organisatoriske udfordringer ved at indføre en decentraliseret socio-teknisk tilgang til at dele, få adgang til og administrere data i komplekse og store miljøer – inden for eller på tværs af organisationer. Datamesh-designmønsteret skaber en ansvarlig datadelingsmodel, der stemmer overens med den organisatoriske vækst for at nå det ultimative mål om at øge afkastet af forretningsinvesteringer i datateamene, processen og teknologien.

I denne todelte serie giver vi vejledning om, hvordan organisationer kan bygge en moderne dataarkitektur ved hjælp af et datamesh-designmønster på AWS og gøre det muligt for en analyse- og ML CoE at bygge og træne ML-modeller med data på tværs af flere LoB'er. Vi bruger et eksempel på en finansiel serviceorganisation til at sætte konteksten og brugssituationen for denne serie.

I dette første indlæg viser vi procedurerne for opsætning af en datamesh-arkitektur med flere AWS-dataproducent- og forbrugerkonti. Derefter fokuserer vi på ét dataprodukt, som ejes af én LoB i den finansielle organisation, og hvordan det kan deles ind i et datamesh-miljø for at give andre LoB'er mulighed for at forbruge og bruge dette dataprodukt. Dette er hovedsageligt rettet mod data steward-personen, som er ansvarlig for at strømline og standardisere processen med at dele data mellem dataproducenter og forbrugere og sikre overholdelse af regler for datastyring.

I det andet indlæg viser vi et eksempel på, hvordan en analyse- og ML CoE kan forbruge dataproduktet til en risikoforudsigelsesanvendelse. Dette er hovedsageligt rettet mod dataforskerens persona, som er ansvarlig for at bruge både organisationsdækkende og tredjeparts dataaktiver til at bygge og træne ML-modeller, der uddrager forretningsindsigt for at forbedre oplevelsen for kunder med finansielle tjenester.

Data mesh oversigt

Grundlæggeren af ​​datanetmønsteret, Zhamak Dehghani i sin bog Data Mesh leverer datadrevet værdi i skala, definerede fire principper for målet med datanettet:

• Distribueret domæneejerskab – At forfølge et organisatorisk skift fra centraliseret ejerskab af data af specialister, der driver dataplatformsteknologierne, til en decentraliseret dataejerskabsmodel, der skubber ejerskab og ansvarlighed for dataene tilbage til de LoB'er, hvor data produceres (kildetilpassede domæner) eller forbruges ( forbrugstilpassede domæner).
• Data som et produkt – At skubbe opstrøms ansvarligheden for at dele kuraterede, højkvalitets, interoperable og sikre dataaktiver. Derfor er dataproducenter fra forskellige LoB'er ansvarlige for at lave data i en forbrugsform lige ved kilden.
• Selvbetjeningsanalyse – At strømline oplevelsen for databrugere af analytics og ML, så de kan opdage, få adgang til og bruge dataprodukter med deres foretrukne værktøjer. Derudover for at strømline LoB-dataudbyderes oplevelse med at bygge, implementere og vedligeholde dataprodukter via opskrifter og genbrugelige komponenter og skabeloner.
• Fødereret beregningsstyring – At samle og automatisere beslutningstagningen involveret i styring og kontrol af dataadgang til at være på niveau med dataejere fra de forskellige LoB'er, hvilket stadig er i overensstemmelse med den bredere organisations juridiske, overholdelses- og sikkerhedspolitikker, der i sidste ende håndhæves gennem nettet.

AWS introducerede sin vision for at bygge et datanet oven på AWS i forskellige indlæg:

• Først fokuserede vi på den organisatoriske del forbundet med distribueret domæneejerskab og data som produktprincipper. Forfatterne beskrev visionen om at tilpasse flere LOB'er på tværs af organisationen hen imod en dataproduktstrategi, der giver de forbrugstilpassede domæner værktøjer til at finde og indhente de data, de har brug for, og samtidig garantere den nødvendige kontrol omkring brugen af ​​disse data ved at indføre ansvarlighed for de kildetilpassede domæner for at levere dataprodukter klar til at blive brugt lige ved kilden. For mere information, se Hvordan JPMorgan Chase byggede en datamesh-arkitektur for at skabe betydelig værdi for at forbedre deres virksomhedsdataplatform.
• Derefter fokuserede vi på den tekniske del i forbindelse med opbygning af dataprodukter, selvbetjeningsanalyse og fødererede beregningsmæssige styringsprincipper. Forfatterne beskrev de kerne AWS-tjenester, der giver de kildetilpassede domæner mulighed for at bygge og dele dataprodukter, en bred vifte af tjenester, der kan gøre det muligt for forbrugertilpassede domæner at forbruge dataprodukter på forskellige måder baseret på deres foretrukne værktøjer og de use cases, de arbejder hen imod, og endelig, AWS-tjenesterne, der styrer datadelingsproceduren ved at håndhæve dataadgangspolitikker. For mere information, se Design en datamesh-arkitektur ved hjælp af AWS Lake Formation og AWS Glue.
• Vi viste også en løsning til at automatisere dataopdagelse og adgangskontrol gennem en centraliseret data mesh UI. For flere detaljer, se Byg en arbejdsgang for datadeling med AWS Lake Formation til dit datanet.

Brugscase for finansielle tjenester

Typisk har store finansielle serviceorganisationer flere LoB'er, såsom forbrugerbank, investeringsbank og asset management, og også et eller flere analyse- og ML CoE-teams. Hver LoB tilbyder forskellige tjenester:

• Forbrugerbank LoB leverer en række tjenester til forbrugere og virksomheder, herunder kredit og realkredit, kontantstyring, betalingsløsninger, indlåns- og investeringsprodukter og mere
• Den kommercielle eller investeringsbank LoB tilbyder omfattende finansielle løsninger, såsom udlån, konkursrisiko og engrosbetalinger til kunder, herunder små virksomheder, mellemstore virksomheder og store virksomheder
• Asset Management LoB tilbyder pensionsprodukter og investeringsservice på tværs af alle aktivklasser

Hver LoB definerer deres egne dataprodukter, som er kurateret af personer, der forstår dataene og er bedst egnede til at specificere, hvem der er autoriseret til at bruge dem, og hvordan de kan bruges. I modsætning hertil er andre LoB'er og applikationsdomæner såsom analytics og ML CoE interesserede i at opdage og forbruge kvalificerede dataprodukter, blande det sammen for at generere indsigt og tage datadrevne beslutninger.

Den følgende illustration viser nogle LoB'er og eksempler på dataprodukter, som de kan dele. Det viser også forbrugerne af dataprodukter såsom analytics og ML CoE, som bygger ML-modeller, der kan implementeres til kundevendte applikationer for yderligere at forbedre slutkundens oplevelse.

Efter det socio-tekniske datamesh-koncept starter vi med det sociale aspekt med et sæt organisatoriske trin, såsom følgende:

• Brug af domæneeksperter til at definere grænser for hvert domæne, så hvert dataprodukt kan kortlægges til et specifikt domæne
• Identifikation af ejere for dataprodukter leveret fra hvert domæne, så hvert dataprodukt har en strategi defineret af deres ejer
• Identifikation af styringspolitikker fra globale og lokale eller fødererede incitamenter, så når dataforbrugere får adgang til et specifikt dataprodukt, kan den adgangspolitik, der er knyttet til produktet, automatisk håndhæves gennem et centralt datastyringslag

Derefter går vi til det tekniske aspekt, som inkluderer følgende ende-til-ende-scenarie defineret i det foregående diagram:

1. Giv forbrugerbank LoB værktøjer til at bygge et brugsklart forbrugerkreditprofildataprodukt.
2. Tillad forbrugerbank LoB at dele dataprodukter i det centrale styringslag.
3. Integrer globale og fødererede definitioner af dataadgangspolitikker, der bør håndhæves, mens du får adgang til forbrugerkreditprofildataproduktet gennem den centrale datastyring.
4. Tillad analytics og ML CoE at opdage og få adgang til dataproduktet gennem det centrale styringslag.
5. Giv analytics og ML CoE værktøjer til at bruge dataproduktet til at opbygge og træne en kreditrisikoforudsigelsesmodel. Vi dækker ikke de sidste trin (6 og 7 i det foregående diagram) i denne serie. Men for at vise den forretningsværdi en sådan ML-model kan tilføre organisationen i et end-to-end-scenarie, illustrerer vi følgende:
6. Denne model kan senere implementeres tilbage til kundevendte systemer såsom en forbrugerbankwebportal eller mobilapplikation.
7. Det kan specifikt bruges i låneansøgningen til at vurdere risikoprofilen for kredit- og realkreditanmodninger.

Dernæst beskriver vi de tekniske behov for hver af komponenterne.

Dyb dyk ned i tekniske behov

For at gøre dataprodukter tilgængelige for alle, skal organisationer gøre det nemt at dele data mellem forskellige enheder på tværs af organisationen, samtidig med at de bevarer passende kontrol over det, eller med andre ord at balancere agilitet med korrekt styring.

Dataforbruger: Analytics og ML CoE

Dataforbrugerne som f.eks. dataforskere fra analytics og ML CoE skal være i stand til at gøre følgende:

• Opdag og få adgang til relevante datasæt for en given use case
• Vær sikker på, at datasæt, de ønsker at få adgang til, allerede er kurateret, opdateret og har robuste beskrivelser
• Anmod om adgang til datasæt af interesse for deres business cases
• Brug deres foretrukne værktøjer til at forespørge og behandle sådanne datasæt i deres miljø til ML uden behov for at replikere data fra den oprindelige fjernplacering eller for at bekymre sig om tekniske eller infrastrukturkompleksiteter forbundet med behandling af data, der er fysisk lagret på et eksternt sted
• Få besked om eventuelle dataopdateringer foretaget af dataejerne

Dataproducent: Domæneejerskab

Dataproducenterne, såsom domæneteams fra forskellige LoB'er i den finansielle serviceorganisation, skal registrere og dele kurerede datasæt, der indeholder følgende:

• Tekniske og operationelle metadata, såsom database- og tabelnavne og -størrelser, kolonneskemaer og nøgler
• Virksomhedsmetadata såsom databeskrivelse, klassificering og følsomhed
• Sporing af metadata såsom skemaudvikling fra kilden til målformularen og eventuelle mellemformer
• Datakvalitetsmetadata såsom korrektheds- og fuldstændighedsforhold og databias
• Adgang til politikker og procedurer

Disse er nødvendige for at give dataforbrugere mulighed for at opdage og få adgang til data uden at være afhængige af manuelle procedurer eller at skulle kontakte dataproduktets domæneeksperter for at få mere viden om betydningen af ​​dataene og hvordan de kan tilgås.

Datastyring: Findbarhed, tilgængelighed og auditerbarhed

Organisationer er nødt til at balancere de agiliteter, der er illustreret tidligere, med passende afbødning af risiciene forbundet med datalæk. Især i regulerede brancher som f.eks. finansielle tjenester er der behov for at opretholde central datastyring for at give overordnet dataadgang og revisionskontrol og samtidig reducere lagringsfodaftrykket ved at undgå flere kopier af de samme data på tværs af forskellige lokationer.

I traditionelle centraliserede datasø-arkitekturer udgiver dataproducenterne ofte rådata og videregiver ansvaret for datakurering, datakvalitetsstyring og adgangskontrol til data- og infrastrukturingeniører i et centraliseret dataplatformsteam. Disse dataplatformsteams kan dog være mindre fortrolige med de forskellige datadomæner og stadig være afhængige af support fra dataproducenterne for at være i stand til korrekt at kurere og styre adgangen til data i henhold til de politikker, der håndhæves på hvert datadomæne. I modsætning hertil er dataproducenterne selv bedst positioneret til at levere kuraterede, kvalificerede dataaktiver og er opmærksomme på de domænespecifikke adgangspolitikker, der skal håndhæves, mens de får adgang til dataaktiver.

Løsningsoversigt

Følgende diagram viser højniveauarkitekturen for den foreslåede løsning.

Vi adresserer dataforbrug af analytics og ML CoE med Amazonas Athena , Amazon SageMaker in del 2 af denne serie.

I dette indlæg fokuserer vi på data-onboarding-processen ind i datanettet og beskriver, hvordan en individuel LoB såsom forbrugerbankdomænets datateam kan bruge AWS-værktøjer som f.eks. AWS Lim , AWS Glue Data Brew at forberede, kuratere og forbedre kvaliteten af ​​deres dataprodukter og derefter registrere disse dataprodukter på den centrale datastyringskonto gennem AWS søformation.

Consumer Banking LoB (dataproducent)

Et af kerneprincipperne for data mesh er konceptet data som et produkt. Det er meget vigtigt, at forbrugerbankdomænets datateam arbejder på at forberede dataprodukter, der er klar til brug af dataforbrugere. Dette kan gøres ved at bruge AWS extract, transform and load (ETL) værktøjer som AWS Glue til at behandle rå data indsamlet på Amazon Simple Storage Service (Amazon S3), eller alternativt oprette forbindelse til de operationelle datalagre, hvor dataene produceres. Du kan også bruge DataBrew, som er et kodefrit visuelt dataforberedelsesværktøj, der gør det nemt at rense og normalisere data.

For eksempel, mens de forbereder forbrugerkreditprofildataproduktet, kan forbrugerbankdomænedatateamet lave en simpel kuration for at oversætte attributnavnene på de rådata, der hentes fra open source-datasættet, fra tysk til engelsk Statlog tyske kreditdata, som består af 20 attributter og 1,000 rækker.

Datastyring

Kerne AWS-tjenesten til at aktivere data mesh-styring er Lake Formation. Lake Formation tilbyder muligheden for at håndhæve datastyring inden for hvert datadomæne og på tværs af domæner for at sikre, at data er let at finde og sikre. Det giver en fødereret sikkerhedsmodel, der kan administreres centralt med bedste praksis for dataopdagelse, sikkerhed og overholdelse, samtidig med at det tillader høj agilitet inden for hvert domæne.

Lake Formation tilbyder en API til at forenkle, hvordan data indtages, lagres og administreres, sammen med række-niveau sikkerhed for at beskytte dine data. Det giver også funktionalitet som granulær adgangskontrol, styrede tabeller og lageroptimering.

Derudover tilbyder Lake Formations en Datadeling API som du kan bruge til at dele data på tværs af forskellige konti. Dette giver analytics- og ML CoE-forbrugeren mulighed for at køre Athena-forespørgsler, der forespørger og forbinder tabeller på tværs af flere konti. For mere information, se AWS Lake Formation Developer Guide.

AWS Resource Access Manager (AWS RAM) giver en sikker måde at dele ressourcer via AWS Identity and Access Manager (IAM) roller og brugere på tværs af AWS-konti i en organisation eller organisatoriske enheder (OU'er) i AWS-organisationer.

Lake Formation sammen med AWS RAM giver én måde at administrere datadeling og adgang på tværs af AWS-konti. Vi omtaler denne tilgang som RAM-baseret adgangskontrol. For flere detaljer om denne tilgang, se Byg en arbejdsgang for datadeling med AWS Lake Formation til dit datanet.

Lake Formation tilbyder også en anden måde at administrere datadeling og adgang vha Lake Formation tags. Vi omtaler denne tilgang som tag-baseret adgangskontrol. For flere detaljer, se Byg en moderne dataarkitektur og datamaskemønster i skala ved hjælp af AWS Lake Formation tag-baseret adgangskontrol.

Igennem dette indlæg bruger vi den tag-baserede tilgangskontroltilgang, fordi den forenkler oprettelsen af ​​politikker på et mindre antal logiske tags, der almindeligvis findes i forskellige LoB'er i stedet for at specificere politikker på navngivne ressourcer på infrastrukturniveau.

Forudsætninger

For at opsætte en datamesh-arkitektur skal du bruge mindst tre AWS-konti: en producentkonto, en central konto og en forbrugerkonto.

Implementer datamesh-miljøet

For at implementere et datamesh-miljø kan du bruge følgende GitHub repository. Dette lager indeholder tre AWS CloudFormation skabeloner, der implementerer et datamesh-miljø, der inkluderer hver af konti (producent, central og forbruger). Inden for hver konto kan du køre dens tilsvarende CloudFormation-skabelon.

Central konto

I den centrale konto skal du udføre følgende trin:

1. Start CloudFormation-stakken:
   
2. Opret to IAM-brugere:
   1. DataMeshOwner
   2. ProducerSteward
3. Grant DataMeshOwner som Lake Formation admin.
4. Opret én IAM-rolle:
   1. LFRegisterLocationServiceRole
5. Opret to IAM-politikker:
   1. ProducerStewardPolicy
   2. S3DataLakePolicy
6. Opret databasen kreditkort for ProducerSteward på producentkontoen.
7. Del dataplaceringstilladelsen med producentkontoen.

Producentkonto

I producentkontoen skal du udføre følgende trin:

1. Start CloudFormation-stakken:
   
2. Opret S3-spanden credit-card, som holder bordet credit_card.
3. Tillad S3 bucket-adgang for den centrale konto Lake Formation-servicerolle.
4. Opret AWS Glue-crawleren creditCrawler-<ProducerAccountID>.
5. Opret en AWS Glue-crawler-servicerolle.
6. Giv tilladelser til S3-spandplaceringen credit-card-<ProducerAccountID>-<aws-region> til AWS Glue crawler-rollen.
7. Opret en producer steward IAM-bruger.

Forbrugerkonto

På forbrugerkontoen skal du udføre følgende trin:

1. Start CloudFormation-stakken:
   
2. Opret S3-spanden <AWS Account ID>-<aws-region>-athena-logs.
3. Opret Athena-arbejdsgruppen consumer-workgroup.
4. Opret IAM-brugeren ConsumerAdmin.

Tilføj en database og abonner på forbrugerkontoen på den

Når du har kørt skabelonerne, kan du gå igennem trin-for-trin guide at tilføje et produkt i datakataloget og få forbrugeren til at abonnere på det. Vejledningen starter med at oprette en database, hvor producenten kan placere sine produkter og forklarer derefter, hvordan forbrugeren kan abonnere på den pågældende database og få adgang til dataene. Alt dette udføres under brug LF-tags, som er den tag-baseret adgangskontrol for Sødannelse.

Data produktregistrering

Den følgende arkitektur beskriver de detaljerede trin i, hvordan forbrugerbanks LoB-teamet, der fungerer som dataproducenter, kan registrere deres dataprodukter på den centrale datastyringskonto (dataprodukter ombord til organisationens datamaske).

De generelle trin for at registrere et dataprodukt er som følger:

1. Opret en måldatabase for dataproduktet i den centrale styringskonto. Som et eksempel opretter CloudFormation-skabelonen fra den centrale konto allerede måldatabasen credit-card.
2. Del den oprettede måldatabase med oprindelsen i producentkontoen.
3. Opret et ressourcelink til den delte database på producentkontoen. I det følgende skærmbillede ser vi på Lake Formation-konsollen i producentkontoen, at rl_credit-card er ressourcelinket til credit-card databasen.
   
4. Udfyld tabeller (med dataene kureret i producentkontoen) i ressourcelinkdatabasen (rl_credit-card) ved hjælp af en AWS Glue-crawler på producentkontoen.
   

Den oprettede tabel vises automatisk i den centrale styringskonto. Følgende skærmbillede viser et eksempel på tabellen i Lake Formation i den centrale konto. Dette er efter at have udført de tidligere trin for at udfylde ressourcelinkdatabasen rl_credit-card på producentkontoen.

Konklusion

I del 1 af denne serie diskuterede vi finansielle serviceorganisationers mål for at opnå mere agilitet for deres analyse- og ML-teams og reducere tiden fra data til indsigt. Vi fokuserede også på at bygge en data mesh-arkitektur på AWS, hvor vi har introduceret brugervenlige, skalerbare og omkostningseffektive AWS-tjenester såsom AWS Glue, DataBrew og Lake Formation. Dataproducerende teams kan bruge disse tjenester til at bygge og dele kuraterede, interoperable og sikre dataprodukter af høj kvalitet, der er klar til brug af forskellige dataforbrugere til analytiske formål.

In del 2, fokuserer vi på analyse- og ML CoE-teams, der bruger dataprodukter, der deles af forbrugerbank-LoB for at opbygge en kreditrisikoforudsigelsesmodel ved hjælp af AWS-tjenester såsom Athena og SageMaker.

---

Om forfatterne

Karim Hammouda er en Specialist Solutions Architect for Analytics hos AWS med en passion for dataintegration, dataanalyse og BI. Han arbejder med AWS-kunder for at designe og bygge analyseløsninger, der bidrager til deres virksomhedsvækst. I sin fritid kan han godt lide at se tv-dokumentarer og spille videospil med sin søn.

Hasan Poonawala er Senior AI/ML Specialist Solutions Architect hos AWS, Hasan hjælper kunder med at designe og implementere maskinlæringsapplikationer i produktion på AWS. Han har over 12 års erhvervserfaring som dataforsker, maskinlæringspraktiker og softwareudvikler. I sin fritid elsker Hasan at udforske naturen og tilbringe tid med venner og familie.

Benoit de Patoul er AI/ML Specialist Solutions Architect hos AWS. Han hjælper kunder ved at yde vejledning og teknisk assistance til at bygge løsninger relateret til AI/ML ved hjælp af AWS. I sin fritid kan han lide at spille klaver og bruge tid sammen med venner.