vorheriger Artikel
Du willst einen Power-BI-Bericht bauen, aber die Datenmenge ist zu groß, um überhaupt erst mit dem Erstellen der Visuals beginnen zu können? Oder Du hast es sogar geschafft, einen Bericht auf diesen Daten aufzusetzen, aber Power BI Desktop hängt sich ständig auf? Der Bericht braucht ewig, bis er veröffentlicht ist? Damit bist Du nicht allein. Im Folgenden zeigen wir Dir deshalb ein paar einfach zu realisierende Tipps.
Tipp 1: Separate pbix-Datei als Dataset
Ist die Datenmenge so groß, dass ein Upload der Desktopdatei zum Power BI Service sehr lange dauert, empfiehlt es sich, das Dataset von der Berichtsdatei zu trennen. Das bedeutet, man entwickelt die Datenanbindung wie gewohnt in einer pbix-Datei, aber erstellt in dieser keine Berichtsseite. Diese ist dann das „Dataset“. Es wird in den Service in einem Arbeitsbereich veröffentlicht, sodass beliebig viele weitere Berichte (diesmal nur mit Berichtsseiten) darauf aufsetzen können.
Die Trennung der Entwicklung von Berichtsseiten von der des Datasets hat den Vorteil, dass
- das Dataset und die Berichte gleichzeitig bearbeitet werden können,
- die Berichtsdatei kleiner und stabiler wird,
- das Hochladen der Berichtsdatei nicht mehr so lange dauert
- und mehrere Berichtsdateien auf dasselbe Dataset aufsetzen können, was beim Erstellen einer Power BI App zur Gliederung hilfreich sein kann.
Zur weiteren Erklärung sei hier das folgende einfache Beispiel-Data-Warehouse verwendet. Es setzt auf einer SQL-Datenbank in Azure auf. Das kleinste Granulat der Fact_Orders-Tabelle sind die einzelnen Produkte.
Tipp 2: Nutzung aggregierter Tabellen und des Composite Models
Die Idee dahinter ist folgende: In den meisten Fällen ist es so, dass ein Großteil der Visuals gar nicht das kleinste Granular der Fakten (in unserem Beispiel Product) nutzt, sondern die Daten aggregiert (beispielsweise auf Customer und OrderDate). Es werden in diesen Fällen also gar nicht die detaillierten Daten auf Produktebene benötigt. Vielmehr würde eine Tabelle mit aggregierten Daten genügen. Entsprechend legt man eine solche Aggregationsfaktentabelle an, die oftmals deutlich kleiner ist und deshalb importiert werden kann.
Bleibt also das Problem mit Visuals und Filtern, die nun doch auf die Produktebene zurückgreifen (beispielsweise eine Auswertung der Umsätze nach Produkt). In diesem Fall ist eine Faktentabelle auf Produktebene unumgänglich. Für eine solche Detailfaktentabelle kann man aber ideal den Direct-Query-Modus einsetzen.
Im Folgenden eine kurze Anleitung zur praktischen Umsetzung. In unserem Beispiel werden wir die Dimension Produkt aggregieren und nach den restlichen Dimensionen gruppieren. Man legt zunächst alle Abfragen im Power Query Editor als Direct Query an. Anschließend referenziert man die Query für die Faktentabelle, benennt sie um (hier zu Fact_Orders_Agg) und gruppiert nach den zu behaltenden Dimensionen (s. Abbildung).
Mit der reduzierten Zeilenanzahl durch die Aggregation kannst Du nun die Tabelle in der Modellansicht auf Import umstellen. Außerdem wird sie mit den Dimensionstabellen verbunden.
Weil der Speichermodus der Faktentabellen jeweils Direct Query oder Import ist, muss der Speichermodus der Dimensionstabellen auf Dual festgelegt werden. Power BI erkennt somit automatisch, welcher Speichermodus für diese Tabellen optimal ist: Werden Daten aus der aggregierten Faktentabelle abgefragt, so werden die vorgehaltenen Daten der Dimensionstabellen genutzt. Werden in einem Visual beispielsweise jedoch Daten auf Produktebene abgefragt (also über die Fact_Orders-Tabelle), so werden auch die Daten aus der Dim_Product-Tabelle über Direct Query abgefragt.
Damit diese Logik funktioniert, muss Power BI allerdings wissen, welche die Aggregationstabelle und welche die Detailtabelle ist.
Wie in der Meldung bereits zu sehen ist, wird die aggregierte Tabelle automatisch ausgeblendet. Das bedeutet, man baut sämtliche Visuals scheinbar auf der Detailtabelle (Fact_Orders) auf, wobei Power BI dann die Daten entsprechend oben genannter Logik abruft. Hier ein Beispiel:
Die obere Grafik beinhaltet nur Daten aus der aggregierten Tabelle und bezieht somit die vorgehaltenen Daten aus Power BI. Die untere beinhaltet das Feld Color, das aus der Dim_Product-Tabelle stammt. Daher werden diese Daten über Direct Query abgefragt.
Tipp 3: Parameter zur Datenbegrenzung
Nun kann es sein, dass selbst die aggregierte Tabelle noch relativ groß ist und das Importieren sehr viel Zeit in Anspruch nimmt. Außerdem erhöht sich dadurch die Dateigröße, was den Arbeitsspeicher füllt und die Veröffentlichung zu einem langwierigen Prozess machen kann. Daher empfehle ich Dir folgenden Trick: Leg einen Parameter an, der bereits in der Query die Anzahl der Zeilen beschränkt. Das lässt sich mit einer einfachen if-Bedingung im erweiterten Editor realisieren. Möchtest Du homogenere Daten zum Bauen von Visuals erhalten, so kannst Du statt der einfachen Zeilenbeschränkung einen Filter auf eine Kalenderwoche oder einzelne Tage einbauen.
Veröffentlichst Du dann die Datei, so kannst Du in den Einstellungen des Datasets im Power BI Service den Parameterwert auf 0 setzen. Somit werden im Service alle Daten geladen, während Du in der Desktopversion zum Entwickeln nur eine Teilmenge handhaben musst.
Oft treten bei großen Datenmengen gleichzeitig Probleme in der Performance auf. Die beschriebenen Tipps sind keine abschließende Betrachtung. Vielmehr gibt es eine Vielzahl weiterer Optimierungsmöglichkeiten. Informationen hierzu sind leicht im Internet oder direkt in der entsprechenden Microsoft-Dokumentation zu finden.
