Verfahren zur Datenreduktion für die Importmodellierung

  • Artikel

Dieser Artikel richtet sich an Power BI Desktop-Datenmodellierer, die Importmodelle entwickeln. Im Folgenden werden die verschiedenen Verfahren zur Reduktion von Daten beschrieben, die in Importmodelle geladen werden.

In Importmodelle werden Daten geladen, die zuerst komprimiert und optimiert und anschließend von der VertiPaq-Speicher-Engine auf dem Datenträger gespeichert werden. Wenn die Quelldaten in den Speicher geladen werden, ist eine 10-fache Komprimierung möglich, sodass man davon ausgehen kann, dass 10 GB Quelldaten auf eine Größe von etwa 1 GB komprimiert werden können. Darüber hinaus kann eine zusätzliche Reduzierung von 20 % erreicht werden, wenn die Daten auf der Festplatte gespeichert werden.

Trotz der von der VertiPaq-Speicher-Engine erzielten Effizienz ist es wichtig, dass Sie sich bemühen, die Daten, die in Ihre Modelle geladen werden müssen, so gering wie möglich zu halten. Dies gilt insbesondere für große Modelle und Modelle, die im Laufe der Zeit voraussichtlich größer werden. Vier Gründe sprechen für eine Reduktion der Daten:

  • Größere Modelle werden von Ihrer Kapazität möglicherweise nicht unterstützt. Eine gemeinsam genutzte Kapazität kann Modelle mit einer Größe von bis zu 1 GB hosten, während Premium-Kapazitäten je nach SKU größere Modelle hosten können. Weitere Informationen finden Sie im Artikel Unterstützung von großen Semantikmodellen in Power BI Premium. (Semantikmodelle waren früher als Datasets bekannt.)
  • Kleinere Modelle führen zu weniger Konflikten bei Kapazitätsressourcen. Dies gilt insbesondere für den Arbeitsspeicher. Dadurch können mehr Modelle über längere Zeiträume gleichzeitig geladen werden, was zu niedrigeren Entfernungsraten führt.
  • Kleinere Modelle ermöglichen eine schnellere Datenaktualisierung, was zu einer geringeren Latenz bei der Berichterstattung, einem höheren Durchsatz bei der Aktualisierung des Semantikmodells und einer geringeren Belastung des Quellsystems und der Kapazitätsressourcen führt.
  • Eine geringere Anzahl von Tabellenzeilen kann zu einer schnelleren Auswertung der Berechnungen führen, wodurch eine Zunahme der Gesamtabfrageleistung möglich ist.

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.

In diesem Artikel werden acht Verfahren zur Reduktion von Daten behandelt. Diese Verfahren umfassen Folgendes:

Entfernen von unnötigen Spalten

Tabellenspalten in Modellen erfüllen zwei Hauptaufgaben:

  • Berichterstellung: Bei diesem Vorgang sollen Berichtsentwürfe entstehen, mit denen sich Modelldaten filtern, gruppieren und zusammenfassen lassen.
  • Modellstrukturierung: Bei diesem Vorgang werden Modellbeziehungen und -berechnungen, Sicherheitsrollen und sogar die Farbformatierung von Daten unterstützt.

Spalten, die diese Aufgaben nicht erfüllen, können vermutlich entfernt werden. Das Entfernen von Spalten wird auch als vertikales Filtern bezeichnet.

Sie sollten für Ihre Modelle eine Spaltenzahl festlegen, die sich aus den Anforderungen an die Berichterstellung ergibt. Ihre Anforderungen können sich im Laufe der Zeit ändern, aber bedenken Sie, dass es einfacher ist, später Spalten hinzuzufügen als sie zu entfernen. Wenn Spalten entfernt werden, kann das dazu führen, dass Berichte nicht mehr funktionieren oder die Modellstruktur Fehler aufweist.

Entfernen von unnötigen Zeilen

Modelltabellen sollten mit möglichst wenigen Zeilen geladen werden. Dazu können gefilterte Rowsets in Modelltabellen geladen und dann nach Entität oder Zeit gefiltert werden. Das Entfernen von Zeilen wird auch als horizontales Filtern bezeichnet.

Beim Filtern nach Entität wird eine Teilmenge der Quelldaten in das Modell geladen. Beispielsweise können so Verkaufsfakten nur für eine einzelne Region statt für alle Regionen geladen werden. Dieser Entwurfsansatz führt zu vielen kleineren Modellen und macht die Definition von Sicherheit auf Zeilenebene überflüssig (erfordert aber die Erteilung spezifischer Berechtigungen für semantische Modelle im Power BI-Dienst und die Erstellung „doppelter“ Berichte, die mit jedem Semantikmodell verbunden sind). Mithilfe von Power Query-Parametern und Power BI-Vorlagendateien können Sie die Verwaltung und Veröffentlichung von Berichten vereinfachen. Weitere Informationen finden Sie im Blogbeitrag Ausführliche Informationen zu Abfrageparametern und Power BI-Vorlagen

Beim Filtern nach Zeit wird die Menge der Verlaufsdaten begrenzt, die in Faktentabellen geladen wird. Außerdem wird die Zahl der Datumszeilen eingeschränkt, die in die Datumstabellen des Modells geladen werden. Wir empfehlen Ihnen, nicht automatisch den gesamten verfügbaren Verlauf zu laden, es sei denn, es handelt sich um eine bekannte Berichtsanforderung. Es ist hilfreich zu wissen, dass zeitbasierte Power Query-Filter parametrisiert und sogar so eingestellt werden können, dass sie relative Zeiträume verwenden (relativ zum Aktualisierungsdatum, zum Beispiel die letzten fünf Jahre). Denken Sie auch daran, dass nachträgliche Änderungen an den Zeitfiltern die Berichte nicht zerstören, sondern nur dazu führen, dass weniger (oder mehr) historische Daten in den Berichten verfügbar sind.

Gruppieren nach und Zusammenfassen

Das wohl effektivste Verfahren zur Verringerung der Modellgröße umfasst das Laden vorab zusammengefasster Daten. Bei dieser Methode kann die Granularität (Grain) der Faktentabellen erhöht werden. Es gibt jedoch einen deutlichen Kompromiss, der zu einem Verlust an Details führt.

Angenommen, in einer Faktentabelle mit Quelldaten zu Verkaufszahlen wird für jede Auftragsposition eine Zeile gespeichert. Wenn alle Verkaufsmetriken zusammengefasst und nach Datum, Kunde und Produkt gruppiert werden, könnte eine erhebliche Datenreduktion erzielt werden. Dieser Vorgang könnte sogar noch optimiert werden, wenn auf der Monatsebene nach Datum gefiltert wird. Dadurch kann die Modellgröße zwar um bis zu 99 % verringert werden, jedoch ist dann eine Berichterstellung auf Tagesebene oder auf der Ebene einer Auftragsposition nicht mehr möglich. Wenn Daten aus Faktentabellen zusammengefasst werden, hat dies immer auch Nachteile. Die Auswirkungen dieser Nachteile lassen sich mit einem gemischten Modell verringern. Diese Möglichkeit wird im Abschnitt Wechseln in den gemischten Modus beschrieben.

Optimieren von Spaltendatentypen

Die VertiPaq-Speicher-Engine verwendet für jede Spalte eigene Datenstrukturen. Diese sind entwurfsbedingt für numerische Spaltendaten optimiert, für die eine Wertcodierung verwendet wird. Für Text und andere nicht numerische Daten wird hingegen die Hashcodierung genutzt. Die Speicher-Engine muss daher jedem eindeutigen Textwert in der Spalte einen numerischen Bezeichner zuweisen, Der numerische Bezeichner wird dann in der Datenstruktur gespeichert und erfordert eine Hash-Suche bei der Speicherung und Abfrage.

In bestimmten Fällen können Sie Quelltextdaten in numerische Werte konvertieren. Zum Beispiel kann einer Kundenauftragsnummer durchgängig ein Textwert vorangestellt werden (zum Beispiel „SO123456“). Dieses Präfix könnte dann entfernt und der Wert der Auftragsnummer in eine ganze Zahl konvertiert werden. Bei großen Tabellen kann dies vor allem dann zu einer erheblichen Datenreduktion führen, wenn die Spalten eindeutige Werte oder Werte mit hoher Kardinalität enthalten.

In diesem Beispiel wird empfohlen, die Spalteneigenschaft „Default Summarization“ (Standardzusammenfassung) auf „Nicht zusammenfassen“ festzulegen. Sie hilft dabei, die unangemessene Verdichtung der Bestellnummernwerte zu minimieren.

Verwenden von benutzerdefinierten Spalten

Die VertiPaq-Speicher-Engine speichert (in DAX definierte) berechnete Modellspalten ebenso wie reguläre Power Query-Quellspalten. Die Datenstrukturen werden jedoch etwas anders gespeichert. Außerdem ist deren Komprimierung in der Regel weniger effizient. Außerdem werden sie erstellt, sobald alle Power Query-Tabellen geladen sind, was zu längeren Datenaktualisierungszeiten führen kann. Tabellenspalten, die als berechnete Spalten hinzugefügt werden, sind daher weniger effizient als (in M definierte) berechnete Power Query-Spalten.

Aus diesem Grund sollten vorzugsweise benutzerdefinierte Spalten in Power Query erstellt werden. Wenn es sich bei der Quelle um eine Datenbank handelt, können Sie die Ladeeffizienz auf zwei Arten optimieren. Die Berechnung kann in der SQL-Anweisung (mithilfe der nativen Abfragesprache des Anbieters) definiert werden oder als Spalte in der Datenquelle materialisiert werden.

Gelegentlich sind jedoch berechnete Modellspalten möglicherweise die bessere Wahl. Dies kann der Fall sein, wenn durch die Formel Measures ausgewertet werden oder für die Formel bestimmte Modellierungsfunktionen erforderlich sind, die nur in DAX-Funktionen unterstützt werden. Informationen zu einem solchen Beispiel finden Sie im Artikel Grundlegendes zu Funktionen für Hierarchien aus über- und untergeordneten Elementen in DAX.

Deaktivieren des Ladevorgangs für Power Query-Abfragen

Power Query-Abfragen, welche die Datenintegration mit anderen Abfragen unterstützen sollen, sollten nicht in das Modell geladen werden. Deaktivieren Sie daher in diesen Fällen den Ladevorgang für Abfragen.

Screenshot von Power Query mit der Option „Laden aktivieren“

Datum/Uhrzeit automatisch deaktivieren

Power BI Desktop enthält eine Option mit dem Namen Datum/Uhrzeit automatisch. Wenn diese Option aktiviert ist, wird eine verborgene automatische Datums-/Uhrzeittabelle für Datumsspalten erstellt, um Berichtsautoren beim Konfigurieren von Filtern, Gruppieren und bei Drilldownaktionen für Kalenderzeiträume zu unterstützen. Die verborgenen Tabellen sind tatsächlich berechnete Tabellen, die die Größe des Modells anwachsen lassen. Anleitungen zum Verwenden dieser Option finden Sie im Artikel Auto date/time guidance in Power BI Desktop (Anleitungen zum automatischen Datum/der automatischen Uhrzeit in Power BI Desktop).

Wechseln in den gemischten Modus

In Power BI Desktop wird im gemischten Modus ein zusammengesetztes Modell erzeugt. Damit können Sie den Speichermodus für jede Tabelle festlegen. Für jede Tabelle kann daher die Eigenschaft „Speichermodus“ auf „Importieren“, „DirectQuery“ oder „Dual“ festgelegt werden.

Ein wirksames Verfahren zum Verringern der Modellgröße besteht darin, die Eigenschaft „Speichermodus“ für größere Faktentabellen auf „DirectQuery“ festzulegen. Dieser Entwurfsansatz kann in einigen Fällen gut mit der Strategie kombiniert werden, die im Verfahren Gruppieren nach und Zusammenfassen weiter oben beschrieben wurde. So könnten z. B. zusammengefasste Verkaufsdaten verwendet werden, um Zusammenfassungsberichte effizient zu erstellen. Auf einer Drillthroughseite könnten außerdem Verkäufe für einen bestimmten (eingegrenzten) Filterkontext detailgenau aufgeführt werden, in dem alle zugehörigen Auftragspositionen angezeigt werden. In diesem Beispiel würde die Drillthroughseite Visuals enthalten, die auf einer DirectQuery-Tabelle basieren, mit der die Auftragsdaten abgerufen werden.

Wenn Sie zusammengesetzte Modelle verwenden, müssen Sie jedoch auch zahlreiche Auswirkungen auf die Sicherheit und Leistung berücksichtigen. Weitere Informationen finden Sie im Artikel Verwenden zusammengesetzter Modelle in Power BI Desktop.

Zugehöriger Inhalt

Weitere Informationen zum Entwerfen von Power BI-Importmodellen finden Sie in den folgenden Artikeln: