Bouw en train ML-modellen met behulp van een data mesh-architectuur op AWS: deel 1

Organisaties in verschillende sectoren gebruiken kunstmatige intelligentie (AI) en machine learning (ML) om zakelijke uitdagingen op te lossen die specifiek zijn voor hun branche. In de financiële dienstverlening kunt u bijvoorbeeld AI en ML gebruiken om uitdagingen op het gebied van fraudedetectie, kredietrisicovoorspelling, direct marketing en vele andere op te lossen.

Grote ondernemingen zetten soms een centre of excellence (CoE) op om de behoeften van verschillende bedrijfstakken (LoB's) aan te pakken met innovatieve analyse- en ML-projecten.

Om hoogwaardige en performante ML-modellen op schaal te genereren, moeten ze het volgende doen:

• Bieden een gemakkelijke manier om toegang te krijgen tot relevante gegevens voor hun analyses en ML CoE
• Creëer verantwoordelijkheid over gegevensproviders van individuele LoB's om beheerde gegevensactiva te delen die vindbaar, begrijpelijk, interoperabel en betrouwbaar zijn

Dit kan de lange cyclustijd voor het converteren van ML-use-cases van experiment naar productie verkorten en bedrijfswaarde genereren in de hele organisatie.

Een data mesh-architectuur streeft ernaar deze technische en organisatorische uitdagingen op te lossen door een gedecentraliseerde sociaal-technische benadering te introduceren voor het delen, openen en beheren van gegevens in complexe en grootschalige omgevingen, binnen of tussen organisaties. Het ontwerppatroon van data mesh creëert een verantwoord model voor het delen van gegevens dat aansluit bij de groei van de organisatie om het uiteindelijke doel te bereiken, namelijk het verhogen van het rendement van bedrijfsinvesteringen in de datateams, het proces en de technologie.

In deze tweedelige serie bieden we richtlijnen over hoe organisaties een moderne data-architectuur kunnen bouwen met behulp van een data mesh-ontwerppatroon op AWS en een analyse en ML CoE in staat stellen om ML-modellen te bouwen en te trainen met data over meerdere LoB's. We gebruiken een voorbeeld van een financiële dienstverlener om de context en de use case voor deze serie te bepalen.

In dit eerste bericht laten we de procedures zien voor het opzetten van een data mesh-architectuur met meerdere AWS-gegevensproducenten en consumentenaccounts. Vervolgens richten we ons op één dataproduct, dat eigendom is van één LoB binnen de financiële organisatie, en hoe dit kan worden gedeeld in een datamesh-omgeving zodat andere LoB's dit dataproduct kunnen consumeren en gebruiken. Dit is voornamelijk gericht op de data steward persona, die verantwoordelijk is voor het stroomlijnen en standaardiseren van het proces van het delen van gegevens tussen gegevensproducenten en consumenten en het waarborgen van de naleving van de regels voor gegevensbeheer.

In de tweede post laten we een voorbeeld zien van hoe een analyse en ML CoE het dataproduct kunnen gebruiken voor een gebruiksscenario voor risicovoorspelling. Dit is voornamelijk gericht op de persona van datawetenschappers, die verantwoordelijk is voor het gebruik van zowel organisatiebrede als externe data-assets om ML-modellen te bouwen en te trainen die zakelijke inzichten extraheren om de ervaring van klanten in de financiële dienstverlening te verbeteren.

Overzicht datamesh

De grondlegger van het data mesh-patroon, Zhamak Dehghani in haar boek Data Mesh levert datagedreven waarde op schaal, definieerde vier principes voor het doel van de data mesh:

• Eigendom van gedistribueerd domein – Een organisatorische verschuiving nastreven van gecentraliseerd eigendom van gegevens door specialisten die de dataplatformtechnologieën uitvoeren naar een gedecentraliseerd model voor gegevenseigendom, waarbij eigendom en verantwoordelijkheid van de gegevens worden teruggedrongen naar de LoB's waar gegevens worden geproduceerd (source-aligned domeinen) of verbruikt ( consumptie-uitgelijnde domeinen).
• Gegevens als product – Om de verantwoordelijkheid voor het delen van samengestelde, hoogwaardige, interoperabele en veilige data-assets stroomopwaarts te pushen. Daarom zijn dataproducenten van verschillende LoB's verantwoordelijk voor het direct bij de bron maken van data in een consumeerbare vorm.
• Selfservice-analyse – Om de ervaring van datagebruikers van analytics en ML te stroomlijnen, zodat ze dataproducten kunnen ontdekken, openen en gebruiken met hun favoriete tools. Bovendien, om de ervaring van LoB-dataproviders te stroomlijnen voor het bouwen, implementeren en onderhouden van dataproducten via recepten en herbruikbare componenten en sjablonen.
• Federaal computationeel bestuur – Het bundelen en automatiseren van de besluitvorming die betrokken is bij het beheren en controleren van gegevenstoegang op het niveau van gegevenseigenaren van de verschillende LoB's, wat nog steeds in overeenstemming is met het juridische, nalevings- en beveiligingsbeleid van de bredere organisatie dat uiteindelijk wordt afgedwongen door het gaas.

AWS introduceerde zijn visie voor het bouwen van een datamesh bovenop AWS in verschillende posts:

• Ten eerste hebben we ons gericht op het organisatorische deel dat verband houdt met gedistribueerd domeineigendom en gegevens als productprincipes. De auteurs beschreven de visie om meerdere LOB's in de hele organisatie op één lijn te brengen in de richting van een dataproductstrategie die de op consumptie afgestemde domeinen tools biedt om de data te vinden en te verkrijgen die ze nodig hebben, terwijl de nodige controle over het gebruik van die data wordt gegarandeerd door verantwoordelijkheid te introduceren voor de source-aligned domeinen om dataproducten te leveren die direct bij de bron kunnen worden gebruikt. Voor meer informatie, zie: Hoe JPMorgan Chase een data mesh-architectuur heeft gebouwd om aanzienlijke waarde te genereren om hun enterprise data-platform te verbeteren.
• Daarna hebben we ons gericht op het technische deel dat verband houdt met het bouwen van dataproducten, selfservice-analyse en federatieve computationele governance-principes. De auteurs beschreven de belangrijkste AWS-services die de source-aligned domeinen in staat stellen om dataproducten te bouwen en te delen, een breed scala aan services die de consument-aligned domeinen in staat stellen om dataproducten op verschillende manieren te consumeren op basis van hun voorkeurstools en de use cases die ze gebruiken. werken aan, en ten slotte, de AWS-services die de procedure voor het delen van gegevens regelen door het afdwingen van beleid voor gegevenstoegang. Voor meer informatie, zie: Ontwerp een data mesh-architectuur met behulp van AWS Lake Formation en AWS Glue.
• We lieten ook een oplossing zien om gegevensdetectie en toegangscontrole te automatiseren via een gecentraliseerde gebruikersinterface voor datamesh. Voor meer details, zie: Bouw een workflow voor het delen van gegevens met AWS Lake Formation voor uw datamesh.

Gebruiksscenario voor financiële diensten

Grote financiële dienstverleners hebben doorgaans meerdere LoB's, zoals consumentenbankieren, investeringsbankieren en vermogensbeheer, en ook een of meer analyse- en ML CoE-teams. Elke LoB biedt verschillende diensten aan:

• De LoB voor consumentenbankieren biedt een verscheidenheid aan diensten aan consumenten en bedrijven, waaronder kredieten en hypotheken, contant geldbeheer, betalingsoplossingen, deposito- en beleggingsproducten, en meer
• De commerciële of investeringsbank LoB biedt uitgebreide financiële oplossingen, zoals leningen, faillissementsrisico's en groothandelsbetalingen aan klanten, waaronder kleine bedrijven, middelgrote bedrijven en grote bedrijven
• De LoB voor vermogensbeheer biedt pensioenproducten en beleggingsdiensten voor alle activaklassen

Elke LoB definieert zijn eigen dataproducten, die worden samengesteld door mensen die de data begrijpen en die het meest geschikt zijn om te specificeren wie geautoriseerd is om deze te gebruiken en hoe deze kan worden gebruikt. Daarentegen zijn andere LoB's en applicatiedomeinen, zoals analytics en ML CoE, geïnteresseerd in het ontdekken en consumeren van gekwalificeerde dataproducten, deze samen te voegen om inzichten te genereren en datagestuurde beslissingen te nemen.

De volgende afbeelding toont enkele LoB's en voorbeelden van gegevensproducten die ze kunnen delen. Het toont ook de consumenten van dataproducten zoals analytics en ML CoE, die ML-modellen bouwen die kunnen worden ingezet in klantgerichte applicaties om de ervaring van de eindklant verder te verbeteren.

Volgens het socio-technische concept van data mesh, beginnen we met het sociale aspect met een reeks organisatorische stappen, zoals de volgende:

• Domeinexperts gebruiken om grenzen voor elk domein te definiëren, zodat elk dataproduct kan worden toegewezen aan een specifiek domein
• Eigenaren identificeren voor dataproducten die vanuit elk domein worden geleverd, zodat elk dataproduct een strategie heeft die is gedefinieerd door de eigenaar
• Het identificeren van governancebeleid van wereldwijde en lokale of gefedereerde incentives, zodat wanneer dataconsumenten toegang krijgen tot een specifiek dataproduct, het toegangsbeleid dat aan het product is gekoppeld automatisch kan worden afgedwongen via een centrale datagovernancelaag

Vervolgens gaan we naar het technische aspect, dat het volgende end-to-end-scenario omvat dat in het vorige diagram is gedefinieerd:

1. Geef de LoB van consumentenbankieren de middelen om een ​​kant-en-klaar product voor consumentenkredietprofielgegevens te bouwen.
2. Laat de LoB voor consumentenbankieren dataproducten delen in de centrale bestuurslaag.
3. Integreer wereldwijde en gefedereerde definities van beleid voor gegevenstoegang dat moet worden afgedwongen bij toegang tot het gegevensproduct voor consumentenkredietprofielen via het centrale gegevensbeheer.
4. Laat de analyses en ML CoE het dataproduct ontdekken en openen via de centrale bestuurslaag.
5. Geef analyses en ML CoE tools om het dataproduct te gebruiken voor het bouwen en trainen van een voorspellingsmodel voor kredietrisico's. We behandelen de laatste stappen (6 en 7 in het voorgaande diagram) in deze serie niet. Om echter de zakelijke waarde te laten zien die een dergelijk ML-model kan opleveren voor de organisatie in een end-to-end scenario, illustreren we het volgende:
6. Dit model kan later weer worden geïmplementeerd in klantgerichte systemen, zoals een webportaal voor consumentenbankieren of een mobiele applicatie.
7. Het kan specifiek worden gebruikt binnen de kredietaanvraag om het risicoprofiel van krediet- en hypotheekaanvragen te beoordelen.

Vervolgens beschrijven we de technische behoeften van elk van de componenten.

Diepe duik in technische behoeften

Om dataproducten voor iedereen beschikbaar te maken, moeten organisaties het gemakkelijk maken om gegevens tussen verschillende entiteiten in de organisatie te delen en tegelijkertijd de juiste controle erover te behouden, of met andere woorden, om wendbaarheid in evenwicht te brengen met goed bestuur.

Gegevensconsument: Analytics en ML CoE

De dataconsumenten zoals datawetenschappers van de analytics en ML CoE moeten het volgende kunnen:

• Ontdek en krijg toegang tot relevante datasets voor een bepaalde use case
• Vertrouw erop dat de datasets waartoe ze toegang willen hebben, al zijn samengesteld, up-to-date zijn en een robuuste beschrijving hebben
• Toegang vragen tot datasets die van belang zijn voor hun businesscases
• Gebruik hun favoriete tools om dergelijke datasets binnen hun omgeving te doorzoeken en te verwerken voor ML zonder de noodzaak om gegevens te repliceren van de oorspronkelijke externe locatie of om je zorgen te maken over technische of infrastructurele complexiteiten die samenhangen met het verwerken van gegevens die fysiek zijn opgeslagen op een externe locatie
• Ontvang een melding van eventuele gegevensupdates door de gegevenseigenaren

Gegevensproducent: Domeineigendom

De gegevensproducenten, zoals domeinteams van verschillende LoB's in de financiële dienstverleningsorganisatie, moeten beheerde datasets registreren en delen die het volgende bevatten:

• Technische en operationele metadata, zoals database- en tabelnamen en -groottes, kolomschema's en sleutels
• Zakelijke metadata zoals gegevensbeschrijving, classificatie en gevoeligheid
• Metadata volgen, zoals schema-evolutie van de bron naar de doelvorm en eventuele tussenvormen
• Metadata van gegevenskwaliteit, zoals correctheids- en volledigheidsratio's en gegevensbias
• Toegangsbeleid en procedures

Deze zijn nodig om dataconsumenten in staat te stellen data te ontdekken en te openen zonder te vertrouwen op handmatige procedures of contact op te nemen met de domeinexperts van het dataproduct om meer kennis te krijgen over de betekenis van de data en hoe deze toegankelijk zijn.

Gegevensbeheer: vindbaarheid, toegankelijkheid en controleerbaarheid

Organisaties moeten een evenwicht vinden tussen de eerder geïllustreerde wendbaarheid en de juiste beperking van de risico's die gepaard gaan met datalekken. Met name in gereguleerde sectoren zoals de financiële dienstverlening, is er behoefte aan centraal gegevensbeheer om algemene gegevenstoegang en controlecontrole te bieden en tegelijkertijd de opslagvoetafdruk te verkleinen door meerdere kopieën van dezelfde gegevens op verschillende locaties te vermijden.

In traditionele gecentraliseerde data lake-architecturen publiceren de dataproducenten vaak onbewerkte data en dragen ze de verantwoordelijkheid voor datacuratie, datakwaliteitsbeheer en toegangscontrole over aan data- en infrastructuuringenieurs in een gecentraliseerd dataplatformteam. Deze dataplatformteams zijn echter mogelijk minder bekend met de verschillende datadomeinen en vertrouwen nog steeds op ondersteuning van de dataproducenten om de toegang tot data correct te kunnen beheren en beheren volgens het beleid dat in elk datadomein wordt afgedwongen. Daarentegen zijn de dataproducenten zelf het best gepositioneerd om samengestelde, gekwalificeerde data-assets te leveren en zijn ze zich bewust van het domeinspecifieke toegangsbeleid dat moet worden afgedwongen bij het verkrijgen van toegang tot data-assets.

Overzicht oplossingen

Het volgende diagram toont de architectuur op hoog niveau van de voorgestelde oplossing.

We pakken het dataverbruik door de analytics en ML CoE aan met: Amazone Athene en Amazon Sage Maker in deel 2 van deze serie.

In dit bericht richten we ons op het data-onboardingproces in het datamesh en beschrijven we hoe een individuele LoB, zoals het datateam voor consumentenbankieren, AWS-tools kan gebruiken zoals AWS lijm en AWS lijm DataBrew om de kwaliteit van hun dataproducten voor te bereiden, te beheren en te verbeteren, en deze dataproducten vervolgens te registreren in het centrale datagovernance-account via AWS Lake-formatie.

Consumentenbankieren LoB (gegevensproducent)

Een van de kernprincipes van data mesh is het concept van data als product. Het is erg belangrijk dat het datateam van het domein voor consumentenbankieren werkt aan het voorbereiden van dataproducten die klaar zijn voor gebruik door dataconsumenten. Dit kan worden gedaan door AWS-tools voor extraheren, transformeren en laden (ETL) zoals AWS Glue te gebruiken om onbewerkte gegevens te verwerken die zijn verzameld op Amazon eenvoudige opslagservice (Amazon S3), of maak verbinding met de operationele gegevensopslag waar de gegevens worden geproduceerd. Je kan ook gebruiken DataBrouwen, een visuele datavoorbereidingstool zonder code waarmee u eenvoudig gegevens kunt opschonen en normaliseren.

Tijdens het voorbereiden van het gegevensproduct voor het consumentenkredietprofiel kan het domeingegevensteam van het consumentenbankieren bijvoorbeeld een eenvoudige bewerking maken om de attribuutnamen van de onbewerkte gegevens die zijn opgehaald uit de open-sourcegegevensset van het Duits naar het Engels te vertalen. Statlog Duitse kredietgegevens, die uit 20 attributen en 1,000 rijen bestaat.

Gegevensbeheer

De belangrijkste AWS-service voor het inschakelen van data mesh-governance is Lake Formation. Lake Formation biedt de mogelijkheid om gegevensbeheer binnen elk gegevensdomein en tussen domeinen af ​​te dwingen om ervoor te zorgen dat gegevens gemakkelijk vindbaar en veilig zijn. Het biedt een federatief beveiligingsmodel dat centraal kan worden beheerd, met best practices voor gegevensontdekking, beveiliging en naleving, terwijl een hoge flexibiliteit binnen elk domein mogelijk is.

Lake Formation biedt een API om de manier waarop gegevens worden opgenomen, opgeslagen en beheerd te vereenvoudigen, samen met beveiliging op rijniveau om uw gegevens te beschermen. Het biedt ook functionaliteit zoals gedetailleerd toegangscontrole, beheerde tabellen en opslagoptimalisatie.

Daarnaast biedt Lake Formations a API voor het delen van gegevens die u kunt gebruiken om gegevens te delen over verschillende accounts. Hierdoor kunnen de Analytics- en ML CoE-consumenten Athena-query's uitvoeren die tabellen opvragen en samenvoegen in meerdere accounts. Raadpleeg voor meer informatie de AWS Lake Formation-ontwikkelaarsgids.

AWS Resource Access Manager (AWS RAM) biedt een veilige manier om bronnen te delen via AWS Identiteits- en toegangsbeheer (IAM) rollen en gebruikers in AWS-accounts binnen een organisatie of organisatie-eenheden (OE's) in AWS-organisaties.

Lake Formation biedt samen met AWS RAM een manier om het delen van gegevens en toegang tussen AWS-accounts te beheren. Deze benadering noemen we RAM-gebaseerde toegangscontrole. Voor meer details over deze aanpak, zie: Bouw een workflow voor het delen van gegevens met AWS Lake Formation voor uw datamesh.

Lake Formation biedt ook een andere manier om het delen en openen van gegevens te beheren met behulp van Lake Formation-tags. Deze benadering noemen we op tags gebaseerde toegangscontrole. Voor meer details, zie: Bouw een moderne data-architectuur en data mesh-patroon op schaal met behulp van AWS Lake Formation op tags gebaseerde toegangscontrole.

In dit bericht gebruiken we de op tags gebaseerde benadering voor toegangsbeheer, omdat het het maken van beleid voor een kleiner aantal logische tags die vaak in verschillende LoB's worden aangetroffen, vereenvoudigt in plaats van beleid op benoemde bronnen op infrastructuurniveau te specificeren.

Voorwaarden

Voor het opzetten van een data mesh-architectuur heb je minimaal drie AWS-accounts nodig: een producentenaccount, een centraal account en een consumentenaccount.

De data mesh-omgeving implementeren

Om een ​​data mesh-omgeving te implementeren, kunt u het volgende gebruiken: GitHub-repository. Deze repository bevat drie AWS CloudFormatie sjablonen die een data mesh-omgeving implementeren die elk van de accounts bevat (producent, centrale en consument). Binnen elk account kunt u de bijbehorende CloudFormation-sjabloon uitvoeren.

Centrale rekening

Voer in het centrale account de volgende stappen uit:

1. Start de CloudFormation-stapel:
   
2. Maak twee IAM-gebruikers aan:
   1. DataMeshOwner
   2. ProducerSteward
3. Grant DataMeshOwner als de Lake Formation-beheerder.
4. Maak één IAM-rol aan:
   1. LFRegisterLocationServiceRole
5. Maak twee IAM-beleidsregels:
   1. ProducerStewardPolicy
   2. S3DataLakePolicy
6. Maak de database-creditcard voor ProducerSteward op de producentenrekening.
7. Deel de toestemming voor de gegevenslocatie met het producentenaccount.

Producentenaccount

Voer in het producentenaccount de volgende stappen uit:

1. Start de CloudFormation-stapel:
   
2. Maak de S3-bucket credit-card, die de tafel vasthoudt credit_card.
3. Sta S3-buckettoegang toe voor de centrale account Lake Formation-servicerol.
4. Maak de AWS Glue-crawler creditCrawler-<ProducerAccountID>.
5. Maak een AWS Glue-crawlerservicerol.
6. Verleen machtigingen op de S3-bucketlocatie credit-card-<ProducerAccountID>-<aws-region> naar de rol van de AWS Glue-crawler.
7. Maak een producer steward IAM-gebruiker.

Consumentenaccount

Voer in het consumentenaccount de volgende stappen uit:

1. Start de CloudFormation-stapel:
   
2. Maak de S3-bucket <AWS Account ID>-<aws-region>-athena-logs.
3. De Athena-werkgroep maken consumer-workgroup.
4. Maak de IAM-gebruiker aan ConsumerAdmin.

Voeg een database toe en abonneer het consumentenaccount erop

Nadat u de sjablonen hebt uitgevoerd, kunt u de stap-voor-stap handleiding om een ​​product toe te voegen aan de datacatalogus en de consument erop te laten abonneren. De gids begint met het opzetten van een database waar de producent zijn producten kan plaatsen en legt vervolgens uit hoe de consument zich op die database kan abonneren en toegang kan krijgen tot de gegevens. Dit alles wordt uitgevoerd tijdens het gebruik van LF-tags, welke is de op tags gebaseerde toegangscontrole voor Lake Formation.

Gegevens productregistratie

De volgende architectuur beschrijft de gedetailleerde stappen van hoe het LoB-team voor consumentenbankieren, dat optreedt als gegevensproducenten, hun gegevensproducten kan registreren in de centrale gegevensbeheeraccount (aan boord van gegevensproducten aan de data-mesh van de organisatie).

De algemene stappen om een ​​dataproduct te registreren zijn als volgt:

1. Maak een doeldatabase voor het gegevensproduct in het centrale beheeraccount. De CloudFormation-sjabloon van het centrale account maakt bijvoorbeeld al de doeldatabase aan credit-card.
2. Deel de aangemaakte doeldatabase met de oorsprong in het producentenaccount.
3. Maak een bronkoppeling van de gedeelde database in het producentenaccount. In de volgende schermafbeelding zien we op de Lake Formation-console in het producentenaccount dat: rl_credit-card is de bronlink van de credit-card database.
   
4. Vul tabellen in (met de gegevens die zijn samengesteld in het producentenaccount) in de resourcelink-database (rl_credit-card) met behulp van een AWS Glue-crawler in het producentenaccount.
   

De aangemaakte tabel verschijnt automatisch in het centrale beheeraccount. De volgende schermafbeelding toont een voorbeeld van de tabel in Lake Formation in het centrale account. Dit is na het uitvoeren van de eerdere stappen om de database met bronlinks te vullen rl_credit-card in het producentenaccount.

Conclusie

In deel 1 van deze serie bespraken we de doelen van financiële dienstverleners om meer wendbaarheid voor hun analyse- en ML-teams te bereiken en de tijd van data naar inzichten te verkorten. We hebben ons ook gericht op het bouwen van een data mesh-architectuur op AWS, waar we gebruiksvriendelijke, schaalbare en kosteneffectieve AWS-services hebben geïntroduceerd, zoals AWS Glue, DataBrew en Lake Formation. Dataproducerende teams kunnen deze services gebruiken om samengestelde, hoogwaardige, interoperabele en veilige dataproducten te bouwen en te delen die klaar zijn voor gebruik door verschillende dataconsumenten voor analytische doeleinden.

In deel 2, richten we ons op analyse- en ML CoE-teams die gegevensproducten gebruiken die worden gedeeld door de LoB voor consumentenbankieren om een ​​voorspellingsmodel voor kredietrisico's te bouwen met behulp van AWS-services zoals Athena en SageMaker.

---

Over de auteurs

Karim Hammouda is Specialist Solutions Architect for Analytics bij AWS met een passie voor data-integratie, data-analyse en BI. Hij werkt samen met AWS-klanten om analyseoplossingen te ontwerpen en te bouwen die bijdragen aan hun bedrijfsgroei. In zijn vrije tijd kijkt hij graag tv-documentaires en speelt hij graag videogames met zijn zoon.

Hassan Poonawala is Senior AI/ML Specialist Solutions Architect bij AWS, Hasan helpt klanten bij het ontwerpen en implementeren van machine learning-applicaties in productie op AWS. Hij heeft meer dan 12 jaar werkervaring als datawetenschapper, beoefenaar van machine learning en softwareontwikkelaar. In zijn vrije tijd houdt Hasan ervan om de natuur te verkennen en tijd door te brengen met vrienden en familie.

Benoït de Patoul is een AI/ML Specialist Solutions Architect bij AWS. Hij helpt klanten door begeleiding en technische assistentie te bieden bij het bouwen van oplossingen met betrekking tot AI/ML met behulp van AWS. In zijn vrije tijd speelt hij graag piano en brengt hij tijd door met vrienden.