Guide d’optimisation pour Power BI

  • Article

Cet article fournit des conseils qui permettent aux développeurs et aux administrateurs de créer et de gérer des solutions Power BI optimisées. Vous pouvez optimiser votre solution sur différentes couches architecturales. Les couches sont les suivantes :

  • la ou les sources de données
  • le modèle de données
  • des visualisations, y compris des tableaux de bord, rapports Power BI et rapports paginés Power BI
  • l’environnement, y compris les capacités, les passerelles de données et le réseau

Optimisation du modèle de données

Le modèle de données prend en charge l’intégralité de l’expérience de visualisation. Les modèles de données sont hébergés dans l’écosystème Power BI ou en externe (à l’aide de DirectQuery ou d’une connexion active). Dans Power BI, ils sont appelés modèles sémantiques et étaient appelés précédemment jeux de données. Il est important de comprendre vos options et de choisir le type de modèle sémantique approprié pour votre solution. Les trois modes de modèle sémantique sont les suivants : Import, DirectQuery et Composite. Pour plus d’informations, consultez Modèles sémantiques dans le service Power BI et Modèles sémantiques dans le service Power BI.

Pour obtenir des conseils spécifiques sur le mode de modèle sémantique, consultez :

Optimisation des visualisations

Les visualisations Power BI peuvent être des tableaux de bord, des rapports Power BI ou des rapports paginés Power BI. Chacun d’eux a des architectures différentes et, par conséquent, chacun possède ses propres conseils.

Tableaux de bord

Il est important de comprendre que Power BI conserve un cache pour vos mosaïques de tableaux de bord, à l’exception des mosaïques de rapport actif et des mosaïques de diffusion en continu. Si votre modèle sémantique applique la sécurité au niveau des lignes dynamique, veillez à comprendre les implications en matière de performances, car les mosaïques seront mises en cache par utilisateur.

Lorsque vous épinglez des mosaïques de rapports actifs à un tableau de bord, elles ne sont pas traitées à partir du cache de requête. Au lieu de cela, elles se comportent comme des rapports et adressent des requêtes aux v-cores à la volée.

Comme son nom l’indique, la récupération des données à partir du cache offre des performances supérieures et plus cohérentes que par la source de données. Pour tirer parti de cette fonctionnalité, vous pouvez notamment définir les tableaux de bord comme page d’accueil pour vos utilisateurs. Épinglez les éléments visuels les plus utilisés et demandés aux tableaux de bord. Les tableaux de bord deviennent ainsi une « première ligne de défense » utile qui fournit des performances cohérentes et une charge moindre sur la capacité. Les utilisateurs peuvent encore cliquer pour accéder au rapport afin d’analyser les détails.

Pour les modèles sémantiques de connexions actives et DirectQuery, le cache est mis à jour régulièrement en interrogeant la source de données. Par défaut, cela se produit toutes les heures, même si vous pouvez configurer une fréquence différente dans les paramètres du modèle sémantique. Chaque mise à jour du cache envoie des requêtes à la source de données sous-jacente pour mettre à jour le cache. Le nombre de requêtes générées dépend du nombre de visuels épinglés aux tableaux de bord qui dépendent de cette source de données. Notez que si la sécurité au niveau des lignes est activée, les requêtes sont générées pour chaque contexte de sécurité différent. Par exemple, considérez qu’il existe deux rôles différents qui catégorisent vos utilisateurs et qu’ils ont deux vues différentes des données. Au cours de l’actualisation du cache des requêtes, Power BI génère deux ensembles de requêtes.

Rapports Power BI

Il existe plusieurs suggestions pour l’optimisation des conceptions de rapport Power BI.

Remarque

Lorsque les rapports sont basés sur un modèle sémantique DirectQuery, pour obtenir des optimisations de conception de rapport supplémentaires, consultez Conseils de modèle DirectQuery dans Power BI Desktop (optimiser les conceptions de rapport).

Appliquer les filtres les plus restrictifs

Plus un élément visuel contient de données à afficher, plus son chargement est lent. Si ce principe semble évident, on a tendance à l’oublier. Par exemple, supposons que vous avez un modèle sémantique volumineux. En fonction de ce modèle sémantique, vous générez un rapport avec une table. Les utilisateurs finaux utilisent les tranches sur la page pour accéder aux lignes qui les intéressent, généralement pas plus de quelques dizaines.

Une erreur fréquente consiste à utiliser la vue par défaut de la table non filtrée, soit la totalité des quelques 100 millions de lignes. Les données de ces lignes sont chargées en mémoire et décompressées à chaque actualisation. Ce traitement impose des charges énormes à la mémoire. La solution consiste à utiliser le filtre « N premiers » pour réduire le nombre maximal d’éléments à afficher dans la table. Vous pouvez définir un nombre maximal d’éléments supérieur à ce dont les utilisateurs peuvent avoir besoin, par exemple 10 000. Le résultat est que l’expérience de l’utilisateur final ne change pas, mais que l’utilisation de la mémoire chute considérablement. Et surtout, les performances sont améliorées.

Une approche de conception similaire à celle-ci est recommandée pour tous les éléments visuels de votre rapport. Demandez-vous si toutes les données présentes dans l’élément visuel sont nécessaires. Est-il possible de réduire la quantité de données affichées sur le visuel d’une manière ou d’une autre sans gêner l’utilisateur ? Souvenez-vous que les tables peuvent être coûteuses.

Limiter le nombre d’éléments visuels sur les pages de rapport

Le principe ci-dessus s’applique également au nombre d’éléments visuels ajoutés à une page de rapport. Il est fortement recommandé de limiter le nombre d’éléments visuels sur une page de rapport au strict nécessaire. Les pages d’extraction et les info-bulles des pages de rapport permettent d’ajouter des détails supplémentaires sans accumuler les éléments visuels sur la page.

Évaluer les performances des éléments visuels personnalisés

Pour garantir des performances élevées, veillez à mettre à l’épreuve chaque élément visuel personnalisé. Les visuels Power BI mal optimisés peuvent réduire les performances de l’intégralité du rapport.

Rapports paginés Power BI

Les conceptions des rapports paginés Power BI peuvent être optimisées en appliquant la conception des meilleures pratiques à l’extraction des données du rapport. Pour plus d’informations, consultez les conseils sur l’extraction de données pour les rapports paginés.

En outre, assurez-vous que votre capacité dispose de suffisamment de mémoire allouée à la charge de travail des rapports paginés.

Optimisation de l’environnement

Vous pouvez optimiser l’environnement Power BI en configurant les paramètres de capacité, en redimensionnant les passerelles de données et en réduisant la latence du réseau.

Paramètres de capacité

Quand vous utilisez des capacités, disponibles avec Power BI Premium (références SKU P), avec des licences Premium par utilisateur ou avec Power BI Embedded (références SKU A, A4-A6), vous pouvez gérer les paramètres de capacité. Pour plus d’informations, consultez Gestion des capacités Premium.

Dimensionnement de la passerelle

La passerelle est obligatoire chaque fois que Power BI doit accéder à des données qui ne sont pas directement accessibles sur Internet. Vous pouvez installer la passerelle de données locale sur un serveur local ou sur une infrastructure IaaS (infrastructure as a service) hébergée sur une machine virtuelle.

Pour comprendre les charges de travail et les suggestions de dimensionnement de la passerelle, consultez Dimensionnement des passerelles de données locales.

Latence du réseau

La latence du réseau peut affecter les performances du rapport en augmentant le temps nécessaire aux demandes pour atteindre le service Power BI et aux réponses pour être envoyées. Les abonnés de Power BI sont affectés à une région spécifique.

Conseil

Pour déterminer où se trouve votre abonné, consultez Où est situé mon abonné Power BI ?

Lorsque les utilisateurs d’un client accèdent au service Power BI, leurs requêtes sont acheminées vers cette région. Lorsque les requêtes atteignent le service Power BI, celui-ci peut ensuite envoyer des requêtes supplémentaires (par exemple, à la source de données sous-jacente ou à la passerelle) qui sont également soumises à la latence du réseau.

Des outils tels que Azure Speed Test donnent une indication de la latence du réseau entre le client et la région Azure. De manière générale, pour minimiser l’impact de la latence du réseau, essayez de rapprocher le plus possible les sources de données, les passerelles et votre capacité Power BI. De préférence, elles se trouvent dans la même région. Si la latence du réseau pose problème, essayez de rapprocher les passerelles et les sources de données de votre capacité Power BI en les plaçant sur des machines virtuelles hébergées sur le cloud.

Analyse des performances

Vous pouvez surveiller les performances afin d’identifier les goulots d’étranglement. Les éléments visuels de requêtes ou de rapports lents doivent être au cœur de l’optimisation continue. La surveillance peut être effectuée au moment de la conception dans Power BI Desktop ou sur des charges de travail de production dans des capacités de Power BI Premium. Pour plus d’informations, consultez Surveillance des performances de rapports dans Power BI.

Contenu connexe

Pour plus d’informations sur cet article, consultez les ressources suivantes :