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 taken met betrekking tot het gegevensplatform. Schaalaanpassing op abonnementsniveau ontbreekt in de meeste architectuurplatforms, wat de verdere acceptatie van Azure kan belemmeren als gebruikers te maken hebben met een van de beperkingen op Azure-abonnement of serviceniveau. 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 met verschillende teams die verantwoordelijk zijn voor de verschillende taken van een oplossing, zoals opname, opschoning, aggregatie en service. Afhankelijk van meerdere teams kan een aanzienlijk verlies van snelheid 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 gegevensassets die de gegevensconsumer 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 ernstig, 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 gebruiken voor schalen
- Gegevensproducten of gegevensintegraties gebruiken voor schalen om gedistribueerd en gedecentraliseerd gegevenseigendom mogelijk te maken
U kunt één gegevenslandingszone of meerdere zones 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.
Schalen met landingszones voor gegevens
De centrale concepten van cloudanalyses zijn de landingszone voor gegevensbeheer en de datalandingszone. 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, worden in cloudanalyses abonnementen gebruikt 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. Het nemen van de juiste beslissing vormt de basis voor een effectief en efficiënt gegevensplatform.
Het aantal gegevenslandingszones dat vereist is, 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 | Omschrijving |
|---|---|
| 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 of regio's de gegevenszones moeten hosten. Zorg ervoor dat u aan alle vereisten voor gegevenslocatie voldoet. |
| Targets | Abonnementsquota zijn geen capaciteitsgaranties en worden per regio toegepast. |
| Gegevenssoevereiniteit | 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 governance en isolatie die duidelijk zorgen 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. |
| Limieten | Een abonnement heeft limieten. Door verschillende abonnementen te hebben, kunt u de gevaren van het bereiken van deze limieten beperken. |
| Kostenverdeling | 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 | Omschrijving |
|---|---|
| Gegevensdomeinen | Houd rekening met de gegevensdomeinen die uw organisatie gebruikt en bepaal welke gegevens zich op uw gegevensplatform bevinden. Houd rekening met de grootte van uw afzonderlijke gegevensdomeinen. Zie Wat zijn gegevensdomeinen voor meer informatie ? |
| Latentie | Domeinen die samenwerken aan grote hoeveelheden gegevens kunnen een grote hoeveelheid gegevens overdragen over landingszones. Overweeg uw domeinen toe te wijzen in dezelfde landingszone of regio. Door ze te scheiden, neemt de latentie toe en kunnen de kosten in domeinen tussen regio's toenemen. |
| Beveiliging | 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 netwerkarchitectuur voor meer informatie.
Hetzelfde geldt voor de identiteitslaag. Wanneer u één Microsoft Entra-tenant gebruikt, kunt u identiteiten toegang verlenen tot gegevensassets in meerdere datalandingszones. Zie Gegevenstoegangsbeheer voor meer informatie over het proces voor gebruikers- en identiteitsautorisatie.
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.
Let op
We raden u aan om gegevens in 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.
Schalen met gegevensproducten of gegevensintegraties
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 die wordt aangestuurd door gegevensdomeinen. Functionele teams nemen de end-to-end functionele verantwoordelijkheid en het eigendom van het gegevensbereik 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 veel 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 voor 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. Met deze gegevenssets kunnen uw dataproductteams innoveren in zakelijke feitentabellen en besluitvorming en bedrijfsprocessen 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 gebruik te maken van de schaalmechanismen van uw architectuur voor analyse op cloudschaal, groeit uw organisatie in de loop van de tijd uw gegevensdomein in Azure en voorkomt u bekende technische beperkingen. 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.