Incremental refresh

Wat is incremental refresh?

Incremental refresh is een Power BI- en Fabric-functie waarmee je bij elke refresh alleen nieuwe of gewijzigde data oppakt, in plaats van de volledige tabel opnieuw te laden. Je bepaalt hoeveel historiek je wil bewaren (bijvoorbeeld drie jaar) en vanaf welk venster je data opnieuw mag lezen (bijvoorbeeld de laatste twee dagen). Alles daarbuiten blijft ongemoeid.

Onder de motorkap verdeelt Power BI je tabel in partities per dag, maand, kwartaal of jaar. Enkel de partities in het refreshvenster worden opnieuw geladen. De rest blijft zoals ze is en bespaart je enorm veel tijd en rekenkracht.

Je kan incremental refresh vergelijken met het onderhouden van een archief. Je hoeft niet elke avond het volledige archief door te lopen, enkel de laatste dossiers en misschien die van de voorbije week waar nog correcties op gebeurd zijn. De mappen uit 2019 blijven dicht.

Waarom is incremental refresh belangrijk?

Een klassieke volledige refresh schaalt slecht. Drie problemen beginnen te knellen vanaf enkele tientallen miljoenen rijen:

Duurtijd
Een volledige refresh van 200 miljoen rijen kan uren duren. Je verliest refresh-vensters, je blokkeert de bron en je botst tegen de limieten van je capaciteit.

Brondruk
Elke volledige refresh vraagt de bron om miljoenen rijen opnieuw uit te spuwen. Bij een drukke OLTP-databank is dat pijnlijk.

Capaciteit
De refresh verbruikt je Power BI Premium- of Fabric-capaciteit. Een falende refresh midden in de nacht betekent een lege dag voor de business de volgende ochtend.

Incremental refresh beperkt dat tot enkel de relevante partities. Een refresh van een grote tabel duikt zo van uren naar minuten.

Hoe stel je incremental refresh in?

Het proces bestaat uit drie stappen, grotendeels vanuit Power BI Desktop.

1. Filter parameters aanmaken
   Je maakt twee parameters aan van type datetime: RangeStart en RangeEnd. Die heten exact zo, want Power BI zoekt op naam.

2. Filter toepassen in Power Query
   In de tabel filter je de datumkolom tussen RangeStart en RangeEnd. Hiermee weet Power BI welke kolom de tijdssleutel is. Belangrijk: deze filter moet gefoldet kunnen worden, anders werkt het niet efficiënt.

3. Incremental refresh policy instellen
   In de kolom-instellingen van de tabel zet je de policy aan: hoeveel historiek bewaren (bijvoorbeeld 5 jaar) en hoeveel recente periodes opnieuw verwerken (bijvoorbeeld de laatste 10 dagen). Eventueel zet je detect data changes aan, waarmee Power BI een hash per partitie bewaart en enkel herlaadt waar de hash veranderd is.

Bij de eerste publicatie en refresh in de Power BI service bouwt de engine alle partities op, daarna refresht hij enkel nog het bewegende venster.

Incremental refresh in Fabric

Binnen Microsoft Fabric verandert de context.

Klassieke semantische modellen
Incremental refresh werkt hier identiek aan Power BI Premium. Je kan de partitiegrootte en het refreshvenster fijner tunen via XMLA-endpoints en Tabular Editor.

DirectLake
Wanneer je een semantisch model in DirectLake gebruikt, is incremental refresh niet meer nodig. DirectLake leest rechtstreeks Delta-tabellen uit OneLake en kent geen refreshstap op de Power BI-laag. De incrementele logica schuift dan naar de data-engineering kant, typisch via ETL/ELT-pipelines of CDC op de brontabel.

Geavanceerde opties

Hybrid tables
Je kan incremental refresh combineren met een DirectQuery-partitie voor de allerlaatste data. Historische maanden zitten in Import-partities (snel), de lopende dag in DirectQuery (live). Het beste van beide werelden zonder composite-modellen zelf te bouwen.

Detect data changes
Bij historische partities die soms retroactief wijzigen (correcties, backdates) kan detect data changes op basis van een ModifiedDate-kolom partities selectief opnieuw laden. Bewaart correctheid zonder grote performance-impact.

XMLA endpoint-beheer
Via Tabular Editor of SSMS kan je partities handmatig refreshen, splitsen of samenvoegen. Handig bij eenmalige correcties of bij het bijstellen van de partitiestrategie.

Valkuilen

Filter die niet foldet
Als Power Query de RangeStart/RangeEnd-filter niet kan vertalen naar de bron, haalt hij alsnog alles op en filtert hij lokaal. De feature werkt dan, maar de winst verdwijnt. Controleer via View Native Query of de filter echt in SQL terechtkomt.

Tabellen zonder betrouwbare datumkolom
Incremental refresh hangt aan een datetime-kolom. Wanneer die kolom onbetrouwbaar wordt bijgewerkt in de bron, krijg je gaten of duplicaten. Zorg voor een strikte LoadedOn- of ModifiedOn-kolom.

Schema-wijzigingen in de bron
Wanneer een kolomtype of -naam wijzigt, moet je soms de volledige tabel opnieuw opbouwen. Plan schema-wijzigingen in met een refreshvenster dat dat toelaat.

Historische correcties
Data die soms retroactief wijzigt (bijvoorbeeld boekhoudkundige aanpassingen aan oude maanden) wordt gemist als je refreshvenster te kort is. Breid het venster uit of gebruik detect data changes.

Publiceren overschrijft partities
Een simpele republicatie van het PBIX vanuit Desktop wist je partities. Gebruik PBIP-projecten en XMLA deployment-pipelines om dat te voorkomen.