Power BI Composite Models: flexible Modelle ohne Entweder-oder

Definition

Power BI Composite Models sind semantische Modelle, in denen Tabellen mit unterschiedlichen Storage Modes gemeinsam genutzt werden, z. B. Import, DirectQuery und Dual sowie Direct Lake.

Sie sind keine reine „Live Connection ohne Modellierung“, sondern ermöglichen gezielte Erweiterungen und Mischarchitekturen innerhalb eines Models.

Einleitung

Wenn du heute ein Reporting aufbaust, willst du zwei Dinge gleichzeitig: schnelle Interaktion (keine Ladepausen) und Daten, die nah an der Realität sind. Genau hier kommen Power BI Composite Models ins Spiel: Du kombinierst den jeweils passenden Modus pro Tabelle, statt dich für ein Extrem zu entscheiden. Das senkt manuellen Aufwand (weniger Excel-Schattenwelten), verbessert Vertrauen in KPIs und macht Rollouts planbarer.

DirectQuery, Import und Direct Lake: was passt wofür?

In Power BI entscheidet der Storage Mode darüber, wo Daten liegen und wie Abfragen laufen. Für Composite Models ist das die zentrale Weiche.

• Import Mode: Daten landen im VertiPaq-In-Memory-Engine. Sehr schnell, ideal für Standard-KPIs und stark genutzte Berichte.
• DirectQuery: Abfragen laufen zur Quelle (z. B. SQL). Gut für sehr große Datenmengen oder wenn Aktualität wichtiger als maximale Performance ist.
• Direct Lake: Abfragen greifen direkt auf OneLake/Lakehouse-Dateien zu. Ziel ist eine „Lakehouse-first“-Nutzung, ohne klassischen Import-Refresh, und mit breiter Nutzbarkeit der Gold-Daten.

Warum Composite Models in der Praxis so wertvoll sind

Composite bedeutet: du legst nicht alles auf „schnell“ oder alles auf „aktuell“, sondern baust ein Modell, das beides in den richtigen Teilen kann. Typische Vorteile:

• Weniger Doppelarbeit: zentrale KPIs bleiben zentral, Fachbereiche ergänzen nur, was wirklich fehlt.
• Bessere Nutzererfahrung: häufig genutzte Sichten laufen schnell, Detaildaten bleiben verfügbar.
• Schrittweise Modernisierung: du kannst Quellen und Architekturen migrieren, ohne jedes Report-Frontend neu zu bauen.

Mini-Use-Case: Historie schnell, Tagesdaten aktuell

Ein Controlling-Team analysiert Umsatz- und Deckungsbeiträge über mehrere Jahre. Die Historie wird als Import (schnell für Trends, Vorjahresvergleiche) modelliert. Für die heutige Auftragseingangsliste wird DirectQuery genutzt, weil sie stündlich wechseln kann. Im Report wirkt das wie „ein Modell“: Management sieht Trends sofort und kann bei Bedarf in aktuelle Details springen, ohne dass alles langsam wird.

Modell-Design: Beziehungen, Dual und Architektur-Regeln

Composite Models scheitern selten an „Power BI kann das nicht“, sondern am Modell-Design. Drei Regeln, die fast immer helfen:

• Sauberes Star-Schema: Dimensionen stabil halten, Fakten trennen. Mischmodelle werden sonst schnell unwartbar.
• Dual Storage Mode gezielt: Dimensionstabellen als Dual können DirectQuery-Facts sinnvoll beschleunigen, weil Filter lokal bedient werden können.
• Beziehungen prüfen: Cross-Source-Beziehungen können zu eingeschränktem Verhalten führen (Limited Relationships). Das muss bewusst getestet werden, sonst entstehen „komische“ Filtereffekte.

DAX in Composite Models: typische Fallstricke

DAX ist in Composite Models nicht grundsätzlich anders, aber die Kosten von „schlechtem DAX“ werden sichtbarer, weil Teile der Berechnung über DirectQuery oder Direct Lake laufen können. Praktische Leitplanken:

• Iterationen über große DirectQuery-Tabellen vermeiden: besser voraggregieren oder Measures so bauen, dass die Quelle aggregieren kann.
• Calculation Groups sparsam und gezielt: sie sind mächtig, erhöhen aber Komplexität und Testaufwand.
• Aggregationen nutzen: User-defined Aggregations (z. B. importierte Summen) können Detailtabellen in DirectQuery entlasten.

Performance, Skalierung und Governance: woran Teams wirklich hängen bleiben

Composite Models sind oft ein Architekturthema, nicht nur ein Berichtsthema. Entscheidend für stabile Performance und geringes Betriebsrisiko:

• Performance: Abfragepläne testen, Visuals reduzieren, und DirectQuery-Quellen auf sinnvolle Indizes und Views vorbereiten.
• Skalierung: klare Trennung zwischen „zentralem Semantic Model“ und „lokalen Erweiterungen“, sonst entsteht Wildwuchs.
• Governance: definieren, wer Modelle erweitern darf, wie Releases laufen (Dev/Test/Prod) und wie Datenherkunft nachvollziehbar bleibt.

Gerade bei OneLake/Gold-Daten ist der Nutzen für Anwender hoch: Nicht-IT-affine Nutzer können auf aufbereitete, verständliche Tabellen zugreifen und direkt in Power BI oder Excel starten, ohne Daten erst aus zig Files zusammenzuklicken.

Schritt-für-Schritt: Composite Model erstellen (pragmatisch)

Ein schlanker Ablauf, der in der Praxis funktioniert:

1. Use Case und Aktualitätsbedarf klären: welche Seiten müssen „instant“ sein, welche „near real-time“?
2. Quellen festlegen und Storage Mode pro Tabelle wählen (Import, DirectQuery, Direct Lake, Dual).
3. Semantic Model bauen: Star-Schema, Beziehungen, Rollen/Security, Namenskonventionen.
4. DAX-Set minimal starten: zentrale KPIs zuerst, dann iterativ erweitern; Performance nach jedem Schritt prüfen.
5. Refresh- und Betriebslogik definieren: Gateways, Kapazitäten, Monitoring, Verantwortlichkeiten.
6. Rollout: als App veröffentlichen, Feedback sammeln, dann standardisieren (Templates, Guidelines).

DirectQuery vs. Import vs. Direct Lake: Entscheidungshilfe

Wenn du nur eine Faustregel willst:

• Import, wenn Performance und Nutzererlebnis Priorität haben und Refresh-Zyklen reichen.
• DirectQuery, wenn Daten zu groß sind oder operative Aktualität dominiert und die Quelle für BI-Abfragen gebaut ist.
• Direct Lake, wenn eure Datenplattform im Lakehouse lebt und ihr „Gold-Daten“ breit nutzbar machen wollt, ohne klassische Import-Workflows.

Ressourcen & weiterführende Lektüre

Für die Vertiefung sind diese Microsoft-Begriffe die richtigen Suchanker: Storage Modes, Dual Storage Mode, DirectQuery-Guidance, Direct Lake, Aggregations, Limited Relationships, VertiPaq, XMLA Endpoints und die Abgrenzung zu Azure Analysis Services / SSAS.

Wann externe Unterstützung sinnvoll wird

Composite Models wirken im Prototyp oft schnell „fertig“ und fallen dann beim Rollout auseinander: Performance kippt, Filterlogik wird unklar oder Governance fehlt. Externe Unterstützung lohnt sich typischerweise, wenn du DirectQuery/Direct Lake mit vielen Nutzern skalieren willst, wenn DAX und Modellierung intern nicht sauber abgesichert sind oder wenn ein zentrales Semantic Model entstehen soll, das Fachbereiche kontrolliert erweitern können. Das spart Zeit in der Umsetzung und reduziert den späteren Wartungsaufwand deutlich.