DAX REKENTABEL versus FILTER-functie

Zowel als zijn krachtige tools voor het manipuleren en analyseren van gegevens in DAX-query's, maar ze hebben enkele belangrijke verschillen die belangrijk zijn om te begrijpen.

In deze blog gaan we in op de CALCULATETABLE- functie en het queryplan in DAX studio en begrijpen we hoe deze verschilt van de FILTER- functie. Aan het einde zult u een beter begrip hebben van hoe u de juiste functie kiest voor uw behoeften op het gebied van gegevensanalyse.

Ter demonstratie gebruiken we de onderstaande DAX-code.

Wanneer u deze code uitvoert, krijgt u een tabel met merk en kleur.

Op het tabblad Queryplannen krijgt u een code die overeenkomt met de CrossApply- operator in de Formula Engine .

Tegelijkertijd kunt u zien dat de code alleen de productkleur en het merk ophaalt op het tabblad Server Timings .

Inhoudsopgave

• DAX Studio Server Timings Resultaat voor CALCULATABEL
• BEREKENTABEL Queryplan in DAX Studio
• Contextovergang voor vergelijkbare DAX-functies
  • Servertijden
  • Vraagplan
• Conclusie

DAX Studio Server Timings Resultaat voor CALCULATABEL

Laten we als voorbeeld de productkleur filteren zodat alleen rood en/of zwart wordt weergegeven.

U kunt dit doen door de FILTER-functie te gebruiken. Wanneer u het uitvoert, zal de Server Timings laten zien dat het FILTER-argument niet wordt toegepast op de xmSQL-code .

Maar als u de CALCULATABEL-functie gebruikt, zal de query op het tabblad Server Timings laten zien dat de resultaten zijn gefilterd op productkleur.

BEREKENTABEL Queryplan in DAX Studio

Laten we eens kijken naar het queryplan voor elke functie.

De CALCULATETABLE bevindt zich op de eerste regel van het Logical Query Plan omdat het een functie op het hoogste niveau in de code is en daarom niet afhankelijk is van vereisten.

Wanneer u het queryplan van een CALCULATETABLE-functie leest, begint u niet met het eerste argument. U moet eerst de gebruikte filtercontext begrijpen. Dus laten we naar regel 5 gaan.

U kunt zien dat de VertiPaq- operator de productkleurkolom vereist vanwege het toegepaste filter. Vervolgens wordt deze kolom gescand en wordt de filtercombinatie Not IsEmpty gebruikt om de productkleur voor elke rij te controleren.

Nadat de filtercontext is voorbereid, wordt het argument uitgevoerd.

Als u achteraf de functie FILTER gebruikt, ziet u een ander queryplan, dus wordt het argument CROSSJOIN uitgevoerd voordat de filtercontext wordt geïdentificeerd.

Het nadeel van deze aanpak is dat de filtervoorwaarde niet naar de Storage Engine wordt doorgestuurd. U kunt de WHERE- component in xmSQL niet gebruiken, wat een zware belasting vormt voor de Formula Engine.

En wanneer u met meerdere tabellen werkt, zal de filtercombinatie van de CROSSJOIN-functie enorm zijn. Dit vertraagt ​​de prestaties van de DAX-code. Daarom wordt in de meeste gevallen aanbevolen om de functie CALCULATABEL te gebruiken.

Dus in plaats van alle berekeningen in de Formula Engine uit te voeren, kunt u de filtervoorwaarde in de WHERE-klasse van de XMSQL-code injecteren.

Contextovergang voor vergelijkbare DAX-functies

Servertijden

Dit concept is ook van toepassing op de functie CALCULATE. Laten we de onderstaande DAX-code als voorbeeld gebruiken.

Een maat heeft automatisch een CALCULATE functie eromheen.

Wanneer u deze code uitvoert, krijgt u een tabel met het totale verkoopbedrag voor elke kleur.

Op het tabblad Server Timings kunt u zien dat de code twee query's uitvoert. De eerste query berekent de som van het verkoopbedrag uit de tabel Verkoop ten opzichte van de tabel Producten.

Aan de andere kant haalt de tweede query de productkleur weer op uit de tabel Producten. Het komt overeen met de functie in de DAX-code.

De Formula Engine plaatst de gegevenscaches van de twee query's naast elkaar. Het begint met het ophalen van de waarden uit de tweede datacache en voert vervolgens een zoekopdracht uit in de eerste datacache.

Vraagplan

Op het tabblad Queryplan scant het Logische Queryplan de productkleur vanwege het argument .

Vervolgens somt VertiPaq het totale verkoopbedrag op, afhankelijk van de productkleur. Het voert de contextovergang uit die de productkleurwaarde converteert naar een equivalente filtercontext.

Het filter dat door de contextovergang is gemaakt, wordt vertaald naar een eigenschap DependOnCols in het Queryplan. Nadat VertiPaq de kolommen heeft gescand die nodig zijn om de totale verkoop te berekenen, vermenigvuldigt het de verkoophoeveelheid met de nettoprijs.

De Totale Verkoop wordt dan als resultaat geretourneerd in de vorm van een valutagegevenstype. En ten slotte retourneert ADDCOLUMNS een tabel met twee kolommen die de kleur en het totale verkoopbedrag bevatten.

Conclusie

Het queryplan kan een aanzienlijke invloed hebben op de prestaties van een query, aangezien verschillende queryplannen verschillende efficiëntieniveaus kunnen hebben.

Wanneer u de functies CALCULATETABLE en FILTER gebruikt in een DAX-query, kan het queryplan verschillen, afhankelijk van het specifieke scenario en diverse factoren, zoals de specifieke formule-expressie die wordt gebruikt en de mogelijkheden van de query-engine.

Over het algemeen is het een goed idee om de prestaties van verschillende queryplannen te testen en te vergelijken om de meest efficiënte aanpak voor een bepaald scenario te bepalen.

Al het beste,