DAX BEREGNETABEL Vs FILTER Funktion

Beggeoger kraftfulde værktøjer til at manipulere og analysere data i DAX-forespørgsler, men de har nogle vigtige forskelle, som er vigtige at forstå.

I denne blog vil vi gennemgå funktionen CALCUATETABLE og dens , og forstå, hvordan den adskiller sig fra FILTER -funktionen. Til sidst vil du have en bedre forståelse af, hvordan du vælger den rigtige funktion til dine dataanalysebehov.

For at demonstrere bruger vi DAX-koden nedenfor.

Når du kører denne kode, får du en tabel, der viser mærke og farve.

På fanen Forespørgselsplaner får du en kode, der svarer til CrossApply- operatoren i .

Samtidig kan du se, at koden kun henter produktfarve og mærke i fanen Server Timings .

Indholdsfortegnelse

• DAX Studio Server Timings Resultat for KALKULATTABEL
• BEREGNETABEL Forespørgselsplan i DAX Studio
• Kontekstovergang for lignende DAX-funktioner
  • Server timings
  • Forespørgselsplan
• Konklusion

DAX Studio Server Timings Resultat for KALKULATTABEL

Lad os som et eksempel filtrere produktfarven til kun at vise rød og/eller sort.

Det kan du gøre ved at bruge FILTER-funktionen. Når du kører det, vil servertimingerne vise, at FILTER-argumentet ikke anvendes på .

Men hvis du bruger funktionen CALCULATETABLE, vil forespørgslen på fanen Server Timings vise, at resultaterne er blevet filtreret efter produktfarve.

BEREGNETABEL Forespørgselsplan i DAX Studio

Lad os se på forespørgselsplanen for hver funktion.

CALCULATETABLE er på den første linje i den logiske forespørgselsplan, fordi det er en funktion på øverste niveau i koden og derfor ikke afhænger af nogen krav.

Når du læser forespørgselsplanen for en CALCULATETABLE-funktion, starter du ikke med det første argument. Du skal først forstå den anvendte filterkontekst. Så lad os gå til linje 5.

Du kan se, at operatøren kræver produktfarvekolonnen på grund af det anvendte filter. Den scanner derefter denne kolonne og bruger kombinationen Not IsEmpty Filter til at kontrollere produktfarven mod hver række.

Efter at filterkonteksten er blevet forberedt, udføres argumentet.

Set i bakspejlet, hvis du bruger FILTER-funktionen, vil du se en anden forespørgselsplan, så CROSSJOIN-argumentet udføres før identifikation af filterkonteksten.

Ulempen ved denne tilgang er, at den ikke skubber filtertilstanden til Storage Engine. Du vil ikke være i stand til at bruge WHERE -klausulen inde i xmSQL, som vil lægge en tung byrde på Formula Engine.

Og når du arbejder med flere tabeller, vil filterkombinationen af ​​CROSSJOIN-funktionen være enorm. Dette sænker ydeevnen af ​​DAX-koden. Derfor anbefales det i de fleste tilfælde at bruge funktionen CALCUATETABLE.

Så i stedet for at udføre alle beregningerne i Formula Engine, kan du injicere filterbetingelsen inde i WHERE-klassen i XMSQL-koden.

Kontekstovergang for lignende DAX-funktioner

Server timings

Dette koncept er også anvendeligt til CALCUATE-funktionen. Lad os bruge DAX-koden nedenfor som et eksempel.

Et mål har automatisk en CALCUATE-funktion omkring sig.

Når du kører denne kode, får du en tabel, der viser det samlede salgsbeløb for hver farve.

På fanen Server Timings kan du se, at koden udfører to forespørgsler. Den første forespørgsel beregner summen af ​​salgsbeløbet fra salgstabellen i forhold til tabellen produkter.

På den anden side henter den anden forespørgsel produktfarven igen fra tabellen Produkter. Det svarer til funktionen i DAX-koden.

Formula Engine placerer datacachene for de to forespørgsler side om side. Den starter med at hente værdierne fra den anden datacache og udfører derefter et opslag i den første datacache.

Forespørgselsplan

På fanen Forespørgselsplan scanner den logiske forespørgselsplan produktfarven på grund af argumentet.

Derefter opsummerer VertiPaq det samlede salgsbeløb afhængigt af produktfarven. Den udfører kontekstovergangen, der konverterer produktfarveværdien til en tilsvarende filterkontekst.

Filteret, der oprettes af kontekstovergangen, oversættes til en DependOnCols -egenskab i forespørgselsplanen. Efter at VertiPaq har scannet de kolonner, der er nødvendige for at beregne det samlede salg, ganges salgsmængden med nettoprisen.

Det samlede salg returneres derefter som et resultat i form af en valutadatatype. Og til sidst returnerer ADDCOLUMNS en tabel med to kolonner, der indeholder farven og det samlede salgsbeløb.

Konklusion

Forespørgselsplanen kan have en væsentlig indflydelse på en forespørgsels ydeevne, da forskellige forespørgselsplaner kan have forskellige effektivitetsniveauer.

Når du bruger funktionerne CALCULATETABLE og FILTER i en DAX-forespørgsel, kan forespørgselsplanen variere afhængigt af det specifikke scenarie og en række faktorer, såsom det specifikke formeludtryk, der bruges, og forespørgselsmotorens muligheder.

Generelt er det en god idé at teste og sammenligne ydeevnen af ​​forskellige forespørgselsplaner for at bestemme den mest effektive tilgang til et givet scenarie.

Alt det bedste,