Comprenons cela en détail. Lorsque nous faisons glisser un champ dans une ligne/colonne de matrice/table ou sur l’axe X/Y/Légende d’un graphique à colonnes/lignes, Power BI regroupe en interne les données pour obtenir des valeurs uniques dans ces champs. Lorsque vous faites glisser un champ ou une mesure dans la zone de valeurs, Power BI applique en interne une opération d’agrégation telle que SOMME, COMPTE, MOYENNE, MIN, MAX, etc. Lorsque plusieurs tables sont connectées à l’aide d’une relation, lorsque vous faites glisser l’un des champs / mesures de ces colonnes, fusion interne de ces tables est effectuée par Power BI en arrière-plan. Et lors de la sélection de valeur (s) dans le trancheur ou les filtres, l’opération de filtrage est effectuée.
Power BI a 2 mains puissantes, DAX (alimenté par SQL Server Analysis Service) et Script M (optimisé par Power Query), pour effectuer les tâches ETL et les calculs liés à la visualisation. Ces deux moteurs sont efficaces avec leur façon d’effectuer des calculs. Mais lorsqu’il s’agit d’effectuer des calculs de manière optimisée, les deux sous-performent par rapport aux moteurs de base de données, car ce sont des moteurs de calcul en mémoire les mieux adaptés pour jouer avec les données. Ils manquent d’indexation des données, que la base de données gère lors du stockage des données. De plus, le moteur de base de données réutilise les résultats des dernières requêtes, en gardant une trace de l’évolution des données, ce qui est quelque chose de complexe pour DAX et Power Query. À mesure que la taille des données augmente, la différence de performances est assez notable.
Dans quel scénario le mode Import est-il plus performant que Direct Query ?
C’est un mythe que la requête directe est toujours plus rapide que l’importation. Il peut y avoir des scénarios où l’inverse est observé
-
Ne pas utiliser la fonction d’indexation de la base de données. Cela peut créer une situation dans laquelle le serveur de base de données prend trop de temps pour lire les données du disque, alors que les calculs en mémoire par Power BI lui-même peuvent fonctionner un peu plus rapidement.
-
Serveur de base de données en cours d’exécution avec très peu de ressources (comme le processeur, la RAM, etc.). Dans ce scénario, le serveur de base de données peut avoir de graves difficultés avec les ressources pour récupérer les données. Bien que le service Power BI s’exécute sur des ressources Azure partagées, il peut être plus performant dans ce cas.
-
De nombreux utilisateurs simultanés interrogent la base de données. Power BI déclenche pratiquement plusieurs requêtes SQL pour plusieurs visuels. S’il y a des verrous sur la table, cela peut entraîner une longue attente de blocage des visuels Power BI.
-
Long temps de connexion à la base de données. Cela se produit lorsque la demande de connexion à la base de données est adressée au serveur sur site via un VPN ayant une latence élevée. Si le volume de données n’est pas assez important, il serait judicieux d’importer des données au lieu d’une requête directe. Avec l’importation, profitez toujours du bon service de la ressource Azure en back-end sur le service Power BI.
Direct Query est-il en temps réel ?
Non, il faut faire une distinction entre Live et Realtime. Direct Query est une connexion en direct. Chaque fois que le rapport est ouvert, une nouvelle connexion au serveur de base de données est établie pour extraire les dernières données. Mais le visuel ne sera pas automatiquement mis à jour pour les changements de base de données affectant le visuel comme un téléscripteur du marché de la sécurité. Après avoir ouvert l’écran, il deviendra statique. Ce n’est qu’après avoir appuyé sur Actualiser ou réouvrir le rapport que de nouvelles données seront chargées.
Source link