Power BI-Implementierungsplanung: Auditing auf Datenebene

Hinweis

Dieser Artikel ist Teil der Artikelreihe zur Power BI-Implementierungsplanung. Diese Reihe konzentriert sich hauptsächlich auf den Power BI-Workload innerhalb von Microsoft Fabric. Eine Einführung in die Artikelreihe finden Sie unter Power BI-Implementierungsplanung.

Dieser Artikel zum Auditing auf Datenebene richtet sich an mehrere Zielgruppen:

  • Datenerstellende und Arbeitsbereichsadministrator*innen: Benutzer*innen, die die Verwendung, Einführung und Leistung der Semantikmodelle (ehemals Datasets genannt), Dataflows und Datamarts verstehen müssen, die sie erstellen, veröffentlichen und freigeben.
  • Power BI-Administrator*innen: Administrator*innen, die für die Überwachung von Power BI in der Organisation verantwortlich sind. Power BI-Administrator*innen müssen möglicherweise mit Teams für IT, Sicherheit, interne Überwachung und anderen relevanten Teams zusammenarbeiten. Power BI-Administratoren müssen möglicherweise auch mit Inhaltserstellenden zusammenarbeiten, wenn sie Probleme mit der Leistung beheben.
  • Power BI-Kapazitätsadministratoren: Die Administratoren, die für die Überwachung der Premium-Kapazität in der Organisation verantwortlich sind. Power BI-Kapazitätsadministratoren müssen möglicherweise mit Inhaltserstellenden zusammenarbeiten, wenn sie Probleme mit der Leistung beheben.
  • Center of Excellence-, IT- und BI-Team: Die Teams, die ebenfalls für die Überwachung von Power BI verantwortlich sind. Sie müssen möglicherweise mit Power BI-Administrator*innen und anderen relevanten Teams zusammenarbeiten.
  • Systemadministratoren: Das Team, das für das Erstellen und Sichern von Azure Log Analytics-Ressourcen verantwortlich ist, und die Datenbankadministratoren, die Datenquellen verwalten.

Wichtig

Manchmal bezieht sich dieser Artikel auf Power BI Premium oder seine Kapazitätsabonnements (P-SKUs). Beachten Sie, dass Microsoft derzeit Kaufoptionen konsolidiert und die SKUs von Power BI Premium pro Kapazität einstellt. Neue und vorhandene Kunden sollten stattdessen den Kauf von Fabric-Kapazitätsabonnements (F-SKUs) in Betracht ziehen.

Weitere Informationen finden Sie unter Wichtige Updates zur Power BI Premium-Lizenzierung und Häufig gestellte Fragen zu Power BI Premium.

Die in diesem Artikel behandelten Konzepte gelten in erster Linie für Lösungen, die für drei Inhaltsbereitstellungsbereiche erstellt wurden, nämlich Enterprise-BI, Abteilungs-BI und Team-BI. Für Entwickler von persönlichen BI-Lösungen sind die Informationen in diesem Artikel möglicherweise ebenfalls nützlich. Sie gehören jedoch nicht zur primären Zielgruppe.

Eine gute Leistung in Berichten und Visuals ist nicht möglich, wenn das zugrunde liegende Semantikmodell und/oder die Datenquelle nicht gut funktioniert. Dieser Artikel konzentriert sich auf das Auditing und die Überwachung von Semantikmodellen, Dataflows und Datamarts. Dies ist der zweite Artikel in der Auditing- und Überwachungsreihe, da die Tools und Techniken komplexer sind als im Artikel Auditing auf Berichtsebene beschrieben. Im Idealfall erstellen Sie freigegebene Semantikmodelle (die für die Wiederverwendung in vielen Berichten bestimmt sind), bevor Benutzer*innen Berichte erstellen. Daher wird empfohlen, diesen Artikel zusammen mit dem Artikel Auditing auf Berichtsebene zu lesen.

Da Power BI-Semantikmodelle auf der tabellarischen Engine von Analysis Services basieren, können Sie eine Verbindung mit einem lokalen Datenmodell (in Power BI Desktop) oder einem Premium-Semantikmodell (im Power BI-Dienst) herstellen, als ob es sich dabei um eine Analysis Services-Datenbank handelt. Daher werden viele Auditing- und Überwachungsfunktionen von Analysis Services für Power BI Premium-Semantikmodelle unterstützt.

Hinweis

Weitere Informationen zu Modellen, die in Analysis Services gehostet werden, finden Sie unter Übersicht über die Überwachung.

Der Rest dieses Artikels konzentriert sich hauptsächlich auf Modelle, die im Power BI-Dienst veröffentlicht sind.

Ereignisprotokolle für Semantikmodelle

Im Laufe der Zeit kann es bei Erstellenden und Besitzer*innen von Daten zu bestimmten Situationen mit ihren Semantikmodellen kommen. Ein Semantikmodell kann:

  • Komplexer werden und komplexe Measures umfassen.
  • An Datenvolumen zunehmen.
  • Mehr Arbeitsspeicher verbrauchen (manchmal unnötig, wenn schlechte Entwurfsentscheidungen getroffen wurden).
  • Vielfältigere Datenquellen und komplexere Tabellenbeziehungen verwenden.
  • Weitere Regeln für die Sicherheit auf Zeilenebene (Row-Level Security, RLS) umfassen. Weitere Informationen finden Sie unter Datensicherheit basierend auf Benutzeridentität durchsetzen.
  • Über weitere, davon abhängige Berichte verfügen. Weitere Informationen zur Verwendung von Liveverbindungen mit einem freigegebenen Semantikmodell finden Sie im Nutzungsszenario Verwaltete Self-Service-BI.
  • Über weitere, davon abhängige nachgeschaltete Datenmodelle verfügen. Weitere Informationen zur Verwendung von DirectQuery für Power BI-Semantikmodelle und Analysis Services mit einem freigegebenen Semantikmodell finden Sie im Nutzungsszenario Anpassbare verwaltete Self-Service-BI.
  • Eine langsamere Abfrageausführung und langsamere Datenaktualisierungszeiten erleben.
  • Zum langsameren Rendern von Berichten und visuellen Elementen beitragen.

Um die Benutzerfreundlichkeit, die gute Leistung und die Einführung der von ihnen erstellten Inhalte zu gewährleisten, sollten Sie die Nutzung und Leistung der Datenressourcen überwachen, die Sie für die Verwaltung verantwortlich sind. Sie können die Datasetereignisprotokolle verwenden, die benutzergenerierte und vom System generierte Aktivitäten erfassen, die für ein semantisches Modell auftreten. Sie werden auch als Ablaufverfolgungsereignisse, Datasetprotokolle oder Datasetaktivitätsprotokolle bezeichnet. Systemadministratoren nennen sie häufig Ablaufverfolgungsereignisse auf niedriger Ebene, weil sie detailliert sind.

Hinweis

Die Dataset-Namensänderung wurde im Power BI-Dienst und in der Dokumentation eingeführt, obwohl es möglicherweise einige Fälle gibt – wie mit Ereignisprotokoll-Vorgängen – in denen die Änderung noch nicht aufgetreten ist.

Analysieren Sie Ablaufverfolgungsereignisse für Semantikmodelle, um:

  • Alle Aktivitäten zu prüfen, die für ein Semantikmodell stattgefunden haben
  • Probleme mit der Semantikmodellleistung, Arbeitsspeicherauslastung und Abfrageeffizienz zu beheben und diese zu optimieren
  • Details und Dauer der Semantikmodellaktualisierung zu untersuchen
  • Power Query Formelsprache (M-Abfragen), die von Power Query gesendet werden, zu überwachen.
  • DAX-Formeln und -Ausdrücke zu überwachen, die an das Semantikmodell gesendet werden (Analysis Services-Engine)
  • Zu überprüfen, ob der richtige Speichermodus basierend auf den Workloads und der Notwendigkeit ausgewählt wurde, neue Daten und optimale Leistung auszugleichen.
  • Zu überwachen, welche Rollen vom Typ Sicherheit auf Zeilenebene für welche Benutzer*innen und für welche Semantikmodelle aufgerufen werden
  • Die Anzahl gleichzeitiger Benutzer zu verstehen.
  • Ein Semantikmodell zu überprüfen (z. B. um die Datenqualität und -leistung vor dem Bestätigen eines Semantikmodells oder vor der Veröffentlichung in einem Produktionsarbeitsbereich zu überprüfen)

Die von einem Power BI-Semantikmodell generierten Ereignisse werden von vorhandenen, für Azure Analysis Services verfügbaren Diagnoseprotokollen abgeleitet. Es gibt viele Arten von Überwachungsereignissen, die Sie erfassen und analysieren können, die in den folgenden Abschnitten beschrieben werden.

Azure Log Analytics

Azure Log Analytics ist eine Komponente des Azure Monitor-Diensts. Mit der Azure Log Analytics-Integration in Power BI können Sie Semantikmodellereignisse aus allen Semantikmodellen in einem Power BI-Arbeitsbereich erfassen. Sie wird nur für Premium-Arbeitsbereiche unterstützt. Nachdem Sie die Integration eingerichtet haben und die Verbindung aktiviert ist (für einen Power BI Premium-Arbeitsbereich), werden Semantikmodellereignisse automatisch erfasst und kontinuierlich an einen Azure Log Analytics-Arbeitsbereich gesendet. Die Semantikmodellprotokolle werden in Azure Data Explorer gespeichert. Hierbei handelt es sich um eine reine Anfügedatenbank, die für die Erfassung von Telemetriedaten mit hohem Volumen in Quasi-Echtzeit optimiert ist.

Sie weisen einem Log Analytics-Arbeitsbereich in Azure einen Power BI Premium-Arbeitsbereich zu. Sie müssen eine neue Log Analytics-Ressource in Ihrem Azure-Abonnement erstellen, um diese Art der Protokollierung zu aktivieren.

Protokolle aus einem oder mehreren Power BI-Arbeitsbereichen werden an einen Log Analytics-Zielarbeitsbereich gesendet. Im Folgenden finden Sie einige Möglichkeiten, wie Sie die Daten organisieren können.

  • Ein Zielarbeitsbereich für alle Überwachungsdaten: Speichern Sie alle Daten in einem Log Analytics-Arbeitsbereich. Dies ist hilfreich, wenn derselbe Administrator oder Benutzer auf alle Daten zugreift.
  • Zielarbeitsbereiche, die nach Themenbereich organisiert sind: Organisieren Sie den Inhalt nach Themenbereich. Diese Technik ist besonders hilfreich, wenn verschiedene Administratoren oder Benutzer auf die Überwachungsdaten aus Azure Log Analytics zugreifen dürfen. Beispielsweise, wenn Sie Vertriebsdaten von Betriebsdaten trennen müssen.
  • Ein Zielarbeitsbereich für jeden Power BI-Arbeitsbereich: Richten Sie eine 1:1-Beziehung zwischen einem Power BI-Arbeitsbereich und einem Azure Log Analytics-Arbeitsbereich ein. Das ist nützlich, wenn Sie über besonders sensible Inhalte verfügen oder wenn die Daten bestimmten Compliance- oder gesetzlichen Anforderungen unterliegen.

Tipp

Lesen Sie die Dokumentation und die häufig gestellten Fragen zu dieser Funktionalität gründlich, damit Sie wissen, was möglich ist, und damit Sie die technischen Anforderungen verstehen. Bevor Sie diese Funktionalität für Arbeitsbereichsadministratoren in Ihrer Organisation allgemein verfügbar machen, sollten Sie einen technischen Proof of Concept (POC) mit einem Power BI-Arbeitsbereich durchführen.

Wichtig

Obwohl die Namen ähnlich sind, sind die von Azure Log Analytics erfassten Daten nicht identisch mit dem Power BI-Aktivitätsprotokoll. Azure Log Analytics erfasst Ablaufverfolgungsereignisse auf Detailebene aus der Analysis Services-Engine. Ihr einziger Zweck besteht darin, Sie bei der Analyse und Problembehandlung im Zusammenhang mit der Semantikmodellleistung zu unterstützen. Der Bereich befindet sich auf Arbeitsbereichsebene. Umgekehrt besteht der Zweck des Aktivitätsprotokolls darin, Ihnen zu vermitteln, wie oft bestimmte Benutzeraktivitäten auftreten (z. B. Bearbeiten eines Berichts, Aktualisieren eines Semantikmodells oder Erstellen einer App). Sein Bereich ist der gesamte Power BI-Mandant.

Weitere Informationen zu den Benutzeraktivitäten, die Sie für Ihren Power BI-Mandanten überwachen können, finden Sie unter Auditing auf Mandantenebene.

Die MandanteneinstellungAzure Log Analytics-Verbindung für Arbeitsbereichsadministratoren steuert, welche Benutzergruppen (die auch über die erforderliche Arbeitsbereichsadministratorrolle verfügen) einen Power BI-Arbeitsbereich mit einem vorhandenen Azure Log Analytics-Arbeitsbereich verbinden können.

Bevor Sie die Integration einrichten können, müssen Sie die Sicherheitsvoraussetzungen erfüllen. Erwägen Sie daher, die Power BI-Mandanteneinstellung nur für Power BI-Arbeitsbereichsadministratoren zu aktivieren, die auch über die erforderlichen Berechtigungen in Azure Log Analytics verfügen oder diese Berechtigungen auf Anfrage erhalten können.

Tipp

Arbeiten Sie frühzeitig mit Ihrem Azure-Administrator zusammen, insbesondere wenn die Erteilung der Genehmigung für die Erstellung einer neuen Azure-Ressource eine Herausforderung in Ihrer Organisation ist. Außerdem müssen Sie die Sicherheitsvoraussetzungen planen. Entscheiden Sie, ob Sie Ihrem Power BI-Arbeitsbereichsadministrator in Azure die Berechtigung erteilen oder dem Azure-Administrator in Power BI eine Berechtigung erteilen möchten.

Die von Azure Log Analytics erfassten Semantikmodellprotokolle umfassen Semantikmodellabfragen, Abfragestatistiken, detaillierte Aktualisierungsaktivitäten, CPU-Zeitverbrauch für Premium-Kapazitäten und Ähnliches. Da es sich um Protokolle auf Detailebene aus der Analysis Services-Engine handelt, können die Daten ausführlich sein. Große Datenvolumen sind üblich für große Arbeitsbereiche mit hoher Semantikmodellaktivität.

So optimieren Sie die Kosten bei Verwendung von Azure Log Analytics mit Power BI:

  • Verbinden Sie Power BI-Arbeitsbereiche nur dann mit Azure Log Analytics, wenn Sie aktiv Probleme mit der Semantikmodellaktivität behandeln bzw. die Semantikmodellaktivität aktiv testen, optimieren oder untersuchen. Bei bestehender Verbindung wird eine Ablaufverfolgung für alle Semantikmodelle im Arbeitsbereich ausgeführt.
  • Trennen Sie Azure Log Analytics von einem Power BI-Arbeitsbereich, wenn Sie nicht mehr aktiv Probleme mit der Semantikmodellaktivität behandeln bzw. aktiv die Semantikmodellaktivität testen, optimieren oder untersuchen. Durch das Trennen der Verbindung wird die Ausführung der Ablaufverfolgung für alle Semantikmodelle im Arbeitsbereich beendet.
  • Stellen Sie sicher, dass Sie das Kostenmodell für die Abrechnung von Azure Log Analytics für Datenerfassung, Speicher und Abfragen kennen.
  • Speichern Sie die Daten nicht länger als den standardmäßigen Aufbewahrungszeitraum von 30 Tagen in Log Analytics. Das liegt daran, dass sich die Semantikmodellanalyse in der Regel auf akute Problembehandlungsaktivitäten konzentriert.

Es gibt mehrere Möglichkeiten, auf die an Azure Log Analytics gesendeten Ereignisse zuzugreifen. Verwenden Sie Folgendes:

  • Die vordefinierte Vorlagen-App „Log Analytics für Power BI-Semantikmodelle“.
  • Den Power BI Desktop-Connector für Azure Data Explorer (Kusto). Verwenden Sie die Kusto-Abfragesprache (KQL), um die in Log Analytics gespeicherten Daten zu analysieren. Wenn Sie über SQL-Abfrageerfahrung verfügen, werden Ihnen viele Ähnlichkeiten mit KQL auffallen.
  • Die webbasierte Abfrageumgebung in Azure Data Explorer.
  • Jedes Abfragetool, das KQL-Abfragen senden kann.

Tipp

Da es eine große Menge an Ablaufverfolgungsereignissen für Semantikmodelle gibt, wird empfohlen, ein DirectQuery-Modell zu entwickeln, um die Daten zu analysieren. Mit einem DirectQuery-Modell können Sie die Daten nahezu in Echtzeit abfragen. Die Ereignisse kommen in der Regel innerhalb von fünf Minuten an.

Weitere Informationen finden Sie unter Steuern von Azure-Verbindungen.

Checkliste: Die Planung der Verwendung von Azure Log Analytics umfasst folgende wichtige Entscheidungen und Aktionen:

  • In Erwägung Ziehen eines technischen POC: Planen Sie ein kleines Projekt, um sicherzustellen, dass Sie die technischen Anforderungen, Sicherheitsanforderungen, die zu erfassenden Ereignisse und die Analyse der Protokolle vollständig verstehen.
  • Entscheiden, welche Arbeitsbereiche in Log Analytics integriert werden sollen: Bestimmen Sie, welche Premium-Arbeitsbereiche Semantikmodelle enthalten, die Sie analysieren möchten.
  • Entscheiden, ob Log Analytics für alle Arbeitsbereiche vollständig aktiviert werden soll: Ermitteln Sie zur Kostenoptimierung, ob es Situationen (oder bestimmte Arbeitsbereiche) gibt, in denen die Protokollierung dauerhaft aktiviert werden soll. Entscheiden Sie, ob Arbeitsbereiche getrennt werden sollen, wenn keine Problembehandlung auftritt.
  • Entscheiden, wie lange Log Analytics-Daten aufbewahrt werden sollen: Ermitteln Sie, ob ein längerer Aufbewahrungszeitraum als die Standardeinstellung von 30 Tagen festgelegt werden muss.
  • Klären des Prozesses zum Anfordern eines neuen Log Analytics-Arbeitsbereichs: Arbeiten Sie mit Ihrem Azure-Administrator zusammen, um zu klären, wie Anforderungen für eine neue Log Analytics-Ressource von Power BI-Arbeitsbereichsadministratoren übermittelt werden sollen.
  • Entscheiden, wie die Sicherheit funktioniert: Arbeiten Sie mit Ihrem Azure-Administrator zusammen, um zu entscheiden, ob es sinnvoller ist, einem Power BI-Arbeitsbereichsadministrator Rechte für einen Azure Log Analytics-Arbeitsbereich zu gewähren oder einem Azure-Administrator Rechte für einen Power BI-Arbeitsbereich zu gewähren. Berücksichtigen Sie bei dieser Sicherheitsentscheidung Ihren Plan, Arbeitsbereiche regelmäßig zu verbinden und zu trennen (zur Kostenoptimierung).
  • Entscheiden Sie, wie die Log Analytics-Zielarbeitsbereiche organisiert werden sollen: Überlegen Sie, wie viele Azure Log Analytics-Arbeitsbereiche geeignet sind, um die Daten aus einem oder mehreren Power BI-Arbeitsbereichen zu organisieren. Richten Sie diese Entscheidung an Ihren Sicherheitsentscheidungen dahingehend aus, wer auf die Protokolldaten zugreifen darf.
  • Entscheiden, welche Arbeitsbereichsadministratoren eine Verbindung herstellen dürfen: Bestimmen Sie, welche Gruppen von Arbeitsbereichsadministratoren einen Power BI-Arbeitsbereich mit einem Log Analytics-Arbeitsbereich verbinden können. Legen Sie die Mandanteneinstellung Azure Log Analytics-Verbindung für Arbeitsbereichsadministratoren entsprechend dieser Entscheidung fest.
  • Erstellen Sie die Azure Log Analytics-Ressource: Arbeiten Sie mit Ihrem Azure-Administrator zusammen, um jeden Log Analytics-Arbeitsbereich zu erstellen. Überprüfen und aktualisieren Sie die Berechtigungen, die in Azure zugewiesen sind, um sicherzustellen, dass die Power BI-Konfiguration ohne Probleme ausgeführt werden kann. Überprüfen Sie, ob sich die in Azure gespeicherten Daten in der richtigen geografischen Region befinden.
  • Festlegen der Log Analytics-Verbindung für jeden Power BI-Arbeitsbereich: Arbeiten Sie mit Ihren Power BI-Arbeitsbereichsadministratoren zusammen, um die Verbindung mit Log Analytics für jeden Power BI-Arbeitsbereich einzurichten. Stellen Sie sicher, dass die Protokolldaten ordnungsgemäß in den Log Analytics-Arbeitsbereich fließen.
  • Erstellen von Abfragen zum Analysieren der Daten: Richten Sie KQL-Abfragen ein, um die Daten in Log Analytics basierend auf Ihrem Anwendungsfall und den aktuellen Anforderungen zu analysieren.
  • Einfügen einer Anleitung für Power BI-Arbeitsbereichsadministratoren: Stellen Sie Ihren Power BI-Arbeitsbereichsadministratoren Informationen und Voraussetzungen bereit, um einen neuen Log Analytics-Arbeitsbereich anzufordern und eine Verbindung mit einem Power BI-Arbeitsbereich herzustellen. Erläutern Sie außerdem, wann die Trennung eines Power BI-Arbeitsbereichs angebracht ist.
  • Bereitstellen von Anleitungen und Beispielabfragen für die Analyse der Daten: Erstellen Sie KQL-Abfragen für Arbeitsbereichsadministratoren, um ihnen den Einstieg in die Analyse der erfassten Daten zu erleichtern.
  • Kostenüberwachung: Arbeiten Sie mit Ihrem Azure-Administrator zusammen, um Log Analytics-Kosten kontinuierlich zu überwachen.

SQL Server Profiler

Sie können SQL Server Profiler (SQL Profiler) verwenden, um Power BI-Semantikmodellereignisse zu erfassen. Das ist eine Komponente von SQL Server Management Studio (SSMS). Die Konnektivität mit einem Power BI-Semantikmodell wird mit SSMS unterstützt, da es auf der Analysis Services-Architektur basiert, die aus SQL Server stammt.

Sie können SQL Profiler in verschiedenen Phasen des Lebenszyklus eines Semantikmodells verwenden.

  • Während der Datenmodellentwicklung: SQL Profiler kann eine Verbindung mit einem Datenmodell in Power BI Desktop als externes Tool herstellen. Dieser Ansatz ist nützlich für Datenmodellierer, die ihr Datenmodell überprüfen oder Leistungsoptimierungen vornehmen möchten.
  • Nachdem das Semantikmodell im Power BI-Dienst veröffentlicht wurde: SQL Profiler kann eine Verbindung mit einem Semantikmodell in einem Premium-Arbeitsbereich herstellen. SSMS ist eines von vielen unterstützten Clienttools, die den XMLA-Endpunkt für die Konnektivität verwenden können. Dieser Ansatz ist nützlich, wenn Sie ein veröffentlichtes Semantikmodell im Power BI-Dienst auditieren, überwachen, überprüfen, Probleme behandeln oder es optimieren möchten.

Es ist auch möglich, SQL Profiler als externes Tool in DAX Studio zu verwenden. Sie können DAX Studio verwenden, um eine Profiler-Ablaufverfolgung zu starten, die Daten zu analysieren und die Ergebnisse zu formatieren. Datenmodellierer, die DAX Studio verwenden, bevorzugen diesen Ansatz häufig gegenüber der direkten Verwendung von SQL Profiler.

Hinweis

Die Verwendung von SQL Profiler ist ein anderer Anwendungsfall als die Aktivität der Profilerstellung von Daten. Sie erstellen Profile von Daten im Power Query-Editor, um ein tieferes Verständnis der Merkmale zu erhalten. Die Datenprofilerstellung ist zwar eine wichtige Aktivität für Datenmodellierer, aber nicht Gegenstand dieses Artikels.

Erwägen Sie die Verwendung von SQL Profiler anstelle von Azure Log Analytics in folgenden Fällen:

  • Ihre Organisation ermöglicht es Ihnen nicht, Azure Log Analytics-Ressourcen in Azure zu verwenden oder zu erstellen.
  • Sie möchten Ereignisse für ein Datenmodell in Power BI Desktop erfassen (das nicht in einem Premium-Arbeitsbereich im Power BI-Dienst veröffentlicht wurde).
  • Sie möchten Ereignisse für ein Semantikmodell für einen kurzen Zeitraum (anstelle aller Semantikmodelle in einem Premium-Arbeitsbereich) erfassen.
  • Sie möchten bestimmte Ereignisse nur während einer Ablaufverfolgung erfassen (z. B. nur das Ereignis Abfrageende).
  • Sie möchten Ablaufverfolgungen häufig starten und beenden (etwa wenn Sie aktuelle Semantikmodellereignisse erfassen müssen).

Genau wie Azure Log Analytics (weiter oben in diesem Artikel beschrieben) werden von SQL Profiler erfasste Semantikmodellereignisse von vorhandenen Diagnoseprotokollen, die für Azure Analysis Services verfügbar sind, abgeleitet. Es gibt jedoch einige Unterschiede bei den verfügbaren Ereignissen.

Tipp

Die Verwendung von SQL Profiler für die Überwachung von Analysis Services wird in vielen Büchern, Artikeln und Blogbeiträgen behandelt. Die meisten dieser Informationen sind für die Überwachung eines Power BI-Semantikmodells relevant.

Wichtig

Sie können SQL Profiler auch verwenden, um Abfragen zu überwachen, die vom Power BI-Dienst an die zugrunde liegenden Datenquellen gesendet werden (z. B. an eine relationale SQL Server-Datenbank). Die Funktion zum Nachverfolgen einer relationalen Datenbank ist jedoch veraltet. Das Herstellen einer Verbindung mit der Analysis Services-Engine wird unterstützt und ist nicht veraltet. Wenn Sie mit erweiterten Analysis Services-Ereignissen vertraut sind und diese lieber verwenden möchten, ist die Konnektivität von SSMS für ein Datenmodell in Power BI Desktop möglich. Es wird jedoch nicht für Power BI Premium unterstützt. Daher konzentriert sich dieser Abschnitt nur auf die Standardmäßige SQL Profiler-Konnektivität.

Die Mandanteneinstellung XMLA-Endpunkte zulassen und in Excel mit lokalen Semantikmodellen analysieren steuert, welche Benutzergruppen (die auch der Arbeitsbereichsrolle „Mitwirkender“, „Mitglied“ oder „Administrator“ oder der Berechtigung Build für das einzelne Semantikmodell zugewiesen sind) den XMLA-Endpunkt verwenden können, um Semantikmodelle im Power BI-Dienst abzufragen und/oder zu verwalten. Weitere Informationen zur Verwendung des XMLA-Endpunkts finden Sie im Verwendungsszenario Erweiterte Datenmodellverwaltung.

Hinweis

Sie können SQL Profiler auch verwenden, um bestimmte DAX-Ausdrücke zu debuggen und Probleme zu beheben. Sie können SQL Profiler als externes Tool mit Power BI Desktop verbinden. Suchen Sie nach der DAX-Auswertungsprotokollereignisklasse, um zwischengeschaltete Ergebnisse eines DAX-Ausdrucks anzuzeigen. Dieses Ereignis wird generiert, wenn Sie die EVALUATEANDLOG DAX-Funktion in einer Modellberechnung verwenden.

Diese Funktion ist nur für Entwicklungs- und Testzwecke vorgesehen. Sie sollten es aus Ihren Datenmodellberechnungen entfernen, bevor Sie das Datenmodell in einem Produktionsarbeitsbereich veröffentlichen.

Checkliste: Die Planung der Verwendung von SQL Profiler umfasst die folgenden wichtigen Entscheidungen und Aktionen:

  • Entscheiden, wer SSMS oder DAX Studio möglicherweise installiert hat: Bestimmen Sie, ob Sie es allen Power BI-Inhaltserstellenden in Ihrer Organisation erlauben, SSMS und/oder DAX Studio zu installieren, damit sie SQL Profiler verwenden können. Entscheiden Sie, ob diese Hilfstools auf Anfrage installiert werden oder Teil einer Standardsoftware sind, die für genehmigte Datenerstellende in der Organisation installiert ist.
  • Hinzufügen von SQL Profiler zum Menü „Externe Tools“ in Power BI Desktop: Wenn Datenerstellende SQL Profiler häufig verwenden, bitten Sie die IT-Instanz, sie automatisch zum Menü „Externe Tools“ in Power BI Desktop für diese Benutzer hinzuzufügen.
  • Entscheiden, wer den XMLA-Endpunkt verwenden kann: Legen Sie fest, ob alle Benutzer*innen mithilfe des XMLA-Endpunkts eine Verbindung mit veröffentlichten Semantikmodellen herstellen dürfen oder ob dies nur auf genehmigte Datenerstellende beschränkt ist. Legen Sie die Mandanteneinstellung XMLA-Endpunkte und „In Excel analysieren“ mit lokalen Semantikmodellen zulassen entsprechend dieser Entscheidung fest.
  • Bereitstellen von Anleitungen und Beispielabfragen für die Analyse der Daten: Erstellen Sie eine Dokumentation für Ihre Datenerstellenden, damit sie die empfohlene Methode zum Auditieren und Überwachen von Semantikmodellen verstehen. Stellen Sie Anleitungen für gängige Anwendungsfälle bereit, um ihnen den Einstieg in das Sammeln und Analysieren von Ablaufverfolgungsdaten zu erleichtern.

Datenmodellmetadaten

Da Power BI-Semantikmodelle auf der Analysis Services-Engine basieren, haben Sie Zugriff auf die Tools, die die Metadaten eines Datenmodells abfragen können. Metadaten enthalten alles über das Datenmodell, einschließlich Tabellennamen, Spaltennamen und Measureausdrücken.

Dynamische Verwaltungssichten

Die Dynamischen Verwaltungssichten (DMVs) von Analysis Services können die Datenmodellmetadaten abfragen. Sie können die DMVs verwenden, um Ihre Datenmodelle zu einem bestimmten Zeitpunkt zu überwachen, zu dokumentieren und zu optimieren.

Insbesondere bestehen die folgenden Möglichkeiten:

  • Auditieren Sie die von einem Modell verwendeten Datenquellen.
  • Ermitteln Sie, welche Objekte den meisten Arbeitsspeicher in einem Modell verbrauchen.
  • Bestimmen Sie, wie effizient Spaltendaten komprimiert werden können.
  • Suchen Sie nach Spalten in einem Modell, die nicht verwendet werden.
  • Auditieren Sie aktive Benutzersitzungen und -verbindungen.
  • Überprüfen Sie die Struktur des Modells.
  • Überprüfen Sie DAX-Ausdrücke, die von berechneten Tabellen, berechneten Spalten, Measures und RLS-Regeln (Row-Level Security) verwendet werden.
  • Identifizieren Sie Abhängigkeiten zwischen Objekten und Measures.

Tipp

Die DMVs rufen Informationen zum aktuellen Zustand eines Semantikmodells ab. Stellen Sie sich die von DMVs zurückgegebenen Daten als Momentaufnahme dessen vor, was zu einem bestimmten Zeitpunkt auftritt. Umgekehrt rufen die Ereignisprotokolle für Semantikmodelle (weiter oben in diesem Artikel beschrieben) Informationen dazu ab, welche Aktivitäten für ein Semantikmodell aufgetreten sind, während eine Ablaufverfolgungsverbindung aktiv war.

SSMS ist ein Tool, das häufig zum Ausführen von DMV-Abfragen verwendet wird. Sie können auch das PowerShell-Cmdlet Invoke-ASCmd verwenden, um XMLA-Skripts zu erstellen und auszuführen, die die DMVs abfragen.

Tools von Drittanbietern und externe Tools sind auch bei der Power BI-Community beliebt. Diese Tools verwenden die öffentlich dokumentierten DMVs, um den Zugriff zu vereinfachen und mit den von den DMVs zurückgegebenen Daten zu arbeiten. Ein Beispiel ist DAX Studio, das explizite Funktionen für den Zugriff auf die DMVs enthält. DAX Studio enthält auch ein integriertes Feature Metriken anzeigen, das allgemein als Vertipaq Analyzer bezeichnet wird. Vertipaq Analyzer verfügt über eine Benutzeroberfläche zum Analysieren der Struktur und Größe von Tabellen, Spalten, Beziehungen und Partitionen in einem Datenmodell. Sie können die Datenmodellmetadaten auch in eine VPAX-Datei exportieren (oder importieren). Die exportierte Datei enthält nur Metadaten zur Datenmodellstruktur und -größe und speichert keine Modelldaten.

Tipp

Erwägen Sie, eine VPAX-Datei für eine andere Person freizugeben, wenn Sie Hilfe bei einem Datenmodell benötigen. Auf diese Weise geben Sie für diese Person keine Modelldaten frei.

Sie können DMV-Abfragen in verschiedenen Phasen des Lebenszyklus eines Semantikmodells verwenden.

  • Während der Datenmodellentwicklung: SQL Profiler kann eine Verbindung mit einem Datenmodell in Power BI Desktop als externes Tool herstellen. Dieser Ansatz ist nützlich für Datenmodellierer, die ihr Datenmodell überprüfen oder Leistungsoptimierungen vornehmen möchten.
  • Nachdem das Semantikmodell im Power BI-Dienst veröffentlicht wurde: Das Tool Ihrer Wahl kann eine Verbindung mit einem Semantikmodell in einem Premium-Arbeitsbereich herstellen. SSMS ist eines von vielen unterstützten Clienttools, die den XMLA-Endpunkt für die Konnektivität verwenden. Dieser Ansatz ist nützlich, wenn Sie ein veröffentlichtes Semantikmodell im Power BI-Dienst auditieren oder überprüfen möchten.

Tipp

Wenn Sie Ihre eigenen DMV-Abfragen schreiben möchten (z. B. in SSMS), beachten Sie, dass die DMVs nicht alle SQL-Vorgänge unterstützen. Außerdem werden einige DMVs in Power BI nicht unterstützt (da sie Analysis Services-Serveradministratorberechtigungen erfordern, die von Power BI nicht unterstützt werden).

Die Mandanteneinstellung XMLA-Endpunkte zulassen und in Excel mit lokalen Semantikmodellen analysieren steuert, welche Benutzergruppen (die auch der Arbeitsbereichsrolle „Mitwirkender“, „Mitglied“ oder „Administrator“ oder der Berechtigung Build für das einzelne Semantikmodell zugewiesen sind) den XMLA-Endpunkt verwenden können, um Semantikmodelle im Power BI-Dienst abzufragen und/oder zu verwalten.

Weitere Informationen zur Verwendung des XMLA-Endpunkts, der Tools von Drittanbietern und von externen Tools finden Sie im Nutzungsszenario für die erweiterte Datenmodellverwaltung.

Best Practice Analyzer

Best Practice Analyzer (BPA) ist ein Feature von Tabular Editor, einem Drittanbietertool, das von der Power BI-Community häufig verwendet wird. BPA enthält eine Reihe anpassbarer Regeln, mit denen Sie die Qualität, Konsistenz und Leistung Ihres Datenmodells überwachen können.

Tipp

Laden Sie zum Einrichten von BPA den Satz bewährter Methodenregeln herunter, die von Microsoft auf GitHub bereitgestellt werden.

In erster Linie kann BPA Ihnen helfen, die Konsistenz von Modellen zu verbessern, indem suboptimale Entwurfsentscheidungen erkannt und somit Leistungsprobleme reduziert werden können. Dies ist hilfreich, wenn Sie Self-Service-Datenmodellierer auf verschiedene Bereiche der Organisation verteilt haben.

BPA kann Ihnen auch dabei helfen, Ihre Datenmodelle zu überwachen und zu steuern. Sie können beispielsweise überprüfen, ob ein Datenmodell Row-Level Security-Rollen (RLS) enthält. Alternativ können Sie überprüfen, ob alle Modellobjekte über eine Beschreibung verfügen. Dies ist hilfreich, wenn Sie beispielsweise sicherstellen möchten, dass ein Datenmodell ein Datenwörterbuch enthält.

BPA kann Entwurfsprobleme offenlegen, die dem Center of Excellence helfen können festzustellen, ob weitere Schulungen oder Dokumentationen erforderlich sind. Es kann Maßnahmen ergreifen, um Datenersteller über bewährte Methoden und Organisationsrichtlinien zu informieren.

Tipp

Beachten Sie, dass BPA das Vorhandensein eines Merkmals (z. B. Sicherheit auf Zeilenebene) erkennen kann. Es kann jedoch schwierig sein festzustellen, ob es richtig eingerichtet ist. Aus diesem Grund muss möglicherweise eine Überprüfung durch einen Fachexperten durchgeführt werden. Umgekehrt bedeutet die Nichtexistenz eines bestimmten Merkmals nicht unbedingt ein schlechtes Design; der Datenmodellierer kann einen guten Grund für die Erstellung eines bestimmten Entwurfs haben.

Checkliste: Die Planung des Zugriffs auf Metadaten für Datenmodelle beinhaltet die folgenden wichtigen Entscheidungen und Maßnahmen:

  • Entscheiden, von wem SSMS installiert werden kann: Legen Sie fest, ob Sie allen Erstellenden von Power BI-Inhalten in Ihrer Organisation die Installation von SSMS erlauben möchten, damit sie eine Verbindung mit veröffentlichten Semantikmodellen herstellen können. Entscheiden Sie, ob es auf Anfrage installiert wird oder Teil einer Standardsoftware ist, die für genehmigte Datenerstellende in der Organisation installiert ist.
  • Entscheiden, von wem Drittanbietertools installiert werden können: Legen Sie fest, ob Sie allen Erstellenden von Power BI-Inhalten in Ihrer Organisation die Installation von Drittanbietertools (z. B. DAX Studio und Tabular Editor) erlauben möchten, damit sie lokale Datenmodelle und/oder veröffentlichte Semantikmodelle überwachen können. Entscheiden Sie, ob sie auf Anfrage installiert werden oder Teil einer Standardsoftware sind, die für genehmigte Datenerstellende in der Organisation installiert ist.
  • Einrichten von Best Practices-Regeln: Entscheiden Sie, welche Best Practice Analyzer-Regeln die Datenmodelle in Ihrer Organisation scannen können.
  • Entscheiden, wer den XMLA-Endpunkt verwenden kann: Legen Sie fest, ob alle Benutzer*innen mithilfe des XMLA-Endpunkts eine Verbindung mit Semantikmodellen herstellen dürfen oder ob dies nur auf genehmigte Datenerstellende beschränkt ist. Legen Sie die Mandanteneinstellung XMLA-Endpunkte und „In Excel analysieren“ mit lokalen Semantikmodellen zulassen entsprechend dieser Entscheidung fest.
  • Bereitstellen von Anleitungen für Inhaltserstellende: Erstellen Sie eine Dokumentation für Ihre Datenerstellenden, damit sie die empfohlenen Methoden zum Analysieren von Semantikmodellen verstehen. Stellen Sie Anleitungen zu gängigen Anwendungsfällen bereit, um ihnen das Sammeln und Analysieren von DMV-Ergebnissen und/oder die Verwendung von Best Practice Analyzer zu erleichtern.

Datenmodell- und Abfrageleistung

Power BI Desktop enthält mehrere Tools, die Datenerstellenden bei der Problembehandlung und Untersuchung ihrer Datenmodelle helfen. Diese Funktionen richten sich an Datenmodellierer, die ihr Datenmodell überprüfen und die Leistungsoptimierung vor der Veröffentlichung im Power BI-Dienst durchführen möchten.

Leistungsanalyse

Verwenden Sie die Leistungsanalyse, die in Power BI Desktop verfügbar ist, um die Leistung eines Datenmodells zu überwachen und zu untersuchen. Die Leistungsanalyse hilft Berichtserstellenden, die Leistung einzelner Berichtselemente zu messen. In der Regel stehen Leistungsprobleme jedoch im Zusammenhang mit dem Entwurf des Datenmodells. Aus diesem Grund können auch Erstellende von Semantikmodellen von der Verwendung der Leistungsanalyse profitieren. Wenn es verschiedene Inhaltserstellende gibt, die für die Erstellung von Berichten und Semantikmodellen verantwortlich sind, müssen sie wahrscheinlich bei der Behandlung eines Leistungsproblems zusammenarbeiten.

Tipp

Sie können DAX Studio verwenden, um die von der Leistungsanalyse generierten Protokolldateien zu importieren und zu analysieren.

Weitere Informationen zur Leistungsanalyse finden Sie unter Auditing auf Berichtsebene.

Abfragediagnose

Verwenden Sie die Abfragediagnose, die in Power BI Desktop verfügbar ist, um die Leistung von Power Query zu untersuchen. Sie sind nützlich für die Problembehandlung und für den Fall, dass Sie verstehen müssen, was die Power Query Engine tut.

Die Informationen, die Sie aus der Abfragediagnose gewinnen können, umfassen:

  • Zusätzliche Details im Zusammenhang mit Fehlermeldungen (wenn eine Ausnahme auftritt).
  • Die Abfragen, die an eine Datenquelle gesendet werden.
  • Ob die Abfragefaltung erfolgt oder nicht.
  • Die Anzahl der von einer Abfrage zurückgegebenen Zeilen.
  • Mögliche Verlangsamungen während eines Datenaktualisierungsvorgangs.
  • Hintergrundereignisse und systemgenerierte Abfragen.

Je nachdem, wonach Sie suchen, können Sie ein oder alle Protokolle aktivieren: aggregierte, detaillierte, Leistungsindikatoren und Datenschutzpartitionen.

Sie können die Sitzungsdiagnose in Power Query-Editor starten. Nach der Aktivierung werden Abfrage- und Aktualisierungsvorgänge gesammelt, bis die Diagnoseablaufverfolgung beendet ist. Die Daten werden direkt im Abfrage-Editor aufgefüllt, sobald die Diagnose beendet ist. Power Query erstellt eine Diagnosegruppe (Ordner) und fügt ihr mehrere Abfragen hinzu. Anschließend können Sie die standardmäßige Power Query-Funktionalität verwenden, um die Diagnosedaten anzuzeigen und zu analysieren.

Alternativ können Sie eine Ablaufverfolgung in Power BI Desktop im Abschnitt Diagnose des Fensters Optionen aktivieren. Protokolldateien werden in einem Ordner auf Ihrem lokalen Computer gespeichert. Diese Protokolldateien werden mit den Daten aufgefüllt, nachdem Sie Power BI Desktop geschlossen haben, wodurch die Ablaufverfolgung beendet wird. Sobald Power BI Desktop geschlossen ist, können Sie die Protokolldateien mit Ihrem bevorzugten Programm (z. B. einem Text-Editor) öffnen, um sie anzuzeigen.

Abfrageauswertung und -faltung

Power Query unterstützt verschiedene Funktionen, die Ihnen helfen, die Abfrageauswertung zu verstehen, einschließlich des Abfrageplans. Außerdem können Sie feststellen, ob die Abfragefaltung für eine gesamte Abfrage oder für eine Teilmenge von Schritten in einer Abfrage erfolgt. Die Abfragefaltung ist einer der wichtigsten Aspekte der Leistungsoptimierung. Es ist auch hilfreich, die nativen Abfragen zu überprüfen, die von Power Query gesendet werden, wenn Sie eine Datenquelle überwachen, was weiter unten in diesem Artikel beschrieben wird.

Premium Metrik-App

Bei der Problembehandlung kann es hilfreich sein, mit Ihrem Power BI Premium-Kapazitätsadministrator zusammenzuarbeiten. Der Kapazitätsadministrator hat Zugriff auf die Power BI Premium Nutzungs- und Metrik-App. Diese App kann Ihnen eine Fülle von Informationen zu Aktivitäten bereitstellen, die in der Kapazität stattfinden. Diese Informationen können Ihnen bei der Behandlung von Problemen mit Semantikmodellen helfen.

Tipp

Ihr Premium-Kapazitätsadministrator kann zusätzlichen Benutzern (Nicht-Kapazitätsadministratoren) Zugriff gewähren, um ihnen den Zugriff auf die Premium Metrik-App zu ermöglichen.

Die Premium-Metrik-App umfasst ein internes Semantikmodell und einen ersten Satz von Berichten. Sie unterstützt Sie bei der Nahezu-Echtzeitüberwachung einer Power BI Premium Kapazität (P-SKU) oder einer Power BI Embedded-Kapazität (A SKU). Sie enthält Daten für die letzten zwei bis vier Wochen (abhängig von der Metrik).

Verwenden Sie die Premium-Metrik-App, um Probleme zu beheben und Semantikmodelle zu optimieren. Sie können beispielsweise Semantikmodelle identifizieren, die einen großen Arbeitsspeicherbedarf oder immer wieder eine hohe CPU-Auslastung aufweisen. Sie ist auch nützlich, um Semantikmodelle zu finden, die sich der Kapazitätsgrenze nähern.

Checkliste: Wenn Sie Ansätze für die Überwachung der Datenmodell- und Abfrageleistung in Betracht ziehen, sind die wichtigsten Entscheidungen und Aktionen:

  • Identifizieren von Leistungszielen für das Abfragen von Semantikmodellen: Stellen Sie sicher, dass Sie verstehen, was gute Semantikmodellleistung bedeutet. Bestimmen Sie, wann Sie bestimmte Abfrageleistungsziele benötigen (z. B.: Abfragen zur Unterstützung von Berichten müssen innerhalb von fünf Sekunden gerendert werden). Stellen Sie in diesem Fall sicher, dass die Ziele den Datenerstellern in Ihrer Organisation mitgeteilt werden.
  • Identifizieren von Leistungszielen für das Aktualisieren von Semantikmodellen: Bestimmen Sie, wann Sie bestimmte Datenaktualisierungsziele benötigen (z. B. Abschluss eines Datenaktualisierungsvorgangs innerhalb von 15 Minuten und vor 5 Uhr). Stellen Sie in diesem Fall sicher, dass die Ziele den Datenerstellern in Ihrer Organisation mitgeteilt werden.
  • Informieren Ihres Supportteams: Stellen Sie sicher, dass Ihr internes Benutzersupportteam mit den Diagnosefunktionen vertraut ist, damit es Power BI-Benutzer unterstützen kann, wenn sie Hilfe benötigen.
  • Verbinden Ihres Supportteams mit den Datenbankadministratoren: Stellen Sie sicher, dass Ihr Supportteam weiß, wie Sie die jeweiligen Administratoren für jede Datenquelle kontaktieren können (z. B. bei der Problembehandlung beim Falten von Abfragen).
  • Zusammenarbeiten mit Ihrem Premium-Kapazitätsadministrator bzw. Ihrer Premium-Kapazitätsadministratorin: Wenden Sie sich an Ihren Premium-Kapazitätsadministrator bzw. an Ihre Premium-Kapazitätsadministratorin, um die Probleme im Zusammenhang mit Semantikmodellen zu behandeln, die sich in einem Arbeitsbereich befinden, der der Premium-Kapazität oder der Power BI Embedded-Kapazität zugewiesen ist. Fordern Sie ggf. Zugriff auf die Premium Metrik-App an.
  • Bereitstellen von Anleitungen für Inhaltserstellende: Erstellen Sie eine Dokumentation für Ihre Datenerstellenden, damit sie verstehen, welche Aktionen bei der Problembehandlung zu ergreifen sind.
  • Einbeziehen in Schulungsmaterialien: Stellen Sie Ihren Datenerstellenden Anleitungen zum Erstellen leistungsstarker Datenmodelle zur Verfügung. Helfen Sie ihnen, frühzeitig gute Entwurfsgewohnheiten anzunehmen. Konzentrieren Sie sich darauf, Datenerstellenden beizubringen, wie sie gute Entwurfsentscheidungen treffen können.

Datenquellenüberwachung

Manchmal ist es erforderlich, eine bestimmte Datenquelle, mit der Power BI eine Verbindung herstellt, direkt zu überwachen. Beispielsweise können Sie über ein Data Warehouse verfügen, bei dem eine erhöhte Workload auftritt, sodass Benutzer von Leistungseinbußen berichten. In der Regel werden Datenquellen von einem Datenbank- oder Systemadministrator überwacht.

Sie können eine Datenquelle überwachen, um Folgendes zu erreichen:

  • Auditieren, welche Benutzer Abfragen an die Datenquelle senden.
  • Auditieren, welche Anwendungen (wie Power BI) Abfragen an die Datenquelle senden.
  • Überprüfen, welche Abfrageanweisungen wann und von welchen Benutzern an die Datenquelle gesendet werden.
  • Bestimmen, wie lange es dauert, bis eine Abfrage ausgeführt wird.
  • Überwachen, wie die Sicherheit auf Zeilenebene vom Quellsystem aufgerufen wird, wenn einmaliges Anmelden (Single Sign-On, SSO) verwendet wird.

Es gibt viele Aktionen, die Power BI-Inhaltserstellende ausführen können, wenn sie die Überwachungsergebnisse analysieren. Sie können:

  • Die Abfragen, die an die Datenquelle gesendet werden, optimieren und verfeinern, damit sie so effizient wie möglich sind.
  • Die nativen Abfragen, die an die Datenquelle gesendet werden, überprüfen und optimieren.
  • Die Anzahl der Spalten reduzieren, die in ein Datenmodell importiert werden.
  • Spalten mit hoher Genauigkeit und hoher Kardinalität entfernen, die in ein Datenmodell importiert werden.
  • Die Menge an Verlaufsdaten reduzieren, die in ein Datenmodell importiert werden.
  • Die Power BI-Datenaktualisierungszeiten anpassen, um die Nachfrage nach der Datenquelle zu verteilen.
  • Inkrementelle Datenaktualisierung verwenden, um die Last der Datenquelle zu reduzieren.
  • Die Anzahl von Power BI-Datenaktualisierungen reduzieren, indem mehrere Semantikmodelle in einem freigegebenen Semantikmodell konsolidiert werden.
  • Die Einstellungen für die automatische Seitenaktualisierung anpassen, um die Aktualisierungshäufigkeit zu erhöhen und damit die Last der Datenquelle zu verringern.
  • Berechnungen vereinfachen, um die Komplexität von Abfragen zu verringern, die an die Datenquelle gesendet werden.
  • Den Datenspeichermodus ändern (z. B. in den Importmodus anstelle von DirectQuery), um die konsistente Abfragelast für die Datenquelle zu verringern.
  • Methoden zur Abfragereduzierung verwenden, um die Anzahl von Abfragen zu reduzieren, die an die Datenquelle gesendet werden.

Systemadministratoren können andere Aktionen ergreifen. Sie können:

  • Eine zwischengeschaltete Datenebene einführen, z. B. Power BI-Dataflows (wenn ein Data Warehouse keine praktikable Option ist). Power BI-Inhaltserstellende können die Dataflows als Datenquelle verwenden, anstatt eine direkte Verbindung mit Datenquellen herzustellen. Eine zwischengeschaltete Datenebene kann die Last eines Quellsystems reduzieren. Sie hat auch den zusätzlichen Vorteil der Zentralisierung der Datenaufbereitungslogik. Weitere Informationen finden Sie in den Anwendungsszenarien zur Self-Service-Datenaufbereitung.
  • Den Speicherort der Datenquelle ändern, um die Auswirkungen der Netzwerklatenz zu verringern (z. B., indem dieselbe Datenregion für Power BI-Dienst, Datenquellen und Gateways verwendet wird).
  • Die Datenquelle optimieren, damit Daten für Power BI effizienter abgerufen werden. Verschiedene Commons-Techniken umfassen das Erstellen von Tabellenindizes, das Erstellen von indizierten Ansichten, das Erstellen dauerhaft berechneter Spalten, das Verwalten von Statistiken, die Verwendung von In-Memory- oder Columnstore-Tabellen und das Erstellen materialisierter Ansichten.
  • Benutzer anweisen, anstelle einer ursprünglichen Produktionsdatenbank ein schreibgeschütztes Replikat der Datenquelle zu verwenden. Ein Replikat kann im Rahmen einer Hochverfügbarkeitsdatenbankstrategie verfügbar sein. Ein Vorteil eines schreibgeschützten Replikats besteht darin, Konflikte im Quellsystem zu reduzieren.

Welche Tools und Techniken Sie zum Überwachen von Datenquellen verwenden können, hängt von der Technologieplattform ab. Ihr Datenbankadministrator kann beispielsweise erweiterte Ereignisse oder den Abfragespeicher für die Überwachung der Azure SQL-Datenbank und SQL Server-Datenbanken verwenden.

Manchmal greift Power BI über ein Datengateway auf eine Datenquelle zu. Gateways verarbeiten die Konnektivität vom Power BI-Dienst zu bestimmten Arten von Datenquellen. Sie stellen jedoch nicht nur eine Verbindung zu Daten her. Ein Gateway enthält eine Mashup-Engine, die Verarbeitungs- und Datentransformationen auf dem Computer ausführt. Außerdem werden die Daten komprimiert und verschlüsselt, sodass sie effizient und sicher an den Power BI-Dienst übertragen werden können. Daher kann ein nicht verwaltetes oder nicht optimiertes Gateway zu Leistungsengpässen beitragen. Es wird empfohlen, mit Ihrem Gatewayadministrator zu sprechen, um Hilfe bei der Überwachung von Gateways zu erhalten.

Tipp

Ihr Power BI-Administrator kann einen vollständigen Mandantenbestand (einschließlich Herkunft) kompilieren und auf Benutzeraktivitäten im Aktivitätsprotokoll zugreifen. Durch das Korrelieren der Herkunfts- und Benutzeraktivitäten können Administratoren die am häufigsten verwendeten Datenquellen und Gateways identifizieren.

Weitere Informationen zum Mandantenbestand und zum Aktivitätsprotokoll finden Sie unter Auditing auf Mandantenebene.

Checkliste: Die Planung der Überwachung einer Datenquelle umfasst folgende wichtige Entscheidungen und Aktionen:

  • Festlegen bestimmter Ziele: Wenn Sie eine Datenquelle überwachen, erhalten Sie Klarheit darüber, was Sie genau erreichen müssen und welche Ziele Sie für die Problembehandlung festlegen sollten.
  • Zusammenarbeit mit Datenbankadministratoren: Wenden Sie sich an Ihre Datenbank- oder Systemadministratoren, um Hilfe beim Überwachen einer bestimmten Datenquelle zu erhalten.
  • Zusammenarbeit mit Gatewayadministratoren: Bei Datenquellen, die eine Verbindung über ein Datengateway herstellen, sollten Sie bei der Problembehandlung mit dem Gatewayadministrator zusammenarbeiten.
  • Verbinden Ihres Supportteams mit den Datenbankadministratoren: Stellen Sie sicher, dass Ihr Supportteam weiß, wie Sie die jeweiligen Administratoren für jede Datenquelle kontaktieren können (z. B. bei der Problembehandlung beim Falten von Abfragen).
  • Aktualisieren von Schulungen und Anleitungen: Fügen Sie wichtige Informationen und Tipps für Datenerstellende zum Arbeiten mit Organisationsdatenquellen ein. Fügen Sie Informationen darüber hinzu, was zu tun ist, wenn etwas schief geht.

Überwachung der Datenaktualisierung

Ein Datenaktualisierungsvorgang beinhaltet das Importieren von Daten aus zugrunde liegenden Datenquellen in ein Power BI-Semantikmodell, einen Dataflow oder einen Datamart. Sie können einen Datenaktualisierungsvorgang planen oder nur bei Bedarf ausführen.

Vereinbarung zum Servicelevel

In der IT werden häufig Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) verwendet, um die Erwartungen an Datenressourcen zu dokumentieren. Für Power BI sollten Sie eine SLA für kritische Inhalte oder Inhalte auf Unternehmensebene verwenden. Dies beinhaltet in der Regel, wann Benutzer*innen davon ausgehen können, dass aktualisierte Daten in einem Semantikmodell verfügbar sind. Beispielsweise könnte eine SLA vorsehen, dass alle Datenaktualisierungen jeden Tag um 7 Uhr abgeschlossen sein müssen.

Semantikmodellprotokolle

Die Ereignisprotokolle für Semantikmodelle von Azure Log Analytics oder SQL Profiler (zuvor in diesem Artikel beschrieben) enthalten ausführliche Informationen zu den Vorgängen in einem Semantikmodell. Die erfassten Ereignisse umfassen die Aktualisierungsaktivität für Semantikmodelle. Die Ereignisprotokolle sind besonders nützlich für die Problembehandlung und Untersuchung im Zusammenhang mit Semantikmodellaktualisierungen.

Semantikmodelle mit Premium-Kapazität

Wenn Sie über Inhalte verfügen, die in einer Power BI Premium-Kapazität gehostet werden, verfügen Sie über mehr Funktionen zum Überwachen von Datenaktualisierungsvorgängen.

  • Die Seite Zusammenfassungen der Power BI-Aktualisierung im Verwaltungsportal enthält eine Zusammenfassung des Aktualisierungsverlaufs. Diese Zusammenfassung enthält Informationen zur Aktualisierungsdauer und zu Fehlermeldungen.
  • Die App Power BI Premium-Nutzung und -Metriken enthält auch hilfreiche Aktualisierungsinformationen. Dies ist nützlich, wenn Sie die Aktualisierungsaktivität für eine Power BI Premium-Kapazität (P-SKU) oder Power BI Embedded-Kapazität (A SKU) untersuchen müssen.

Erweiterte Semantikmodellaktualisierungen

Inhaltserstellende können Semantikmodellaktualisierungen programmgesteuert initiieren, indem sie die erweiterte Aktualisierung mithilfe der Power BI-REST-API zum Aktualisieren des Semantikmodells in der Gruppe verwenden. Wenn Sie die erweiterte Aktualisierung verwenden, können Sie die verlaufsbezogenen, aktuellen und ausstehenden Aktualisierungsvorgänge überwachen.

Überwachung des Datenaktualisierungszeitplans

Power BI-Administratoren können Datenaktualisierungszeitpläne im Mandanten überwachen, um zu ermitteln, ob während eines bestimmten Zeitraums viele Aktualisierungsvorgänge gleichzeitig geplant sind (z. B. zwischen 5 und 7 Uhr, was eine besonders ausgelastete Datenaktualisierungszeit sein kann). Administrator*innen sind berechtigt, über die Metadatenüberprüfungs-APIs, die als Scanner-APIs bezeichnet werden, auf die Metadaten des Semantikmodell-Aktualisierungszeitplans zuzugreifen.

Power BI-REST-APIs

Verlassen Sie sich bei wichtigen Semantikmodellen nicht ausschließlich auf E-Mail-Benachrichtigungen, um Datenaktualisierungsprobleme zu überwachen. Erwägen Sie, den Datenaktualisierungsverlauf in einem zentralisierten Speicher zu kompilieren, in dem Sie ihn überwachen, analysieren und darauf reagieren können.

Sie können den Datenaktualisierungsverlauf wie folgt abrufen:

Tipp

Es wird dringend empfohlen, den Aktualisierungsverlauf Ihrer Semantikmodelle zu überwachen, um sicherzustellen, dass aktuelle Daten für Berichte und Dashboards verfügbar sind. Das hilft Ihnen auch herauszufinden, ob SLAs erfüllt werden.

Checkliste: Die Planung der Überwachung von Datenaktualisierung umfasst folgende wichtige Entscheidungen und Aktionen:

  • Festlegen bestimmter Ziele: Verschaffen Sie sich beim Überwachen von Datenaktualisierungen Klarheit darüber, was genau Sie erreichen möchten und welchen Umfang die Überwachung haben sollte (z. B. Produktionssemantikmodelle, zertifizierte Semantikmodelle und andere).
  • Erwägen der Einrichtung einer SLA: Bestimmen Sie, ob eine SLA nützlich ist, um Erwartungen an die Datenverfügbarkeit und Datenaktualisierungszeitpläne festzulegen.
  • Zusammenarbeit mit Datenbank- und Gatewayadministratoren: Arbeiten Sie mit Ihren Datenbank- oder Systemadministratoren und Gatewayadministratoren zusammen, um Datenaktualisierungen zu überwachen oder Probleme zu beheben.
  • Wissenstransfer für das Supportteam: Stellen Sie sicher, dass Ihr Supportteam weiß, wie es Inhaltserstellenden helfen kann, wenn Probleme bei der Datenaktualisierung auftreten.
  • Aktualisieren von Schulungen und Anleitungen: Fügen Sie wichtige Informationen und Tipps für Datenerstellende zum Aktualisieren von Daten aus Organisationsdatenquellen und gängigen Datenquellen ein. Fügen Sie bewährte Methoden und Organisationseinstellungen für die Verwaltung der Datenaktualisierung ein.
  • Verwenden einer Support-E-Mail-Adresse für Benachrichtigungen: Richten Sie für kritische Inhalte eine Support-E-Mail-Adresse für Aktualisierungsbenachrichtigungen ein.
  • Einrichten der zentralisierten Aktualisierungsüberwachung: Verwenden Sie die Power BI-REST-APIs, um den Datenaktualisierungsverlauf zu kompilieren.

Datenflussüberwachung

Sie erstellen einen Power BI-Dataflow mit Power Query Online. Viele der zuvor beschriebenen Features für die Abfrageleistung und die Power Query Diagnose sind anwendbar.

Optional können Sie Arbeitsbereiche so festlegen, dass Azure Data Lake Storage Gen2 für Dataflowspeicher (als Bring-Your-Own-Storage bezeichnet) anstelle des internen Speichers verwendet werden. Wenn Sie Bring-Your-Own-Storage verwenden, sollten Sie die Aktivierung von Telemetriedaten in Betracht ziehen, damit Sie Metriken für das Speicherkonto überwachen können. Weitere Informationen finden Sie in den Anwendungsszenarien zur Self-Service-Datenaufbereitung und zur erweiterten Datenaufbereitung.

Sie können die Power BI-REST-APIs verwenden, um Dataflowtransaktionen zu überwachen. Verwenden Sie beispielsweise die API zum Abrufen von Datenflusstransaktionen, um die Status von Dataflowaktualisierungen zu überprüfen.

Sie können Benutzeraktivitäten für Power BI-Dataflows mit dem Power BI-Aktivitätsprotokoll nachverfolgen. Weitere Informationen finden Sie unter Auditing auf Mandantenebene.

Tipp

Es gibt viele bewährte Methoden, die Sie anwenden können, um Ihre Dataflowdesigns zu optimieren. Weitere Informationen finden Sie unter Bewährte Methoden für Dataflows.

Datamart-Überwachung

Ein Power BI-Datamart umfasst mehrere integrierte Komponenten, einschließlich eines Dataflows, einer verwalteten Datenbank und eines Semantikmodells. Die vorherigen Abschnitten dieses Artikels enthalten weitere Informationen zum Auditing und zur Überwachung der einzelnen Komponenten.

Sie können Benutzeraktivitäten für Power BI-Datamarts mit dem Power BI-Aktivitätsprotokoll nachverfolgen. Weitere Informationen finden Sie unter Auditing auf Mandantenebene.

Im nächsten Artikel dieser Serie erfahren Sie etwas über das Auditing auf Mandantenebene.