Skala analys på molnnivå i Azure
En skalbar dataplattform är viktig för att ta emot den snabba tillväxten av data. Stora mängder data genereras varje sekund runt om i världen. Mängden tillgängliga data förväntas fortsätta att växa exponentiellt under de närmaste åren. I takt med att datagenereringen ökar ökar också hastigheten på dataflytten.
Oavsett hur mycket data du har kräver användarna snabba frågesvar. De förväntar sig att vänta minuter, inte timmar, på resultat. Den här artikeln beskriver hur du kan skala din Azure-analyslösning i molnskala och fortsätta att uppfylla användarnas krav på hastighet.
Introduktion
Många företag har stora dataplattformsmonoliter. Dessa monoliter bygger på ett enda Azure Data Lake Gen2-konto och ibland en enda lagringscontainer. En enda Azure-prenumeration används ofta för alla dataplattformsrelaterade uppgifter. Skalning på prenumerationsnivå saknas på de flesta arkitekturplattformar, vilket kan hindra fortsatt Azure-implementering om användarna stöter på någon av de Azure-prenumerationer eller begränsningar på tjänstnivå. Även om vissa av begränsningarna är mjuka gränser kan det fortfarande ha en betydande negativ effekt på din dataplattform om du når dem.
När du strukturerar din dataplattform bör du tänka på organisationens struktur. Observera dataägarskapet och funktionsansvaret för dina team. Om din organisation ger teamen stora grader av självbestämmande och distribuerat ägarskap är en datanätsarkitektur det bästa alternativet.
Undvik situationer där olika team ansvarar för olika uppgifter i en lösning – uppgifter som inmatning, rensning, aggregering och servering. Beroende på flera team kan orsaka en dramatisk hastighetsförlust. Om dina datakonsumenter på det betjänande lagret till exempel behöver registrera nya datatillgångar eller implementera funktionella ändringar för en viss datatillgång måste de genomgå en process i flera steg. I det här exemplet är stegen:
- Datakonsumenten skickar en biljett till alla team som ansvarar för en datapipelinefas.
- Teamen måste arbeta tillsammans i synkronisering eftersom lagren är sammankopplade. De nya tjänsterna kräver ändringar i datarensningslagret, vilket leder till ändringar i dataaggregeringslagret, vilket leder till ändringar i serveringslagret. Ändringarna kan påverka varje pipelinesteg.
- Det är svårt för teamen att se de potentiella effekterna av bearbetningsändringar eftersom de inte har en översikt över hela livscykeln från slutpunkt till slutpunkt. De måste samarbeta för att utforma en väldefinierad lanseringsplan som minimerar effekterna på befintliga konsumenter och pipelines. Den här beroendehanteringen ökar hanteringskostnaderna.
- Teamen är i regel inte ämnesexperter på datatillgången som datakonsumenten begär. För att förstå nya datamängdsfunktioner eller parametervärden måste de kontakta en expert.
- När alla ändringar har implementerats meddelas datakonsumenten att den nya datatillgången är redo att användas.
Varje stor organisation har tusentals datakonsumenter. En komplicerad process som den som beskrivs minskar kraftigt hastigheten i stora arkitekturer eftersom centraliserade team blir en flaskhals för affärsenheter. Resultatet är mindre innovation och begränsad effektivitet. Affärsenheter kan eventuellt välja att lämna tjänsten och skapa en egen dataplattform i stället.
Metoder för skalning
Analys i molnskala hanterar skalningsutmaningar med hjälp av två grundläggande begrepp:
- Datalandningszoner för skalning
- Dataprodukter eller dataintegreringar för skalning för att göra distribuerat och decentraliserat dataägarskap möjligt
Du kan distribuera en enda datalandningszon eller flera. Med datalandningszoner kan du identifiera och hantera data genom att ansluta till en landningszon för datahantering. Varje landningszon för datahantering finns i en enda Azure-prenumeration.
Prenumerationer är Azures enheter för hantering, fakturering och skalning. De spelar en viktig roll i din storskaliga Azure-implementeringsplan.
Skalning med datalandningszoner
De centrala begreppen för analys i molnskala är Microsoft Purview, Azure Databricks Unity Catalog om du använder Azure Databricks, en landningszon för datahantering och datalandningszonen. Du bör placera var och en i en egen Azure-prenumeration. Genom att separera dem kan du tydligt avgränsa uppgifter, följa principen om minsta behörighet och delvis åtgärda de problem med prenumerationsskala som nämnts tidigare. En minimal analyskonfiguration i molnskala innehåller en enda datalandningszon och en enda landningszon för datahantering.
En minimal konfiguration räcker dock inte för storskaliga distributioner av dataplattformar. Företag skapar storskaliga plattformar och gör investeringar för att konsekvent och effektivt skala sina data- och analysinsatser över tid. För att övervinna begränsningar på prenumerationsnivå använder molnskalningsanalys prenumerationer som skalningsenhet, enligt beskrivningen i Azure-landningszoner. Den här tekniken gör det möjligt att öka fotavtrycket för dataplattformen genom att lägga till fler datalandningszoner i arkitekturen. Genom att använda den här tekniken åtgärdas också problemet med att en Azure Data Lake Gen2 används för en hel organisation eftersom varje datalandningszon innehåller tre datasjöar. Projekt och aktiviteter från flera domäner kan distribueras i fler än en Azure-prenumeration, vilket ger större skalbarhet.
Bestäm hur många datalandningszoner din organisation behöver innan du implementerar en analysarkitektur i molnskala. Genom att välja rätt lösning skapas grunden för en effektiv och effektiv dataplattform.
Antalet datalandningszoner som krävs beror på många faktorer, särskilt:
- Organisationsjustering, till exempel hur många affärsenheter som behöver en egen datalandningszon
- Operativa överväganden, till exempel hur din organisation anpassar driftresurser och resurser som är specifika för en affärsenhet.
Med rätt datalandningszonmodell minimeras framtida ansträngningar för att flytta dataprodukter och datatillgångar från en landningszon till en annan. Det hjälper dig också att effektivt och konsekvent skala stordata och analysarbete i framtiden.
Tänk på följande faktorer när du bestämmer hur många datalandningszoner som ska distribueras.
| Faktor | Beskrivning |
|---|---|
| Organisationsstruktur och dataägarskap | Överväg hur din organisation är strukturerad och hur data ägs i din organisation. |
| Region och plats | Om du distribuerar i flera regioner bestämmer du vilka regioner som ska vara värdar för datazonerna. Säkerställ att alla krav på lagring av data uppfylls. |
| Kvoter | Prenumerationskvoter är inte kapacitetsgarantier och tillämpas per region. |
| Datasuveränitet | På grund av regler för datasuveränitet måste data lagras i en viss region och följa regionspecifika principer. |
| Azure-policys | Datalandningszoner måste följa kraven i olika Azure-principer. |
| Hanteringsgräns | Prenumerationer ger en hanteringsgräns för styrning och isolering som tydligt separerar problem. |
| Nätverkande | Varje landningszon har ett virtuellt nätverk. Eftersom ett virtuellt nätverk finns i en enda region kräver varje ny region en ny landningszon. De virtuella nätverken måste vara peer-virtuella nätverk för att möjliggöra kommunikation mellan domäner. |
| Gränser | En prenumeration har gränser. Genom att ha flera prenumerationer kan du minimera farorna med att nå dessa gränser. |
| Kostnadsallokering | Fundera på om delade tjänster som lagringskonton som betalas centralt måste delas upp av affärsenhet eller domän. Om du använder en separat prenumeration skapas en gräns för kostnadsallokering. Du kan uppnå samma funktioner med hjälp av taggar. |
| Dataklassificeringar och strikt konfidentiella data | Säkerhetsmekanismer kan påverka dataproduktutvecklingen och användbarheten för en dataplattform. Överväg dataklassificeringar och bestäm om strikt konfidentiella datauppsättningar kräver särskild behandling, till exempel just-in-time-åtkomst, kundhanterade nycklar (CMK), detaljerade nätverkskontroller eller mer kryptering. |
| Andra juridiska eller säkerhetsmässiga konsekvenser | Fundera på om det finns andra juridiska krav eller säkerhetskrav som kräver logisk eller fysisk uppdelning av data. |
Om du implementerar en datanätsarkitektur bör du tänka på följande faktorer när du bestämmer hur du ska distribuera dina datalandningszoner och datadomäner.
| Faktor | Beskrivning |
|---|---|
| Datadomäner | Överväg de datadomäner som din organisation använder och bestäm datadomänerna för din dataplattform. Överväg storleken på dina enskilda datadomäner. Mer information finns i Vad är datadomäner? |
| Fördröjning | Domäner som samarbetar med stora mängder data kan överföra en stor mängd data mellan landningszoner. Överväg att allokera dina domäner i samma landningszon eller region. Att separera dem ökar svarstiden och kan öka kostnaderna i domäner mellan regioner. |
| Säkerhet | Vissa tjänstdistributioner eller konfigurationer kräver utökade privilegier i en prenumeration. Att ge dessa behörigheter till en användare i en domän ger implicit användaren samma behörigheter i andra domäner inom samma prenumeration. |
Du hittar fler överväganden i vägledningen för ramverket för tillämpning av molnet för prenumerationer .
Många organisationer vill ha effektiv skalning av sin företagsdataplattform. Affärsenheter bör kunna skapa egna datalösningar och program för att uppfylla sina unika krav. Att tillhandahålla den här möjligheten kan vara en utmaning eftersom många befintliga dataplattformar inte bygger på begreppen skalbarhet och decentraliserat ägande. Den här bristen syns tydligt i arkitekturen, teamstrukturen och ops-modellen för dessa dataplattformar.
Datalandningszoner skapar inte datasilor i din organisation. Den rekommenderade nätverkskonfigurationen för analys i molnskala möjliggör säker och platsbaserad datadelning mellan landningszoner, vilket i sin tur möjliggör innovation mellan datadomäner och affärsenheter. Mer information finns i överväganden för nätverksarkitektur.
Detsamma gäller för identitetsskiktet. När du använder en enda Microsoft Entra-klient kan du ge identiteter åtkomst till datatillgångar i flera datalandningszoner. Mer information om processen för användar- och identitetsauktorisering finns i Dataåtkomsthantering.
Not
Om du har flera datalandningszoner kan varje zon ansluta till data som finns i andra zoner. På så sätt kan grupper samarbeta i hela verksamheten.
Analys i molnskala använder en gemensam arkitektur för att förespråka konsekvent styrning. Din arkitektur definierar baslinjefunktioner och principer. Alla datalandningszoner följer samma granskning och kontroller. Dina team kan skapa datapipelines, mata in källor och skapa dataprodukter som rapporter och instrumentpaneler. Teams kan också utföra Spark-/SQL-analys efter behov. Du kan utöka funktionerna i datalandningszonen genom att lägga till tjänster i policyn. Ett team kan till exempel lägga till en grafmotor från tredje part för att uppfylla ett affärsbehov.
Analys i molnskala lägger stor vikt vid central katalogisering och klassificering för att skydda data och göra det möjligt för olika grupper att identifiera dataprodukter.
Försiktighet
Vi rekommenderar att du inte kör frågor mot data över regioner. Kontrollera i stället att data ligger nära den beräkning som använder den, samtidigt som du respekterar regionala gränser.
Arkitektur för analys i molnskala och begreppet datalandningszoner gör det möjligt för din organisation att enkelt öka storleken på din dataplattform över tid. Du kan lägga till fler datalandningszoner i en stegvis metod. Dina kunder behöver inte ha flera landningszoner först. När du använder den här arkitekturen prioriterar du några datalandningszoner och de dataprodukter som de innehåller. Korrekt prioritering hjälper till att säkerställa att distributionen av analys i molnskala lyckas.
Skalning med dataprogram
Inom varje landningszon kan din organisation skala med hjälp av dataprogram. Dataprogram är enheter eller komponenter i din dataarkitektur som kapslar in funktioner som tillhandahåller läsoptimerade dataprodukter för förbrukning av andra dataprogram. I Azure är dataprogram miljöer i form av resursgrupper som gör det möjligt för korsfunktionella team att implementera datalösningar och arbetsbelastningar. Ett associerat team tar hand om datalösningens livscykel från slutpunkt till slutpunkt, vilket omfattar inmatning, rensning, aggregering och serveringsuppgifter.
Analys i molnskala hanterar de problem med dataintegrering och ansvar som diskuterades tidigare. I stället för monolitiska funktionella ansvarsområden för tabellinmatning och källsystemintegrering tillhandahåller referensdesignen en distribuerad arkitektur som drivs av datadomäner. Tvärfunktionella team tar över det funktionella ansvaret från början till slut och ägarskap över dataomfånget.
I stället för att ha en centraliserad teknisk stack och ett team som ansvarar för alla uppgifter i arbetsflödet för databearbetning kan du distribuera ansvar från slutpunkt till slutpunkt över flera autonoma korsfunktionella dataintegreringsteam. Varje team äger en domän- eller underdomänfunktion och uppmuntras att hantera datauppsättningar som krävs av datakonsumenter.
Dessa arkitekturskillnader leder till ökad hastighet på din dataplattform. Dina datakonsumenter behöver inte längre förlita sig på en uppsättning centraliserade team eller kämpa för att deras begärda ändringar ska prioriteras. När mindre team tar över ägarskapet för ditt integreringsarbetsflöde från slutpunkt till slutpunkt är feedbackloopen mellan dataleverantör och datakonsument kortare. Den här metoden resulterar i snabbare prioritering, snabbare utvecklingscykler och en mer flexibel utvecklingsprocess. Dina team behöver inte längre synkronisera processer och lanseringsplaner sinsemellan eftersom det korsfunktionella dataintegreringsteamet har full medvetenhet om den tekniska stacken från slutpunkt till slutpunkt och konsekvenserna av ändringar. Den kan använda programvaruteknikmetoder för att köra enhets- och integreringstester för att minimera den övergripande effekten på konsumenterna.
Helst äger teamet som äger dataintegreringssystemen också källsystemen. Det här teamet bör bestå av datatekniker som arbetar med källsystemen, ämnesexperter (SMF) för datauppsättningar, molntekniker och dataproduktägare. Att skapa den här typen av korsfunktionella team minskar mängden kommunikation som behövs med externa team och är viktigt när du utvecklar din fullständiga stack från infrastruktur till faktiska datapipelines.
Grunden för din dataplattform är datauppsättningar som är integrerade från källsystem. Dessa datauppsättningar gör det möjligt för dina dataproduktteam att förnya sig i faktatabeller för företag och förbättra beslutsfattandet och affärsprocesserna. Dina dataintegreringsteam och dataproduktteam bör erbjuda serviceavtal till konsumenter och se till att alla avtal uppfylls. De erbjudna serviceavtalen kan vara relaterade till datakvalitet, aktualitet, felfrekvens, drifttid och andra uppgifter.
Sammanfattning
Med hjälp av skalningsmekanismerna i din analysarkitektur i molnskala kan din organisation utöka sin dataegendom i Azure över tid och samtidigt undvika vanliga tekniska begränsningar. Båda skalningsmetoderna som beskrivs i den här artikeln hjälper dig att övervinna olika tekniska komplexiteter och kan användas på ett enkelt och effektivt sätt.