Incremental refresh in Power BI: wat het is en wanneer het loont

Een rapport dat vorig jaar in acht minuten ververste, doet er nu vijftig over. Er is niets kapot: het archief is gewoon gegroeid. Elke nacht wordt dezelfde historie opnieuw opgehaald, inclusief jaren die niemand meer wijzigt. Incremental refresh is het antwoord op precies dat probleem.

Incremental refresh betekent: alleen het deel van de tabel opnieuw laden dat nog kan veranderen. De rest blijft staan zoals het was.

Volledig versus incrementeel

De duur van een volledige verversing schaalt mee met je archief. Incrementeel schaalt mee met de verandering.

Het verschil dat op de lange termijn telt, is niet de snelheidswinst van vanavond. Het is dat de duur van je verversing losgekoppeld raakt van de omvang van je historie. Een organisatie die tien jaar aan orders bewaart, verwerkt in de praktijk maar een paar dagen aan wijzigingen.

Hoe Power BI het opdeelt

Power BI knipt de tabel in partities op basis van een datumkolom. Je geeft twee getallen op: hoeveel historie je bewaart, en over hoeveel recente periodes je opnieuw laadt. Daaronder ontstaan partities per maand of per dag.

Alleen de bovenste laag beweegt nog. Daaronder ligt vastgezette historie.

Dat levert twee dingen op die verder gaan dan snelheid. Een mislukte verversing raakt alleen het recente venster, niet je hele model. En je kunt één periode gericht opnieuw laden als een bron met terugwerkende kracht is gecorrigeerd.

De voorwaarden waar het meestal op stukloopt

Incremental refresh werkt alleen als je bron eerlijk is over verandering. In de praktijk zien we vier struikelblokken:

• Geen betrouwbare wijzigingsdatum. De filterkolom moet een datum of datumtijd zijn die daadwerkelijk meebeweegt met een aanpassing. Een aanmaakdatum is niet hetzelfde als een wijzigingsdatum.
• Filters die niet worden doorgeduwd. Als de bron de datumfilter niet zelf kan uitvoeren, haalt Power BI alsnog alles op en verdwijnt de winst. Databases en views die netjes filteren zijn hier de norm; een export naar bestanden zelden.
• Verwijderde rijen. Een record dat in de bron wordt weggehaald, verdwijnt niet vanzelf uit een vastgezette partitie. Werk met een status in plaats van een harde verwijdering, of ververs die periode gericht.
• Correcties in oude jaren. Boekt de administratie nog in een afgesloten jaar? Dan hoort dat jaar niet in de bevroren laag, of moet er een periodieke herlaad afspraak zijn.

Wat je vooraf vastlegt

Incrementeel verversen is een afspraak over tijd, en die afspraak hoort niet alleen in de instellingen van een rapport te staan. Leg vast wanneer een periode als afgesloten geldt, wie mag besluiten dat er alsnog in wordt teruggeboekt, en hoe lang je historie bewaart.

Dat is dezelfde discipline als bij data lifecycle management: niet elk gegeven verdient dezelfde behandeling, en de vraag wie dat bepaalt is een organisatievraag, geen technische.

Waar het echt schuurt

Als een verversing te lang duurt, is dat vaak een symptoom en niet de kwaal. De onderliggende oorzaak is meestal dat het rapport te veel werk doet: brondata ophalen, opschonen, koppelen, definities toepassen en dan pas tonen. Incremental refresh verkort de laadtijd, maar verplaatst niets van dat werk.

De duurzame oplossing is dat schoning en betekenis onder het rapport gebeuren, in het platform, zodat elk rapport op dezelfde cijfers uitkomt. Zie wat data architectuur is voor hoe die lagen zich tot elkaar verhouden.

Kort samengevat

Incremental refresh loont zodra je tabel groter is dan het deel dat verandert, en je bron een betrouwbare wijzigingsdatum heeft. Het is geen truc om een traag model te redden: het is een manier om je verversing te laten schalen met de verandering in plaats van met het archief.