Power BI performance optimizer: in 3 stappen naar topprestaties

Een rapport of een dashboard opstarten en dan alle tijd hebben om uitgebreid koffie te gaan halen omdat de performance dramatisch is… herkenbaar? Je bent niet de enige, met de toenemende beschikbaarheid van data en de steeds betere visuele mogelijkheden van tools als Power BI worden ook de toepassingen ambitieuzer:

 

• Bepalen welke klanten en producten veel, weinig of zelfs negatief bijdragen aan de bedrijfswinst?
• Of op basis van alle productie, logistieke en sales data het wereldwijde planproces optimaliseren?
• De actuele toestand van een netwerk doorrekenen op basis van sensordata?

 

En die ambitie is logisch, want veel data gedreven inzichten worden zo veel waardevoller wanneer de gevraagde stuurinformatie ook tot in groot detail, volledig en actueel beschikbaar is. Helaas zien we regelmatig Power BI dashboards voorbij komen met een prachtig doel die volledig vastlopen door slechte performance.

 

Om een Power BI dashboard snel te laten werken is kennis van alle facetten van Power BI nodig. In dit blog beschrijven we hoe we onze klanten in drie stappen helpen om hun Power BI performance issues te lijf te gaan.

 

Een strakke benchmark

‘Goede performance’ is een rekbaar begrip en niet voor iedereen hetzelfde. Daarom is het belangrijk om te bepalen wat je gaat meten (en verbeteren) en wat een meetbare ‘goede performance’ is. Dit blog gaat over interactieve performance, dus de reactietijd wanneer een gebruiker filtert of doorklikt in een Power BI dashboard. We starten met de definitie van een strakke reproduceerbare benchmark, bijvoorbeeld:

 

• Initieel openen van een Power BI dashboard: maximaal vier seconden
• Vervolg interacties zoals filteren of doorklikken: maximaal twee seconden

 

Doorgaans hebben we het dan over performance in ImportQuery modus waarbij het dashboard draait in de Power BI Cloud service. Na het bepalen van deze benchmark gaan we aan de slag met de performance verbeteringen via een aantal stappen.

 

Stap 1 – Dataset

De dataset is de basis van Power BI. We kijken eerst naar hoe de dataset is gemodelleerd, welke relaties zijn gelegd, hoe die relatiesleutels zijn opgebouwd en wat de kardinaliteit (1:1, 1:n, n:n) is van de objecten onderling. Het is een best practice om elke Power BI dataset op te zetten volgens een ster schema op basis van centrale Fact (of ‘event’) tabellen en Dimensies (of ‘context’) tabellen. Daarnaast checken we of er kolommen, tabellen of relaties verwijderd of geoptimaliseerd kunnen worden. Ook zetten we de Power BI ‘Auto-Date’ functie uit. Resultaat is een dataset die zo gemodelleerd is dat we in stappen twee en drie tot goede performance kunnen komen. Bijkomende voordeel is dat de dataset ook niet onnodig groot wordt qua records, kolommen en MB’s.

 

Stap 2 – Rapport design

Het visuele design van het Power BI rapport heeft invloed op de prestaties. Met name tooltips, custom visuals en grote hoeveelheden slicers kunnen resulteren in vele seconden wachttijd. Let er ook op dat op de eerste pagina van een Power BI rapportage bijna nooit alle data getoond moet worden: less is more! De eerste pagina moet gaan over afwijkingen en benodigde actie. Dat kan het best op basis van alleen de top 10 of bottom 10 te tonen van grote datasets, of de laatste maande, of de year to date prestaties in enkele KPI’s. Doorklikken naar een bredere overzichten of meer details kan daarna altijd nog.

 

Stap 3 – DAX & VertiPaq

Waar stappen één en twee redelijk goed te doen zijn voor minder ervaren Power BI gebruikers worstelen de meeste van onze klanten met stap 3: optimalisatie van dashboards door de DAX code te verbeteren. De sleutel zit hem daarbij in het beter gebruik maken van de onderliggende Power BI ‘engines’ die de DAX code uitvoeren. Dit zijn de Formula Engine en de Storage Engine (ook bekend als VertiPaq engine). Hier valt enorm veel winst te behalen die vaak het verschil maakt tussen een onbruikbaar rapport of juist een heel responsief rapport. We hebben prestatieverbeteringen van 50 tot 750x gerealiseerd door dit deel te verbeteren. Let wel: een goede dataset is altijd een randvoorwaarde om DAX code optimaal te laten presteren.

 

De kern van performanceverbeteringen onder stap 3 zit hem in twee aspecten. Ten eerste kun je met de DAX code bepalen welke data in memory wordt geladen. Als je in de berekening van DAX meetwaarden alleen de data in memory neemt die je nodig hebt, en goed doorbouwt op variabelen en arrays, scheelt dat al heel veel! Ook kan je in de DAX code deels bijsturen of query’s opgepakt worden door de Formula Engine (langzaam en ook nog eens single threaded!) of door de Storage Engine (snel en multi threaded). Ook kan je het aantal query’s naar deze engines minimaliseren. Als je dan ook nog zoveel mogelijk query’s laat uitvoeren door de Storage Engine schiet de performance omhoog.

 

Er een element van trial & error in deze aanpak omdat Power BI nog niet vooraf query plans kan generen zoals database ontwikkelaars gewend zijn. Wel zijn er diverse blogs en andere resources beschikbaar waar delen van deze kennis te vinden is, en tenslotte is de ervaring van de Power BI DAX programmeur onmisbaar. Om een tipje van de sluier op te lichten: kijk eens naar DAX Studio, DAX Guide, DAX Column fusion en DAX strict versus eager evaluation. Succes! En, mocht je vragen hebben, bel ons dan gerust.

 

Maak de stap naar topprestaties

Heb jij een enorm mooie, waardevolle Power BI toepassing die niet uit de verf komt doordat de huidige performance niet toereikend lijkt? Op basis van een toelichting van de data, de toepassing en KPI’s en een interne analyse van de opbouw van het Power BI rapport kunnen we in de regel binnen een paar dagen aangeven welke verbeteringen mogelijk zijn en wat je mag verwachten qua performance verbetering. Bovendien nemen we de Power BI gebruiker van onze klanten ook altijd mee in het verbetertraject zodat ze daarna zelf in staat zijn om dit in de praktijk te brengen en op door te bouwen!