8 redenen waarom Fabric-capaciteitsverbruik onverwacht stijgt

Ed Kisman · 13 okt 2026

Microsoft Fabric biedt organisaties enorme mogelijkheden om data te verwerken, analyseren en visualiseren binnen één geïntegreerd platform. Maar wie de factuur aan het einde van de maand openslaat en schrikt van het Microsoft Fabric-capaciteitsverbruik, is zeker niet de eerste. Fabric-capaciteit wordt gemeten in Capacity Units (CU’s), en die kunnen sneller oplopen dan verwacht. Hieronder vind je acht concrete oorzaken waardoor Fabric-capaciteit stijgt zonder dat je het doorhebt, inclusief wat je eraan kunt doen.

Wanneer Fabric-kosten hoger uitvallen dan verwacht

Onverwacht hoog Fabric CU-verbruik ontstaat zelden door één grote boosdoener. Vaker is het een combinatie van kleine, onopgemerkte patronen die samen voor een flinke rekening zorgen. Inzicht in de meest voorkomende oorzaken is de eerste stap naar een beheersbare capaciteitsplanning. De acht redenen hieronder zijn elk verantwoordelijk voor een herkenbaar patroon van overconsumptie.

1: Achtergrondprocessen die ongemerkt CU’s verbruiken

Geplande vernieuwingen, geautomatiseerde pipelines en achtergrondtaken draaien ook buiten kantooruren, en dat is precies waar het probleem zit. Wanneer meerdere geplande taken tegelijk worden uitgevoerd, of wanneer een mislukte taak automatisch opnieuw wordt gestart zonder limiet, stapelt het CU-verbruik zich op zonder dat iemand het merkt.

Controleer regelmatig de planning van alle geautomatiseerde processen in je Fabric-omgeving. Zorg dat er een maximum is ingesteld op het aantal herhaalpogingen bij fouten, en bekijk of taken die ’s nachts draaien echt op dat moment nodig zijn, of dat ze ook buiten piektijden kunnen worden verspreid.

Dit probleem treft vooral omgevingen waar meerdere teams zelfstandig pipelines en vernieuwingen inplannen zonder centrale coördinatie. Een overzicht van alle actieve geplande taken is een eenvoudige maar effectieve eerste stap.

2: Ongeoptimaliseerde dataflows met hoge rekenbelasting

Dataflows Gen2 zijn krachtig, maar slecht geschreven transformaties kunnen buitensporig veel rekenkracht vragen. Denk aan onnodige joins op grote tabellen, het ophalen van meer kolommen dan nodig, of het herhalen van dezelfde berekening in meerdere stappen.

Een dataflow die technisch correct werkt, is nog niet automatisch efficiënt. Het gebruik van query folding, het beperken van het aantal stappen en het filteren van data zo vroeg mogelijk in de transformatie zijn technieken die het Fabric CU-verbruik aanzienlijk kunnen verlagen. Meer over het optimaliseren van dataflows lees je op de pagina over Fabric pipelines en dataflows consultancy.

Dataflows met complexe transformaties op grote datasets zijn de meest voorkomende stille verbruikers in Fabric-omgevingen. Een periodieke review van de zwaarste dataflows loont altijd.

3: Paralleluitvoering van meerdere workloads tegelijk

Fabric verdeelt CU’s over alle actieve workloads. Wanneer meerdere zware processen gelijktijdig draaien, zoals een grote pijplijnvernieuwing tegelijk met een semantisch model dat wordt herladen en een Spark-notebook dat actief is, dan piekt het verbruik sterk.

Het bewust spreiden van workloads over de tijd, ook wel workload scheduling genoemd, is een van de meest effectieve manieren om pieken te vermijden. Fabric biedt mogelijkheden om prioriteiten in te stellen per workload, maar dat werkt alleen als er actief gebruik van wordt gemaakt.

Organisaties met meerdere teams en veel gelijktijdige gebruikers zijn het meest kwetsbaar voor dit patroon. Een capaciteitsplanning waarbij piekbelasting bewust wordt gespreid, voorkomt onnodige overconsumptie.

4: Grote semantische modellen zonder partitionering

Semantische modellen die bij elke vernieuwing volledig opnieuw worden geladen, verbruiken aanzienlijk meer CU’s dan modellen die gebruikmaken van incrementele vernieuwing of partitionering. Hoe groter het model, hoe hoger de rekenkosten per refresh-cyclus.

Incrementele vernieuwing instellen op grote tabellen is een van de meest impactvolle optimalisaties binnen Microsoft Fabric-beheer. Hiermee wordt alleen de nieuwe of gewijzigde data verwerkt, in plaats van de volledige tabel opnieuw te laden. Combineer dit met een logische partitioneringsstrategie op basis van datum of regio voor het beste resultaat.

Dit is met name relevant voor modellen met historische data die meerdere jaren beslaan. Zonder partitionering groeit het verbruik lineair mee met de omvang van de dataset.

5: Onbeheerde Spark-sessies in notebooks

Spark-sessies in Fabric-notebooks blijven actief zolang de sessie open staat, ook als er geen code meer wordt uitgevoerd. Elke actieve sessie reserveert rekencapaciteit, en wanneer meerdere ontwikkelaars notebooks open laten staan, loopt het verbruik snel op.

Stel een maximale sessieduur in en activeer automatisch stoppen van inactieve sessies. Fabric biedt configuratieopties om sessies na een bepaalde periode van inactiviteit automatisch te beëindigen. Dit is een eenvoudige instelling met een direct meetbaar effect op het CU-verbruik.

In omgevingen waar data-engineers en analisten dagelijks met notebooks werken, is dit een van de snelst te adresseren verbruiksoorzaken. Het vraagt weinig technische aanpassing maar vereist wel bewustzijn bij het team.

6: Overmatig gebruik van Direct Lake zonder limieten

Direct Lake is een van de krachtigste functies van Fabric: het maakt het mogelijk om rechtstreeks vanuit OneLake te lezen zonder import. Maar zonder goede limieten en governance kan overmatig gebruik van Direct Lake leiden tot hoog en moeilijk voorspelbaar CU-verbruik, zeker bij grote datasets en veel gelijktijdige gebruikers.

Stel row limits en query time-outs in om te voorkomen dat één zware query de volledige capaciteit opslokt. Monitor welke rapporten en gebruikers de meeste Direct Lake-queries genereren en overweeg voor minder kritische rapporten een importmodus als alternatief. Meer over governance en beveiliging binnen dataplatforms lees je op de pagina beveiliging en governance.

Direct Lake is ideaal voor real-time analyses op grote datasets, maar vereist actief beheer om het verbruik beheersbaar te houden. Zonder monitoring is het lastig om te zien welke queries de grootste impact hebben.

7: Ongecontroleerde toegang en wildgroei aan werkruimten

Wanneer iedereen werkruimten kan aanmaken en datasets kan publiceren, ontstaat er al snel een situatie waarbij tientallen overlappende datasets en rapporten actief zijn, elk met hun eigen vernieuwingsschema. Deze wildgroei is een van de meest onderschatte oorzaken van onverwacht hoog Microsoft Fabric-capaciteitsverbruik.

Stel een governance-beleid in voor het aanmaken van werkruimten en het publiceren van content. Definieer wie welke werkruimten mag beheren, en maak gebruik van Fabric-capaciteitsinstellingen om te bepalen welke werkruimten aan welke capaciteit worden gekoppeld. Een periodieke audit van actieve werkruimten en datasets helpt om verouderde of dubbele content te identificeren en te verwijderen.

Dit vraagt om een combinatie van technische instellingen en organisatorische afspraken. Zonder beide blijft wildgroei een terugkerend probleem, ongeacht hoe goed de technische configuratie is.

8: Capaciteitslimieten zonder throttling-bewustzijn

Fabric heeft een ingebouwd throttling-mechanisme dat in werking treedt wanneer de capaciteitslimiet wordt overschreden. Wat veel gebruikers niet weten, is dat throttling niet direct zichtbaar is: queries worden vertraagd of in de wachtrij gezet, wat leidt tot trage rapporten en gefrustreerde gebruikers, terwijl het onderliggende probleem ongezien blijft.

Gebruik de Fabric Capacity Metrics App om inzicht te krijgen in het werkelijke verbruik per workload, per werkruimte en per tijdstip. Deze app maakt zichtbaar wanneer de capaciteit onder druk staat en welke processen daarvoor verantwoordelijk zijn. Op basis van die inzichten kun je gerichte keuzes maken over Fabric-capaciteitsplanning, zoals het opschalen van capaciteit of het herverdelen van workloads. Meer over capaciteitsinrichting vind je op de pagina Fabric inrichting.

Throttling-bewustzijn is essentieel voor iedereen die verantwoordelijk is voor een Fabric-omgeving. Zonder dit inzicht is capaciteitsbeheer reactief in plaats van proactief, en dat is precies wat leidt tot verrassingen op de factuur.

Grip houden op Fabric-capaciteit met proactief beheer

De acht oorzaken hierboven hebben één ding gemeen: ze zijn allemaal te voorkomen of te beperken met de juiste monitoring, governance en configuratie. Proactief Microsoft Fabric-beheer betekent niet dat je continu handmatig controleert, maar dat je de juiste processen en tools inricht zodat afwijkingen vroeg worden gesignaleerd.

Bekijk ook onze pagina over Microsoft Fabric voor een volledig overzicht van onze dienstverlening op dit platform.

Hoe DBA helpt met Microsoft Fabric-capaciteitsbeheer

Wij helpen organisaties om grip te krijgen op hun Fabric-omgeving, van de eerste inrichting tot structureel beheer en optimalisatie. Onze aanpak is concreet en gericht op meetbare resultaten:

Capaciteitsanalyse: We brengen het huidige CU-verbruik in kaart via de Fabric Capacity Metrics App en identificeren de grootste verbruikers.
Workload-optimalisatie: We analyseren dataflows, pipelines en semantische modellen en adviseren over partitionering, incrementele vernieuwing en query-optimalisatie.
Governance-inrichting: We helpen bij het opstellen en implementeren van een werkruimte- en toegangsbeleid dat wildgroei voorkomt.
Monitoring en alerting: We richten proactieve monitoring in zodat afwijkingen in het capaciteitsverbruik direct zichtbaar worden, voordat ze een probleem worden.
Doorlopend beheer: We bieden structureel beheer van je Fabric-omgeving, zodat capaciteitsplanning geen verrassing meer is maar een beheerste keuze.

Wil je weten hoe we jouw Fabric-omgeving kunnen optimaliseren? Neem contact met ons op voor een vrijblijvend gesprek.