Aggregations in Power BI Tom Martens & Gabi Münster Aggregations in Power BI

Eine kleine Demo zum Einstieg

Videos (kleine Live Demo zum Schluss? Falls Zeit genug ist…) Christian Wade Video Alberto Ferrari Video Ich überlege, ob wir das beim Design ansprechen, denn das geht ja deutlich mehr in unsere Richtung und hat nicht so den “WOW-Effekt”

Warum überhaupt Aggregations?

Performance!

Und vor allem… Warum bzw. Wann nicht Import auf Import Weak Relationships Security DAX Einschränkungen Leaf Level aggregations …?

Der Design-Prozess

Rückblende: SSAS Multidimensional Komplett gekoppelt an SSAS Technologie Aggregations wurden als zusätzliche Dateien innerhalb der SSAS Datenbankstruktur abgelegt Anpassungsbedarf bei Dimensionsänderungen Immer MOLAP Konnte nur von SSAS genutzt warden Designoptionen Usage Based Optimization Aggregation Wizard Manuelles Anlegen eines Aggregation Designs

Gegenwart: Power BI Freie Technologiewahl Aggregations können in diversen Technologien abgelegt werden Können auch anderen Applikationen zur Verfügung gestellt werden Können DirectQuery oder Import sein Eigenverantwortliches Design: Was muss ich berücksichtigen? Design der Aggregation Table Basierend auf Abschätzung oder Query Analyse Auswahl der Technologie Richtige Anbindung im Modell Z.B. Auswahl des Storage Modes Design der Synchronisierung

Design der Aggregation Table Wie identifizieren wir, was wir aggregieren wollen? Was davon können wir aggregieren? S. Erklärungen vorher

Auswahl der Technologie s. Architektur

Richtige Anbindung im Modell Korrekte Zuordnung der Measures Pflegen der Beziehungen Auswahl des richtigen Storage Modes der Dimensionen (Nur bei Agg im Import Mode) Tests mit DAX Studio

Design der Synchronisierung “Einfacher” bei Direct Query Agg Table Bei Import Agg Table maximaler Synch-Zyklus alle 30 Minuten Wie gewährleisten wir, dass in der Zwischenzeit keine aktuelleren Daten in der Faktentabelle zur Verfügung stehen? Z.B. mit Timestamp Filter in den Direct Query Abfragen

Architektur

Grundsätzliche Überlegungen Detailtabelle -> DirectQuery Aggregationstabelle -> DirectQuery oder Import Gemeinsam genutzte Dimensionstabellen DirectQuery, falls beide Faktentabellen DirectQuery sind Dual, falls Mixed Mode genutzt wird

DirectQuery Datenquellen Amazon Redshift Azure SQL Database/Azure SQL Data Warehouse/SQL Server IBM DB2 database Oracle Database (version 12 and above) SAP Business Warehouse Application Server SAP HANA Snowflake Spark (Beta) (version 0.9 and above) Teradata Database … https://docs.microsoft.com/de-de/power-bi/desktop-directquery-data-sources

Data Bricks total

Azure SQL DWH Warum? Warum nicht? “Gewohnte” DWH Modellierung Zugriff über T-SQL für viele User bekannt Polybase erlaubt Einsatz als Virtualisierungsschicht Kontinuierliche Performance- und Security-Verbesserungen Build conference: Power BI Meets Azure SQL Data Warehouse: Amplifying your data stack with petabyte-scale analytics https://azure.microsoft.com/en-ca/blog/azure-sql-data-warehouse-releases-new-capabilities-for-performance-and-security/ Warum nicht? Kosten Compute: ~ €325 – 280k/Monat Entfällt während “Pause” Zeiten Storage: ~ €125/1 TB/Monat Fällt immer an Disaster Recovery: ~ €0,1/GB/Monat

Azure SQL DWH – Die Detailtabelle Option 1: Daten liegen außerhalb, Zugriff über Polybase Pros “Real-Time” Wenig Speicherbedarf Cons Performance Option 2: Daten werden persistiert Speicherbedarf Synchronisierungsprozess notwendig

Azure SQL DWH – Die Aggregationstabelle View Pros Gleiche Datengrundlage Keine zusätzlichen Ladeprozesse Speicherbedarf Cons Performance Materialisierte View Optimizer “schreibt Userabfragen um” - Persistierte Tabelle Pros Abfrage-Performance Cons Speicherbedarf Ladeprozesse notwendig Synchronisierung mit Detailtabelle notwendig Power BI Import Modus Abfage-Performance Incremental Refresh

SQL Server total

Big Data Clusters?

Demo