Capacity planning is geen keuze tussen “klein” en “groot”. Het beschrijft hoe ingestion, Spark, semantic models, rapporten en gebruikers de compute door de tijd heen delen.
De gemiddelde workload kan onschuldig lijken, terwijl een refreshvenster, notebookrun en het ochtendverkeer naar rapporten tegelijk pieken. Plan voor die botsing, niet alleen voor het gemiddelde.
Begin met workloadpatronen
Beantwoord dit voordat je een capacity kiest:
- Hoeveel mensen bevragen de oplossing regelmatig?
- Zijn queries interactief, gepland, of allebei?
- Draait de omgeving vooral op Lakehouse- en SQL-werk, of vooral op semantic-modelqueries?
- Hoe vaak draaien pipelines, notebooks en refreshes?
- Welke groei is waarschijnlijk in de komende drie tot zes maanden?
Die antwoorden zijn nuttiger dan “we hebben een grote capacity nodig”.
Een uitgewerkt voorbeeld
Stel dat de omgeving dit bevat:
- één Lakehouse met 3-5 TB aan data;
- drie of vier pipeline-refreshes per dag;
- een semantic model dat door 20 mensen wordt gebruikt;
- nachtelijke notebookverwerking; en
- verschillende operationele kwaliteitscontroles.
Dat is geen kleine test meer. Vraag:
- Is de vraag stabiel of piekerig?
- Overlappen pipelinevensters?
- Draait verwerking tijdens kantooruren?
- Concurreren meerdere workspaces om dezelfde capacity?
Het ontwerp hangt net zo sterk van die overlap af als van het datavolume.
Een praktisch planningsproces
1. Classificeer de workloads
Scheid:
- ingestion en transformaties;
- notebook- of Spark-verwerking;
- interactieve BI- en semantic-modelqueries;
- rapportrefreshes en exploratie; en
- orchestration en geplande jobs.
Ze hebben verschillende timing- en concurrencykenmerken.
2. Breng piekvensters in kaart
Schrijf op wanneer de omgeving het drukst is. Een veelvoorkomend patroon:
- 08:00-10:00 voor datarefreshes;
- 11:00-14:00 voor rapportexploratie; en
- 18:00 voor batchverwerking.
Als die vensters overlappen, kan de capacity beperkt aanvoelen terwijl het daggemiddelde gematigd is.
3. Controleer contention
Zoek naar gelijktijdige notebooks, geopende rapporten, pipeline-refreshes en semantic-modelverwerking. Herhaalde overlap is een capacitysignaal, geen toevallige pech.
4. Voeg speelruimte toe
Begin met de huidige baseline, voeg realistische kwartaalgroei toe, neem pieken rond maand- of kwartaaleinde mee en houd ruimte over voor herstel. Een capacity die alleen bij 95% utilization werkt, is kwetsbaar.
Trial capacity is om te leren, niet om te certificeren
Test met een Fabric trial een kleine maar representatieve workload:
- draai de pipeline met een realistische frequentie;
- test concurrency;
- creëer een refreshpiek;
- observeer notebook- of Spark-gedrag; en
- leg vast wat vóór het volgende capacityniveau moet veranderen.
“Het werkte één keer” beantwoordt de vraag over productiedimensionering niet.
Operationele gewoontes die helpen
- Scheid waar mogelijk development-, test- en production-workspaces.
- Plan zware verwerking niet in hetzelfde venster als bekende rapportpieken.
- Leg normale utilization voor en na grote wijzigingen vast.
- Herzie het capacityplan wanneer nieuwe modellen, pipelines of gebruikersgroepen bijkomen.
- Documenteer welke workload iedere piek veroorzaakt.
De kern
Een bruikbaar capacityplan benoemt de workloads, hun piekvensters, concurrency en de groeiaanname. Kies de capacity pas als die vier zichtbaar zijn. Zo wordt een dure gok een testbaar ontwerp.
Reacties laden…