Dela via


Ett scenario för finansinstitut för Data Mesh

Det här scenariot gäller för kunder som vill använda analys i molnskala för skalbarhet och datanät arkitekturer. Det visar ett komplext scenario med landningszoner, dataintegreringar och dataprodukter.

Kundprofil

Ett fiktivt företag, Woodgrove Bank, är ett stort företag inom finansiella tjänster med ett globalt fotavtryck. Woodgrove Banks data finns i lokala och molnbaserade distributionssystem. Inom Woodgrove Bank-arkitekturen finns det flera informationslagersystem för konsoliderad marknadsföring och integrerad rapportering. Den här arkitekturen innehåller flera datasjöar för oplanerad analys och dataidentifiering. Woodgrove Bank-program är sammankopplade via programintegreringsmönster, som till största delen är API-baserade eller händelsebaserade.

Den aktuella situationen

Det är svårt för Woodgrove Bank att distribuera data till olika platser på grund av komplexiteten i datalagerhantering. Det är tidskrävande att integrera nya data och det är frestande att duplicera data. Woodgrove Bank har svårt att övervaka datalandskapet från slutpunkt till slutpunkt på grund av punkt-till-punkt-anslutning. Banken underskattade efterfrågan på intensiv dataförbrukning. Nya användningsfall introduceras snabbt, en efter en. Datastyrning, till exempel dataägarskap och kvalitet, och kostnader är svåra att kontrollera. Att hålla sig uppdaterad med regler är svårt eftersom Woodgrove Bank inte vet exakt var dess data finns.

Arkitekturlösning: Data Mesh

Under de senaste åren har organisationer uppmärksammat att data är kärnan i allt. Data öppnar nya effektivitetsvinster, driver innovation, låser upp nya affärsmodeller och ökar kundnöjdheten. Det är högsta prioritet för företag att använda datadrivna metoder, till exempel data i stor skala.

Det är svårt att nå ett stadium där det djupare värdet av data är tillgängligt för alla organisationsmedlemmar. Äldre och nära sammankopplade system, centraliserade monolitiska plattformar och komplex styrning kan vara betydande hinder för att generera värde ur data.

Om Data Mesh

Begreppet datanät, en term som myntas av Zhamak Dehghani, omfattar data, teknik, processer och organisation. Konceptuellt är det en tillgänglig metod för att hantera data där olika domäner använder sina egna data. Data mesh utmanar idén om konventionell centralisering av data. I stället för att titta på data som en stor lagringsplats tar data mesh hänsyn till nedbrytningen av oberoende dataprodukter. Det här skiftet, från centraliserat till federerat ägande, stöds av en modern dataplattform med självbetjäning som vanligtvis är utformad med hjälp av molnbaserade tekniker.

När du delar upp datanätskonceptet i byggstenar kan du tänka på följande:

  • Data som produkt: Varje domän (organisationsdomän) hanterar sina data från början till slut. Ansvar ligger hos dataägaren i domänen. Pipelines blir ett förstklassigt problem för själva domänerna.
  • Federated Computational Data Governance: För att säkerställa att varje dataägare kan lita på de andra och dela sina dataprodukter måste ett organ för företagsdatastyrning upprättas. Styrningsorganet implementerar datakvalitet, central synlighet för dataägarskap, hantering av dataåtkomst och principer för datasekretess.
  • Domain-Oriented dataägarskap: Företaget bör helst definiera och modellera varje datadomännod i nätet genom att tillämpa principerna för domänorienterad design.
  • Self-Serve Data Platform: Ett datanät kräver en dataplattform med självbetjäning som gör att användarna kan ta bort den tekniska komplexiteten och fokusera på sina enskilda dataanvändningsfall.

Cloud-Scale Analytics

Data som en produkt-tänkande och en plattformsmodell med självbetjäning är inte nya för Microsoft. Microsoft observerade bästa praxis för distribuerade plattformar, pipelines över domäner, federerat ägande och självförklarande data under många år.

Woodgrove Bank kan övergå till datanät med hjälp av analys i molnskala. Analys i molnskala är en plan med öppen källkod och en normativ skiss för att utforma och snabbt distribuera moderna dataplattformar. Det är kopplat till Metodtips och designprinciper för Azure och är i linje med Azure Well-Architected Framework. Analys i molnskala ger företag en 80-procentig föreskriven synvinkel och de återstående 20 procenten är anpassningsbara.

Analys i molnskala erbjuder företag en strategisk designväg mot datanät och kan användas för att snabbt konfigurera en sådan arkitektur. Den erbjuder en skiss, inklusive grundläggande dataplattformstjänster för datahantering.

På den högsta nivån använder molnskalningsanalys en datahanteringsfunktion som är aktiverad via landningszonen för datahantering. Den här zonen ansvarar för federerad datastyrning för en organisation av (självbetjäningsplattformen) och de datadomäner som driver affärsvärde via dataprodukter. Fördelen med den här metoden är att den tar bort den tekniska komplexiteten samtidigt som den följer samma standarder. Det säkerställer att det inte finns någon spridning av teknik. Det gör det också möjligt för företag att börja modulärt, med ett litet fotavtryck och sedan växa med tiden.

Landningszonen för datahantering, som du kan se i följande diagram, omger alla datadomäner. Det limmar samman alla domäner och ger den översikt som Woodgrove Bank letar efter.

diagram som visar hur datanät intelligent distribuerar dataprodukter mellan datadomäner.

Analys i molnskala förespråkar också tillämpning av konsekvent styrning som använder en gemensam arkitektur när dataprodukter distribueras. Ramverket tillåter direkt kommunikation mellan domäner. Den förblir i kontroll genom att fokusera på central katalogisering och klassificering för att skydda data och tillåta grupper att identifiera data. Det placerar ett paraply ovanpå ditt dataekosystem.

Datadomäner

När du använder analys i molnskala som en strategisk väg måste du tänka på nedbrytningen av din arkitektur och den resulterande kornigheten. Data mesh bryter ner data genom att inte följa teknikens gränser. I stället tillämpas principerna för domändriven design (DDD), en metod för programvaruutveckling som omfattar komplexa system för större organisationer. DDD är populärt på grund av dess effekt på moderna metoder för programutveckling, till exempel mikrotjänster.

Ett av mönstren från domändriven design kallas begränsad kontext. Avgränsade kontexter anger de logiska gränserna för en domäns lösningsutrymme för att bättre hantera komplexiteten. Det är viktigt att teamen förstår vilka aspekter, inklusive data, som de kan ändra och vilka som är delade beroenden som kräver samordning med andra. Data mesh omfattar avgränsad kontext. Det använder det här mönstret för att beskriva hur organisationer kan samordna datadomäner och fokusera på att leverera data som en produkt. Varje datadomän äger och driver flera dataprodukter med sin egen teknikstack, som är oberoende av de andra.

diagram som visar datanätarkitekturen.

Dataprodukter

När du zoomar in på den inre arkitekturen för en sådan datadomän förväntar du dig att hitta dataprodukter i den.

Dataprodukter uppfyller ett specifikt behov inom företag som använder data. Dataprodukter hanterar, organiserar och beskriver data mellan domäner och presenterar sedan de insikter de fått. En dataprodukt är resultatet av data från en eller flera dataintegreringar eller andra dataprodukter. Dataprodukter är nära anpassade till datadomäner och ärver samma konstruerade, formaliserade språk som intressenter och designers kommit överens om. Varje domän som genererar data ansvarar för att göra dessa dataprodukter tillgängliga för de andra domänerna.

För att snabbt kunna leverera dataprodukter erbjuder analys i molnskala mallar för datadistribution och integreringsmönster. Ramverket tillhandahåller databatch, strömning och analys för att tillgodose behoven hos olika konsumenter.

En bra sak med analys i molnskala är hur domäner och dataprodukter organiseras. Varje datadomän överensstämmer med en datalandningszon, vilket är en logisk konstruktion och en skalningsenhet i analysarkitekturen i molnskala. Det möjliggör datalagring och körning av databelastningar, vilket genererar insikter och värde. Varje dataprodukt överensstämmer med en resursgrupp i datalandningszonen och alla datalandningszoner och hanteringszoner överensstämmer med prenumerationer. Den här metoden underlättar implementering och hantering.

Alla analysmallar i molnskala ärver samma uppsättning principer från landningszonen för datahantering. Mallarna levererar automatiskt nödvändiga metadata för dataidentifiering, styrning, säkerhet, kostnadshantering och driftseffektivitet. Du kan snabbt registrera nya datadomäner utan att behöva komplexa registreringar, integrering och testning.

Följande diagram visar hur en dataprodukt kan se ut:

Diagram över en datadomän som innehåller en dataprodukt.

En pragmatisk metod för att skapa dataprodukter är att antingen anpassa sig till källan, var data kommer ifrån eller med användningsfallet. I båda fallen måste du tillhandahålla en abstrakt vy över den underliggande (komplexa) programdatamodellen. Du måste försöka dölja den tekniska informationen och optimera för intensiv dataförbrukning. En Azure Synapse-vy eller Parquet-fil, som logiskt grupperar data tillsammans, är ett exempel på hur en dataprodukt kan delas mellan olika datadomäner.

Därefter måste du arbeta med dataidentifiering, härkomst, användning och ursprung. En beprövad metod är att använda en datastyrningstjänst, till exempel Microsoft Purview, för att registrera alla data. Dataintegrering i analys i molnskala ansluter perfekt punkterna eftersom det gör det möjligt att skapa dessa dataprodukter samtidigt som metadataregistreringen utförs.

Genom att justera datadomäner och Microsoft Purview-samlingar samlar du automatiskt in all information om data ursprung, ursprung, datakvalitet och förbrukningsinformation från de enskilda domänerna. Med den här metoden kan du ansluta flera datadomäner och produkter till en centraliserad styrningslösning som lagrar alla metadata från varje miljö. Fördelen är att den integrerar alla metadata centralt och gör den lättillgänglig för olika konsumenter. Du kan utöka den här arkitekturen för att registrera nya dataprodukter.

Följande diagram illustrerar en arkitektur för datanät mellan domäner som använder analys i molnskala.

diagram som visar dataintegrering.

Nätverksdesignen gör att dataprodukter kan delas mellan domäner med minimal kostnad och eliminera en enda fel- och bandbreddsbegränsning. För att säkerställa säkerheten kan du använda säkerhetsmodellen Microsoft Zero Trust. I analys i molnskala föreslås användning av nätverksisolering via privata slutpunkter och privat nätverkskommunikation, en identitetsdriven dataåtkomstmodell som använder MIs, UMIs och kapslade säkerhetsgrupper, enligt principen om lägsta behörighet.

Du kan använda hanterade identiteter för att säkerställa att en modell för åtkomst med minst behörighet följs. Program och tjänster i den här modellen har begränsad åtkomst till dataprodukter. Azure-principer, med kommande dataprinciper, används för att aktivera självbetjäning och framtvinga kompatibla resurser i alla dataprodukter i stor skala. Med den här designen kan du ha enhetlig dataåtkomst samtidigt som du har fullständig kontroll via centraliserad datastyrning och granskning.

diagram som illustrerar ett datakontrakt.

Utvecklas mot framtiden

Analys i molnskala är utformad med datanät i åtanke. Analys i molnskala är en beprövad metod där organisationer kan dela data över många datadomäner. Det här ramverket gör det möjligt för domäner att ha självständighet att göra val och det styr arkitekturen genom att avgränsa den med datahanteringstjänster.

När du implementerar datanät grupperar och organiserar du dina domäner logiskt. Den här metoden kräver en företagsvy och är sannolikt ett kulturellt skifte för din organisation. Skiftet kräver att du federerar dataägarskapet mellan datadomäner och ägare som ansvarar för att tillhandahålla sina data som produkter. Det kräver också att teamen följer de centraliserade funktioner som erbjuds av landningszonen för datahantering. Den här nya metoden kan kräva att enskilda team ger upp sina nuvarande mandat, vilket sannolikt kommer att generera motstånd. Du kan behöva göra vissa politiska val och hitta en balans mellan centraliserade och decentraliserade metoder.

Du kan skala en datanätarkitektur genom att lägga till fler landningszoner i arkitekturen för enskilda domäner. Dessa landningszoner använder virtuell nätverkspeering och ansluter till landningszonen för datahantering samt alla andra landningszoner. Med det här mönstret kan du dela dataprodukter och resurser mellan zoner. När du delar upp dig i separata zoner kan du sprida arbetsbelastningar mellan Azure-prenumerationer och resurser. Med den här metoden kan du implementera datanätet organiskt.

Lära sig mer

Microsoft-resurser:

Artikel av data mesh-grundaren Zhamak Dehghani: