Funzione DAX CALCULATETABLE Vs FILTER

Sia che sono strumenti potenti per la manipolazione e l'analisi dei dati nelle query DAX, ma presentano alcune differenze fondamentali che è importante comprendere.

In questo blog esamineremo la funzione CALCULATETABLE e il relativo piano di query in DAX Studio e capiremo in che modo differisce dalla funzione FILTER . Alla fine, avrai una migliore comprensione di come scegliere la funzione giusta per le tue esigenze di analisi dei dati.

Per dimostrarlo, utilizzeremo il codice DAX riportato di seguito.

Quando esegui questo codice, otterrai una tabella che mostra Brand e Color.

Nella scheda Piani di query , otterrai un codice corrispondente all'operatore CrossApply in Formula Engine .

Allo stesso tempo, puoi vedere che il codice recupera solo il colore e il marchio del prodotto nella scheda Server Timings .

Sommario

• Risultato tempistiche server DAX Studio per CALCULATETABLE
• Piano di query CALCULATETABLE in DAX Studio
• Transizione di contesto per funzioni DAX simili
  • Tempistiche del server
  • Piano di interrogazione
• Conclusione

Risultato tempistiche server DAX Studio per CALCULATETABLE

Ad esempio, filtriamo il colore del prodotto per mostrare solo il rosso e/o il nero.

Puoi farlo usando la funzione FILTRO. Quando lo esegui, i tempi del server mostreranno che l'argomento FILTER non è applicato al codice xmSQL .

Ma se utilizzi la funzione CALCULATETABLE, la query nella scheda Server Timings mostrerà che i risultati sono stati filtrati per colore del prodotto.

Piano di query CALCULATETABLE in DAX Studio

Diamo un'occhiata al piano di query per ciascuna funzione.

CALCULATETABLE si trova sulla prima riga del Logical Query Plan perché è una funzione di primo livello nel codice e pertanto non dipende da alcun requisito.

Quando leggi il piano di query di una funzione CALCULATETABLE, non inizi con il primo argomento. Devi prima capire il contesto del filtro utilizzato. Quindi andiamo alla riga 5.

Puoi vedere che l' operatore VertiPaq richiede la colonna del colore del prodotto a causa del filtro applicato. Quindi esegue la scansione di questa colonna e utilizza la combinazione del filtro Not IsEmpty per controllare il colore del prodotto rispetto a ciascuna riga.

Dopo che il contesto del filtro è stato preparato, viene eseguito l' argomento .

Col senno di poi, se utilizzi la funzione FILTER, vedrai un piano di query diverso, quindi l'argomento CROSSJOIN viene eseguito prima di identificare il contesto del filtro.

Lo svantaggio di questo approccio è che non invia la condizione del filtro allo Storage Engine. Non sarai in grado di utilizzare la clausola WHERE all'interno di xmSQL che metterà un pesante fardello sul Formula Engine.

E quando lavori con più tabelle, la combinazione di filtri della funzione CROSSJOIN sarà enorme. Ciò rallenta le prestazioni del codice DAX. Pertanto, nella maggior parte dei casi, si consiglia di utilizzare la funzione CALCULATETABLE.

Quindi, invece di eseguire tutti i calcoli nel Formula Engine, puoi inserire la condizione del filtro all'interno della classe WHERE del codice XMSQL.

Transizione di contesto per funzioni DAX simili

Tempistiche del server

Questo concetto è applicabile anche alla funzione CALCULATE. Usiamo il codice DAX riportato di seguito come esempio.

Una misura ha automaticamente una funzione CALCULATE attorno ad essa.

Quando esegui questo codice, otterrai una tabella che mostra l'importo totale delle vendite per ciascun colore.

Nella scheda Server Timings, puoi vedere che il codice sta eseguendo due query. La prima query calcola la somma dell'importo Sales dalla tabella Sales rispetto alla tabella Products.

La seconda query, invece, recupera nuovamente il colore del prodotto dalla tabella Prodotti. Corrisponde alla funzione nel codice DAX.

Il Formula Engine affianca le cache dei dati delle due query. Inizia recuperando i valori dalla seconda cache di dati e quindi esegue una ricerca nella prima cache di dati.

Piano di interrogazione

Nella scheda Piano di query, il Piano di query logico esegue la scansione del colore del prodotto a causa dell'argomento .

Quindi, VertiPaq riassume l'importo delle vendite totali in base al colore del prodotto. Esegue la transizione del contesto che converte il valore del colore del prodotto in un contesto di filtro equivalente.

Il filtro creato dalla transizione del contesto viene convertito in una proprietà DependOnCols nel piano della query. Dopo che VertiPaq ha scansionato le colonne necessarie per calcolare le vendite totali, moltiplica la quantità di vendita per il prezzo netto.

Le vendite totali vengono quindi restituite come risultato sotto forma di un tipo di dati valuta. Infine, ADDCOLUMNS restituisce una tabella con due colonne contenenti il ​​colore e l'importo delle vendite totali.

Conclusione

Il piano di query può avere un impatto significativo sulle prestazioni di una query, poiché diversi piani di query possono avere diversi livelli di efficienza.

Quando si usano le funzioni CALCULATETABLE e FILTER in una query DAX, il piano di query può variare a seconda dello scenario specifico e di una varietà di fattori, ad esempio l'espressione della formula specifica utilizzata e le funzionalità del motore di query.

In generale, è consigliabile testare e confrontare le prestazioni di diversi piani di query per determinare l'approccio più efficiente per un determinato scenario.

Ti auguro il meglio,