Measure-Magie ohne Bremsspuren: Wie Vertical & Horizontal Fusion deine Power-BI-Kennzahlen turboschnell machen
Einleitung
Du klickst im Power-BI-Report auf ein Filter-Slicer, wartest … und wartest. Das Meeting läuft, alle Augen sind auf den Bildschirm gerichtet. Sekunden fühlen sich wie Minuten an. Später im Debug-Modus siehst du vier Storage-Engine-Queries (SE Queries) und eine Formel-Engine-Zeit (FE Time) von 350 ms – für eine scheinbar banale Umsatz-Kennzahl. Warum passiert das – und wie verhindert man es?
In diesem Artikel tauchen wir tief in die DAX-Engine, reisen von den Anfängen des xVelocity-Speichers bis zu den heutigen Optimierern „Vertical“ und „Horizontal Fusion“ – und zeigen praxisnah, wann Measure-Branching gratis ist und wann es dich Performance kostet.
TL;DR
- Measure-Branching ist meist kostenneutral: Ab „Vertical Fusion“ (VertiPaq V2, 2016) fasst die Engine Aggregationen mit identischem Filter-Set zu einer SE-Abfrage zusammen.
- Teuer wird es, wenn untergeordnete Measures unterschiedliche Filter oder Iterator-Kontexte haben – dann entstehen mehrere SE Queries und viel FE-CPU.
- Horizontal Fusion (ab 2022) kombiniert auch unterschiedliche Filter an derselben Spalte in eine einzige Sammelabfrage.
- Messen statt Rätseln: DAX Studio › Server Timings zeigt FE Time, SE Queries und den generierten xmSQL.
Begriffsdefinitionen
| Begriff | Erklärung | Quelle |
|---|---|---|
| Server Timings | Trace-Modus in DAX Studio; listet jede SE-Query, FE-Time, SE-Time, Cache-Treffer u. v. m. | (daxstudio.org) |
| SE Queries | Anzahl der Aufrufe, die die Formula Engine an die Storage Engine (VertiPaq / DirectQuery) sendet. Weniger Queries = weniger Round-Trips. | (blog.enterprisedna.co) |
| FE Time | Reine CPU-Zeit der Formula Engine, errechnet aus Total-Time – SE-Time. Die FE läuft single-threaded – hohe Werte sind bottlenecks. | (daxstudio.org) |
| Inlining / Measure-Expansion | Während des Parsens ersetzt die FE jeden Measure-Aufruf durch seinen vollständigen DAX-Text; Ergebnis ist ein einziger Operator-Baum. | (sqlbi.com) |
| Measure-Branching | Technik, bei der ein Basis-Measure in weitere abgeleitete Measures gekapselt wird (z. B. [Sales] → [Sales YTD] → [Sales YTD Audio]). | |
| xmSQL | Internes, lesbares SQL-ähnliches Dialekt, das die FE an VertiPaq schickt. Immer gruppierend, nie direkt ausführbar. | (docs.sqlbi.com) |
Geschichte der Optimizer-Generationen
| Ära | Spitzname | Haupt-Feature | Wann? | Quelle |
|---|---|---|---|---|
| VertiPaq V1 | xVelocity | Komprimierte In-Memory-Spalten, aber keine Fusion → jede Measure-Ebene war eine eigene SE-Query. | Power Pivot 2010 / SSAS Tabular 2012 | |
| Vertical Fusion | V2 Optimizer | Erkennt Aggregationen mit identischem Filter-Set und fusioniert sie in eine SE-Abfrage. | SQL Server 2016 / Power BI Desktop 2017 | (docs.sqlbi.com) |
| Horizontal Fusion | oft einfach Fusion | Kombiniert unterschiedliche Filter derselben Spalte zu einer Sammel-Query – reduziert SE Queries bei „Audio vs. Video“ u. Ä. | Preview 2021, GA Nov 2022 | (sqlbi.com, powerbi.microsoft.com) |
Wie kann man die Performance eines Measures ermitteln?
DAX Studio > Server Timings
