Partager via

Planification de l’implémentation de Power BI : audit au niveau des données

  • Article

Notes

Cet article fait partie de la série d’articles sur la planification de l’implémentation de Power BI. Cette série se concentre principalement sur l’expérience Power BI au sein de Microsoft Fabric. Pour une introduction à la série, consultez Planification de la mise en œuvre de Power BI.

Cet article sur l’audit au niveau des données est destiné à plusieurs publics :

  • Créateurs de données et administrateurs d’espace de travail : utilisateurs qui doivent comprendre l’utilisation, l’adoption et les performances des modèles sémantiques, des dataflows et des datamarts qu’ils créent, publient et partagent.
  • Administrateurs Power BI : Les administrateurs chargés de superviser Power BI dans l’organisation. Les administrateurs Power BI peuvent avoir besoin de collaborer avec les équipes de l’informatique, de la sécurité, de l’audit interne et d’autres équipes pertinentes. Les administrateurs Power BI peuvent également avoir besoin de collaborer avec les créateurs de contenu pour résoudre les problèmes de performance.
  • Administrateurs de capacité Power BI : administrateurs responsables de la supervision de la capacité Premium dans l’organisation. Les administrateurs de capacité Power BI peuvent avoir besoin de collaborer avec les créateurs de contenu pour résoudre les problèmes de performance.
  • Centre d’excellence, service informatique et équipe BI : les équipes qui sont également responsables de la supervision de Power BI. Ils peuvent avoir besoin de collaborer avec les administrateurs Power BI et d’autres équipes pertinentes.
  • Administrateurs système : l’équipe responsable de la création et de la sécurisation des ressources Azure Log Analytics, et les administrateurs de base de données qui gèrent les sources de données.

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 Importante mise à jour à venir des licences Power BI Premium et FAQ sur Power BI Premium.

Les concepts abordés dans cet article s’appliquent principalement aux solutions créées pour trois étendues de distribution de contenu, en particulier la BI d’entreprise, la BI départementale et la BI d’équipe. Les créateurs de solutions décisionnelles personnelles peuvent également trouver les informations de cet article utiles, mais ils ne constituent pas la cible principale.

Il n’est pas possible d’obtenir de bonnes performances dans les rapports et les visuels lorsque le modèle sémantique et/ou la source de données sous-jacents ne fonctionnent pas correctement. Cet article se concentre sur l’audit et le monitoring des modèles sémantiques, des flux de données et des datamarts. Il s’agit du deuxième article de la série Audit et supervision, car les outils et techniques sont plus complexes que ceux décrits dans l’article Audit au niveau du rapport. Dans l’idéal, vous créez des modèles sémantiques partagés (destinés à être réutilisés dans de nombreux rapports) avant que les utilisateurs ne créent des rapports. Par conséquent, nous vous recommandons de lire cet article avec l’article Audit au niveau du rapport.

Étant donné que les modèles sémantiques Power BI reposent sur le moteur tabulaire Analysis Services, vous pouvez vous connecter à un modèle de données local (dans Power BI Desktop) ou à un modèle sémantique Premium (dans le service Power BI) comme s’il s’agit d’une base de données Analysis Services. Par conséquent, la plupart des fonctionnalités d’audit et de monitoring d’Analysis Services sont prises en charge pour les modèles sémantiques Power BI Premium.

Remarque

Pour plus d’informations sur les modèles hébergés dans Analysis Services, consultez Vue d’ensemble de la supervision.

Le reste de cet article se concentre principalement sur les modèles publiés sur le service Power BI.

Journaux des événements de modèle sémantique

Au fil du temps, les créateurs et les propriétaires de données peuvent rencontrer des situations avec leurs modèles sémantiques. Un modèle sémantique peut :

Pour garantir la convivialité, les bonnes performances et l’adoption du contenu qu’ils créent, vous devez auditer l’utilisation et les performances des ressources de données que vous devez gérer. Vous pouvez utiliser les journaux d'événements du jeu de données, qui capturent les activités générées par l'utilisateur et par le système qui se produisent pour un modèle sémantique. Ils sont également appelés événements de trace, journaux de jeu de données ou journaux d’activité de jeu de données. Les administrateurs système les appellent souvent des événements de trace de bas niveau, car ils sont détaillés.

Remarque

La modification du nom du jeu de données a été déployée dans la service Power BI et dans la documentation, bien qu’il existe peut-être certaines instances, comme avec les noms des opérations du journal des événements, où la modification n’a pas encore eu lieu.

Vous devez analyser les événements de trace du modèle sémantique pour :

  • Auditer toutes les activités qui se sont produites sur un modèle sémantique.
  • Dépanner et optimiser les performances du modèle sémantique, l’utilisation de la mémoire et l’efficacité des requêtes.
  • Investiguer les détails et la durée de l’actualisation du modèle sémantique.
  • Superviser le langage de formule Power Query (requêtes M) envoyé par Power Query.
  • Monitorer les formules et expressions DAX envoyées au modèle sémantique (moteur Analysis Services).
  • Vérifier si le mode de stockage approprié a été sélectionné en fonction des charges de travail et de la nécessité d’équilibrer les données fraîches et les performances optimales.
  • Vérifier quels rôles de sécurité au niveau des lignes sont appelés, pour quels utilisateurs et sur quels modèles sémantiques.
  • Comprendre le nombre d’utilisateurs simultanés.
  • Valider un modèle sémantique (par exemple, pour vérifier la qualité et les performances des données avant d’endosser un modèle sémantique ou avant de le publier dans un espace de travail de production).

Les événements générés par un modèle sémantique Power BI sont dérivés des journaux de diagnostic existants disponibles pour Azure Analysis Services. Il existe de nombreux types d’événements de trace que vous pouvez capturer et analyser, qui sont décrits dans les sections suivantes.

Azure Log Analytics

Azure Log Analytics est un composant du service Azure Monitor. L’intégration d’Azure Log Analytics à Power BI vous permet de capturer des événements de modèle sémantique à partir de tous les modèles sémantiques d’un espace de travail Power BI. Elle est prise en charge uniquement pour les espaces de travail Premium. Une fois que vous avez configuré l’intégration et que la connexion est activée (pour un espace de travail Power BI Premium), les événements de modèle sémantique sont automatiquement capturés et envoyés en continu à un espace de travail Azure Log Analytics. Les journaux du modèle sémantique sont stockés dans Azure Data Explorer, qui est une base de données en ajout uniquement optimisée pour capturer des volumes importants de données de télémétrie en quasi-temps réel.

Vous affectez un espace de travail Power BI Premium à un espace de travail Log Analytics dans Azure. Vous devez créer une ressource Log Analytics dans votre abonnement Azure pour activer ce type de journalisation.

Les journaux d’un ou de plusieurs espaces de travail Power BI sont envoyés vers un espace de travail Log Analytics cible. Voici quelques façons parmi lesquelles choisir pour organiser les données.

  • Un espace de travail cible pour toutes les données d’audit : stockez toutes les données dans un espace de travail Log Analytics. Cette opération est utile lorsque le même administrateur ou les mêmes utilisateurs accèdent à toutes les données.
  • Espaces de travail cibles organisés par zone de sujet : organisez le contenu par zone de sujet. Cette technique est particulièrement utile lorsque divers administrateurs ou utilisateurs sont autorisés à accéder aux données d’audit à partir d’Azure Log Analytics. Par exemple, lorsque vous devez séparer des données de ventes des données d’opérations.
  • Un espace de travail cible pour chaque espace de travail Power BI : configurez une relation un-à-un entre un espace de travail Power BI et un espace de travail Azure Log Analytics. Cette opération est utile lorsque vous avez du contenu particulièrement sensible ou lorsque les données sont soumises à des exigences de conformité ou réglementaires spécifiques.

Conseil

Passez en revue la documentation et les questions fréquemment posées sur cette fonctionnalité afin d’être clair sur ce qui est possible et de comprendre les exigences techniques. Avant de rendre cette fonctionnalité largement disponible pour les administrateurs d’espace de travail dans votre organisation, envisagez d’effectuer une preuve de concept technique (POC) avec un espace de travail Power BI.

Important

Bien que les noms soient similaires, les données capturées par Azure Log Analytics ne sont pas identiques au journal d’activité Power BI. Azure Log Analytics capture les événements de trace au niveau des détails à partir du moteur Analysis Services. Son seul objectif est de vous aider à analyser et à résoudre les problèmes de performances du modèle sémantique. Son étendue est au niveau de l’espace de travail. À l’inverse, l’objectif du journal d’activité est de vous aider à comprendre la fréquence à laquelle certaines activités utilisateur se produisent (telles que la modification d’un rapport, l’actualisation d’un modèle sémantique ou la création d’une application). Son étendue est l’intégralité du locataire Power BI.

Pour plus d’informations sur les activités utilisateur que vous pouvez auditer pour votre locataire Power BI, consultez Audit au niveau du locataire.

La connexion Azure Log Analytics pour les administrateurs d’espace de travail contrôle les groupes d’utilisateurs (qui ont également le rôle d’administrateur d’espace de travail nécessaire) qui peuvent connecter un espace de travail Power BI à un espace de travail Azure Log Analytics existant.

Avant de pouvoir configurer l’intégration, vous devez respecter les prérequis de sécurité. Par conséquent, envisagez d’activer le paramètre de locataire Power BI uniquement pour les administrateurs d’espace de travail Power BI qui disposent également des autorisations requises dans Azure Log Analytics ou qui peuvent obtenir ces autorisations sur demande.

Conseil

Collaborez avec votre administrateur Azure au début du processus de planification, en particulier lorsque l’approbation de créer une ressource Azure est un défi dans votre organisation. Vous devez également planifier les prérequis de sécurité. Décidez d’accorder l’autorisation à l’administrateur de votre espace de travail Power BI dans Azure ou à l’administrateur Azure dans Power BI.

Les journaux de modèle sémantique capturés par Azure Log Analytics incluent les requêtes de modèle sémantique, les statistiques de requête, l’activité d’actualisation détaillée, le temps processeur consommé sur les capacités Premium, etc. Étant donné qu’il s’agit de journaux au niveau des détails du moteur Analysis Services, les données peuvent être détaillées. Les volumes de données importants sont courants pour les espaces de travail volumineux qui connaissent une activité de modèle sémantique élevée.

Pour optimiser les coûts lors de l’utilisation d’Azure Log Analytics avec Power BI :

  • Connectez des espaces de travail Power BI à Azure Log Analytics uniquement lorsque vous dépannez, testez, optimisez ou examinez activement l’activité des modèles sémantiques. Une fois connectée, une trace s’exécute sur tous les modèles sémantiques de l’espace de travail.
  • Déconnectez Azure Log Analytics d’un espace de travail Power BI lorsque vous n’avez plus besoin de dépanner, tester, optimiser ou examiner activement l’activité du modèle sémantique. En vous déconnectant, vous arrêtez l’exécution de la trace sur tous les modèles sémantiques de l’espace de travail.
  • Assurez-vous de comprendre le modèle de coût pour la façon dont Azure Log Analytics facture l’ingestion des données, le stockage et les requêtes.
  • Ne stockez pas les données dans Log Analytics pendant une période de rétention de 30 jours par défaut. Cela est dû au fait que l’analyse des modèles sémantiques se concentre généralement sur les activités de dépannage immédiates.

Il existe plusieurs façons d’accéder aux événements envoyés à Azure Log Analytics. Vous pouvez utiliser :

  • L’application modèle Log Analytics pour modèles sémantiques Power BI prédéfinie.
  • Le connecteur Power BI Desktop pour Azure Data Explorer (Kusto). Utilisez le Langage de requête Kusto (KQL, Kusto Query Language) pour analyser les données stockées dans Log Analytics. Si vous avez une expérience de requête SQL, vous trouverez de nombreuses similitudes avec KQL.
  • L’expérience de requête web dans Azure Data Explorer.
  • Tout outil de requête capable d’exécuter des requêtes KQL.

Conseil

Étant donné qu’il existe un volume élevé d’événements de trace de modèle sémantique, nous vous recommandons de développer un modèle DirectQuery pour analyser les données. Un modèle DirectQuery vous permet d’interroger les données en quasi-temps réel. Les événements arrivent généralement dans les cinq minutes.

Pour plus d’informations, consultez Gouverner les connexions Azure.

Liste de vérification : lorsque vous planifiez d’utiliser Azure Log Analytics, voici les décisions et actions clés :

  • Considérez une preuve de concept technique : planifiez un petit projet pour vous assurer que vous comprenez parfaitement les exigences techniques, les exigences de sécurité, les événements à capturer et comment analyser les journaux.
  • Déterminez les espaces de travail qui doivent être intégrés à Log Analytics : déterminez les espaces de travail Premium qui contiennent des modèles sémantiques que vous souhaitez analyser.
  • Déterminez si Log Analytics doit être activé à plein temps pour tous les espaces de travail : pour optimiser les coûts, déterminez s’il existe des situations (ou des espaces de travail spécifiques) où la journalisation doit être activée de manière permanente. Déterminez si les espaces de travail doivent être déconnectés lorsque la résolution des problèmes ne se produit pas.
  • Déterminez la durée de conservation des données Log Analytics : déterminez s’il est nécessaire de définir une période de rétention plus longue que la valeur par défaut de 30 jours.
  • Clarifiez le processus de demande d’un nouvel espace de travail Log Analytics : collaborez avec votre administrateur Azure pour clarifier comment les demandes d’une nouvelle ressource Log Analytics doivent être envoyées par les administrateurs de l’espace de travail Power BI.
  • Déterminez le fonctionnement de la sécurité : collaborez avec votre administrateur Azure pour décider s’il est davantage possible pour un administrateur d’espace de travail Power BI d’obtenir des droits sur un espace de travail Azure Log Analytics, ou pour un administrateur Azure d’obtenir des droits sur un espace de travail Power BI. Lorsque vous prenez cette décision de sécurité, envisagez votre plan de connexion et de déconnexion des espaces de travail régulièrement (pour l’optimisation des coûts).
  • Décidez comment organiser les espaces de travail Log Analytics cibles : déterminez le nombre d’espaces de travail Azure Log Analytics appropriés pour organiser les données d’un ou plusieurs espaces de travail Power BI. Alignez cette décision sur vos décisions de sécurité relatives aux utilisateurs qui peuvent accéder aux données de journal.
  • Déterminez les administrateurs d’espace de travail autorisés à se connecter : déterminez les groupes d’administrateurs d’espace de travail qui peuvent connecter un espace de travail Power BI à un espace de travail Log Analytics. Définissez le paramètre de locataire Connexion Azure Log Analytics pour les administrateurs de l’espace de travail pour qu’il s’aligne sur cette décision.
  • Créez la ressource Azure Log Analytics : collaborez avec votre administrateur Azure pour créer chaque espace de travail Log Analytics. Vérifiez et mettez à jour les autorisations affectées dans Azure pour vous assurer que la configuration de Power BI peut se produire sans aucun problème. Vérifiez que les données stockées dans Azure se trouvent dans la région géographique appropriée.
  • Définissez la connexion Log Analytics pour chaque espace de travail Power BI : collaborez avec les administrateurs de votre espace de travail Power BI pour configurer la connexion à Log Analytics pour chaque espace de travail Power BI. Vérifiez que les données de journal circulent correctement vers l’espace de travail Log Analytics.
  • Créez des requêtes pour analyser les données : configurez des requêtes KQL pour analyser les données dans Log Analytics en fonction de votre cas d’usage et de vos besoins actuels.
  • Incluez des conseils pour les administrateurs d’espace de travail Power BI : fournissez des informations et des conditions préalables aux administrateurs de votre espace de travail Power BI pour savoir comment demander un nouvel espace de travail Log Analytics et comment se connecter à un espace de travail Power BI. Expliquez également quand il est approprié de déconnecter un espace de travail Power BI.
  • Fournissez des conseils et des exemples de requêtes pour l’analyse des données : créez des requêtes KQL pour les administrateurs d’espace de travail afin de faciliter leur prise en main de l’analyse des données capturées.
  • Supervisez les coûts : collaborez avec votre administrateur Azure pour superviser les coûts de Log Analytics en continu.

SQL Server Profiler

Vous pouvez utiliser SQL Server Profiler (SQL Profiler) pour capturer les événements de modèle sémantique Power BI. Il s’agit d’un composant de SQL Server Management Studio (SSMS). La connectivité à un modèle sémantique Power BI est prise en charge avec SSMS, car elle est basée sur l’architecture Analysis Services issue de SQL Server.

Vous pouvez utiliser SQL Profiler pendant différentes étapes du cycle de vie d’un modèle sémantique.

  • Pendant le développement du modèle de données : SQL Profiler peut se connecter à un modèle de données dans Power BI Desktop en tant qu’outil externe. Cette approche est utile pour les modélisateurs de données qui souhaitent valider leur modèle de données ou qui souhaitent optimiser les performances.
  • Une fois le modèle sémantique publié dans le service Power BI : SQL Profiler peut se connecter à un modèle sémantique dans un espace de travail Premium. SSMS est l’un des nombreux outils clients pris en charge qui peuvent utiliser le point de terminaison XMLA pour la connectivité. Cette approche est utile lorsque vous souhaitez auditer, monitorer, valider, dépanner ou paramétrer un modèle sémantique publié dans le service Power BI.

Il est également possible d’utiliser SQL Profiler en tant qu’outil externe dans DAX Studio. Vous pouvez utiliser DAX Studio pour démarrer une trace du générateur de profil, analyser les données et mettre en forme les résultats. Les modélisateurs de données qui utilisent DAX Studio préfèrent souvent cette approche plutôt que l’utilisation directe de SQL Profiler.

Notes

L’utilisation de SQL Profiler est un cas d’usage différent de l’activité de profilage des données. Vous profilez les données dans l’Éditeur Power Query pour mieux comprendre leurs caractéristiques. Bien que le profilage des données soit une activité importante pour les modélisateurs de données, il n’est pas dans l’étendue de cet article.

Envisagez d’utiliser SQL Profiler au lieu d’Azure Log Analytics dans les cas suivants :

  • Votre organisation ne vous permet pas d’utiliser ni de créer des ressources Azure Log Analytics dans Azure.
  • Vous souhaitez capturer des événements pour un modèle de données dans Power BI Desktop (qui n’a pas été publié dans un espace de travail Premium dans le service Power BI).
  • Vous souhaitez capturer les événements d’un modèle sémantique pendant une courte période (plutôt que tous les modèles sémantiques d’un espace de travail Premium).
  • Vous souhaitez capturer certains événements uniquement pendant une trace (par exemple, uniquement l’événement De fin de requête).
  • Vous souhaitez démarrer et arrêter fréquemment des traces (par exemple, lorsque vous devez capturer des événements de modèle sémantique qui se produisent actuellement).

Comme Azure Log Analytics (décrit plus haut dans cet article), les événements de modèle sémantique capturés par SQL Profiler sont dérivés des journaux de diagnostic existants disponibles pour Azure Analysis Services. Toutefois, il existe certaines différences dans les événements disponibles.

Conseil

L’utilisation de SQL Profiler pour la supervision d’Analysis Services est abordée dans de nombreux livres, articles et billets de blog. La plupart de ces informations sont pertinentes pour le monitoring d’un modèle sémantique Power BI.

Important

Vous pouvez également utiliser SQL Profiler pour superviser les requêtes envoyées à partir du service Power BI aux sources de données sous-jacentes (par exemple, à une base de données relationnelle SQL Server). Toutefois, la possibilité de tracer une base de données relationnelle est déconseillée. La connexion au moteur Analysis Services est prise en charge et non déconseillée. Si vous êtes familiarisé avec les événements étendus Analysis Services et que vous préférez les utiliser, la connectivité à partir de SSMS est possible pour un modèle de données dans Power BI Desktop. Toutefois, elle n’est pas prise en charge pour Power BI Premium. Par conséquent, cette section se concentre uniquement sur la connectivité SQL Profiler standard.

Le paramètre de locataire Autoriser les points de terminaison XMLA et l’analyse dans Excel avec les modèles sémantiques locaux contrôle les groupes d’utilisateurs (également affectés au rôle d’espace de travail Contributeur, Membre ou Administrateur, ou à l’autorisation Génération pour le modèle sémantique individuel) qui peuvent utiliser le point de terminaison XMLA pour interroger et/ou gérer des modèles sémantiques dans le service Power BI. Pour plus d’informations sur l’utilisation du point de terminaison XMLA, consultez le scénario d’utilisation Gestion avancée des modèles de données.

Notes

Vous pouvez également utiliser SQL Profiler pour vous aider à déboguer et dépanner des expressions DAX spécifiques. Vous pouvez connecter SQL Profiler à Power BI Desktop en tant qu’outil externe. Recherchez la classe d’événements DAX Evaluation Log (Journal d’évaluation DAX) pour afficher les résultats intermédiaires d’une expression DAX. Cet événement est généré lorsque vous utilisez la fonction DAX EVALUATEANDLOG dans un calcul de modèle.

Cette fonction est uniquement destinée au développement et au test. Vous devez la supprimer de vos calculs de modèle de données avant de publier le modèle de données dans un espace de travail de production.

Liste de vérification : lors de la planification de l’utilisation de SQL Profiler, les décisions et actions clés sont les suivantes :

  • Déterminez qui peut installer SSMS ou DAX Studio : déterminez si vous allez autoriser tous les créateurs de contenu Power BI de votre organisation à installer SSMS et/ou DAX Studio afin qu’ils puissent utiliser SQL Profiler. Déterminez si ces outils auxiliaires sont installés sur demande ou s’ils font partie d’un ensemble standard de logiciels installés pour les créateurs de données approuvés dans l’organisation.
  • Ajoutez SQL Profiler au menu Outils externes dans Power BI Desktop : si les créateurs de données utilisent souvent SQL Profiler, demandez au service informatique de l’ajouter automatiquement au menu Outils externes dans Power BI Desktop pour ces utilisateurs.
  • Déterminez qui peut utiliser le point de terminaison XMLA : déterminez si tous les utilisateurs sont autorisés à se connecter à des modèles sémantiques publiés à l’aide du point de terminaison XMLA, ou s’il est limité aux créateurs de données approuvés. Définissez le paramètre de locataire Autoriser les points de terminaison XMLA et Analyser dans Excel avec les modèles sémantiques locaux conformément à cette décision.
  • Fournissez des conseils et des exemples de requêtes pour l’analyse des données : créez une documentation pour vos créateurs de données afin qu’ils comprennent la méthode recommandée pour auditer et monitorer les modèles sémantiques. Fournissez des conseils pour les cas d’usage courants afin de faciliter la collecte et l’analyse des données de trace.

Métadonnées du modèle de données

Étant donné que les modèles sémantiques Power BI reposent sur le moteur Analysis Services, vous avez accès aux outils qui peuvent interroger les métadonnées d’un modèle de données. Les métadonnées incluent tout ce qui concerne le modèle de données, y compris les noms de table, les noms de colonnes et les expressions de mesure.

Vues de gestion dynamique (DMV)

Les Vues de gestion dynamique (DMV, Dynamic Management Views) Analysis Services peuvent interroger les métadonnées du modèle de données. Vous pouvez utiliser les vues de gestion dynamiques pour auditer, documenter et optimiser vos modèles de données à un moment donné.

Plus précisément, vous pouvez :

  • Auditez les sources de données utilisées par un modèle.
  • Découvrez les objets qui consomment le plus de mémoire dans un modèle.
  • Déterminez l’efficacité avec laquelle les données de colonne peuvent être compressées.
  • Recherchez les colonnes d’un modèle qui ne sont pas utilisées.
  • Auditez les connexions et les sessions utilisateur actives.
  • Vérifiez la structure du modèle.
  • Passez en revue les expressions DAX utilisées par les tables calculées, les colonnes calculées, les mesures et les règles de sécurité au niveau des lignes.
  • Identifiez les dépendances entre les objets et les mesures.

Conseil

Les DMV récupèrent des informations sur l’état actuel d’un modèle sémantique. Considérez les données retournées par les DMV comme un instantané de ce qui se produit à un moment donné. À l’inverse, les journaux des événements de modèle sémantique (décrits plus haut dans cet article) récupèrent des informations sur les activités qui se sont produites pour un modèle sémantique pendant qu’une connexion de trace était active.

SSMS est un outil couramment utilisé pour exécuter des requêtes DMV. Vous pouvez également utiliser l’applet de commande PowerShell Invoke-ASCmd pour créer et exécuter des scripts XMLA qui interrogent les DMV.

Les outils tiers et les outils externes sont également populaires auprès de la communauté Power BI. Ces outils utilisent les DMV documentés publiquement pour simplifier l’accès et utiliser les données retournées par les DMV. Par exemple, DAX Studio inclut des fonctionnalités explicites permettant d’accéder aux DMV. DAX Studio inclut également une fonctionnalité intégrée d’affichage des métriques, communément appelée Vertipaq Analyzer. Vertipaq Analyzer dispose d’une interface utilisateur permettant d’analyser la structure et la taille des tables, des colonnes, des relations et des partitions dans un modèle de données. Vous pouvez également exporter (ou importer) les métadonnées du modèle de données dans un fichier .vpax. Le fichier exporté contient uniquement des métadonnées sur la structure et la taille du modèle de données, sans stocker de données de modèle.

Conseil

Envisagez de partager un fichier .vpax avec quelqu’un lorsque vous avez besoin d’aide avec un modèle de données. De cette façon, vous ne partagerez pas les données du modèle avec cette personne.

Vous pouvez utiliser des requêtes DMV pendant différentes phases du cycle de vie d’un modèle sémantique.

  • Pendant le développement du modèle de données : l’outil de votre choix peut se connecter à un modèle de données dans Power BI Desktop en tant qu’outil externe. Cette approche est utile pour les modélisateurs de données qui souhaitent valider leur modèle de données ou qui souhaitent optimiser les performances.
  • Une fois le modèle sémantique publié dans le service Power BI : l’outil de votre choix peut se connecter à un modèle sémantique dans un espace de travail Premium. SSMS est l’un des nombreux outils clients pris en charge qui utilisent le point de terminaison XMLA pour la connectivité. Cette approche est utile lorsque vous souhaitez auditer ou valider un modèle sémantique publié dans le service Power BI.

Conseil

Si vous décidez d’écrire vos propres requêtes DMV (par exemple, dans SSMS), n’oubliez pas que les DMV ne prennent pas en charge toutes les opérations SQL. En outre, certaines DMV ne sont pas prises en charge dans Power BI (car elles nécessitent des autorisations d’administrateur de serveur Analysis Services qui ne sont pas prises en charge par Power BI).

Le paramètre de locataire Autoriser les points de terminaison XMLA et l’analyse dans Excel avec les modèles sémantiques locaux contrôle les groupes d’utilisateurs (également affectés au rôle d’espace de travail Contributeur, Membre ou Administrateur, ou à l’autorisation Génération pour le modèle sémantique individuel) qui peuvent utiliser le point de terminaison XMLA pour interroger et/ou gérer des modèles sémantiques dans le service Power BI.

Pour plus d’informations sur l’utilisation du point de terminaison XMLA, d’outils tiers et d’outils externes, consultez le scénario d’utilisation de la gestion avancée des modèles de données.

Best Practice Analyzer

Best Practice Analyzer (BPA) est une fonctionnalité de l’Éditeur tabulaire, qui est un outil tiers qui a été largement adopté par la communauté Power BI. BPA comprend un ensemble de règles personnalisables qui peuvent vous aider à auditer la qualité, la cohérence et les performances de votre modèle de données.

Conseil

Pour configurer BPA, téléchargez l’ensemble de règles de meilleures pratiques, qui sont fournies par Microsoft sur GitHub.

Principalement, BPA peut vous aider à améliorer la cohérence des modèles en détectant des décisions de conception non optimales qui peuvent réduire les problèmes de performances. Cela est utile lorsque vous avez des modélisateurs de données en libre-service distribués dans différentes zones de l’organisation.

BPA peut également vous aider à auditer et à gouverner vos modèles de données. Par exemple, vous pouvez vérifier si un modèle de données inclut des rôles de sécurité au niveau des lignes. Vous pouvez également vérifier si tous les objets de modèle ont une description. Cela est utile lorsque, par exemple, votre objectif est de vous assurer qu’un modèle de données inclut un dictionnaire de données.

BPA peut exposer des problèmes de conception qui peuvent aider le Centre d’excellence à déterminer si une formation ou une documentation supplémentaire est nécessaire. Il peut prendre des mesures pour éduquer les créateurs de données sur les meilleures pratiques et les directives organisationnelles.

Conseil

Gardez à l’esprit que BPA peut détecter l’existence d’une caractéristique (telle que la sécurité au niveau des lignes). Toutefois, il peut être difficile de déterminer s’il est correctement configuré. Pour cette raison, un expert en la matière peut avoir besoin d’effectuer un examen. À l’inverse, l’inexistence d’une caractéristique particulière ne signifie pas nécessairement une mauvaise conception ; le modélisateur de données peut avoir une bonne raison de produire une conception particulière.

Liste de vérification : voici les décisions et actions clés à prendre en compte pour planifier l’accès aux métadonnées des modèles de données :

  • Déterminez qui peut installer SSMS : déterminez si vous allez autoriser tous les créateurs de contenu Power BI de votre organisation à installer SSMS afin qu’ils puissent se connecter aux modèles sémantiques publiés. Déterminez s’il est installé sur demande ou dans le cadre d’un ensemble standard de logiciels installés pour les créateurs de données approuvés dans l’organisation.
  • Déterminez qui peut installer des outils tiers : déterminez si vous allez autoriser tous les créateurs de contenu Power BI de votre organisation à installer des outils tiers (tels que DAX Studio et l’Éditeur tabulaire) pour qu’ils puissent monitorer les modèles de données locaux et/ou les modèles sémantiques publiés. Déterminez s’ils sont installés sur demande ou dans le cadre d’un ensemble standard de logiciels installés pour les créateurs de données approuvés dans l’organisation.
  • Configurez les règles de meilleures pratiques : déterminez les règles Best Practice Analyzer qui peuvent analyser les modèles de données dans votre organisation.
  • Déterminez qui peut utiliser le point de terminaison XMLA : déterminez si tous les utilisateurs sont autorisés à se connecter à des modèles sémantiques à l’aide du point de terminaison XMLA, ou s’il est limité aux créateurs de données approuvés. Définissez le paramètre de locataire Autoriser les points de terminaison XMLA et Analyser dans Excel avec les modèles sémantiques locaux conformément à cette décision.
  • Fournissez des conseils aux créateurs de contenu : créez une documentation pour vos créateurs de données afin qu’ils comprennent la ou les méthodes recommandées pour analyser les modèles sémantiques. Fournissez des conseils pour les cas d’usage courants pour faciliter la collecte et l’analyse des résultats DMV et/ou l’utilisation de Best Practice Analyzer.

Performances du modèle de données et des requêtes

Power BI Desktop comprend plusieurs outils qui aident les créateurs de données à résoudre les problèmes et à examiner leurs modèles de données. Ces fonctionnalités s’adressent aux modélisateurs de données qui souhaitent valider leur modèle de données et optimiser les performances avant de les publier sur le service Power BI.

Analyseur de performances

Utilisez l’Analyseur de performances, disponible dans Power BI Desktop, pour auditer et examiner les performances d’un modèle de données. L’Analyseur de performances aide les créateurs de rapports à mesurer les performances des éléments de rapport individuels. Toutefois, la cause première des problèmes de performances est généralement liée à la conception du modèle de données. Pour cette raison, un créateur de modèle sémantique peut également tirer parti de l’utilisation de l’Analyseur de performances. S’il existe différents créateurs de contenu responsables de la création de rapports et de modèles sémantiques, il est probable qu’ils devront collaborer lors de la résolution d’un problème de performances.

Conseil

Vous pouvez utiliser DAX Studio pour importer et analyser les fichiers journaux générés par l’Analyseur de performances.

Pour plus d’informations sur l’Analyseur de performances, consultez Audit au niveau du rapport.

Diagnostics des requêtes

Utilisez les diagnostics de requête, disponibles dans Power BI Desktop, pour examiner les performances de Power Query. Ils sont utiles pour la résolution des problèmes et lorsque vous avez besoin de comprendre ce que fait le moteur Power Query.

Les informations que vous pouvez obtenir à partir des diagnostics de requête sont les suivantes :

  • Détails supplémentaires liés aux messages d’erreur (lorsqu’une exception se produit).
  • Requêtes envoyées à une source de données.
  • Indique si le pliage des requêtes est ou n’est pas en cours.
  • Nombre de lignes retournées par une requête.
  • Ralentissements potentiels pendant une opération d’actualisation des données.
  • Événements en arrière-plan et requêtes générées par le système.

Selon ce que vous recherchez, vous pouvez activer un ou tous les journaux : agrégés, détaillés, compteurs de performances et partitions de confidentialité des données.

Vous pouvez démarrer les diagnostics de session dans l’Éditeur Power Query. Une fois activées, les opérations de requête et d’actualisation sont collectées jusqu’à l’arrêt du traçage de diagnostic. Les données sont renseignées directement dans l’éditeur de requête dès que les diagnostics sont arrêtés. Power Query crée un groupe Diagnostics (dossier) et y ajoute plusieurs requêtes. Vous pouvez ensuite utiliser les fonctionnalités de Power Query standard pour afficher et analyser les données de diagnostic.

Vous pouvez également activer une trace dans Power BI Desktop dans la section Diagnostics de la fenêtre Options. Les fichiers journaux sont enregistrés dans un dossier sur votre ordinateur local. Ces fichiers journaux sont remplis avec les données une fois que vous fermez Power BI Desktop, date à laquelle la trace est arrêtée. Une fois Power BI Desktop fermé, vous pouvez ouvrir les fichiers journaux avec votre programme préféré (par exemple, un éditeur de texte) pour les afficher.

Évaluation et pliage des requêtes

Power Query prend en charge différentes fonctionnalités pour vous aider à comprendre l’évaluation des requêtes, y compris le plan de requête. Il peut également vous aider à déterminer si le pliage de requête se produit pour une requête entière ou pour un sous-ensemble d’étapes d’une requête. Le pliage de requête est l’un des aspects les plus importants du réglage des performances. Il est également utile de passer en revue les requêtes natives envoyées par Power Query lorsque vous supervisez une source de données, ce qui est décrit plus loin dans cet article.

Application de métriques Premium

Lors de la résolution des problèmes, il peut être utile de collaborer avec votre administrateur de capacité Power BI Premium. L’administrateur de capacité a accès à l’application d’utilisation et de métriques Power BI Premium. Cette application peut vous fournir une multitude d’informations sur les activités qui se produisent dans la capacité. Ces informations peuvent vous aider à résoudre les problèmes liés aux modèles sémantiques.

Conseil

Votre administrateur de capacité Premium peut accorder l’accès à d’autres utilisateurs (autres que des administrateurs de capacité) pour leur permettre d’accéder à l’application de métriques Premium.

L’application de métriques Premium comprend un modèle sémantique interne et un ensemble initial de rapports. Elle vous permet d’effectuer une supervision en quasi temps réel d’une capacité Power BI Premium (référence SKU P) ou Power BI Embedded (référence SKU A). Elle inclut les données des deux à quatre dernières semaines (selon la métrique).

Utilisez l’application de métriques Premium pour résoudre les problèmes et optimiser les modèles sémantiques. Par exemple, vous pouvez identifier les modèles sémantiques qui ont une empreinte mémoire importante ou qui connaissent une utilisation du processeur systématiquement élevée. Il s’agit également d’un outil utile pour rechercher des modèles sémantiques qui approchent de la limite de votre taille de capacité.

Liste de vérification : lorsque vous envisagez d’utiliser des approches pour superviser les performances du modèle de données et des requêtes, les décisions et actions clés sont les suivantes :

  • Identifiez les cibles de performances des requêtes de modèle sémantique : assurez-vous de bien comprendre ce que signifient de bonnes performances de modèle sémantique. Déterminez quand vous aurez besoin d’objectifs de performances de requête spécifiques (par exemple, les requêtes pour prendre en charge les rapports doivent être rendues dans un délai de cinq secondes). Dans ce cas, assurez-vous que les cibles sont communiquées aux créateurs de données dans votre organisation.
  • Identifiez les cibles de performances d’actualisation du modèle sémantique : déterminez quand vous avez besoin de cibles d’actualisation des données spécifiques (par exemple, l’achèvement d’une opération d’actualisation des données dans les 15 minutes et avant 5h00). Dans ce cas, assurez-vous que les cibles sont communiquées aux créateurs de données dans votre organisation.
  • Informez votre équipe de support technique : assurez-vous que votre équipe de support utilisateur interne est familiarisée avec les fonctionnalités de diagnostic pour qu’elle soit prête à assister les utilisateurs Power BI lorsqu’ils ont besoin d’aide.
  • Connectez votre équipe de support et les administrateurs de base de données : assurez-vous que votre équipe de support technique sait comment contacter les administrateurs appropriés pour chaque source de données (lors de la résolution des problèmes de pliage des requêtes, par exemple).
  • Collaborez avec votre administrateur de capacité Premium : collaborez avec votre administrateur de capacité pour résoudre les problèmes liés aux modèles sémantiques qui résident dans un espace de travail affecté à une capacité Premium ou Power BI Embedded. Le cas échéant, demandez l’accès à l’application de métriques Premium.
  • Fournissez des conseils aux créateurs de contenu : créez une documentation pour vos créateurs de données pour qu’ils comprennent les actions à entreprendre lors de la résolution des problèmes.
  • Incluez des supports de formation : fournissez des conseils à vos créateurs de données sur la façon de créer des modèles de données performants. Aidez-les à adopter de bonnes habitudes de conception tôt. Concentrez-vous sur la formation des créateurs de données pour leur apprendre à prendre de bonnes décisions en matière de conception.

Supervision des sources de données

Il est parfois nécessaire de superviser directement une source de données spécifique à laquelle Power BI se connecte. Par exemple, vous pouvez avoir un entrepôt de données qui connaît une charge de travail accrue et les utilisateurs signalent une dégradation des performances. En règle générale, un administrateur de base de données ou un administrateur système supervise les sources de données.

Vous pouvez superviser une source de données pour :

  • Auditer les utilisateurs qui envoient des requêtes à la source de données.
  • Auditer les applications (comme Power BI) qui envoient des requêtes à la source de données.
  • Passer en revue les instructions de requête envoyées à la source de données, quand et par quels utilisateurs.
  • Déterminer le temps nécessaire à l’exécution d’une requête.
  • Auditer la façon dont la sécurité au niveau des lignes est appelée par le système source lorsqu’il utilise l’authentification unique (SSO).

Un créateur de contenu Power BI peut effectuer de nombreuses actions une fois qu’il analyse les résultats de la supervision. Il pourrait :

  • Ajuster et affiner les requêtes envoyées à la source de données pour qu’elles soient aussi efficaces que possible.
  • Valider et régler les requêtes natives envoyées à la source de données.
  • Réduire le nombre de colonnes importées dans un modèle de données.
  • Supprimer les colonnes de haute précision et de haute cardinalité qui sont importées dans un modèle de données.
  • Réduire la quantité de données historiques importées dans un modèle de données.
  • Ajustez les heures d’actualisation des données Power BI pour répartir la demande pour la source de données.
  • Utilisez l’actualisation incrémentielle des données pour réduire la charge sur la source de données.
  • Réduisez le nombre d’actualisations de données Power BI en regroupant plusieurs modèles sémantiques dans un modèle sémantique partagé.
  • Ajuster les paramètres d’actualisation automatique de la page pour augmenter la fréquence d’actualisation et, par conséquent, réduire la charge sur la source de données.
  • Simplifier les calculs pour réduire la complexité des requêtes envoyées à la source de données.
  • Modifier le mode de stockage des données (par exemple, en mode importation au lieu de DirectQuery) pour réduire la charge de requête cohérente sur la source de données.
  • Utiliser des techniques de réduction des requêtes pour réduire le nombre de requêtes envoyées à la source de données.

Les administrateurs système peuvent effectuer d’autres actions. Ils pourraient :

  • Introduire une couche de données intermédiaire, telle que des flux de données Power BI (lorsqu’un entrepôt de données n’est pas une option viable). Les créateurs de contenu Power BI peuvent utiliser les flux de données comme source de données au lieu de se connecter directement à des sources de données. Une couche de données intermédiaire peut réduire la charge sur un système source. Elle présente également l’avantage supplémentaire de centraliser la logique de préparation des données. Pour plus d’informations, consultez les scénarios d’utilisation Préparation de données libre-service.
  • Modifier l’emplacement de la source de données pour réduire l’impact de la latence du réseau (par exemple, utilisez la même région de données pour le service Power BI, les sources de données et les passerelles).
  • Optimiser la source de données afin qu’elle récupère plus efficacement les données pour Power BI. Plusieurs techniques communes incluent la création d’index de table, de vues indexées et de colonnes calculées persistantes, ou la gestion des statistiques, l’utilisation de tables en mémoire ou columnstore et la création de vues matérialisées.
  • Indiquer aux utilisateurs d’utiliser un réplica en lecture seule de la source de données, plutôt qu’une base de données de production d’origine. Un réplica peut être disponible dans le cadre d’une stratégie de base de données à haute disponibilité (HA). L’un des avantages d’un réplica en lecture seule est de réduire les conflits sur le système source.

Les outils et techniques que vous pouvez utiliser pour superviser les sources de données dépendent de la plateforme technologique. Par exemple, votre administrateur de base de données peut utiliser des événements étendus ou le Magasin des requêtes pour superviser les bases de données Azure SQL Database et SQL Server.

Parfois, Power BI accède à une source de données via une passerelle de données. Les passerelles gèrent la connectivité de la service Power BI à certains types de sources de données. Toutefois, elles font plus que se connecter aux données. Une passerelle comprend un moteur mashup qui effectue des transformations de traitement et de données sur la machine. Elle compresse et chiffre également les données afin qu’elles puissent être transmises efficacement et en toute sécurité au service Power BI. Par conséquent, une passerelle non managée ou non optimisée peut contribuer à des goulots d’étranglement des performances. Nous vous recommandons de parler à votre administrateur de passerelle pour obtenir de l’aide sur la supervision des passerelles.

Conseil

Votre administrateur Power BI peut compiler un inventaire de locataire complet (qui inclut la traçabilité) et accéder aux activités des utilisateurs dans le journal d’activité. En corrélant la traçabilité et les activités des utilisateurs, les administrateurs peuvent identifier les sources de données et les passerelles les plus fréquemment utilisées.

Pour plus d’informations sur l’inventaire des locataires et le journal d’activité, consultez Audit au niveau du locataire.

Liste de vérification : voici les décisions et actions clés pour superviser une source de données :

  • Déterminez des objectifs spécifiques : lors de la supervision d’une source de données, obtenez des précisions sur ce que vous devez accomplir et sur les objectifs de résolution des problèmes.
  • Collaborez avec les administrateurs de base de données : collaborez avec votre ou vos administrateurs de bases de données ou système pour obtenir leur aide lors de la supervision d’une source de données spécifique.
  • Collaborez avec les administrateurs de passerelle : pour les sources de données qui se connectent via une passerelle de données, collaborez avec l’administrateur de la passerelle lors de la résolution des problèmes.
  • Connectez votre équipe de support et les administrateurs de base de données : assurez-vous que votre équipe de support technique sait comment contacter les administrateurs appropriés pour chaque source de données (par exemple, lors de la résolution des problèmes de pliage des requêtes).
  • Mettez à jour les formations et les conseils : incluez des informations clés et des conseils pour les créateurs de données sur la façon d’utiliser les sources de données organisationnelles. Incluez des informations sur ce qu’il faut faire en cas de problème.

Supervision de l’actualisation des données

Une opération d’actualisation des données implique l’importation de données à partir de sources de données sous-jacentes dans un modèle sémantique, un flux de données ou un datamart Power BI. Vous pouvez planifier une opération d’actualisation des données ou l’exécuter à la demande.

Contrat de niveau de service

Le service informatique utilise généralement des contrats de niveau de service (SLA) pour documenter les attentes en matière de ressources de données. Pour Power BI, envisagez d’utiliser un contrat SLA pour le contenu critique ou le contenu au niveau de l’entreprise. Il inclut généralement quand les utilisateurs peuvent s’attendre à ce que les données mises à jour dans un modèle sémantique soient disponibles. Par exemple, vous pouvez disposer d’un contrat SLA selon lequel toutes les actualisations de données doivent être effectuées à 7h00 chaque jour.

Journaux de modèle sémantique

Les journaux des événements de modèle sémantique d’Azure Log Analytics ou de SQL Profiler (décrits précédemment dans cet article) incluent des informations détaillées sur ce qui se passe dans un modèle sémantique. Les événements capturés incluent l’activité d’actualisation du modèle sémantique. Les journaux des événements sont particulièrement utiles lorsque vous devez résoudre les problèmes et examiner les actualisations du modèle sémantique.

Modèles sémantiques de capacité Premium

Lorsque vous avez du contenu hébergé dans une capacité Power BI Premium, vous disposez de davantage de fonctionnalités pour superviser les opérations d’actualisation des données.

  • La page Résumés de l’actualisation de Power BI dans le portail d’administration inclut un résumé de l’historique d’actualisation. Ce résumé fournit des informations sur la durée d’actualisation et les messages d’erreur.
  • L’application d’utilisation et de métriques Power BI Premium inclut également des informations d’actualisation utiles. Elle est utile lorsque vous devez examiner l’activité d’actualisation pour une capacité Power BI Premium (référence SKU P) ou Power BI Embedded (référence SKU A).

Actualisations améliorées du modèle sémantique

Les créateurs de contenu peuvent lancer des actualisations de modèle sémantique par programmation à l’aide de l’actualisation améliorée avec l’API REST Power BI Actualiser le jeu de données dans le groupe. Lorsque vous utilisez l’actualisation améliorée, vous pouvez superviser les opérations d’actualisation historiques, actuelles et en attente.

Supervision de la planification de l’actualisation des données

Les administrateurs Power BI peuvent superviser les planifications d’actualisation des données dans le locataire pour déterminer si de nombreuses opérations d’actualisation sont planifiées simultanément pendant une période spécifique (par exemple, entre 5 h et 7 h, ce qui peut être une heure d’actualisation des données particulièrement occupée). Les administrateurs sont autorisés à accéder aux métadonnées de la planification d’actualisation du modèle sémantique à partir des API d’analyse des métadonnées, appelées API de scanneur.

API REST Power BI

Pour les modèles sémantiques critiques, ne vous appuyez pas uniquement sur les notifications par e-mail pour monitorer les problèmes d’actualisation des données. Envisagez de compiler l’historique d’actualisation des données dans un magasin centralisé dans lequel vous pouvez le superviser, l’analyser et agir sur la base de celui-ci.

Vous pouvez récupérer l’historique d’actualisation des données à l’aide de :

Conseil

Nous vous recommandons vivement de monitorer l’historique d’actualisation de vos modèles sémantiques pour vous assurer que les données actuelles sont disponibles pour les rapports et les tableaux de bord. Il vous aide également à savoir si les contrats de niveau de service sont respectés.

Liste de vérification : voici les décisions et actions clés pour planifier la supervision de l’actualisation des données :

  • Déterminez des objectifs spécifiques : lors de la supervision de l’actualisation des données, obtenez des précisions sur ce que vous devez accomplir et sur l’étendue du monitoring (par exemple, les modèles sémantiques de production, les modèles sémantiques certifiés, etc.).
  • Envisagez de configurer un contrat de niveau de service : déterminez si un contrat de niveau de service est utile pour définir les attentes en matière de disponibilité des données et quand les planifications d’actualisation des données doivent s’exécuter.
  • Collaborez avec les administrateurs de base de données et de passerelle : collaborez avec vos administrateurs de base de données ou système et les administrateurs de passerelle pour superviser ou résoudre les problèmes d’actualisation des données.
  • Transfert des connaissances pour l’équipe de support : assurez-vous que votre équipe de support technique sait comment aider les créateurs de contenu en cas de problèmes d’actualisation des données.
  • Mettez à jour les formations et les conseils : incluez des informations clés et des conseils pour les créateurs de données sur la façon d’actualiser les données à partir de sources de données organisationnelles et courantes. Incluez les meilleures pratiques et les préférences organisationnelles pour gérer l’actualisation des données.
  • Utilisez une adresse e-mail de support pour les notifications : pour le contenu critique, configurez les notifications d’actualisation pour utiliser une adresse e-mail de support.
  • Configurez la supervision d’actualisation centralisée : utilisez les API REST Power BI pour compiler l’historique d’actualisation des données.

Surveillance du flux de données

Vous créez un flux de données Power BI avec Power Query Online. La plupart des fonctionnalités de performances de requête et les diagnostics Power Query, qui ont été décrites précédemment, sont applicables.

Si vous le souhaitez, vous pouvez définir des espaces de travail pour utiliser Azure Data Lake Storage Gen2 pour le stockage de flux de données (appelé « bring-your-own-storage ») plutôt que pour le stockage interne. Lorsque vous utilisez bring-your-own-storage, envisagez d’activer la télémétrie afin de pouvoir superviser les métriques pour le compte de stockage. Pour plus d’informations, consultez les scénarios d’utilisation Préparation des données libre-service et Préparation des données avancée.

Vous pouvez utiliser les API REST Power BI pour superviser les transactions de flux de données. Par exemple, utilisez l’API Get Dataflow Transactions pour vérifier l’état des actualisations du flux de données.

Vous pouvez suivre les activités des utilisateurs pour les flux de données Power BI avec le journal d’activité Power BI. Pour plus d’informations, consultez Audit au niveau des locataires.

Conseil

Il existe de nombreuses meilleures pratiques que vous pouvez adopter pour optimiser vos conceptions de flux de données. Pour plus d'informations, consultez Meilleures pratiques relatives aux flux de données.

Supervision des datamarts

Un datamart Power BI comprend plusieurs composants intégrés, notamment un flux de données, une base de données managée et un modèle sémantique. Reportez-vous aux sections précédentes de cet article pour en savoir plus sur l’audit et la supervision de chaque composant.

Vous pouvez suivre les activités des utilisateurs pour les datamarts Power BI à l’aide du journal d’activité Power BI. Pour plus d’informations, consultez Audit au niveau des locataires.

Contenu connexe

Dans le prochain article de cette série, vous allez découvrir l’audit au niveau des locataires.