DAX CALCULATETABLE vs. FILTER-Funktion

Sowohl als auch sind leistungsstarke Tools zum Bearbeiten und Analysieren von Daten in DAX-Abfragen, weisen jedoch einige wichtige Unterschiede auf, die es zu verstehen gilt.

In diesem Blog gehen wir auf die Funktion CALCULATETABLE und ihren Abfrageplan in DAX Studio ein und verstehen, wie sie sich von der Funktion FILTER unterscheidet . Am Ende werden Sie besser verstehen, wie Sie die richtige Funktion für Ihre Datenanalyseanforderungen auswählen.

Zur Veranschaulichung verwenden wir den folgenden DAX-Code.

Wenn Sie diesen Code ausführen, erhalten Sie eine Tabelle mit Marke und Farbe.

Auf der Registerkarte „Abfragepläne“ erhalten Sie einen Code, der dem CrossApply- Operator in der Formel-Engine entspricht .

Gleichzeitig können Sie sehen, dass der Code nur die Produktfarbe und -marke auf der Registerkarte „Server-Timings“ abruft .

Inhaltsverzeichnis

• DAX Studio Server-Timings-Ergebnis für CALCULATETABLE
• BERECHNBARER Abfrageplan in DAX Studio
• Kontextübergang für ähnliche DAX-Funktionen
  • Server-Timings
  • Abfrageplan
• Abschluss

DAX Studio Server-Timings-Ergebnis für CALCULATETABLE

Filtern wir beispielsweise die Produktfarbe so, dass nur Rot und/oder Schwarz angezeigt wird.

Sie können dies tun, indem Sie die FILTER-Funktion verwenden. Wenn Sie es ausführen, zeigen die Server-Timings an, dass das FILTER-Argument nicht auf den xmSQL-Code angewendet wird .

Wenn Sie jedoch die Funktion CALCULATETABLE verwenden, zeigt die Abfrage auf der Registerkarte „Server-Timings“ an, dass die Ergebnisse nach Produktfarbe gefiltert wurden.

BERECHNBARER Abfrageplan in DAX Studio

Schauen wir uns den Abfrageplan für jede Funktion an.

Die CALCULATETABLE befindet sich in der ersten Zeile des logischen Abfrageplans, da es sich um eine Funktion der obersten Ebene im Code handelt und daher nicht von irgendwelchen Anforderungen abhängt.

Wenn Sie den Abfrageplan einer CALCULATETABLE-Funktion lesen, beginnen Sie nicht mit dem ersten Argument. Sie müssen zunächst den verwendeten Filterkontext verstehen. Gehen wir also zu Zeile 5.

Sie können sehen, dass der VertiPaq- Operator aufgrund des angewendeten Filters die Spalte „Produktfarbe“ benötigt. Anschließend wird diese Spalte gescannt und mithilfe der Filterkombination „Not IsEmpty“ die Produktfarbe anhand jeder Zeile überprüft.

Nachdem der Filterkontext vorbereitet wurde, wird das Argument ausgeführt.

Wenn Sie im Nachhinein die FILTER-Funktion verwenden, sehen Sie einen anderen Abfrageplan, sodass das CROSSJOIN-Argument vor der Identifizierung des Filterkontexts ausgeführt wird.

Der Nachteil dieses Ansatzes besteht darin, dass die Filterbedingung nicht an die Speicher-Engine übertragen wird. Sie können die WHERE- Klausel nicht in xmSQL verwenden, was die Formel-Engine stark belastet.

Und wenn Sie mit mehreren Tabellen arbeiten, ist die Filterkombination der CROSSJOIN-Funktion sehr umfangreich. Dies verlangsamt die Leistung des DAX-Codes. Daher empfiehlt es sich in den meisten Fällen, die Funktion CALCULATETABLE zu verwenden.

Anstatt also alle Berechnungen in der Formel-Engine durchzuführen, können Sie die Filterbedingung in die WHERE-Klasse des XMSQL-Codes einfügen.

Kontextübergang für ähnliche DAX-Funktionen

Server-Timings

Dieses Konzept ist auch auf die CALCULATE-Funktion anwendbar. Nehmen wir den folgenden DAX-Code als Beispiel.

Eine Kennzahl ist automatisch von einer CALCULATE-Funktion umgeben.

Wenn Sie diesen Code ausführen, erhalten Sie eine Tabelle mit dem Gesamtverkaufsbetrag für jede Farbe.

Auf der Registerkarte „Server-Timings“ können Sie sehen, dass der Code zwei Abfragen ausführt. Die erste Abfrage berechnet die Summe des Verkaufsbetrags aus der Tabelle „Sales“ in Bezug auf die Tabelle „Products“.

Andererseits ruft die zweite Abfrage die Produktfarbe erneut aus der Tabelle „Products“ ab. Es entspricht der Funktion im DAX-Code.

Die Formel-Engine platziert die Datencaches der beiden Abfragen nebeneinander. Es beginnt mit dem Abrufen der Werte aus dem zweiten Datencache und führt dann eine Suche im ersten Datencache durch.

Abfrageplan

Auf der Registerkarte „Abfrageplan“ scannt der logische Abfrageplan die Produktfarbe aufgrund des Arguments.

Dann summiert VertiPaq den Gesamtverkaufsbetrag abhängig von der Produktfarbe. Es führt den Kontextübergang durch, der den Produktfarbwert in einen äquivalenten Filterkontext umwandelt.

Der durch den Kontextübergang erstellte Filter wird im Abfrageplan in eine DependOnCols- Eigenschaft übersetzt. Nachdem VertiPaq die zur Berechnung des Gesamtumsatzes erforderlichen Spalten gescannt hat, multipliziert es die Verkaufsmenge mit dem Nettopreis.

Als Ergebnis werden dann die Gesamtumsätze in Form eines Währungsdatentyps zurückgegeben. Und schließlich gibt ADDCOLUMNS eine Tabelle mit zwei Spalten zurück, die die Farbe und den Gesamtverkaufsbetrag enthalten.

Abschluss

Der Abfrageplan kann einen erheblichen Einfluss auf die Leistung einer Abfrage haben, da unterschiedliche Abfragepläne unterschiedliche Effizienzgrade aufweisen können.

Wenn Sie die Funktionen CALCULATETABLE und FILTER in einer DAX-Abfrage verwenden, kann der Abfrageplan je nach dem spezifischen Szenario und einer Vielzahl von Faktoren, wie z. B. dem spezifischen verwendeten Formelausdruck und den Fähigkeiten der Abfrage-Engine, unterschiedlich sein.

Im Allgemeinen empfiehlt es sich, die Leistung verschiedener Abfragepläne zu testen und zu vergleichen, um den effizientesten Ansatz für ein bestimmtes Szenario zu ermitteln.

Alles Gute,