Optimiser des modèles DirectQuery avec un stockage au niveau de la table

DirectQuery est un mode de stockage dans lequel Power BI se connecte directement à la source de données. Il s’agit d’une alternative à l’importation de données dans des tables de modèle.

Lorsque vous utilisez le mode de stockage DirectQuery, les temps de réponse aux requêtes dépendent 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 états en même temps alourdit la charge pesant sur la source de données. Par exemple, si une page d’état comporte 20 visuels et que 10 personnes ouvrent cette page, 200 requêtes (ou plus) sont envoyées à la source de données, car chaque visuel émet une ou plusieurs requêtes.

Malheureusement, les performances de votre modèle sémantique sont non seulement impactées par les performances de la source de données sous-jacente, mais aussi 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 Conseils sur le modèle DirectQuery dans Power BI Desktop.

Implications de l’utilisation de DirectQuery

Il est recommandé d’importer des données dans vos tables de modèle, mais votre organisation peut avoir besoin d’utiliser le mode de stockage 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 d’états 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 comportant des mesures telles que SAP Business Warehouse (BW).

Si votre organisation souhaite utiliser DirectQuery, vous devez clairement comprendre son comportement 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 ajoutez un visuel à un état, 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’affichent pas immédiatement dans les visuels existants 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 fichier Power BI Desktop dans le service Power BI, celui-ci publie un modèle sémantique. Cependant, aucune donnée n’est comprise dans ce modèle sémantique.
• Lorsque vous ouvrez un état 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 d’état 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 avec Power Query. Par exemple, si vous vous connectez à une source OLAP comme 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 que vous avez avec des données importées ne sont pas disponibles ou sont limitées.
• Reporting : la quasi-totalité des fonctionnalités de reporting que vous avez 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 performance approprié.

Pour en savoir plus sur les limitations liées à l’utilisation de DirectQuery, consultez Implications de l’utilisation de DirectQuery.

Le fonctionnement de DirectQuery et ses limitations 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 le modèle se connecte aux données sources à l’aide de DirectQuery. Cette utilisation de DirectQuery est la raison pour laquelle les utilisateurs sont confrontés à des performances d’état médiocres. Le chargement des pages dans l’état 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

Lorsque vous avez optimisé la source de données autant que possible, vous pouvez prendre d’autres mesures dans Power BI Desktop à l’aide de 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 envoyées à la source sous-jacente pour identifier les requêtes dont le chargement prend beaucoup de temps. Autrement dit, 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 vous permettant d’ajuster les données importées. Par exemple, vous pouvez réduire le nombre de visuels sur la page d’état 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 retransmettre l’expression à la source, car cela évite le pushdown. Vous pouvez également envisager d’ajouter des colonnes clés de substitution à des tables dimensionnelles.
• Examinez les index de tables source et vérifiez que l’indexation actuelle est optimale. Si vous devez créer des index, assurez-vous qu’ils sont appropriés.

Consultez les documents de référence de votre source de données afin d’implémenter leurs recommandations en matière de performances.

Personnaliser les options de réduction des requêtes

Power BI Desktop vous permet d’envoyer moins de requêtes et de désactiver certaines interactions qui nuiront à l’expérience lorsque 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 état. 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 réduction des requêtes 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 de l’état à 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 de l’état à 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)