Fonction DAX CALCULATETABLE Vs FILTER

et sont tous deux des outils puissants pour manipuler et analyser des données dans une requête DAX, mais ils présentent des différences clés qu'il est important de comprendre.

Dans ce blog, nous allons passer en revue la fonction CALCULATETABLE et son plan de requête dans DAX studio et comprendre en quoi elle diffère de la fonction FILTER . À la fin, vous comprendrez mieux comment choisir la bonne fonction pour vos besoins d'analyse de données.

Pour démontrer, nous utiliserons le code DAX ci-dessous.

Lorsque vous exécutez ce code, vous obtenez un tableau indiquant la marque et la couleur.

Dans l' onglet Plans de requête , vous obtiendrez un code correspondant à l' opérateur CrossApply dans le Formula Engine .

En même temps, vous pouvez voir que le code ne récupère que la couleur et la marque du produit dans l' onglet Server Timings .

Table des matières

• Résultat des synchronisations du serveur DAX Studio pour CALCULATETABLE
• Plan de requête CALCULATETABLE dans DAX Studio
• Transition de contexte pour des fonctions DAX similaires
  • Horaires du serveur
  • Plan de requête
• Conclusion

Résultat des synchronisations du serveur DAX Studio pour CALCULATETABLE

Par exemple, filtrons la couleur du produit pour n'afficher que le rouge et/ou le noir.

Vous pouvez le faire en utilisant la fonction FILTER. Lorsque vous l'exécutez, le Server Timings indique que l'argument FILTER n'est pas appliqué au code xmSQL .

Mais si vous utilisez la fonction CALCULATETABLE, la requête dans l'onglet Server Timings montrera que les résultats ont été filtrés par couleur de produit.

Plan de requête CALCULATETABLE dans DAX Studio

Examinons le plan de requête pour chaque fonction.

CALCULATETABLE se trouve sur la première ligne du plan de requête logique car il s'agit d'une fonction de niveau supérieur dans le code et ne dépend donc d'aucune exigence.

Lorsque vous lisez le plan de requête d'une fonction CALCULATETABLE, vous ne commencez pas par le premier argument. Vous devez d'abord comprendre le contexte de filtre utilisé. Passons donc à la ligne 5.

Vous pouvez voir que l' opérateur VertiPaq nécessite la colonne de couleur du produit en raison du filtre appliqué. Il analyse ensuite cette colonne et utilise la combinaison de filtres Not IsEmpty pour vérifier la couleur du produit par rapport à chaque ligne.

Une fois le contexte de filtre préparé, l' argument est exécuté.

Avec le recul, si vous utilisez la fonction FILTER, vous verrez un plan de requête différent, de sorte que l'argument CROSSJOIN est exécuté avant d'identifier le contexte de filtre.

L'inconvénient de cette approche est qu'elle ne pousse pas la condition de filtre vers le moteur de stockage. Vous ne pourrez pas utiliser la clause WHERE dans xmSQL, ce qui imposera une lourde charge au Formula Engine.

Et lorsque vous travaillez avec plusieurs tables, la combinaison de filtres de la fonction CROSSJOIN sera énorme. Cela ralentit les performances du code DAX. Ainsi, dans la plupart des cas, il est recommandé d'utiliser la fonction CALCULATETABLE.

Ainsi, au lieu d'effectuer tous les calculs dans le Formula Engine, vous pouvez injecter la condition de filtre dans la classe WHERE du code XMSQL.

Transition de contexte pour des fonctions DAX similaires

Horaires du serveur

Ce concept s'applique également à la fonction CALCULER. Utilisons le code DAX ci-dessous comme exemple.

Une mesure est automatiquement entourée d'une fonction CALCULER.

Lorsque vous exécutez ce code, vous obtenez un tableau indiquant le montant total des ventes pour chaque couleur.

Dans l'onglet Server Timings, vous pouvez voir que le code exécute deux requêtes. La première requête calcule la somme du montant Sales de la table Sales par rapport à la table Products.

En revanche, la deuxième requête récupère à nouveau la couleur du produit dans la table Produits. Il correspond à la fonction dans le code DAX.

Le moteur de formule place les caches de données des deux requêtes côte à côte. Il commence par récupérer les valeurs du deuxième cache de données, puis effectue une recherche dans le premier cache de données.

Plan de requête

Dans l'onglet Plan de requête, le plan de requête logique analyse la couleur du produit en raison de l' argument .

Ensuite, VertiPaq résume le montant total des ventes en fonction de la couleur du produit. Il effectue la transition de contexte qui convertit la valeur de couleur du produit en un contexte de filtre équivalent.

Le filtre créé par la transition de contexte est traduit en une propriété DependOnCols dans le plan de requête. Une fois que VertiPaq a scanné les colonnes requises pour calculer le total des ventes, il multiplie la quantité des ventes par le prix net.

Les ventes totales sont ensuite renvoyées sous la forme d'un type de données de devise. Et enfin, ADDCOLUMNS renvoie une table avec deux colonnes contenant le montant de la couleur et du total des ventes.

Conclusion

Le plan de requête peut avoir un impact significatif sur les performances d'une requête, car différents plans de requête peuvent avoir différents niveaux d'efficacité.

Lors de l'utilisation des fonctions CALCULATETABLE et FILTER dans une requête DAX, le plan de requête peut différer selon le scénario spécifique et divers facteurs, tels que l'expression de formule spécifique utilisée et les capacités du moteur de requête.

En général, il est conseillé de tester et de comparer les performances de différents plans de requête afin de déterminer l'approche la plus efficace pour un scénario donné.

Tous mes vœux,