- januari 25, 2021
- Power BI
Performanceproblemen in Power BI worden meestal veroorzaakt door ofwel de manier waarop de gegevens in het model zijn gestructureerd of door inefficiënte DAX. Als het gaat om het datamodel, is DAX studio nodig om de oorzaak te kunnen vinden. Deze blog post gaat echter over de optimalisatie van DAX code. Waar overigens ook DAX Studio voor nodig is!
Wat u moet weten, eenvoudig gezegd, is dat de engine die uw DAX verwerkt eigenlijk niet één engine is maar twee engines die dicht bij elkaar werken: een extreem snelle engine die alleen eenvoudige code kan verwerken, de Storage Engine (SE) genaamd. En een snelle, maar zeker niet even snelle, die alle code kan verwerken, de Formula Engine (FE) genaamd. Dit is hoe Microsoft erin geslaagd is snelheid en complexiteit met elkaar in evenwicht te brengen. Waar DAX performance tuning uiteindelijk op neerkomt is het verschuiven van de werklast van de FE naar de SE. Dus dat vereist alleen het gebruik van code die de Storage Engine aankan. Er is veel te vertellen over de interne werking van deze engines, maar laat ik het zo eenvoudig mogelijk houden door te zeggen dat de SE queries ontvangt die worden beschreven in een taal die xmSQL heet. Hier is de xmSQL die de SE kan verwerken.
Lijst van beschikbare xm_SQL formules
De code die je nu hebt geschreven in je model s blijkbaar traag, anders zou je dit nu niet nog lezen 😉. Dus hoe zorg je ervoor dat je alleen deze formules gebruikt en het daardoor sneller maakt? Wel, je bent waarschijnlijk in een van de "performance valkuilen" gevallen waar je uit kunt komen door deze optimalisatie strategieën te volgen.
1. Vermijd het gebruik van een FILTER tabelformule in een CALCULATE Boolean test (een waar of onwaar test). Deze eerste strategie kent echter een paar uitzonderingen. U kunt het gebruik van een tabelfilter met FILTER niet vermijden wanneer:
- Voor de test zijn meerdere kolommen nodig
- Je moet een maatregel voor de test noemen
- Je moet nog een CALCULATE gebruiken voor de test
2. Wanneer het gebruik van FILTER niet kan worden vermeden, gebruik dan alleen de kolommen die werkelijk nodig zijn voor de test in plaats van de volledige tabel
3. Vermijd IF statements
4. Vermijd te moeten vertrouwen op de CallbackDataID
5. Vermijd het activeren van een contextovergang wanneer dat niet nodig is
6. Vermijd waar mogelijk het gebruik van dubbele iterators
Je wilt een berekening baseren op de taxidataset van NYC. Meer specifiek wilt u de ritafstand gedeeld door het ritbedrag, maar alleen voor ritten waarbij het ritbedrag niet gelijk is aan 0, anders zou u een fout krijgen. Hier is uw eerste poging en de statistieken van deze code in DAX studio.
Nu, ik heb de Lijst van beschikbare xm_SQL formules niet voor niets toegevoegd 😉. IF statements staan er bijvoorbeeld niet op. En in dit geval is er ook geen nodig. Je hebt er al voor gezorgd dat delen door 0 niet in een fout resulteert door de DIVIDE formule te gebruiken in plaats van de / operator.
Dus laten we deze code herschrijven en KISS (Keep It Simple Stupid!).
Dus dat hielp een beetje, maar niet zoveel als je waarschijnlijk gehoopt had. Dus laten we verder gaan en kijken hoe de motor onze code eigenlijk verwerkt. In plaats van te kijken naar de statistieken in DAX Studio, laten we nu kijken naar de xmSQL in DAX Studio (onderaan deze schermafdruk).
Je hoeft in dit geval niet de hele xm_SQL te lezen om te zien dat er een CallbackDataID aanwezig is. Dat betekent dat de SE dit niet helemaal zelf kan doen en hulp vraagt aan de FE, wat komt doordat de DIVIDE formule niet op de lijst van beschikbare xm_SQL formules staat. En je wilt wel proberen om de SE al het werk te laten doen. Nu, welke formules kunt u vinden op het xmSQL formules overzicht die de dag zouden kunnen redden? Precies, FILTER en de / operator. Dus als u erin zou slagen om zich te ontdoen van de reizen waar de fare_amount gelijk is aan nul met behulp van FILTER, kunt u zich te ontdoen van de DIVIDE formule door deze te vervangen door de / operator en je zou het werk te duwen naar de SE. Laten we dat eens proberen.
Succes! De DAX code heeft niet langer een CallbackDataID nodig en we zijn erin geslaagd 62% van de initiële verwerkingstijd te verminderen.
Laatste woorden
Snellere DAX schrijven betekent hetzelfde resultaat op een snellere en dus andere manier bereiken. Je moet dus in staat zijn om DAX op een behoorlijk niveau te schrijven vooraleer je aan het optimaliseren ervan kan beginnen. En dan nog, het zal niet gemakkelijk zijn. Maar het is mogelijk en jij kan het ook leren! Als je maar... mijn DAX cursus gevolgd hebt door de Advanced Power BI cursus 😉. Daar leer je alles over en nog veel meer.
