Freigeben über

Verfahren zur Datenreduktion für die Importmodellierung

Dieser Artikel zielt auf Power BI Desktop-Datenmodellierer ab, die Power BI-Semantikmodelle entwickeln und veröffentlichen. Insbesondere werden verschiedene Techniken beschrieben, mit denen die in Importmodelle geladenen Daten reduziert werden können.

Importmodelle werden mit Daten geladen, die komprimiert und optimiert sind, und dann vom VertiPaq-Speichermodul auf dem Datenträger gespeichert. Wenn Quelldaten in den Arbeitsspeicher geladen werden, ist es möglich, eine 10x-Komprimierung zu erzielen. Daher ist es sinnvoll, zu erwarten, dass 10 GB Quelldaten in etwa 1 GB komprimieren können. Darüber hinaus kann eine zusätzliche Reduzierung von 20 % erreicht werden, wenn die Daten auf der Festplatte gespeichert werden.

Trotz der Effizienz, die vom VertiPaq-Speichermodul erreicht wird, sollten Sie versuchen, die Daten zu minimieren, die in Ihre Modelle geladen werden. Das gilt insbesondere für große Modelle oder Modelle, von denen Sie erwarten, dass sie in Zukunft an Größe zunehmen. Vier Gründe sprechen für eine Reduktion der Daten:

  • Größere Modellgrößen werden möglicherweise von Ihrer Kapazität 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 unter "Große Semantikmodelle" in Power BI Premium.
  • Kleinere Modelle führen zu weniger Konflikten bei Kapazitätsressourcen. Dies gilt insbesondere für den Arbeitsspeicher. Viele kleinere Modelle in einer Kapazität können für längere Zeiträume gleichzeitig geladen werden, was zu niedrigeren Eviction-Raten führt.
  • Kleinere Modellgrößen erzielen eine schnellere Datenaktualisierung, was zu einer geringeren Latenzberichterstattung, einem höheren Aktualisierungsdurchsatz des Semantikmodells und weniger Druck auf Quellsystem- und Kapazitätsressourcen führt.
  • Kleinere Tabellenzeilenanzahlen können zu schnelleren Berechnungsauswertungen führen, was zu einer besseren Gesamtleistung von Abfragen führt.

Wichtig

Dieser Artikel bezieht sich auf Power BI Premium oder seine Kapazitätsabonnements (P-SKUs). Derzeit konsolidiert Microsoft Kaufoptionen und setzt die Power BI Premium-SKUs pro Kapazität zurück. 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.

Entfernen von unnötigen Spalten

Tabellenspalten in Modellen erfüllen zwei Hauptaufgaben:

  • Berichterstellung, um Berichtsdesigns zu erzielen, die Modelldaten entsprechend filtern, gruppieren und zusammenfassen.
  • Modellstruktur, durch Unterstützung von Modellbeziehungen, Modellberechnungen, Sicherheitsrollen und sogar Datenfarbformatierung.

Sie können wahrscheinlich jede Spalte entfernen, die keiner dieser Zwecke dient. Das Entfernen einer Spalte aus einer Tabelle wird manchmal als vertikale Filterung bezeichnet.

Es wird empfohlen, Modelle mit genau der richtigen Anzahl von Spalten basierend auf Ihren bekannten Berichtsanforderungen zu entwerfen. Ihre Anforderungen können sich im Laufe der Zeit ändern, bedenken Sie jedoch, dass es einfacher ist, später Spalten hinzuzufügen, als sie später zu entfernen sind. Wenn Spalten entfernt werden, kann das dazu führen, dass Berichte nicht mehr funktionieren oder die Modellstruktur Fehler aufweist.

Entfernen von unnötigen Zeilen

Sie sollten Modelltabellen mit so wenigen Zeilen wie möglich laden. Sie können dies erreichen, indem Sie gefilterte Rowsets aus zwei verschiedenen Gründen in Modelltabellen laden: nach Zeit oder nach Entität zu filtern. Das Entfernen von Zeilen wird manchmal als horizontale Filterung bezeichnet.

  • Das Filtern nach Zeit umfasst das Einschränken der Datenhistorie , die in Faktentabellen geladen wurde (und das Einschränken der Datumszeilen, die in die Modelldatumstabellen geladen wurden). Es wird empfohlen, den gesamten verfügbaren Verlauf standardmäßig nicht zu laden, es sei denn, es handelt sich um eine bekannte Berichtsanforderung. Sie können zeitbasierte Power Query-Filter mit Parametern implementieren und sogar festlegen, dass relative Zeiträume verwendet werden (relativ zum Aktualisierungsdatum, z. B. die letzten fünf Jahre). Denken Sie auch daran, dass eine retrospektive Änderung der Zeitfilter keine Berichte unterbricht; es führt nur zu weniger (oder mehr) Datenverlauf, der in Berichten verfügbar ist.
  • 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 kann auch die Notwendigkeit der Definition der Sicherheit auf Zeilenebene (RLS) vermeiden, erfordert jedoch die Gewährung bestimmter Semantikmodellberechtigungen im Power BI-Dienst und das Erstellen doppelter Berichte, die mit jedem semantischen Modell verbunden sind. Sie können Power Query-Parameter und Power BI-Vorlagendateien verwenden, um die Verwaltung und Publikation zu vereinfachen. Weitere Informationen finden Sie unter Erstellen und Verwenden von Berichtsvorlagen in Power BI Desktop.

Gruppieren nach und Zusammenfassen

Das wohl effektivste Verfahren zur Verringerung der Modellgröße umfasst das Laden vorab zusammengefasster Daten. Sie können diese Technik verwenden, um den Detailgrad von Faktentabellen zu erhöhen. Es gibt jedoch einen deutlichen Kompromiss, der zu einem Verlust an Details führt.

Sehen Sie sich ein Beispiel an, in dem eine Verkaufs-Faktentabelle aus der Quelle eine einzige Zeile pro Auftragsposition speichert. Eine signifikante Datenreduzierung kann erreicht werden, indem alle Vertriebsmetriken zusammengefasst, nach Datum, Kunde und Produkt gruppiert werden. Eine noch signifikantere Datenreduzierung kann durch Gruppieren nach Datum auf Monatsebene erreicht werden. Obwohl es eine mögliche Reduzierung der Modellgröße um 99% erreichen könnte, ist die Berichterstattung auf Tages- oder Einzelauftragszeilenebene nicht mehr möglich. Die Entscheidung, Faktendaten zusammenzufassen, beinhaltet immer Kompromisse. Der Kompromiss könnte durch ein Modelldesign verringert werden, das einige Tabellen im DirectQuery-Speichermodus enthält, die weiter unten in diesem Artikel beschrieben wird.

Optimieren von Spaltendatentypen

Das VertiPaq-Speichermodul verwendet separate interne Datenstrukturen für jede Spalte. Im Entwurf erzielen diese Datenstrukturen die höchsten Optimierungen für numerische Spaltendaten, die die Wertcodierung verwenden. Text und andere nicht numerische Daten verwenden jedoch Hashcodierung. Für die Hashcodierung muss das Speichermodul jedem eindeutigen Wert, der in der Spalte enthalten ist, einen numerischen Bezeichner zuweisen. Es ist der numerische Bezeichner, der dann in der Datenstruktur gespeichert ist und während des Speichers und der Abfrage eine Hash-Suche erfordert.

In bestimmten Fällen können Sie Quelltextdaten in numerische Werte konvertieren. Eine Verkaufsauftragsnummer kann z. B. konsistent mit einem Textwert vorangestellt werden (z. B. SO123456). In diesem Fall kann das Präfix SO entfernt werden, und der Bestellnummernwert wird in eine ganze Zahl konvertiert. Bei großen Tabellen kann diese Änderung zu einer erheblichen Datenreduzierung führen, insbesondere, wenn die Spalte eindeutige oder hohe Kardinalitätswerte enthält.

In diesem Beispiel empfehlen wir, die Zusammenfassungseigenschaft der Spalte standardmäßig auf Do Not Summarize festzulegen. Es hilft, unangemessene Zusammenfassungen der Bestellnummernwerte zu vermeiden.

Verwenden von benutzerdefinierten Spalten

Das VertiPaq-Speichermodul speichert modellbasierte berechnete Spalten (definiert in DAX) genau wie normale Power Query-Quellspalten. Die internen Datenstrukturen werden jedoch etwas anders gespeichert und erzielen in der Regel weniger effiziente Komprimierung. Außerdem werden die Datenstrukturen erstellt, nachdem alle Power Query-Tabellen geladen wurden, was zu erweiterten Datenaktualisierungszeiten führen kann. Tabellenspalten, die als berechnete Spalten hinzugefügt werden, sind daher weniger effizient als (in M definierte) berechnete Power Query-Spalten.

Wann immer möglich, sollten Sie bevorzugen, benutzerdefinierte Spalten in Power Query zu erstellen. Wenn es sich bei der Quelle um eine Datenbank handelt, können Sie auf zwei Arten eine höhere Auslastungseffizienz erzielen: Die Berechnung kann in der SQL-Anweisung definiert werden (mithilfe der systemeigenen Abfragesprache des Anbieters), oder sie kann als Spalte in der Datenquelle materialisiert werden.

In einigen Fällen könnten modellberechnete Spalten jedoch die bessere Wahl sein. Das ist der Fall, wenn die Formel die Auswertung von Measures umfasst oder bestimmte Modellierungsfunktionen erfordert, die nur in DAX-Funktionen unterstützt werden. Informationen zu einem solchen Beispiel finden Sie unter Verständnis von Funktionen für Eltern-Kind-Hierarchien in DAX.

Deaktivieren des Ladevorgangs für Power Query-Abfragen

Power Query-Abfragen, die die Datenintegration in andere Abfragen unterstützen sollen, sollten nicht in das Modell geladen werden. Um das Laden dieser Abfragen in das Modell zu vermeiden, stellen Sie sicher, dass Sie das Laden der Abfrage in diesen Instanzen deaktivieren.

Screenshot von Power Query mit der Option

Datum/Uhrzeit automatisch deaktivieren

Power BI Desktop enthält eine Option mit dem Namen Datum/Uhrzeit automatisch. Wenn diese Option aktiviert ist, werden ausgeblendete automatische Datums-/Uhrzeittabellen für jede Datumsspalte im Modell erstellt. Diese Option unterstützt Berichtsautoren beim Konfigurieren von Filtern, Gruppieren und Drilldownaktionen für Kalenderzeiträume. Die ausgeblendeten Tabellen sind tatsächlich berechnete Tabellen, die die Größe des Modells erhöhen.

Weitere Informationen finden Sie in Power BI Desktop unter dem Leitfaden für automatische Datums- und Uhrzeiteinstellungen.

Verwenden des DirectQuery-Speichermodus

Der DirectQuery-Speichermodus ist eine Alternative zum Importspeichermodus. DirectQuery-Modelltabellen importieren keine Daten. Stattdessen bestehen sie nur aus Metadaten, die die Tabellenstruktur definieren. Wenn die Tabelle abgefragt wird, werden systemeigene Abfragen verwendet, um Daten aus der zugrunde liegenden Datenquelle abzurufen. Wenn Sie Tabellen im Import- und DirectQuery-Speichermodus in einem einzigen Modell kombinieren, wird es als Zusammengesetztes Modell bezeichnet.

Eine effektive Methode zum Verringern der Modellgröße besteht darin, den Speichermodus für größere Faktentabellen auf DirectQuery festzulegen. Denken Sie daran, dass dieser Entwurfsansatz häufig gut mit der "Gruppieren und Zusammenfassen"-Technik funktioniert, die zuvor eingeführt wurde. So könnten beispielsweise zusammengefasste Umsatzdaten verwendet werden, um eine zusammenfassende Berichterstellung mit hoher Leistung zu erzielen. Auf einer Drillthrough-Seite können detaillierte Umsätze für spezifische und eingegrenzte Filterkontexte angezeigt werden, wobei alle Verkaufsaufträge im Kontext angezeigt werden. In diesem Beispiel kann die Drillthrough-Seite visuelle Elemente enthalten, die auf Basis einer DirectQuery-Modelltabelle erstellt werden, um die Verkaufsauftragsdaten abzurufen.

Es gibt jedoch viele Sicherheits- und Leistungsauswirkungen im Zusammenhang mit dem DirectQuery-Speichermodus und zusammengesetzten Modellen. Weitere Informationen finden Sie unter Verwenden von zusammengesetzten Modellen in Power BI Desktop.

Zugehöriger Inhalt

Weitere Informationen zu diesem Artikel finden Sie in den folgenden Artikeln: