Partage via


Guide d’optimisation pour Power BI

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 de Live Connection) et dans Power BI, ils sont appelés modèles sémantiques. Il est important de comprendre vos options et de choisir le type de modèle sémantique approprié pour votre solution. Il existe trois modes de stockage de table de modèles sémantiques : Importation, 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 stockage de table de modèles sémantiques, consultez :

Optimisation pour les auteurs de rapports et les consommateurs de modèles

Le modèle sémantique est la base de tous les rapports dans Power BI. Les consommateurs du modèle sémantique peuvent créer des rapports Power BI dans Power BI Desktop en se connectant à un modèle sémantique publié ou en se connectant aux données et en créant un modèle sémantique local. Le modèle sémantique peut également être utilisé pour créer des rapports Power BI dans le navigateur, créer des explorations Power BI, créer des rapports paginés, créer des requêtes DAX et créer des rapports dans Excel avec Analyser dans Excel, se connecter à Power BI dans Excel ou exporter des données à partir d’un visuel de rapport, ainsi que de nombreux autres outils de création de rapports. Un auteur de modèle sémantique peut aider les consommateurs de modèles sémantiques à comprendre et à utiliser le modèle sémantique avec la façon dont ils créent le modèle.

  • Noms : tables, colonnes et mesures dans le modèle sémantique avec des noms descriptifs. Par exemple, « Store Sales » comme nom de table est plus intuitif que « Table1 ».
  • Descriptions : Les tables, les colonnes et les mesures du modèle peuvent avoir des descriptions ajoutées pour fournir plus de détails que ce qui peut s’adapter au nom. Expliquer non seulement ce qu’ils incluent, mais comment ils doivent être utilisés.
  • Masquer : vous pouvez masquer les tables, les colonnes et les mesures dans le modèle pour afficher uniquement ce que vous attendez qu’ils utilisent dans un rapport. Par exemple, les colonnes de relation peuvent être un ID qui n’est pas nécessaire pour la création de rapports et peuvent être masquées, car elles ne sont pas censées être utilisées dans un rapport, ou les colonnes de données qui ont une mesure pour agréger la colonne peuvent être masquées pour encourager l’utilisation de la mesure à la place. Les objets masqués peuvent toujours être masqués plus tard par le consommateur de modèle, de sorte qu’ils seront toujours disponibles, mais le masquage peut fournir le focus.
  • Hiérarchies : vous pouvez créer des hiérarchies pour transmettre la hiérarchie sur plusieurs colonnes. Par exemple, une hiérarchie calendrier peut contenir des colonnes Year, Month, Day et Une hiérarchie Product peut contenir Des colonnes Catégorie, Sous-Catégorie, Product. Cliquez avec le bouton droit sur une colonne pour créer une hiérarchie.
  • Mesures : vous pouvez utiliser des mesures pour agréger des colonnes de données dans le modèle sémantique pour assurer la cohérence entre les rapports. Les mesures peuvent aller de la SOMME d’une colonne à un index d’intégrité combinant plusieurs agrégations d’une manière spécifique ou en comparant des agrégations sur plusieurs périodes, telles que la moyenne quotidienne ce mois-ci par rapport à la moyenne quotidienne du même mois l’année dernière. Les mesures peuvent également être exposées dans la recherche Power BI et d’autres fonctionnalités, telles que les métriques et les cartes de performance.
  • Formats : vous pouvez spécifier le mode d’affichage d’une colonne ou d’une mesure dans un visuel, par défaut. Les valeurs des visuels peuvent être personnalisées plus loin dans le visuel. Les options de format incluent s’il comporte des milliers de virgules, le nombre de décimales, la façon dont une date est affichée, etc. Vous pouvez également appliquer des formats personnalisés ou dynamiques .
  • Catégorie de données : vous pouvez spécifier une catégorie de données de colonne, par exemple s’il s’agit d’un pays ou d’une URL web.

Il s’agit des fonctionnalités courantes du modèle sémantique Power BI qui peuvent être exploitées pour aider vos auteurs de rapports et vos consommateurs de modèles. Il existe de nombreux autres, tels que des groupes de calcul, des paramètres de champ, des paramètres de champ, le cas échéant, et les colonnes de regroupement et de binning, qui doivent être évaluées pour voir s’ils appliquent vos besoins de création de rapports spécifiques.

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 Licences de capacité Microsoft Fabric et Gestion des capacités Premium.

Important

Cet article fait parfois référence à Power BI Premium ou à ses abonnements de capacité (SKU P). Sachez que Microsoft regroupe actuellement des options d’achat et met hors service les SKU Power BI Premium par capacité. Les clients nouveaux et existants doivent plutôt envisager l’achat d’abonnements de capacité Fabric (SKU F).

Pour plus d’informations, consultez l’article Importante mise à jour à venir des licences Power BI Premium et la FAQ sur Power BI 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.

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