Je opent de Fabric Monitor op een doordeweekse ochtend. Twee rijen. Eén groen vinkje, één rood kruis. Het refreshen van het Centraal Datamodel heeft gefaald — en niemand weet precies waarom.
Herkenbaar? Voor veel organisaties die werken met PowerBI en semantische modellen is dit een alledaags tafereel. En toch wordt er verrassend weinig aandacht besteed aan één van de meest kritische processen in je data-omgeving: het refreshen van je semantische modellen.
In deze blog neem ik je mee onder de motorkap van een Semantic Model refresh. We kijken naar wat er technisch gebeurt, waar het fout gaat, waarom het in het tijdperk van Microsoft Fabric nóg belangrijker is geworden om dit goed in te richten — en hoe je stap voor stap een robuust refresh mechanisme opbouwt.
Dit blog is geschreven door Anino Loche en verscheen eerder op zijn LinkedIn.
Een semantisch model is niet zomaar een technisch artefact. Het is de ruggengraat van je rapportageomgeving. Het bevat je bedrijfsdata, je KPI’s, je beveiligingsregels. Elke dashboard, elk rapport, elke AI-toepassing die gebouwd wordt op PowerBI staat of valt bij de kwaliteit en versheid van dit model.
Wanneer een refresh faalt, zijn de gevolgen direct voelbaar:
Met de introductie van Microsoft Fabric is er een nieuwe dimensie bijgekomen: Capacity Units (CU). Fabric werkt op basis van een gedeeld capaciteitsmodel. Elke refresh, elke query, elke bewerking verbruikt CU’s. Een slecht geconfigureerd refresh proces kan letterlijk je hele capaciteit overbelasten — met vertragingen en throttling voor alle gebruikers op je platform als gevolg.
Kort gezegd: een inefficiënt refresh mechanisme kost geld en schaadt de betrouwbaarheid van je data-omgeving. Dat is een businessrisico, geen technisch detail.
Voor de data consultants die willen begrijpen hoe het werkt
Oké, laten we eerlijk zijn — als je op die refresh-knop klikt, denk je er misschien niet zo veel bij na. Maar er gebeurt achter de schermen heel wat! Laten we eens kijken wat er onder de motorkap van een import semantisch model afspeelt.
Een refresh van een import semantisch model verloopt via de volgende stappen:
Elk van deze stappen heeft zijn eigen risico’s. En dat brengt ons bij de vraag die iedere PowerBI ontwikkelaar vroeg of laat stelt:
De meest voorkomende problemen bij het refreshen van semantische modellen vallen in zes categorieën:
Laten we de belangrijkste dieper induiken.
Bij credential issues draait het om het juist instellen van de Authentication Type. Maak gebruik van workspace identities, service principals, etc. Gebruik gateways alleen indien nodig, en richt autorisaties in met security groups.
Een veelgemaakte fout is dat een semantisch model geconfigureerd staat onder de persoonlijke credentials van een individuele medewerker. Zodra diegene van rol wisselt, MFA-instellingen wijzigen of het account verloopt — faalt de refresh. De oplossing: gebruik service principals of workspace identities en leg dit vast in security groups op verbindingsniveau.
Dit is één van de meest onderschatte problemen. Tijdens een refresh heeft Power BI tijdelijk meer dan twee keer de modelgrootte aan geheugen nodig: het bestaande model blijft beschikbaar voor gebruikers, terwijl het nieuwe model opgebouwd wordt. Hier door krijg je dus eigenlijk twee keer je model naast elkaar in het geheugen. Maar dat is nog niet alles. Het model heeft ook nog gebruikers die aan het querien zijn. Ook deze queries kosten memory. Zo kan een model wat stil staan 10GB kost in eens bijna 25GB kosten tijdens het verversen.
De veelvoorkomende oorzaken van memory druk tijdens een refresh zijn:
In Fabric gelden per SKU strikte geheugenlimieten per model. Wanneer het geheugen de limiet overschrijdt, geeft het systeem een foutmelding: de operatie wordt geannuleerd omdat er onvoldoende geheugen was om de bewerking te voltooien.
Een refresh die te lang duurt kan meerdere oorzaken hebben die op verschillende plekken in het proces zitten:
De oplossing? Breng berekeningen zo ver mogelijk upstream — naar je goud laag — zodat Power Query en DAX calculated columns / tables zo min mogelijk hoeft te doen.
Met de komst van Microsoft Fabric is er een compleet nieuw kostenmodel geïntroduceerd dat directe impact heeft op hoe je refreshes inricht.
1 CU staat gelijk aan het gebruik van 2 vCores. 1 CU(s) staat voor het gebruik van 2 vCores gedurende 1 seconde. Een F2-capaciteit heeft 4 vCores en 2 CU per seconde beschikbaar. Over een hele dag (86.400 seconden) geeft dat een totaal van 172.800 CU(s) per dag. Een F64-capaciteit heeft 128 vCores en 64 CU per seconde beschikbaar — goed voor 5.529.600 CU(s) per dag.
Het CU-verbruik tijdens een refresh is aanzienlijk: een Full Refresh verbruikt hoog CU, omdat 100% van de data opnieuw geladen wordt. Een Incremental Refresh verbruikt beduidend minder, omdat slechts circa 20-30% van de data ververst wordt.
Dit verschil is enorm. Als je een groot model elke nacht volledig ververst, eet dat een significant deel van je dagelijkse CU-budget op. Bij CU-throttling worden alle processen op je capacity vertraagd — niet alleen jouw refresh, maar ook de queries van je eindgebruikers.
De conclusie: Slecht geconfigureerde refreshes zijn in Fabric geen technisch ongemak meer — ze zijn een directe kostenpost en een risico voor de beschikbaarheid van je platform.
Het inrichting van een goed en volledig refresh mechanisme gaat altijd volgens dezelfde stappen:
Voordat je iets gaat aanpassen, moet je weten wat er aan de hand is. Begin met het in kaart brengen van de veelvoorkomende problemen: credential issues, memory pressure, te lange refresh duur, parallelle conflicten, CU throttling en schema changes.
Om te zien wat er écht gebeurt, heb je de juiste tools nodig: Fabric Capacity Metrics voor CU-verbruik, throttling en trends per workspace. VertiPaq Analyzer voor modelgrootte per kolom, dictionary sizes en encoding. Via DAX-Query view; info.partitions voor partitie-status en RefreshTime. Refresh History voor duur, status en foutmeldingen per dataset. Workspace Monitoring voor gedetailleerde operatie-logs.
De Fabric Capacity Metrics app laat je precies zien welke datasets het meeste CU verbruiken, wanneer throttling optreedt en welke workspaces de meeste capaciteit opeisen. Onmisbaar als je serieus werk wilt maken van capaciteitsbeheer.
Dit gratis tool (te gebruiken via Tabular Editor of DAX Studio) geeft je een gedetailleerd inzicht in je modelgrootte op kolomniveau. Je ziet precies welke kolommen de meeste geheugenruimte innemen en waar je winst kunt behalen.
De Workspace Monitor in Microsoft Fabric biedt gedetailleerde operatie-logs. Door een monitoring Eventhouse toe te voegen aan je workspace, worden alle activiteiten automatisch gelogd in een KQL-database. Zo krijg je inzicht in alle operaties — inclusief SemanticModelLogs — op gedetailleerd niveau.
Verwijder ongebruikte kolommen, splits kolommen zoals DateTime-velden op in afzonderlijke Date en Time kolommen, en verlaag de kardinaliteit van je kolommen.
Praktische tip: Gebruik de Best Practice Analyzer in Tabular Editor om automatisch ongebruikte kolommen te detecteren. Je zult versteld staan hoeveel kolommen er in een gemiddeld model zitten die nooit gebruikt worden in visuals of measures — maar wel geheugen verbruiken bij elke refresh.
Het verkleinen van je model is een goede start, maar optimaliseren gaat verder. Het gaat erom dat de data die wél in je model zit, zo efficiënt mogelijk opgeslagen en verwerkt wordt.
DAX calculated columns worden in-memory berekend tijdens de refresh — voor iedere rij, bij iedere refresh opnieuw. Verplaats berekeningen daarom zo ver mogelijk upstream: naar Power Query of je goud laag in het Lakehouse of Warehouse. Importeer al-berekende waarden en laat VertiPaq alleen nog comprimeren. Dit scheelt direct in refreshtijd én memory druk.PBIG – Word master van je Power BI Refreshes.pdf
Gebruik Date in plaats van DateTime als je de tijdcomponent niet nodig hebt, Integer in plaats van Decimal waar mogelijk, en wees spaarzaam met Text-velden. Kolommen met veel unieke waarden resulteren in grote dictionaries — hoe kleiner het domein van mogelijke waarden, hoe beter VertiPaq comprimeert.
Werk met een ster-schema, vermijd brede feitentabellen en verwijder onnodige relaties. Een goed gestructureerd model is niet alleen beter voor query-performance, maar ook voor refresh-efficiëntie. Split waar mogelijk grote tabellen op in smallere, gerichte tabellen.
Zet IsAvailableInMDX = false voor verborgen kolommen om hierarchy-geheugen te besparen. Een kleine ingreep, maar zonder enige functionele impact. De Best Practice Analyzer in Tabular Editor detecteert deze kolommen automatisch voor je.
Spreid refreshes over tijd, vermijd piekuren, en gebruik pipelines voor controle.
Denk na over wanneer je welke data refresht. Vaak hoef je niet alle data in het model te verversen. Kies bijvoorbeeld voor het verversen van de feiten niet de dimensies om de belasting te verlagen.
Daarnaast geld dat een refresh die om 08:00 gestart wordt — precies als alle medewerkers inloggen en queries beginnen te draaien — concurreert direct met gebruikersactiviteit om hetzelfde CU-budget. Plan je refreshes buiten piekuren en gebruik Fabric Data Pipelines om de volgorde en timing te controleren.
Een partitie is een logische verdeling van een tabel in je semantisch model. In plaats van de volledige tabel “Verkopen” als één blok te laden, kun je deze opdelen in meerdere partities — bijvoorbeeld per jaar: 2024, 2025, 2026.
Het grote voordeel: je kunt per partitie bepalen of en hoe vaak je deze ververst. Historische data (2 jaar geleden, 3 jaar geleden) verandert niet meer. Die hoef je dus ook niet elke nacht opnieuw te laden.
De keuze tussen Full en Incremental Refresh is fundamenteel:
Full Refresh:
Incremental Refresh:
Voor gevorderde scenario’s zijn er daarnaast nog opties als Hybrid Tables (DirectQuery partitie voor real-time data), Custom Partitions en Scale-out Refresh.
Er zijn meerdere manieren om je model te verversen:
Nee! Dit is een cruciale inzicht die veel organisaties missen. Dimensietabellen (klanten, artikelen, leveranciers) veranderen veel minder frequent dan feitentabellen (verkopen, transacties). Door slim onderscheid te maken:
Met Advanced Refresh via een Fabric Notebook (Semantic Link Labs) kun je dit heel precies orchestreren: dimensies worden 1x per dag volledig ververst, terwijl de partitie van het huidige jaar en vorig jaar elke 10 minuten ververst wordt, en oudere partities slechts 1x per week.
Bewaak je refresh omgeving continu met Capacity Metrics, info.partitions() en de Workspace Monitor. Stel alerts in bij failures, leg eigenaarschap vast en documenteer je refresh architectuur. Een refresh failure die om 03:00 ’s nachts optreedt en pas om 09:00 ontdekt wordt, kost je organisatie kostbare beslissingstijd.
Samengevat is dit het stappenplan om master te worden van je eigen refreshproces:
En zo weet je de volgende keer dat je ’s ochtends in Fabric kijkt en die rij met refreshes ziet, precies wat er achter dat groene vinkje, of rode kruis, gebeurt.
En belangrijker nog: je weet hoe je er invloed op hebt.
Van reactief brandjes blussen… naar proactief sturen op performance, kosten en betrouwbaarheid.
En dat is precies het verschil tussen een werkende data-oplossing — en een volwassen data platform.
Het laatste tech news, klantcases en events direct in je inbox.
Anino Loche over het veilig gebruiken maken van de Power BI data explorer.
Vanaf 1 juli 2026 bepaal je de positie van jouw organisatie binnen de bedrijfsketen zelf. Dit is wat jij moet…
Versterk je data-strategie met Fabric Data Agents en ‘Talk To Power BI’!
DTX legt het fundament met automation, CI/CD en duidelijke fasen.
Erik van der Leek neemt je mee in de recap van 2025 in 5 delen.
NIS2: strengere EU-cyberregels vanaf mid-2025. Hoe staat het nu met de richtlijn?
DTX uitgeroepen door Rapid7 als EMEA Vulnerability Management Partner van 2024!
Ontdek hoe je 1Password kan aansluiten aan InsightIDR met de kracht van Insightconnect.
Door groeiende tech‑afhankelijkheid werkt de EU aan een Europees cybersecuritybeleid: de NIS2.
Phishing neemt toe; door kennis herken je signalen en voorkom je schade.
