Schaal van analyses in de cloud schalen in Azure
Een schaalbaar gegevensplatform is essentieel voor het meegaan van de snelle groei van gegevens. Er worden elke seconde over de hele wereld enorme hoeveelheden gegevens gegenereerd. De hoeveelheid beschikbare gegevens zal naar verwachting exponentieel blijven groeien in de komende jaren. Naarmate het aantal gegevensgeneratie toeneemt, neemt de snelheid van gegevensverplaatsing ook toe.
Ongeacht hoeveel gegevens u hebt, vragen uw gebruikers om snelle queryreacties. Ze verwachten minuten, geen uren, te wachten op resultaten. In dit artikel wordt uitgelegd hoe u uw Azure Cloud Analytics-oplossing kunt schalen en kunt blijven voldoen aan de eisen van gebruikers voor snelheid.
Introductie
Veel ondernemingen hebben grote dataplatform-monolithen. Deze monolithen zijn gebouwd rond één Azure Data Lake Gen2-account en soms één opslagcontainer. Eén Azure-abonnement wordt vaak gebruikt voor alle gegevensplatformtaken. Schaalaanpassing op abonnementsniveau is niet aanwezig in de meeste architectuurplatforms, wat de verdere acceptatie van Azure kan belemmeren als gebruikers een van de Azure-abonnements- of serviceniveaubeperkingen ondervinden. Hoewel sommige beperkingen zachte limieten zijn, kan het raken ervan nog steeds een aanzienlijk negatief effect hebben op uw gegevensplatform.
Houd rekening met de structuur van uw organisatie wanneer u uw gegevensplatform structuren. Let op het eigendom van gegevens en functionele verantwoordelijkheden van uw teams. Als uw organisatie teams grote mate van autonomie en gedistribueerd eigendom geeft, is een data mesh-architectuur de beste optie.
Vermijd situaties waarin verschillende teams verantwoordelijk zijn voor verschillende taken van een oplossing, zoals opname, opschoning, aggregatie en service. Het afhankelijk zijn van meerdere teams kan een dramatisch snelheidsverlies veroorzaken. Als uw gegevensgebruikers op de ondersteunende laag bijvoorbeeld nieuwe gegevensassets moeten onboarden of functionele wijzigingen voor een bepaalde gegevensasset moeten implementeren, moeten ze een proces met meerdere stappen doorlopen. In dit voorbeeld zijn de stappen:
- De gegevensgebruiker verzendt een ticket naar elk team dat verantwoordelijk is voor een gegevenspijplijnfase.
- De teams moeten synchroon werken omdat de lagen onderling zijn verbonden. De nieuwe services vereisen wijzigingen in de laag voor gegevensopschoning, wat leidt tot wijzigingen in de gegevensaggregatielaag, wat leidt tot wijzigingen in de serverlaag. De wijzigingen kunnen van invloed zijn op elke pijplijnfase.
- Het is moeilijk voor de teams om de mogelijke gevolgen van het verwerken van wijzigingen te zien, omdat ze geen overzicht hebben van de volledige end-to-end levenscyclus. Ze moeten samenwerken om een goed gedefinieerd releaseplan te ontwerpen dat de gevolgen voor bestaande consumenten en pijplijnen minimaliseert. Dit afhankelijkheidsbeheer verhoogt de beheeroverhead.
- In de regel zijn de teams geen deskundigen op het gebied van de gegevensbronnen die de gegevensgebruiker aanvraagt. Om inzicht te krijgen in nieuwe gegevenssetfuncties of parameterwaarden, moeten ze een expert raadplegen.
- Nadat alle wijzigingen zijn geïmplementeerd, krijgt de gegevensgebruiker een melding dat de nieuwe gegevensasset gereed is voor gebruik.
Elke grote organisatie heeft duizenden gegevensgebruikers. Een gecompliceerd proces zoals het proces dat wordt beschreven, vermindert de snelheid in grote architecturen aanzienlijk, omdat gecentraliseerde teams een knelpunt worden voor bedrijfseenheden. Het resultaat is minder innovatie en beperkte effectiviteit. Mogelijk kunnen bedrijfseenheden besluiten om de service te verlaten en in plaats daarvan hun eigen gegevensplatform te bouwen.
Methoden voor schalen
Analyse op cloudschaal biedt een oplossing voor uitdagingen bij het schalen met behulp van twee kernconcepten:
- Gegevenslandingszones voor schaalvergroting
- Gegevensproducten of gegevensintegraties voor schalen, om gedistribueerd en gedecentraliseerd gegevenseigendom mogelijk te maken
U kunt een enkele gegevenslandingszone of meerdere gegevenslandingszones implementeren. Met gegevenslandingszones kunt u gegevens detecteren en beheren door verbinding te maken met een landingszone voor gegevensbeheer. Elke landingszone voor gegevensbeheer bevindt zich binnen één Azure-abonnement.
Abonnementen zijn azure-eenheden voor beheer, facturering en schaal. Ze spelen een belangrijke rol in uw grootschalige Azure-acceptatieplan.
Opschalen met gegevenslandingszones
De belangrijkste concepten van cloudanalyses zijn Microsoft Purview, Azure Databricks Unity Catalog als u Azure Databricks, een landingszone voor gegevensbeheer en de landingszone voor gegevens gebruikt. U moet elk in een eigen Azure-abonnement plaatsen. Door ze te scheiden, kunt u duidelijk taken scheiden, het principe van minimale bevoegdheden volgen en gedeeltelijk de problemen met de abonnementsschaal oplossen die eerder zijn genoemd. Een minimale instelling voor analyse op cloudschaal omvat één landingszone voor gegevens en één landingszone voor gegevensbeheer.
Een minimale installatie is echter niet voldoende voor grootschalige implementaties van gegevensplatforms. Bedrijven bouwen grootschalige platforms en doen investeringen om hun gegevens en analyses in de loop van de tijd consistent en efficiënt te schalen. Om beperkingen op abonnementsniveau te overwinnen, maakt analyse op cloudschaal gebruik van abonnementen als de schaaleenheid, zoals besproken in Azure-landingszones. Deze techniek maakt het mogelijk om de footprint van het gegevensplatform te vergroten door meer landingszones voor gegevens toe te voegen aan de architectuur. Door deze techniek te gebruiken, wordt ook het probleem opgelost dat één Azure Data Lake Gen2 wordt gebruikt voor een hele organisatie, omdat elke datalandingszone drie data lakes bevat. Projecten en activiteiten van meerdere domeinen kunnen worden verdeeld over meer dan één Azure-abonnement, waardoor de schaalbaarheid groter is.
Bepaal hoeveel landingszones uw organisatie nodig heeft voordat u een analysearchitectuur op cloudschaal implementeert. Als u de juiste oplossing kiest, wordt de basis gelegd voor een effectief en efficiënt gegevensplatform.
Het aantal vereiste gegevenslandingszones is afhankelijk van veel factoren, met name:
- Organisatie-uitlijning, zoals hoeveel bedrijfseenheden hun eigen gegevenslandingszone nodig hebben
- Operationele overwegingen, zoals hoe uw organisatie operationele resources en resources uitlijnt die specifiek zijn voor een bedrijfseenheid.
Het juiste model voor gegevenslandingszones minimaliseert toekomstige inspanningen om gegevensproducten en gegevensassets van de ene landingszone naar de andere te verplaatsen. Het helpt u ook om big data- en analyse-inspanningen in de toekomst effectief en consistent te schalen.
Houd rekening met de volgende factoren wanneer u besluit hoeveel gegevenslandingszones u wilt implementeren.
| Factor | Beschrijving |
|---|---|
| Organisatiestructuur en eigendom van gegevens | Bedenk hoe uw organisatie is gestructureerd en hoe gegevens eigendom zijn van uw organisatie. |
| Regio en locatie | Als u in meerdere regio's implementeert, bepaalt u welke regio's de gegevenszones moeten hosten. Zorg ervoor dat u aan alle eisen voor gegevensresidency voldoet. |
| Quota | Abonnementsquota zijn geen capaciteitsgaranties en worden per regio toegepast. |
| Data-soevereiniteit | Vanwege regelgeving voor gegevenssoevereine moeten gegevens worden opgeslagen in een specifieke regio en moeten ze een regiospecifiek beleid volgen. |
| Azure-beleid | Zones voor gegevenslanding moeten voldoen aan de vereisten van verschillende Azure-beleidsregels. |
| Beheergrens | Abonnementen bieden een beheergrens voor bestuur en isolatie die de aandachtsgebieden duidelijk scheidt. |
| Netwerken | Elke landingszone heeft een virtueel netwerk. Omdat een virtueel netwerk zich in één regio bevindt, is voor elke nieuwe regio een nieuwe landingszone vereist. De virtuele netwerken moeten peer-virtuele netwerken zijn om communicatie tussen domeinen mogelijk te maken. |
| Grenzen | Een abonnement heeft limieten. Door verschillende abonnementen te hebben, kunt u de gevaren van het bereiken van deze limieten beperken. |
| Kostentoewijzing | Overweeg of gedeelde services, zoals opslagaccounts die centraal worden betaald, moeten worden gesplitst per bedrijfseenheid of domein. Met behulp van een afzonderlijk abonnement maakt u een grens voor kostentoewijzing. U kunt dezelfde functionaliteit bereiken met behulp van tags. |
| Gegevensclassificaties en zeer vertrouwelijke gegevens | Beveiligingsmechanismen kunnen van invloed zijn op de ontwikkeling van gegevensproduct en de bruikbaarheid van een gegevensplatform. Overweeg gegevensclassificaties en bepaal of zeer vertrouwelijke gegevenssets speciale behandeling vereisen, zoals Just-In-Time-toegang, door de klant beheerde sleutels (CMK), verfijnde netwerkcontroles of meer versleuteling. |
| Andere gevolgen voor juridische of veiligheid | Overweeg of er andere wettelijke of beveiligingsvereisten zijn die logische of fysieke scheiding van gegevens vereisen. |
Als u een data mesh-architectuur implementeert, moet u rekening houden met de volgende factoren wanneer u besluit hoe u uw gegevenslandingszones en gegevensdomeinen distribueert.
| Factor | Beschrijving |
|---|---|
| Gegevensdomeinen | Houd rekening met de gegevensdomeinen die uw organisatie gebruikt en bepaal de gegevensdomeinen voor uw gegevensplatform. Houd rekening met de grootte van uw afzonderlijke gegevensdomeinen. Zie Wat zijn gegevensdomeinen voor meer informatie? |
| Wachttijd | Domeinen die samenwerken aan grote hoeveelheden gegevens kunnen een grote hoeveelheid gegevens overdragen over landingszones. Overweeg uw domeinen in dezelfde landingszone of regio te plaatsen. Door ze te scheiden, neemt de latentie toe en kunnen de kosten in domeinen tussen regio's toenemen. |
| Veiligheid | Voor sommige service-implementaties of configuraties zijn verhoogde bevoegdheden in een abonnement vereist. Als u deze bevoegdheden aan een gebruiker in één domein geeft, geeft deze gebruiker impliciet dezelfde bevoegdheden in andere domeinen binnen hetzelfde abonnement. |
U vindt meer overwegingen in de richtlijnen voor het cloudacceptatieframework voor abonnementen.
Veel organisaties willen efficiënt schalen van hun zakelijke gegevensplatform. Bedrijfseenheden moeten hun eigen gegevensoplossingen en -toepassingen kunnen bouwen om te voldoen aan hun unieke vereisten. Het bieden van deze mogelijkheid kan een uitdaging zijn omdat veel bestaande gegevensplatforms niet zijn gebaseerd op de concepten van schaalbaarheid en gedecentraliseerd eigendom. Deze shortcoming is duidelijk te zien in de architectuur, teamstructuur en het ops-model van deze gegevensplatforms.
Gegevenslandingszones maken geen gegevenssilo's binnen uw organisatie. De aanbevolen netwerkinstallatie voor analyses op cloudschaal maakt het veilig en in-place delen van gegevens mogelijk in landingszones, wat op zijn beurt innovatie mogelijk maakt voor gegevensdomeinen en bedrijfseenheden. Zie Overwegingen voor netwerkarchitectuurvoor meer informatie.
Hetzelfde geldt voor de identiteitslaag. Wanneer u één Microsoft Entra-tenant gebruikt, kunt u identiteiten toegang verlenen tot gegevens in meerdere datalandingszones. Zie Data Access Managementvoor meer informatie over het autorisatieproces voor gebruikers en identiteiten.
Notitie
Als u meerdere landingszones voor gegevens hebt, kan elke zone verbinding maken met gegevens die worden gehost in andere zones. Hierdoor kunnen groepen samenwerken binnen uw bedrijf.
Analyse op cloudschaal maakt gebruik van een algemene architectuur om consistente governance te verdedigen. Uw architectuur definieert basislijnmogelijkheden en -beleid. Alle datalandingszones voldoen aan dezelfde controle en besturingselementen. Uw teams kunnen gegevenspijplijnen maken, bronnen opnemen en gegevensproducten maken, zoals rapporten en dashboards. Teams kan ook spark-/SQL-analyses uitvoeren als dat nodig is. U kunt mogelijkheden voor gegevenslandingszones uitbreiden door services toe te voegen aan de mogelijkheid in het beleid. Een team kan bijvoorbeeld een grafiekengine van derden toevoegen om te voldoen aan een bedrijfsvereiste.
Analyses op cloudschaal leggen een sterke nadruk op centrale catalogi en classificatie om gegevens te beveiligen en het voor verschillende groepen mogelijk te maken om gegevensproducten te detecteren.
Voorzichtigheid
We raden aan om geen gegevens uit verschillende regio's op te vragen. Zorg er in plaats daarvan voor dat gegevens dicht bij de berekening liggen die deze gebruikt, en tegelijkertijd regionale grenzen respecteren.
Dankzij de architectuur voor analyse op cloudschaal en het concept van datalandingszones kan uw organisatie de grootte van uw gegevensplatform in de loop van de tijd eenvoudig vergroten. U kunt meer landingszones voor gegevens toevoegen in een gefaseerde benadering. Uw klanten hoeven in eerste instantie geen meerdere landingszones te hebben. Wanneer u deze architectuur gebruikt, geeft u prioriteit aan een aantal landingszones voor gegevens en de gegevensproducten die ze bevatten. De juiste prioriteitstelling zorgt ervoor dat uw analyse-implementatie op cloudschaal wordt geïmplementeerd.
Opschalen met data-applicaties
Binnen elke landingszone kan uw organisatie schalen met behulp van gegevenstoepassingen. Gegevenstoepassingen zijn eenheden of onderdelen van uw gegevensarchitectuur die functionaliteit inkapselen die voor lees geoptimaliseerde gegevensproducten bieden voor gebruik door andere gegevenstoepassingen. In Azure zijn gegevenstoepassingen omgevingen in de vorm van resourcegroepen waarmee functieteams gegevensoplossingen en workloads kunnen implementeren. Een gekoppeld team zorgt voor de end-to-end levenscyclus van de gegevensoplossing, waaronder opname, opschoning, aggregatie en het uitvoeren van taken.
In cloudanalyses worden de problemen met gegevensintegratie en verantwoordelijkheid behandeld die eerder zijn besproken. In plaats van monolithische functionele verantwoordelijkheden voor tabelopname en bronsysteemintegratie biedt het referentieontwerp een gedistribueerde architectuur op basis van gegevensdomeinen. Cross-functionele teams nemen de end-to-end functionele verantwoordelijkheid en het eigendom van het databereik over.
In plaats van een gecentraliseerde technische stack te hebben en een team dat verantwoordelijk is voor alle taken van uw werkstroom voor gegevensverwerking, kunt u end-to-end verantwoordelijkheid verdelen over meerdere autonome crossfunctionele gegevensintegratieteams. Elk team is eigenaar van een domein- of subdomeinmogelijkheid en wordt aangemoedigd om gegevenssets te bedienen zoals vereist door gegevensgebruikers.
Deze architectuurverschillen leiden tot een hogere snelheid op uw gegevensplatform. Uw gegevensgebruikers hoeven niet langer te vertrouwen op een set gecentraliseerde teams of vechten om hun aangevraagde wijzigingen te prioriteren. Naarmate kleinere teams eigenaar worden van uw end-to-end integratiewerkstroom, is de feedbacklus tussen de gegevensprovider en de gegevensgebruiker korter. Deze aanpak resulteert in snellere prioriteitstelling, snellere ontwikkelingscycli en een flexibeler ontwikkelingsproces. Uw teams hoeven processen en releaseplannen niet meer onderling te synchroniseren, omdat het team voor crossfunctionele gegevensintegratie volledige kennis heeft van de end-to-end technische stack en de gevolgen van wijzigingen. Het kan software-engineeringprocedures gebruiken om eenheids- en integratietests uit te voeren om het algehele effect op consumenten te minimaliseren.
Idealiter is het team dat eigenaar is van de systemen voor gegevensintegratie ook eigenaar van de bronsystemen. Dit team moet bestaan uit data engineers die aan de bronsystemen werken, deskundigen (KMO's) voor de gegevenssets, cloudtechnici en eigenaren van gegevensproduct. Het bouwen van dit soort crossfunctioneel team vermindert de hoeveelheid communicatie die nodig is met externe teams en is essentieel bij het ontwikkelen van uw volledige stack van infrastructuur tot werkelijke gegevenspijplijnen.
De basis van uw gegevensplatform zijn gegevenssets die zijn geïntegreerd vanuit bronsystemen. Deze gegevenssets maken het mogelijk voor uw dataproductteams om te innoveren op zakelijke feitentabellen en om besluitvorming en bedrijfsprocessen te verbeteren. Uw teams voor gegevensintegratie en dataproductteams moeten SLA's aanbieden aan consumenten en ervoor zorgen dat aan alle overeenkomsten wordt voldaan. De aangeboden SLA's kunnen betrekking hebben op gegevenskwaliteit, tijdigheid, foutpercentages, uptime en andere taken.
Samenvatting
Door de schaalmechanismen van uw cloudanalysearchitectuur te gebruiken, kan uw organisatie de gegevensinfrastructuur in Azure in de loop van de tijd uitbreiden en tegelijkertijd algemene technische beperkingen vermijden. Beide methoden voor schalen die in dit artikel worden beschreven, helpen u bij het overwinnen van verschillende technische complexiteiten en kunnen op een eenvoudige en efficiënte manier worden gebruikt.