{"id":59840,"date":"2024-12-03T08:22:37","date_gmt":"2024-12-03T07:22:37","guid":{"rendered":"https:\/\/www.cubeserv.com\/?p=59840"},"modified":"2024-12-03T09:10:02","modified_gmt":"2024-12-03T08:10:02","slug":"datenablage-in-powerbi","status":"publish","type":"post","link":"https:\/\/www.cubeserv.com\/de\/datenablage-in-powerbi\/","title":{"rendered":"Optimale Datenablage f\u00fcr Microsoft Power BI \u2013 Auswertungen"},"content":{"rendered":"\t\t
In diesem Beitrag wird untersucht, wie strukturierte Daten optimal abgelegt werden sollten, um effizient mit Mircosoft Power BI visualisiert werden zu k\u00f6nnen.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t Die Daten sind in einer lokalen Oracle-Datenbank gespeichert und via einer View abrufbar.<\/p> Um die Datenmenge in der View zu skalieren, ist der View eine Tabelle hinzugef\u00fcgt, welche bei der Abfrage ein kartesisches Produkt bildet. Damit ist es m\u00f6glich, die Datenmenge auf einfache Weise zu variieren.<\/p> Es sollen in der Versuchsanlage einmal rund 100\u2018000 Datens\u00e4tze und einmal rund 10 Mio. Datens\u00e4tze ausgewertet werden.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t Untersucht werden folgende Varianten<\/p> Die Auswertungen zu Varianten V1+V2 werden \u00fcber den Power BI-Client erstellt und dann ver\u00f6ffentlicht.<\/span><\/p> Bei den Varianten V3+V4 wird erst jeweils ein DataFlow f\u00fcr die Aktualisierung der Daten in MS Data Fabric erstellt und darauf die Auswertung mit Power BI erstellt.<\/span><\/p> Bei allen Auswertungsvarianten erstellt Power BI jeweils ein semantisches Model.\u00a0<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Das Modell von V1 h\u00e4lt die Daten im Modell und muss eingeplant werden, um die Daten zu aktualisieren. Bei dieser Aktualisierung kann in Modellen, bei welchen garantiert ist, dass ein bestimmter Teil der Daten sich nicht mehr ver\u00e4ndert, eine inkrementelle Aktualisierung definiert werden, was den Aktualisierungsvorgang beschleunigen kann. Auf eine inkrementelle Aktualisierung wird bei dieser Untersuchung nicht weiter eingegangen, da alle Daten der Tabelle \u00fcber die Zeit ver\u00e4nderbar sind.<\/p> Das Modell V2 h\u00e4lt keine Daten im Modell. Bei der Aktualisierung wird lediglich die Struktur und die Definitionen im semantischen Modell aktualisiert. Daher ist der Zeitaufwand f\u00fcr eine Aktualisierung sehr klein.<\/p> Die Modelle V3+V4 halten ebenfalls Daten im Modell. Diese semantischen Modelle k\u00f6nnen eingeplant oder bei Aktualisierung des zugrundeliegenden Datentabellen im Lakehouses\/Warehouses automatisch nachgef\u00fchrt werden.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Bei den Modellen V3+V4 kommt zu diesen Zeiten noch die Beladung des Lakehouse\/Warehouse hinzu. Diese Beladung wird jeweils initial \u00fcber einen Dataflow Gen2 beladen und f\u00fcr die Aktualisierung der Daten jeweils \u00fcber eine Data Pipeline nachgef\u00fchrt.<\/p> Bei der initialen Beladung werden die Daten aus der Quelle \u00fcberschreibend in die jeweilige Zieltabelle geschrieben.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Bei der Aktualisierung der Daten werden alle Daten der Quelle, welche einen neueren Zeitstempel als der maximale Zeitstempel im Ziel haben, in eine tempor\u00e4re Tabelle geladen und dann die Daten im Ziel mit denjenigen Daten aus der tempor\u00e4ren Tabelle aktualisiert.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Hierbei werden die hierzu ben\u00f6tigten Notebooks bei der Lakehouse-Beladung mit Spark SQL, bei der Warehouse-Beladung mit T-SQL umgesetzt<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Wir sehen, dass der Overhead bei der Differenz-Beladung betr\u00e4chtlich ist. Wurde seit dem letzten Load keine Daten ver\u00e4ndert, so dauert der Abgleich, notabene von 0 Daten, nur unwesentlich k\u00fcrzer als ein Update von 25000 Datens\u00e4tze bei 10 Mio. Datens\u00e4tzen insgesamt.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t Alle Berichte V1-V4 sind mit den identischen Berichtselementen best\u00fcckt.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Es wird jeweils die Summe der Area eines Dimensionswertes in einem Kreisdiagramm ausgegeben. Dabei kann nach einer anderen Dimension \u00fcber den ganzen Bericht gefiltert werden.<\/p> Mess-Kriterium hierbei ist der Zeitbedarf, bis der Bericht nach der h\u00f6chsten Filterauspr\u00e4gung (WSJ-790) gefiltert werden kann.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Wir sehen, dass bei 100000 Datens\u00e4tzen bei allen Reports das Mess-Kriterium identisch ist. Bei 10 Mio. Datens\u00e4tzen wird aber bei Direkt Query V2 wesentlich mehr Zeit bis zur freien Navigation im Report ben\u00f6tigt.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t Berechnen wir nun die Gesamt-Zeit, welche ben\u00f6tigt wird, um Daten (bei 250000 zu aktualisierende Datens\u00e4tze) in diesem Bericht zu visualisieren, so kommen wir zu folgender Auflistung:<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Wir sehen, dass bei kleinen Datenmengen von 100’000 Datens\u00e4tzen, Import V1 und Direkt Query V2 das optimale Ergebnis liefern. Sollen jedoch gr\u00f6ssere Datenmengen in der Gr\u00f6\u00dfenordnung von 10 Mio. Datens\u00e4tzen im Report aktualisiert werden, so w\u00fcrde vermeintlich Direkt Query V2 das Rennen machen. Dies stimmt so aber nicht ganz, da, wenn der Endbenutzer den Report \u00f6ffnet und Filtern will, muss dieser hier am l\u00e4ngsten warten. Mit dieser Wartezeit ist bei jedem Aufruf zu rechnen, was bei den Endbenutzern nicht hinzunehmen sein wird.<\/p> Daher ist hier auf eine der Varianten V1, V2 oder V3 auszuweichen. Nur diese Varianten werden von den Endbenutzern akzeptiert.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t Bei kleineren zu visualisierenden Datenmengen bietet sich im Umfeld von Power BI sicher die Varianten mit Direkt Query V2 oder Import der Daten V1 an. Sollen jedoch grosse Datenmengen ausgewertet werden, so ist V2 nicht geeignet, h\u00e4ngt aber sonst etwas von den Vorlieben und Erfahrungen des Entwicklers ab.<\/p> Einige \u00dcberlegungen hierzu:<\/p> Beim Import V1 werden bei jeder Aktualisierung alle Daten aus der semantischen Schicht gel\u00f6scht und neu importiert.<\/p> Bei der Variante V3 Lakehouse werden strukturierte Daten in ein Schema gepresst, welches auch f\u00fcr unstrukturierte Daten vorgesehen ist.<\/p> Die Variante V4 Warehouse ist nach meiner Einsch\u00e4tzung, auch nach meinen Vorlieben der optimale Ablageort der Daten. Zum einen wird ein System verwendet, welches f\u00fcr die vorliegenden strukturierten Daten vorgesehen ist, zum anderen werden nur Daten im Warehouse manipuliert, welche im Source-System auch ver\u00e4ndert wurden.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\tVersuchsanlage<\/h1><\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Zugriff auf die Datenquelle<\/h1><\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Zeitbedarf f\u00fcr die Aktualisierung des semantischen Layers bei manueller Aktualisierung<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Dauer der Initial-Beladung <\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Dauer der Differenz-Beladung<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Aktualisierung Bericht<\/h1><\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Gesamt-Ergebnis<\/h1><\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Fazit<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\tVereinbaren Sie jetzt Ihren<\/span>\n\t\t\t\t\n\t\t\t\t\tExpert Call.<\/span>\n\t\t\t\t<\/span>\n\t\t\t\t\tWir freuen uns \u00fcber Ihre Nachricht.<\/span>\n\t\t\t\t\t<\/h3>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
Silvio Ackermann<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Data Warehouse design, ETL creation and Advanced Analytics on Expert level with interests on technologies and challenges<\/h5>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t\t