Bygg og tren ML-modeller ved å bruke en datamaskeringsarkitektur på AWS: Del 1

Organisasjoner på tvers av ulike bransjer bruker kunstig intelligens (AI) og maskinlæring (ML) for å løse forretningsutfordringer som er spesifikke for deres bransje. For eksempel, i finansnæringen kan du bruke AI og ML for å løse utfordringer rundt svindeloppdagelse, kredittrisikoprediksjon, direkte markedsføring og mange andre.

Store bedrifter setter noen ganger opp et senter for kompetanse (CoE) for å takle behovene til ulike bransjer (LoBs) med innovative analyser og ML-prosjekter.

For å generere høykvalitets og ytende ML-modeller i stor skala, må de gjøre følgende:

• Gi en enkel måte å få tilgang til relevante data til analysene deres og ML CoE
• Skap ansvarlighet på dataleverandører fra individuelle LoBs for å dele kuraterte dataressurser som er oppdagebare, forståelige, interoperable og pålitelige

Dette kan redusere den lange syklustiden for konvertering av ML-brukstilfeller fra eksperiment til produksjon og generere forretningsverdi på tvers av organisasjonen.

En datamaskeringsarkitektur streber etter å løse disse tekniske og organisatoriske utfordringene ved å introdusere en desentralisert sosioteknisk tilnærming for å dele, få tilgang til og administrere data i komplekse og store miljøer – innenfor eller på tvers av organisasjoner. Designmønsteret for datanettverk skaper en ansvarlig datadelingsmodell som er i tråd med organisasjonsveksten for å oppnå det endelige målet om å øke avkastningen av forretningsinvesteringer i datateamene, prosessen og teknologien.

I denne todelte serien gir vi veiledning om hvordan organisasjoner kan bygge en moderne dataarkitektur ved å bruke et datanettdesignmønster på AWS og gjøre det mulig for en analyse- og ML CoE å bygge og trene ML-modeller med data på tvers av flere LoBs. Vi bruker et eksempel på en finansiell tjenesteorganisasjon for å sette konteksten og brukssaken for denne serien.

I dette første innlegget viser vi prosedyrene for å sette opp en datamaskeringsarkitektur med flere AWS-dataprodusent- og forbrukerkontoer. Deretter fokuserer vi på ett dataprodukt, som eies av én LoB i finansorganisasjonen, og hvordan det kan deles inn i et datanettmiljø for å la andre LoBs konsumere og bruke dette dataproduktet. Dette er i hovedsak rettet mot dataansvarlig persona, som er ansvarlig for å effektivisere og standardisere prosessen med å dele data mellom dataprodusenter og forbrukere og sikre overholdelse av regler for datastyring.

I det andre innlegget viser vi ett eksempel på hvordan en analyse- og ML CoE kan konsumere dataproduktet for en risikoprediksjon. Dette er hovedsakelig rettet mot dataforsker-persona, som er ansvarlig for å bruke både organisasjonsomfattende og tredjeparts dataressurser for å bygge og trene ML-modeller som trekker ut forretningsinnsikt for å forbedre opplevelsen til kunder med finansielle tjenester.

Oversikt over datanettverk

Grunnleggeren av datanettmønsteret, Zhamak Dehghani i boken hennes Datanettverk som leverer datadrevet verdi i stor skala, definerte fire prinsipper mot målet med datanettverket:

• Distribuert domeneeierskap – Å forfølge et organisatorisk skifte fra sentralisert eierskap av data av spesialister som driver dataplattformteknologiene til en desentralisert dataeierskapsmodell, og skyve eierskap og ansvarlighet for dataene tilbake til LoB-ene der data produseres (kildejusterte domener) eller forbrukes ( forbrukstilpassede domener).
• Data som et produkt – Å presse oppstrøms ansvarligheten for å dele kuraterte, høykvalitets, interoperable og sikre dataressurser. Derfor er dataprodusenter fra ulike LoBs ansvarlige for å lage data i en forbruksform rett ved kilden.
• Selvbetjeningsanalyse – For å strømlinjeforme opplevelsen til databrukere av analytics og ML slik at de kan oppdage, få tilgang til og bruke dataprodukter med sine foretrukne verktøy. I tillegg for å strømlinjeforme opplevelsen til LoB-dataleverandører for å bygge, distribuere og vedlikeholde dataprodukter via oppskrifter og gjenbrukbare komponenter og maler.
• Federert beregningsstyring – Å forene og automatisere beslutningstakingen involvert i å administrere og kontrollere datatilgang for å være på nivå med dataeiere fra de forskjellige LoB-ene, noe som fortsatt er i tråd med den bredere organisasjonens juridiske, overholdelses- og sikkerhetspolicyer som til slutt håndheves gjennom nettet.

AWS introduserte sin visjon for å bygge et datanett på toppen av AWS i forskjellige innlegg:

• Først fokuserte vi på den organisatoriske delen knyttet til distribuert domeneeierskap og data som produktprinsipper. Forfatterne beskrev visjonen om å justere flere LOB-er på tvers av organisasjonen mot en dataproduktstrategi som gir de forbrukstilpassede domenene verktøy for å finne og skaffe dataene de trenger, samtidig som de garanterer nødvendig kontroll rundt bruken av disse dataene ved å introdusere ansvarlighet for de kildejusterte domenene for å gi dataprodukter klare til å brukes rett ved kilden. For mer informasjon, se Hvordan JPMorgan Chase bygde en datamaskeringsarkitektur for å skape betydelig verdi for å forbedre bedriftens dataplattform.
• Deretter fokuserte vi på den tekniske delen knyttet til bygging av dataprodukter, selvbetjeningsanalyse og forente beregningsprinsipper. Forfatterne beskrev kjerne-AWS-tjenestene som gir de kildejusterte domenene mulighet til å bygge og dele dataprodukter, et bredt utvalg tjenester som kan gjøre det mulig for forbrukertilpassede domener å konsumere dataprodukter på forskjellige måter basert på deres foretrukne verktøy og brukstilfellene de jobber mot, og til slutt, AWS-tjenestene som styrer datadelingsprosedyren ved å håndheve retningslinjer for datatilgang. For mer informasjon, se Design en datanettingsarkitektur ved å bruke AWS Lake Formation og AWS Glue.
• Vi viste også en løsning for å automatisere dataoppdagelse og tilgangskontroll gjennom et sentralisert datanettverk-grensesnitt. For flere detaljer, se Bygg en arbeidsflyt for datadeling med AWS Lake Formation for datanettverket ditt.

Brukscase for finansielle tjenester

Vanligvis har store finansielle tjenesteorganisasjoner flere LoB-er, for eksempel forbrukerbanktjenester, investeringsbanktjenester og kapitalforvaltning, og også ett eller flere analyse- og ML CoE-team. Hver LoB tilbyr forskjellige tjenester:

• Forbrukerbank LoB tilbyr en rekke tjenester til forbrukere og bedrifter, inkludert kreditt og boliglån, kontanthåndtering, betalingsløsninger, innskudds- og investeringsprodukter og mer
• LoB for kommersielle eller investeringsbanker tilbyr omfattende finansielle løsninger, som utlån, konkursrisiko og grossistbetalinger til kunder, inkludert små bedrifter, mellomstore selskaper og store selskaper
• Kapitalforvaltningen LoB tilbyr pensjonsprodukter og investeringstjenester på tvers av alle aktivaklasser

Hver LoB definerer sine egne dataprodukter, som er kuratert av personer som forstår dataene og er best egnet til å spesifisere hvem som er autorisert til å bruke dem, og hvordan de kan brukes. I motsetning til dette er andre LoBs og applikasjonsdomener som analytics og ML CoE interessert i å oppdage og konsumere kvalifiserte dataprodukter, blande det sammen for å generere innsikt og ta datadrevne beslutninger.

Følgende illustrasjon viser noen LoBs og eksempler på dataprodukter som de kan dele. Den viser også forbrukerne av dataprodukter som analytics og ML CoE, som bygger ML-modeller som kan distribueres til kundevendte applikasjoner for å forbedre sluttkundens opplevelse ytterligere.

Etter det sosiotekniske datamaskeringskonseptet starter vi med det sosiale aspektet med et sett med organisatoriske trinn, for eksempel følgende:

• Bruke domeneeksperter til å definere grenser for hvert domene, slik at hvert dataprodukt kan tilordnes et spesifikt domene
• Identifisere eiere for dataprodukter levert fra hvert domene, slik at hvert dataprodukt har en strategi definert av eieren
• Identifisere styringspolitikker fra globale og lokale eller fødererte insentiver, så når dataforbrukere får tilgang til et spesifikt dataprodukt, kan tilgangspolicyen knyttet til produktet håndheves automatisk gjennom et sentralt datastyringslag

Deretter går vi til det tekniske aspektet, som inkluderer følgende ende-til-ende-scenario definert i forrige diagram:

1. Gi forbrukerbank LoB verktøy for å bygge et klart til bruk forbrukerkredittprofildataprodukt.
2. Tillat LoB for forbrukerbank å dele dataprodukter inn i det sentrale styringslaget.
3. Bygg inn globale og forente definisjoner av retningslinjer for datatilgang som bør håndheves mens du får tilgang til forbrukerkredittprofildataproduktet gjennom den sentrale datastyringen.
4. La analytics og ML CoE oppdage og få tilgang til dataproduktet gjennom det sentrale styringslaget.
5. Gi analytics og ML CoE verktøy for å bruke dataproduktet for å bygge og trene en kredittrisikoprediksjonsmodell. Vi dekker ikke de siste trinnene (6 og 7 i det foregående diagrammet) i denne serien. For å vise forretningsverdien en slik ML-modell kan gi organisasjonen i et ende-til-ende-scenario, illustrerer vi følgende:
6. Denne modellen kan senere distribueres tilbake til kundevendte systemer som en nettportal for forbrukerbanker eller mobilapplikasjoner.
7. Den kan spesifikt brukes i lånesøknaden for å vurdere risikoprofilen til kreditt- og boliglånsforespørsler.

Deretter beskriver vi de tekniske behovene til hver av komponentene.

Dypdykk i tekniske behov

For å gjøre dataprodukter tilgjengelige for alle, må organisasjoner gjøre det enkelt å dele data mellom ulike enheter på tvers av organisasjonen samtidig som de opprettholder passende kontroll over det, eller med andre ord, balansere smidighet med riktig styring.

Dataforbruker: Analytics og ML CoE

Dataforbrukerne som dataforskere fra analytics og ML CoE må kunne gjøre følgende:

• Oppdag og få tilgang til relevante datasett for et gitt brukstilfelle
• Vær trygg på at datasett de vil ha tilgang til allerede er kuratert, oppdatert og har robuste beskrivelser
• Be om tilgang til datasett av interesse for deres forretningssaker
• Bruk deres foretrukne verktøy til å spørre etter og behandle slike datasett i miljøet deres for ML uten behov for å replikere data fra den opprinnelige eksterne plasseringen eller for å bekymre deg for tekniske eller infrastrukturkompleksiteter knyttet til behandling av data fysisk lagret på et eksternt sted
• Bli varslet om eventuelle dataoppdateringer gjort av dataeierne

Dataprodusent: Domeneeierskap

Dataprodusentene, for eksempel domeneteam fra forskjellige LoBs i finanstjenesteorganisasjonen, må registrere og dele kuraterte datasett som inneholder følgende:

• Tekniske og operasjonelle metadata, som database- og tabellnavn og størrelser, kolonneskjemaer og nøkler
• Bedriftsmetadata som databeskrivelse, klassifisering og sensitivitet
• Sporing av metadata som skjemautvikling fra kilden til målskjemaet og eventuelle mellomformer
• Datakvalitetsmetadata som korrekthets- og fullstendighetsforhold og databias
• Få tilgang til retningslinjer og prosedyrer

Disse er nødvendige for å tillate dataforbrukere å oppdage og få tilgang til data uten å stole på manuelle prosedyrer eller å måtte kontakte dataproduktets domeneeksperter for å få mer kunnskap om betydningen av dataene og hvordan de kan nås.

Datastyring: Oppdagbarhet, tilgjengelighet og reviderbarhet

Organisasjoner må balansere smidighetene som er illustrert tidligere, med riktig reduksjon av risikoene forbundet med datalekkasjer. Spesielt i regulerte bransjer som finansielle tjenester, er det behov for å opprettholde sentral datastyring for å gi total datatilgang og revisjonskontroll samtidig som man reduserer lagringsfotavtrykket ved å unngå flere kopier av de samme dataene på ulike steder.

I tradisjonelle sentraliserte datainnsjøarkitekturer publiserer dataprodusentene ofte rådata og overfører ansvaret for datakurering, datakvalitetsstyring og tilgangskontroll til data- og infrastrukturingeniører i et sentralisert dataplattformteam. Imidlertid kan disse dataplattformteamene være mindre kjent med de ulike datadomenene, og fortsatt stole på støtte fra dataprodusentene for å kunne kurere og styre tilgangen til data på riktig måte i henhold til retningslinjene som håndheves på hvert datadomene. Derimot er dataprodusentene selv best posisjonert til å tilby kuraterte, kvalifiserte dataressurser og er klar over de domenespesifikke tilgangspolitikkene som må håndheves mens de får tilgang til dataressurser.

Løsningsoversikt

Følgende diagram viser høynivåarkitekturen til den foreslåtte løsningen.

Vi adresserer dataforbruk av analytics og ML CoE med Amazonas Athena og Amazon SageMaker in del 2 av denne serien.

I dette innlegget fokuserer vi på data onboarding-prosessen inn i datanettverket og beskriver hvordan en individuell LoB som for eksempel forbrukerbankdomenedatateamet kan bruke AWS-verktøy som f.eks. AWS Lim og AWS Lim DataBrew å forberede, kuratere og forbedre kvaliteten på dataproduktene deres, og deretter registrere disse dataproduktene i den sentrale datastyringskontoen gjennom AWS Lake formasjon.

Forbrukerbank LoB (dataprodusent)

Et av kjerneprinsippene for datanettverk er konseptet data som et produkt. Det er svært viktig at forbrukerbankdomenedatateamet jobber med å utarbeide dataprodukter som er klare til bruk av dataforbrukere. Dette kan gjøres ved å bruke AWS extract, transform and load (ETL) verktøy som AWS Glue for å behandle rådata samlet på Amazon enkel lagringstjeneste (Amazon S3), eller alternativt koble til driftsdatalagrene der dataene produseres. Du kan også bruke DataBrew, som er et verktøy for klargjøring av visuelle data uten kode som gjør det enkelt å rense og normalisere data.

For eksempel, mens du forbereder dataproduktet for forbrukerkredittprofilen, kan datateamet for forbrukerbankdomene foreta en enkel kurasjon for å oversette attributtnavnene til rådataene hentet fra datasettet med åpen kildekode fra tysk til engelsk Statlog tyske kredittdata, som består av 20 attributter og 1,000 rader.

Datastyring

Kjerne-AWS-tjenesten for å muliggjøre datamaskestyring er Lake Formation. Lake Formation tilbyr muligheten til å håndheve datastyring innenfor hvert datadomene og på tvers av domener for å sikre at data er lett synlige og sikre. Den gir en forent sikkerhetsmodell som kan administreres sentralt, med beste praksis for dataoppdagelse, sikkerhet og samsvar, samtidig som den tillater høy smidighet innenfor hvert domene.

Lake Formation tilbyr et API for å forenkle hvordan data inntas, lagres og administreres, sammen med sikkerhet på radnivå for å beskytte dataene dine. Det gir også funksjonalitet som granulær tilgangskontroll, styrte tabeller og lagringsoptimalisering.

I tillegg tilbyr Lake Formations en Datadeling API som du kan bruke til å dele data på tvers av ulike kontoer. Dette lar analytics- og ML CoE-forbrukeren kjøre Athena-spørringer som spør etter og slår sammen tabeller på tvers av flere kontoer. For mer informasjon, se AWS Lake Formation utviklerveiledning.

AWS Resource Access Manager (AWS RAM) gir en sikker måte å dele ressurser via AWS Identity and Access Manager (IAM) roller og brukere på tvers av AWS-kontoer innenfor en organisasjon eller organisasjonsenheter (OUer) i AWS-organisasjoner.

Lake Formation sammen med AWS RAM gir én måte å administrere datadeling og tilgang på tvers av AWS-kontoer. Vi omtaler denne tilnærmingen som RAM-basert tilgangskontroll. For mer informasjon om denne tilnærmingen, se Bygg en arbeidsflyt for datadeling med AWS Lake Formation for datanettverket ditt.

Lake Formation tilbyr også en annen måte å administrere datadeling og tilgang ved hjelp av Lake Formation-merker. Vi omtaler denne tilnærmingen som tag-basert tilgangskontroll. For flere detaljer, se Bygg en moderne dataarkitektur og datanettmønster i skala ved hjelp av AWS Lake Formation-tagbasert tilgangskontroll.

Gjennom dette innlegget bruker vi den tag-baserte tilgangskontrolltilnærmingen fordi den forenkler opprettelsen av policyer på et mindre antall logiske tagger som vanligvis finnes i forskjellige LoBs i stedet for å spesifisere policyer på navngitte ressurser på infrastrukturnivå.

Forutsetninger

For å sette opp en datamaskeringsarkitektur trenger du minst tre AWS-kontoer: en produsentkonto, en sentralkonto og en forbrukerkonto.

Distribuer datamesh-miljøet

For å distribuere et datanettverk-miljø kan du bruke følgende GitHub repository. Dette depotet inneholder tre AWS skyformasjon maler som distribuerer et datanettverksmiljø som inkluderer hver av kontoene (produsent, sentral og forbruker). Innenfor hver konto kan du kjøre den tilhørende CloudFormation-malen.

Sentral konto

I den sentrale kontoen, fullfør følgende trinn:

1. Start CloudFormation-stabelen:
   
2. Opprett to IAM-brukere:
   1. DataMeshOwner
   2. ProducerSteward
3. Grant DataMeshOwner som Lake Formation-administrator.
4. Opprett én IAM-rolle:
   1. LFRegisterLocationServiceRole
5. Opprett to IAM-policyer:
   1. ProducerStewardPolicy
   2. S3DataLakePolicy
6. Opprett databasen kredittkort for ProducerSteward på produsentkontoen.
7. Del dataplasseringstillatelsen med produsentkontoen.

Produsentkonto

Fullfør følgende trinn i produsentkontoen:

1. Start CloudFormation-stabelen:
   
2. Lag S3-skuffen credit-card, som holder bordet credit_card.
3. Tillat S3-bøttetilgang for den sentrale kontoen Lake Formation-tjenesterollen.
4. Lag AWS Glue-crawler creditCrawler-<ProducerAccountID>.
5. Opprett en tjenesterolle for AWS Glue Crawler.
6. Gi tillatelser på S3-bøtteplasseringen credit-card-<ProducerAccountID>-<aws-region> til AWS Glue crawler-rollen.
7. Opprett en produsentansvarlig IAM-bruker.

Forbrukerkonto

I forbrukerkontoen fullfører du følgende trinn:

1. Start CloudFormation-stabelen:
   
2. Lag S3-skuffen <AWS Account ID>-<aws-region>-athena-logs.
3. Opprett Athena-arbeidsgruppen consumer-workgroup.
4. Opprett IAM-brukeren ConsumerAdmin.

Legg til en database og abonner på forbrukerkontoen på den

Etter at du har kjørt malene, kan du gå gjennom trinnvis veiledning å legge til et produkt i datakatalogen og få forbrukeren til å abonnere på det. Veiledningen starter med å sette opp en database hvor produsenten kan plassere produktene sine og forklarer deretter hvordan forbrukeren kan abonnere på den databasen og få tilgang til dataene. Alt dette utføres under bruk LF-merker, hvilken er den tag-basert tilgangskontroll for Lake Formation.

Data produktregistrering

Den følgende arkitekturen beskriver de detaljerte trinnene for hvordan LoB-teamet for forbrukerbanker som fungerer som dataprodusenter kan registrere dataproduktene sine i den sentrale datastyringskontoen (dataprodukter ombord til organisasjonens datanettverk).

De generelle trinnene for å registrere et dataprodukt er som følger:

1. Lag en måldatabase for dataproduktet i den sentrale styringskontoen. Som et eksempel oppretter CloudFormation-malen fra den sentrale kontoen allerede måldatabasen credit-card.
2. Del den opprettede måldatabasen med opprinnelsen i produsentkontoen.
3. Opprett en ressurskobling for den delte databasen i produsentkontoen. I det følgende skjermbildet ser vi på Lake Formation-konsollen i produsentkontoen at rl_credit-card er ressurslenken til credit-card database.
   
4. Fyll ut tabeller (med dataene kurert i produsentkontoen) i ressurslenkedatabasen (rl_credit-card) ved å bruke en AWS Glue-crawler i produsentkontoen.
   

Den opprettede tabellen vises automatisk i den sentrale styringskontoen. Følgende skjermbilde viser et eksempel på tabellen i Lake Formation i den sentrale kontoen. Dette er etter å ha utført de tidligere trinnene for å fylle ut ressurslenkedatabasen rl_credit-card i produsentkontoen.

konklusjonen

I del 1 av denne serien diskuterte vi målene til finansorganisasjoner for å oppnå mer smidighet for analyse- og ML-teamene deres og redusere tiden fra data til innsikt. Vi fokuserte også på å bygge en datamaskeringsarkitektur på AWS, der vi har introdusert brukervennlige, skalerbare og kostnadseffektive AWS-tjenester som AWS Glue, DataBrew og Lake Formation. Dataproduserende team kan bruke disse tjenestene til å bygge og dele kuraterte, høykvalitets, interoperable og sikre dataprodukter som er klare til bruk av forskjellige dataforbrukere for analytiske formål.

In del 2, fokuserer vi på analyse- og ML CoE-team som bruker dataprodukter som deles av forbrukerbank LoB for å bygge en kredittrisikoprediksjonsmodell ved å bruke AWS-tjenester som Athena og SageMaker.

---

Om forfatterne

Karim Hammouda er en spesialistløsningsarkitekt for Analytics hos AWS med lidenskap for dataintegrasjon, dataanalyse og BI. Han jobber med AWS-kunder for å designe og bygge analyseløsninger som bidrar til deres forretningsvekst. På fritiden liker han å se TV-dokumentarer og spille videospill med sønnen.

Hasan Poonawala er senior AI/ML spesialistløsningsarkitekt hos AWS, Hasan hjelper kunder med å designe og distribuere maskinlæringsapplikasjoner i produksjon på AWS. Han har over 12 års arbeidserfaring som dataforsker, maskinlæringsutøver og programvareutvikler. På fritiden elsker Hasan å utforske naturen og tilbringe tid med venner og familie.

Benoit de Patoul er AI/ML Specialist Solutions Architect hos AWS. Han hjelper kunder ved å gi veiledning og teknisk assistanse for å bygge løsninger relatert til AI/ML ved hjelp av AWS. På fritiden liker han å spille piano og tilbringe tid med venner.