Waarom berekende kolommen in Power BI je rapportprestaties verpesten en het modelgeheugen opblazen

By Mirko Peters · 2026-10-29

Ontdek waarom te veel gebruik van berekende kolommen in Power BI het modelgeheugen opblaast en de rapportprestaties verslechtert. Leer hoe je de architectuur van je datamodel optimaliseert.

Automatically translated with AI from the original post. Read the English original

Berekende kolommen die verkeerd worden ingezet in Power BI kunnen ongemerkt het geheugen van je datamodel opblazen en de weergavetijd van rapporten vertragen. In tegenstelling tot dynamische measures evalueren en slaan berekende kolommen elke afzonderlijke rij op tijdens het vernieuwen van de gegevens. Dat kost waardevol RAM-geheugen en verhoogt de verwerkingsbelasting binnen de architectuur van je werkruimte.

Belangrijkste punten

• Berekende kolommen berekenen waarden rij voor rij tijdens het vernieuwen van de gegevens en slaan die permanent op in het geheugen.
• Te veel berekende kolommen verslechteren de VertiPaq-compressieverhouding sterk, wat leidt tot een enorme toename van de bestandsgrootte.
• Rijcontext zorgt ervoor dat berekeningen statisch worden uitgevoerd, waarbij filterselecties op visuals volledig worden genegeerd.
• Datamodellen met te veel kolommen schalen slecht, zeker wanneer ze zijn geïntegreerd in grote zakelijke Microsoft Fabric-omgevingen.
• Logica verplaatsen van geheugenintensieve kolommen naar measures die tijdens het opvragen worden berekend, bespaart systeem-RAM en optimaliseert de rapportprestaties.

De verborgen geheugenkosten van evaluatie per rij

Wanneer je een nieuw rapport bouwt in Power BI, is het makkelijk om de gewoonte te ontwikkelen om voor elk nieuw gegevenspunt een berekende kolom te gebruiken. Als je een winstmarge nodig hebt, een samengestelde volledige naam of een categorie voor je verkoopcijfers, voelt het intuïtief om een kolom in je tabel te maken. Je ziet de resultaten immers meteen in Gegevensweergave, net als in een Excel-spreadsheet.

Power BI is echter een analytische engine, geen spreadsheet. Elke keer dat je een berekende kolom maakt, geef je de VertiPaq-databaseengine opdracht om die waarde voor elke afzonderlijke rij in de tabel te berekenen tijdens het vernieuwen van de gegevens. Als je verkooptabel vijf miljoen rijen heeft, voegt je nieuwe berekende kolom vijf miljoen afzonderlijke waarden toe aan je semantische model.

Nog erger is dat berekende kolommen de compressiealgoritmen van de engine verstoren. VertiPaq is afhankelijk van kolommen met een lage kardinaliteit, dat wil zeggen kolommen met repetitieve, dubbele waarden, om gegevens efficiënt te comprimeren. Een unieke berekende kolom ondermijnt die compressie vaak, waardoor het RAM-geheugen dat nodig is om het model in het geheugen te houden, sterk toeneemt. Naarmate je model groeit, kan deze geheugenopbouw snel de capaciteitslimieten van je werkruimte in de Microsoft-cloud overschrijden.

Hoe statische context je rapportageflexibiliteit beperkt

Naast het geheugenverbruik brengen berekende kolommen ook aanzienlijke functionele beperkingen met zich mee, vanwege de manier waarop ze met evaluatiecontext omgaan. Een berekende kolom werkt strikt binnen een rijcontext. Ze evalueert de waarden van de huidige rij, los van interacties van gebruikers, slicers of kruisfilterselecties op het rapportcanvas.

Als je een berekende kolom maakt om klanten met een hoge waarde te markeren op basis van een vaste drempelwaarde, wordt die classificatie vastgelegd in de opslaglaag. Als een gebruiker later een slicer wijzigt om gegevens per regio te bekijken of een datumbereik aanpast, blijft de berekende kolom daar volledig onverschillig voor. Ze kan zich niet dynamisch aanpassen aan wijzigende aggregatiestatussen, omdat de waarde al uren eerder tijdens de laatste vernieuwing is berekend en opgeslagen.

Deze starheid staat in schril contrast met measures, die resultaten direct berekenen, volledig op basis van de filtercontext die de gebruiker op dat exacte moment toepast. Wanneer een gebruiker met een visual interacteert, berekent een measure opnieuw om precieze, contextbewuste inzichten te leveren, terwijl een berekende kolom simpelweg de statische gegevens herhaalt die in het RAM-geheugen zijn opgeslagen.

Slankere modellen ontwerpen voor Microsoft Fabric en Azure

Cloudrapportage in een onderneming vraagt om een hoge efficiëntie, zeker wanneer je opschaalt over Microsoft Fabric, Azure en complexe Microsoft 365-datalandschappen. Opgeblazen semantische modellen vreten aan je infrastructuurresources, vertragen de reactietijden van query's en frustreren zakelijke gebruikers die moeten wachten tot dashboards laden.

Om je rapporten op topsnelheid te laten draaien, beperk je berekende kolommen strikt tot situaties waarin waarden op rijniveau echt noodzakelijk zijn. Je gebruikt een berekende kolom bijvoorbeeld als je een relatiesleutel tussen tabellen moet bepalen op basis van meerdere parameters, of als de waarde in een slicer of een regel voor rijbeveiliging (RLS) moet worden gebruikt, waar measures niet zijn toegestaan.

Voor alle andere analytische berekeningen, zoals totalen, gemiddelden, verhoudingen en voorwaardelijke aggregaties, verplaats je de logica naar measures. Measures nemen geen opslagruimte in beslag omdat ze geen waarden in het model opslaan. Ze staan in het geheugen alleen als code en worden pas uitgevoerd wanneer een visual om de gegevens vraagt. Zo bespaar je RAM, maximaliseer je de compressie en blijft je cloudinfrastructuur soepel draaien.

Conclusie

Begrijpen wat het fundamentele verschil is tussen opslag op rijniveau en dynamische queryuitvoering is essentieel voor iedereen die schaalbare analyseoplossingen bouwt. Door onnodige berekende kolommen te vermijden en te kiezen voor dynamische measures, verbeter je de snelheid van je rapporten aanzienlijk en verminder je het geheugengebruik.

Wil je dit onderwerp verder verkennen en een volledige, jargonvrije uitleg horen over hoe de engine met je formules omgaat? Luister naar de volledige aflevering. Blijf voorop lopen met je cloudanalysestrategie door te luisteren naar meer expertinzichten in de M365 FM Podcast.

Veelgestelde vragen

Waarom gebruiken berekende kolommen zoveel geheugen in Power BI?

Berekende kolommen evalueren elke afzonderlijke rij tijdens het vernieuwen van de gegevens en slaan die waarden permanent op in het RAM-geheugen van het model. Hierdoor kan de VertiPaq-engine de gegevens niet goed comprimeren, wat snel leidt tot een opgeblazen model.

Nemen measures opslagruimte in beslag in een semantisch model van Power BI?

Nee, measures nemen geen opslagruimte in beslag. Ze worden alleen opgeslagen als formuledefinities in de metadata en worden pas dynamisch berekend wanneer een visual of een interactie van de gebruiker om de berekening vraagt.

Wanneer is het eigenlijk zinvol om een berekende kolom te gebruiken?

Berekende kolommen moet je reserveren voor specifieke situaties waarin een rijcontext noodzakelijk is, zoals het maken van samengestelde sleutels voor relaties, het toepassen van regels voor rijbeveiliging (RLS), of het leveren van items die als statische slicerwaarden moeten verschijnen.

Hoe beïnvloeden berekende kolommen de weergaveprestaties van rapporten?

Te veel berekende kolommen vergroten de totale omvang van het semantische model en verslechteren de datacompressie. Grotere modellen vragen meer geheugen en rekenkracht, wat uiteindelijk de queryuitvoering en laadtijden van rapporten in je hele werkruimte vertraagt.