Le Post Infeeny

Les articles des consultants et experts Infeeny

[DAX] Inside DAX Query Plans

Speaker : Marco Russo – Durée : 75 mn – Niveau : 400

Objectif de la session

Plonger dans le SQL Profiler pour analyser les plans d’exécution DAX.

Introduction

Pour attaquer un modèle tabulaire on peut utiliser du MDX, DAX pour attaquer le moteur de stockage VertiPaq

Le moteur VertiPaq exécute une requête en parallèle, un cœur par segment

Le formula engine est optimisé pour des exécutions sur des données compressées.

Dax Query Plan Types

On a deux types de plan d’exec : 1 logique (le flux logique de la requête), 1 physique (celui qu’on va analyser pour optimiser les perfs)

Les évènements à tracer sont les suivants :

  • Errors,
  • Query begin,
  • Query end,
  • Dax Query Plan,
  • VertiPaq SE Query Begin,
  • VertiPaq SE Query Cache Match,
  • Vertipaq SE Query End

N.B : quand 2 requêtes sont lancées en parallèle, 1 requête peut utiliser le résultat de l’autre dans le cache, ce qui augmente les perfs.

Comprendre les traces

Les traces sous SQL Server ne sont pas évidentes à lire. La solution est de récupérer DAX Studio disponible sur codeplex.

Outil bien complet avec un requêteur, un profiler permettant de récupérer les traces le tout pouvant être manipulé dans Excel avec le plugin disponible aussi sur codeplex.

Les traces dans DAX Studio permettent de mettre en évidence les points sur lesquels nous devons faire attention (ils apparaissent en rouge)

Les opérations VertiPaq

  • VertiScan => Filtre les données sur un ou plusieurs colonnes
  • VertiCalc => pour des calculs simples les calculs sont faits par le moteur, pour des calculs complexes le moteur fait appel au formula engine pour effectuer les calculs et effectuer des allers retours

Exemple :

  • Le SUM est exécuté dans le moteur xVelocity et pas dans le Formula Engine. Le SUM est donc très performant.
  • Le SUMX est exécuté dans le Formula Engine car il évalue les calculs ligne à ligne. Tant que les calculs sont simples et que le logical plan ne fait pas de CallbackDataID les calculs se font dans le storage engine. Dès qu’on voit apparaître le CallbackDataID  c’est que le moteur appelle le formula engine pour chaque ligne. Lorsque vous manipuler plusieurs millions de lignes cela peut plomber les performances.

N.B : N’oubliez pas de vider le cache lors de vos tests.

Notez qu’actuellement, on ne voit pas dans le plan d’exécution les plans d’exécutions internes utilisées sur des calculs complexes. Faites attention au CallbackDataID

Quelques astuces

  • Sur les traces dès que vous avez du CallbackDataID sur le DAX Query Plan c’est que le Formula Engine est sollicité. Cela signifie que vous pouvez améliorer la requête DAX.
  • Si le DAX query plan est trop compliqué à comprendre vous pouvez déjà identifier certains problèmes en étudiant les VertiPaq SE Query
  • Filtrez les données au plus tôt afin d’économiser les opérations effectuées et de réduire le plan d’exécution
  • Utilisez les relations car elles peuvent être poussées jusqu’au moteur VertiPaq (surtout si vous n’avez pas de relation au niveau du modèle et si vous pouvez raccourcir le chemin, car le moteur n’utilise par défaut que les relations déclarées sur le modèle)

Conclusion

Un super boulot de Marco Russo qui arrive à vulgariser et expliquer la mécanique interne du moteur VertiPaq.

Frédéric

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :