Optimiser les modèles DirectQuery avec un stockage au niveau de la table
DirectQuery est un moyen d’obtenir des données dans Power BI Desktop. La méthode DirectQuery implique une connexion directe aux données de son référentiel source depuis Power BI Desktop. Il s’agit d’une alternative à l’importation de données dans Power BI Desktop.
Quand vous utilisez la méthode DirectQuery, l’expérience utilisateur globale dépend fortement des performances de la source de données sous-jacente. La lenteur des temps de réponse aux requêtes peut nuire à l’expérience utilisateur et, dans le pire des cas, les requêtes peuvent expirer. De plus, le nombre d’utilisateurs qui ouvrent les rapports en même temps alourdira la charge pesant sur la source de données. Par exemple, si votre rapport contient 20 visuels et que 10 personnes utilisent le rapport, 200 requêtes ou plus existent sur la source de données, car chaque visuel émet une ou plusieurs requêtes.
Malheureusement, les performances de votre modèle Power BI ne seront pas seulement affectées par les performances de la source de données sous-jacente, mais également par d’autres facteurs incontrôlables, tels que les suivants :
Latence du réseau : les réseaux plus rapides retournent les données plus rapidement.
Les performances du serveur de la source de données et la quantité d’autres charges de travail sur ce serveur. Par exemple, considérez les implications de l’actualisation d’un serveur pendant que des centaines de personnes utilisent ce même serveur pour différentes raisons.
Ainsi, l’utilisation de DirectQuery représente un risque pour la qualité des performances de votre modèle. Pour optimiser les performances dans ce cas, vous devez contrôler la base de données source ou y accéder.
Pour en savoir plus, consultez le Guide du modèle DirectQuery dans Power BI Desktop.
Implications de l’utilisation de DirectQuery
Il est recommandé d’importer des données dans Power BI Desktop, mais votre organisation peut avoir besoin d’utiliser le mode de connectivité des données DirectQuery pour l’une des raisons suivantes (avantages de DirectQuery) :
Il est approprié dans les cas où les données changent fréquemment et que la création de rapports en quasi-temps réel est nécessaire.
Il peut gérer des données volumineuses sans qu’il soit nécessaire d’effectuer une pré-agrégation.
Il applique des restrictions de souveraineté des données pour se conformer aux exigences légales.
Il peut être utilisé avec une source de données multidimensionnelle contenant des mesures telles que SAP Business Warehouse (BW).
Si votre organisation doit utiliser DirectQuery, vous devez clairement comprendre son comportement dans Power BI Desktop et bien connaître ses limites. Vous pourrez alors prendre des mesures pour optimiser le modèle DirectQuery autant que possible.
Comportement des connexions DirectQuery
Lorsque vous utilisez DirectQuery pour accéder aux données dans Power BI Desktop, cette connexion se comporte de la manière suivante :
Lorsque vous utilisez initialement la fonctionnalité Obtenir les données dans Power BI Desktop, vous sélectionnez la source. Si vous vous connectez à une source relationnelle, vous pouvez sélectionner un ensemble de tables, et chacune d’entre elles définit une requête qui retourne un jeu de données de façon logique. Si vous sélectionnez une source multidimensionnelle, par exemple SAP BW, vous ne pouvez sélectionner que celle-ci.
Lorsque vous chargez les données, aucune donnée n’est importée dans Power BI Desktop, seul le schéma est chargé. Lorsque vous créez un visuel dans Power BI Desktop, des requêtes sont envoyées à la source sous-jacente pour récupérer les données nécessaires. Le temps nécessaire à l’actualisation du visuel dépend des performances de la source de données sous-jacente.
Si des modifications sont apportées aux données sous-jacentes, elles ne s’afficheront pas immédiatement dans les visuels existants dans Power BI en raison de la mise en cache. Vous devez effectuer une actualisation pour voir ces modifications. Les requêtes nécessaires sont présentes pour chaque visuel, et les visuels sont mis à jour en conséquence.
Lorsque vous publiez le rapport dans le service Power BI, cela génère un modèle sémantique dans le service Power BI, identique à celui de l’importation. Cependant, aucune donnée n’est comprise dans ce modèle sémantique.
Lorsque vous ouvrez un rapport existant dans le service Power BI ou que vous en créez un, la source sous-jacente est à nouveau interrogée pour récupérer les données nécessaires. Selon l’endroit où se trouve la source d’origine, vous devrez peut-être configurer une passerelle de données locale.
Vous pouvez épingler des visuels ou des pages de rapport entières sous forme de vignettes de tableau de bord. Les vignettes sont actualisées automatiquement selon une planification, par exemple toutes les heures. Vous pouvez contrôler la fréquence de cette actualisation en fonction de vos besoins. Quand vous ouvrez un tableau de bord, les vignettes reflètent les données au moment de la dernière actualisation et peuvent ne pas inclure les dernières modifications apportées à la source de données sous-jacente. Vous pouvez toujours actualiser un tableau de bord ouvert pour vous assurer qu’il est à jour.
Limitations des connexions DirectQuery
L’utilisation de DirectQuery peut avoir des conséquences négatives. Les limitations varient selon la source de données utilisée. Tenez compte des points suivants :
Performances : comme indiqué plus haut, votre expérience utilisateur globale dépend fortement des performances de la source de données sous-jacente.
Sécurité : si vous utilisez plusieurs sources de données dans un modèle DirectQuery, il est important de comprendre comment les données se déplacent entre les sources de données sous-jacentes et les implications de sécurité associées. Vous devez également identifier si les règles de sécurité s’appliquent aux données de votre source sous-jacente car, dans Power BI, chaque utilisateur peut voir ces données.
Transformation des données : par rapport aux données importées, les données provenant de DirectQuery présentent des limites lors de l’application des techniques de transformation de données dans l’Éditeur Power Query. Par exemple, si vous vous connectez à une source OLAP, telle que SAP BW, vous ne pouvez pas effectuer de transformations ; l’intégralité du modèle externe est extraite de la source de données. Si vous souhaitez appliquer des transformations aux données, vous devez le faire dans la source de données sous-jacente.
Modélisation : certaines fonctionnalités de modélisation disponibles avec des données importées ne sont pas utilisables ou sont limitées dans le cadre de DirectQuery.
Création de rapports : presque toutes les fonctionnalités de création de rapports disponibles avec des données importées sont également prises en charge pour les modèles DirectQuery, à condition que la source sous-jacente offre un niveau de performances approprié. Cependant, lorsque le rapport est publié dans le service Power BI, les fonctionnalités Quick Insights et Q&R ne sont pas prises en charge. En outre, l’utilisation de la fonctionnalité Explorer dans Excel entraîne probablement une baisse des performances.
Pour en savoir plus sur les limitations liées à l’utilisation de DirectQuery, consultez Implications de l’utilisation de DirectQuery.
Le fonctionnement de base de DirectQuery et les limitations qu’il présente n’ayant plus de secret pour vous, vous pouvez prendre des mesures pour améliorer les performances.
Optimiser les performances
Pour reprendre le scénario de Tailwind Traders, lors de votre examen du modèle sémantique, vous découvrez que la requête a utilisé DirectQuery pour connecter Power BI Desktop aux données sources. Cette utilisation de DirectQuery est la raison pour laquelle les utilisateurs sont confrontés à des performances de rapport médiocres. Le chargement des pages dans le rapport prend trop de temps et les tables ne sont pas actualisées suffisamment rapidement quand certaines sélections sont effectuées. Vous devez prendre des mesures pour optimiser les performances du modèle DirectQuery.
Vous pouvez examiner les requêtes qui sont envoyées à la source sous-jacente afin d’essayer d’identifier la raison pour laquelle les performances de requête sont médiocres. Vous pouvez ensuite effectuer des modifications dans Power BI Desktop et la source de données sous-jacente pour optimiser les performances globales.
Optimiser les données dans Power BI Desktop
Quand vous avez optimisé la source de données autant que possible, vous pouvez prendre d’autres mesures dans Power BI Desktop en utilisant l’Analyseur de performances, dans lequel vous pouvez isoler les requêtes pour valider les plans de requête.
Vous pouvez analyser la durée des requêtes qui sont envoyées à la source sous-jacente pour identifier les requêtes dont le chargement prend beaucoup de temps. En d’autres termes, vous pouvez identifier où se trouvent les goulots d’étranglement.
Vous n’avez pas besoin d’utiliser une approche spéciale pour optimiser un modèle DirectQuery ; vous pouvez appliquer les mêmes techniques d’optimisation que celles que vous avez utilisées sur les données importées pour ajuster les données provenant de la source DirectQuery. Par exemple, vous pouvez réduire le nombre de visuels dans la page de rapport ou réduire le nombre de champs utilisés dans un visuel. Vous pouvez également supprimer les colonnes et les lignes inutiles.
Pour obtenir des conseils plus détaillés sur la façon d’optimiser une requête DirectQuery, consultez : Guide du modèle DirectQuery dans Power BI Desktop et Conseils pour utiliser DirectQuery avec succès.
Optimiser la source de données sous-jacente (base de données connectée)
Vous devez d’abord vous pencher sur la source de données. Vous devez optimiser la base de données source autant que possible, car tout ce qui permet d’améliorer ses performances améliorera également DirectQuery Power BI. Les actions que vous effectuez dans la base de données sont les plus efficaces.
Envisagez l’utilisation des pratiques de base de données standard ci-dessous, qui s’appliquent à la plupart des situations :
Évitez l’utilisation de colonnes calculées complexes, car l’expression de calcul est incorporée dans les requêtes source. Il est plus efficace de renvoyer (push) l’expression à la source, car cela évite l’envoi (push down). Vous pouvez également envisager d’ajouter des colonnes clés de substitution à des tables de type dimension.
Examinez les index et vérifiez que l’indexation actuelle est correcte. Si vous avez besoin de créer des index, assurez-vous qu’ils sont appropriés.
Reportez-vous aux documents d’aide de votre source de données afin d’implémenter leurs recommandations en matière de performances.
Personnaliser les options de réduction de requête
Power BI Desktop vous donne la possibilité d’envoyer moins de requêtes et de désactiver certaines interactions qui nuiront à l’expérience si les requêtes qui en résultent mettent longtemps à s’exécuter. L’application de ces options empêche les requêtes d’atteindre continuellement la source de données, ce qui devrait améliorer les performances.
Dans cet exemple, vous modifiez les paramètres par défaut pour appliquer les options de réduction de données disponibles à votre modèle. Pour accéder aux paramètres, sélectionnez Fichier>Options et paramètres>Options, puis faites défiler la page vers le bas et sélectionnez l’option Réduction des requêtes.
Les options de requête suivantes sont disponibles :
Réduire le nombre de requêtes envoyées par : par défaut, chaque visuel interagit avec tous les autres visuels. Si cette case est cochée, l’interaction par défaut est désactivée. Vous pouvez ensuite choisir les visuels qui interagissent les uns avec les autres à l’aide de la fonctionnalité Modifier les interactions.
Segments : par défaut, l’option Appliquer instantanément les changements de segment est sélectionnée. Pour forcer les utilisateurs du rapport à appliquer manuellement les changements de segment, sélectionnez l’option Ajouter un bouton Appliquer à chaque segment pour apporter les changements quand vous êtes prêt.
Filtres : par défaut, l’option Appliquer instantanément les changements de filtre de base est sélectionnée. Pour forcer les utilisateurs du rapport à appliquer manuellement les changements de filtre, sélectionnez l’une des options suivantes :
Ajouter des boutons Appliquer à chaque filtre de base pour appliquer les changements au besoin
Ajouter un seul bouton Appliquer au volet Filtre pour appliquer tous les changements à la fois (version préliminaire)
