Composite Models in Power BI: Mixing Import and DirectQuery

Learn how Power BI composite models combine import and DirectQuery storage modes to balance performance and freshness — with practical configuration guidance and trade-off analysis.

E
ECOSIRE Research and Development Team
|19. März 202611 Min. Lesezeit2.5k Wörter|

Zusammengesetzte Modelle in Power BI: Import und DirectQuery mischen

Jahrelang mussten sich Power BI-Anwender entscheiden: Importmodus (schnell, aber die Daten sind nur so aktuell wie bei der letzten Aktualisierung) oder DirectQuery (immer aktuell, aber möglicherweise langsam und abfragebeschränkt). Zusammengesetzte Modelle haben diese Berechnung geändert, indem sie die Koexistenz beider Speichermodi in einem einzigen Modell ermöglicht haben – mit Beziehungen, die über die Modusgrenze hinausgehen.

Diese Funktion erschließt Szenarien, die zuvor nicht möglich waren: ein Dashboard, das den gesamten Transaktionsverlauf von gestern aus einer Importpartition zusammen mit den heutigen Echtzeitdaten aus einer DirectQuery-Quelle anzeigt, alles verbunden mit einer Live-Salesforce-Opportunity-Tabelle, die bei Bedarf abgefragt wird. Zu verstehen, wie zusammengesetzte Modelle funktionieren – und wann sie mehr Probleme schaffen als sie lösen – ist für jeden fortgeschrittenen Power BI-Anwender von entscheidender Bedeutung.

Wichtige Erkenntnisse

– Zusammengesetzte Modelle kombinieren Import-, DirectQuery- und Dual-Speichermodi in einem einzigen semantischen Modell – Der Importmodus bietet VertiPaq-Komprimierung und In-Memory-Abfrageleistung für historische Daten – Der DirectQuery-Modus fragt die Quelle in Echtzeit ab – die Aktualität ist ausgezeichnet, aber die Leistung hängt von der Quelle ab – Dual-Mode-Tabellen können je nach Abfragekontext entweder als Import oder als DirectQuery fungieren – Beziehungen, die die Grenzen des Speichermodus überschreiten, erhöhen die Komplexität der Abfrage und können zu Leistungsproblemen führen – Aggregationstabellen in zusammengesetzten Modellen verbessern die DirectQuery-Abfrageleistung erheblich – DirectQuery für Power BI-Datensätze (Verkettung) ermöglicht zusammengesetzte Modelle, die auf gemeinsam genutzten semantischen Modellen basieren – Begrenzte Beziehungen zwischen Import- und DirectQuery-Tabellen schränken bestimmte DAX-Funktionen ein


Speichermodi: Import, DirectQuery und Dual

Vor dem Verständnis zusammengesetzter Modelle muss jeder Speichermodus einzeln verstanden werden.

Importmodus lädt Daten aus dem Quellsystem in die speicherinterne VertiPaq-Speicher-Engine von Power BI. Die Daten werden komprimiert (häufig 10:1 oder besser) und als Spaltendaten gespeichert, die analytische Abfragen extrem schnell ausführen – typischerweise Millisekunden für die meisten Abfragen für Datensätze mit bis zu Hunderten Millionen Zeilen. Die Einschränkung: Die Daten sind nur so aktuell wie bei der letzten geplanten oder manuellen Aktualisierung.

DirectQuery-Modus fragt das Quellsystem in Echtzeit ab, wenn ein Benutzer mit einem Bericht interagiert. Die Power BI-Engine übersetzt DAX-Abfragen in native Quellabfragen (SQL für relationale Datenbanken usw.) und führt sie gegen die Quelle aus. Die Daten sind immer aktuell, die Leistung hängt jedoch vollständig von der Abfrageleistung des Quellsystems ab. Eine gut indizierte, dedizierte Analysedatenbank kann DirectQuery-Abfragen gut verarbeiten. Eine OLTP-Produktionsdatenbank unter hoher Transaktionslast kann zu langsamen und inkonsistenten Ergebnissen führen.

Dual Mode ist ein spezieller Hybrid, der in Verbundmodellen verfügbar ist. Eine Dual-Mode-Tabelle wird physisch als Import gespeichert (Daten werden in VertiPaq geladen), kann aber auch über DirectQuery abgefragt werden, wenn der Abfragekontext dies erfordert. Dies wird hauptsächlich für gemeinsam genutzte Dimensionstabellen verwendet, die an Beziehungen sowohl zu Import- als auch zu DirectQuery-Faktentabellen teilnehmen müssen.


Wann man zusammengesetzte Modelle verwendet

Zusammengesetzte Modelle eignen sich für bestimmte Szenarien. Sie erhöhen die Komplexität, die nicht gerechtfertigt ist, wenn einfachere Architekturen die Anforderungen erfüllen.

Verwenden Sie zusammengesetzte Modelle, wenn:

SzenarioArchitektur
Aktuelle Echtzeitdaten + historische AnalyseDirectQuery für die heutige Faktentabelle, Import für historische
Sehr große historische Daten + mittelgroße DimensionenDirectQuery-Fakten mit Importdimensionen (Aggregatmodell)
Mehrere Quellsysteme mit unterschiedlichen FrischeanforderungenImport + DirectQuery aus verschiedenen Quellen
Aufbauend auf einem gemeinsamen semantischen Modell (Power BI-Datensatz)DirectQuery für Power BI-Datensatzverkettung
Premium-Kapazität mit AggregationstabellenGemischter Modus mit benutzerdefinierten Aggregationen

Verwenden Sie keine zusammengesetzten Modelle, wenn: – Ein vollständiges Importmodell wird schnell genug aktualisiert und die Datenlatenz ist akzeptabel (in den meisten Fällen). – Die DirectQuery-Quelle kann die Abfragelast nicht bewältigen (Produktions-OLTP-Datenbanken).

  • Es sind komplexe DAX-Berechnungen erforderlich – zusammengesetzte Modelle schränken bestimmte DAX-Funktionen ein – Die Sicherheit auf Zeilenebene muss sich über die Grenzen des Speichermodus erstrecken (komplexe Implementierung).

Speichermodi konfigurieren

In Power BI Desktop wird der Speichermodus pro Tabelle festgelegt. Klicken Sie mit der rechten Maustaste auf eine Tabelle in der Modellansicht → Eigenschaften → Erweitert → Speichermodus.

Für ein typisches zusammengesetztes Modell mit einer großen Faktentabelle in DirectQuery und Dimensionen im Import:

  1. Stellen Sie FactSales → Speichermodus ein: DirectQuery
  2. Stellen Sie DimDate → Speichermodus ein: Dual (bedient sowohl Import- als auch DirectQuery-Abfragen)
  3. Stellen Sie DimProduct ein → Speichermodus: Importieren (kleine Tabelle, vollständig zwischengespeichert)
  4. Stellen Sie DimCustomer ein → Speichermodus: Dual (wird in quellenübergreifenden Beziehungen verwendet)
  5. Stellen Sie RealtimeSales (heutige Daten) ein → Speichermodus: DirectQuery

Wenn Sie eine Tabelle als DirectQuery konfigurieren oder den Speichermodus ändern, zeigt Power BI Warnungen zu Beziehungen und möglichen Einschränkungen an. Überprüfen Sie diese sorgfältig – sie zeigen, wo sich das Modellverhalten von einem reinen Importmodell unterscheiden kann.


Beziehungen in zusammengesetzten Modellen

Beziehungen zwischen Tabellen unterschiedlicher Speichermodi verhalten sich anders als Beziehungen im gleichen Modus. Das Verständnis dieser Unterschiede ist entscheidend für die Erstellung von Modellen, die korrekte Ergebnisse liefern.

Regelmäßige Beziehungen verbinden zwei Tabellen, wobei die „viele“-Seite die „eins“-Seite zum Filtern verwenden kann. Bei Importmodellen befinden sich beide Tabellen im Speicher und die Beziehung wird schnell im Speicher ausgeführt. In zusammengesetzten Modellen mit einer Importtabelle und einer DirectQuery-Tabelle führt die Beziehung zu einem Tabellenscan einer Tabelle, der dann zum Filtern der anderen verwendet wird – was möglicherweise große modusübergreifende Abfragen generiert.

Eingeschränkte Beziehungen werden automatisch erstellt, wenn eine DirectQuery-Tabelle eine Viele-zu-Viele-Beziehung mit einer Importtabelle hat oder in bestimmten anderen modusübergreifenden Szenarios. Eingeschränkte Beziehungen unterstützen keine bidirektionalen Filter und schränken bestimmte DAX-Funktionen ein (z. B. Funktionen, die auf dem Beziehungsfilterpfad basieren). Power BI meldet eingeschränkte Beziehungen in der Modellansicht mit einer gepunkteten Linie statt einer durchgezogenen Linie.

Quellenübergreifende Beziehungen verbinden Tabellen aus völlig unterschiedlichen Datenquellen (z. B. eine Tabelle von SQL Server, die über DirectQuery verbunden ist, und eine Tabelle von Salesforce, die über eine andere DirectQuery-Verbindung verbunden ist). Für diese Beziehungen muss eine Seite eine Dual-Mode-Tabelle sein – Power BI muss in der Lage sein, eine Seite der Beziehung im Speicher zu materialisieren, um sie mit der anderen zu verbinden.

Die praktischen Auswirkungen dieser Beziehungstypen: DAX-Kennzahlen, die in einem reinen Importmodell korrekt funktionieren, können in einem zusammengesetzten Modell zu unerwarteten Ergebnissen oder Fehlern führen. Testen Sie alle Maßnahmen sorgfältig, nachdem Sie die Speichermodi geändert haben, insbesondere diejenigen, die USERELATIONSHIP, CROSSFILTER, CALCULATE mit beziehungsbezogenen Filterfunktionen und Aggregationen über verknüpfte Tabellen umfassen.


Aggregationstabellen: Das Kernmuster des zusammengesetzten Modells

Das wertvollste zusammengesetzte Modellmuster kombiniert eine große DirectQuery-Faktentabelle mit einer Aggregationstabelle im Importmodus, die die Daten mit einer höheren Körnung vorab zusammenfasst.

Das Problem: Eine Verkaufsfaktentabelle mit 500 Millionen Zeilen in DirectQuery ist zu groß, als dass die meisten Quellsysteme sie interaktiv abfragen könnten – jedes Diagramm benötigt mehr als 10 Sekunden, da die Quelle teure aggregierte Abfragen ausführt.

Die Lösung: Erstellen Sie vorab eine Übersichtstabelle, die die Fakten zu einer Tages-/Monats-/Produktkategorie-Gliederung zusammenfasst, und importieren Sie diese Übersichtstabelle in Power BI. Die meisten Abfragen (die auf monatlicher, vierteljährlicher oder Kategorieebene erfolgen) treffen auf die schnelle Importaggregation. Nur Abfragen, die einen Drilldown auf die Ebene einzelner Transaktionen durchführen, kehren zu DirectQuery zurück.

Aggregationen einrichten:

Erstellen Sie zunächst die Aggregationstabelle in Ihrem Data Warehouse:

CREATE TABLE SalesByDayProduct AS
SELECT
    SaleDateKey,
    ProductKey,
    CustomerSegmentKey,
    RegionKey,
    SUM(SalesAmount) as SalesAmount,
    SUM(Quantity) as Quantity,
    SUM(Cost) as Cost,
    COUNT(*) as TransactionCount
FROM FactSales
GROUP BY SaleDateKey, ProductKey, CustomerSegmentKey, RegionKey;

Importieren Sie diese Tabelle in Power BI und stellen Sie den Speichermodus auf Importieren ein.

Konfigurieren Sie dann die Aggregation in Power BI:

  • Klicken Sie mit der rechten Maustaste auf SalesByDayProduct → Aggregationen verwalten
  • Ordnen Sie jede Spalte ihrer Beziehung zur Detailtabelle und der Zusammenfassungsfunktion (Summe, Durchschnitt, Anzahl usw.) zu.
  • Legen Sie die Spalte „Zusammenfassung“ fest (SalesAmount → Sum wird FactSales[SalesAmount] → Sum zugeordnet)

Die Abfrage-Engine von Power BI leitet Abfragen jetzt nach Möglichkeit automatisch an die Aggregationstabelle weiter und greift nur dann auf die DirectQuery-Detailtabelle zurück, wenn die Abfrage Details auf Zeilenebene erfordert, die die Aggregation nicht bereitstellt.

Das Leistungsergebnis ist beeindruckend: Aggregationen auf Kategorie- und Zeitebene, die zuvor 15 Sekunden dauerten, werden jetzt in weniger als 1 Sekunde zurückgegeben, während die Option zum Drillen zu einzelnen Transaktionen weiterhin verfügbar ist.


DirectQuery für Power BI-Datensätze

Power BI führte DirectQuery für Power BI-Datensätze ein (auch „Live-Verbindung mit zusammengesetzten Modellen“ oder einfach „zusammengesetzte Modelle auf freigegebenen Datensätzen“ genannt). Dadurch kann ein Entwickler einen neuen Bericht oder Datensatz erstellen, der einen vorhandenen veröffentlichten Power BI-Datensatz als DirectQuery-Quelle verwendet – und gleichzeitig neue Tabellen, berechnete Kennzahlen und lokale Importdaten hinzufügt.

Hauptanwendungsfall: Eine Organisation verfügt über ein zertifiziertes semantisches Unternehmensmodell, das zentrale Finanz- und Vertriebsdaten abdeckt. Ein Team, das an einer bestimmten Analyse arbeitet, muss einige lokale Daten hinzufügen (eine CSV-Datei mit Projektcodes, eine Excel-Datei mit Zielen), ohne das zertifizierte Unternehmensmodell zu ändern. Mithilfe von DirectQuery für Power BI-Datensätze erstellen sie ein zusammengesetztes Modell, das über DirectQuery auf das Unternehmensmodell verweist und ihre lokalen Tabellen als Importdaten hinzufügt.

Dies ermöglicht eine kontrollierte Analysearchitektur, in der:

  • Das zentrale Datenteam verwaltet zertifizierte Unternehmensdatensätze – Geschäftsteams erweitern diese Datensätze um lokalen Kontext, ohne separate, inkonsistente Modelle zu erstellen – Das Unternehmensmodell bleibt die einzige Quelle der Wahrheit für gemeinsame Kennzahlen

Einschränkungen: DirectQuery für Power BI-Datensätze übernimmt alle Einschränkungen von regulärem DirectQuery – einige DAX-Funktionen sind eingeschränkt, die Sicherheit auf Zeilenebene muss ordnungsgemäß konfiguriert werden, um durch das zusammengesetzte Modell weitergegeben zu werden, und die Verbindung zum Quelldatensatz fügt eine Ebene der Abfrageverarbeitung hinzu.


Leistungsoptimierung für zusammengesetzte Modelle

Zusammengesetzte Modelle erfordern eine sorgfältigere Leistungsoptimierung als reine Importmodelle. Die folgenden Optimierungen sind am wirkungsvollsten:

Reduzieren Sie modusübergreifende Abfragen: Jeder Beziehungsdurchlauf, der eine Speichermodusgrenze überschreitet, erhöht die Latenz. Minimieren Sie diese, indem Sie Dimensionstabellen im Dualmodus beibehalten (sie können sowohl Import- als auch DirectQuery-Abfragen ohne modusübergreifenden Durchlauf bedienen) und das Modell so strukturieren, dass die meisten Abfragen in einem einzigen Modus bleiben.

Vorab an der Quelle aggregieren: Bitten Sie die DirectQuery-Quelle nicht, Aggregationen durchzuführen, die Power BI effizienter durchführen könnte. Erstellen Sie Ansichten oder materialisierte Ansichten in der Quelldatenbank, die vorab in der von Ihren Berichten tatsächlich benötigten Körnung aggregiert werden.

Abfrageplan mit Leistungsanalysator überwachen: In Power BI Desktop zeichnet „Ansicht → Leistungsanalysator“ die Zeit auf, die für die DAX-Abfrage jedes Visuals und die nachfolgende Quellabfrage (bei DirectQuery) benötigt wird. Dies zeigt, welche Visuals langsam sind und ob sich die langsame Abfrage in der DAX-Ebene oder der Quellabfrageebene befindet.

Einstellungen zur Abfragereduzierung verwenden: Aktivieren Sie in Power BI Desktop → Optionen → Abfragereduzierung Optionen zum Hinzufügen von Anwenden-Schaltflächen zu Slicern und Filtern. Dies verhindert, dass jede Slicer-Interaktion sofort eine Quellabfrage auslöst – besonders wichtig für DirectQuery-Berichte, bei denen jede Abfrage Netzwerk- und Quellausführungslatenz aufweist.

Begrenzen Sie die Anzahl der DirectQuery-Verbindungen: Jede unterschiedliche DirectQuery-Quelle in einem zusammengesetzten Modell erstellt einen separaten Verbindungspool. Beschränken Sie sich nach Möglichkeit auf 1–2 DirectQuery-Quellen. Mehr als 3 erhöhen die Modellkomplexität und potenzielle Leistungsprobleme erheblich.


Sicherheit auf Zeilenebene in zusammengesetzten Modellen

Sicherheit auf Zeilenebene (RLS) in zusammengesetzten Modellen erfordert eine sorgfältige Planung, insbesondere wenn RLS für eine Importtabelle definiert wird, die eine Beziehung zu einer DirectQuery-Tabelle hat.

Wenn ein Benutzer mit einem RLS-Filter einen Bericht abfragt, wendet Power BI den Filter auf die entsprechende Tabelle an. Wenn sich die gefilterte Tabelle im Importmodus befindet und eine Beziehung zu einer DirectQuery-Tabelle hat, muss Power BI den Importfilter in einen Filter übersetzen, der an die DirectQuery-Quelle gesendet werden kann. Dies funktioniert in den meisten Fällen, kann jedoch bei komplexen Filterhierarchien zu unerwarteten Ergebnissen führen.

Best Practice: Definieren Sie RLS für die Dimensionstabellen im Importmodus (nicht für die DirectQuery-Faktentabellen). Der Filter breitet sich durch die Beziehung von der Dimension zum Fakt aus – was zuverlässig funktioniert. Das direkte Definieren von RLS in DirectQuery-Tabellen ist möglich, aber schwieriger zu testen und zu debuggen.

Bei zusammengesetzten Modellen, die DirectQuery für Power BI-Datensätze verwenden, wird das im Quelldatensatz definierte RLS automatisch angewendet, wenn dieser Datensatz abgefragt wird. Zusätzliche RLS können in der zusammengesetzten Modellebene definiert werden. Dieser mehrschichtige RLS-Ansatz erfordert sorgfältige Tests, um sicherzustellen, dass die Filter richtig zusammengesetzt sind.


Häufig gestellte Fragen

Kann ich Daten aus völlig unterschiedlichen Datenbankplattformen in einem zusammengesetzten Modell mischen?

Ja. Ein zusammengesetztes Modell kann gleichzeitig Tabellen aus SQL Server (DirectQuery), Salesforce (DirectQuery), einer Azure Blob Storage-Datei (Import) und Snowflake (DirectQuery) enthalten. Jede Quelle unterhält ihre eigene Verbindung. Beziehungen zwischen Tabellen aus verschiedenen Quellen müssen mindestens eine Dual-Mode-Tabelle haben, um quellübergreifende Verknüpfungen zu ermöglichen. Leistung und Komplexität nehmen mit jeder zusätzlichen Quelle zu – eine Beschränkung auf zwei bis drei Quellen ist für die meisten Implementierungen praktisch.

Welche DAX-Funktionen funktionieren in zusammengesetzten Modellen nicht?

Einige DAX-Funktionen unterliegen Einschränkungen oder verhalten sich in zusammengesetzten Modellen mit DirectQuery-Tabellen anders. Zu den Funktionen, die nicht mit eingeschränkten Beziehungen funktionieren, gehören SUMMARIZE (in bestimmten Kontexten), TOPN (für DirectQuery-Tabellen) und einige Zeitintelligenzfunktionen. USERELATIONSHIP funktioniert, kann jedoch modusübergreifende Abfragen verursachen. Die vollständige Liste der Einschränkungen ist in der Power BI-Dokumentation von Microsoft unter „DirectQuery-Einschränkungen“ dokumentiert. Es wird dringend empfohlen, alle kritischen Maßnahmen nach dem Hinzufügen von DirectQuery-Tabellen zu testen.

Wie funktioniert die inkrementelle Aktualisierung bei zusammengesetzten Modellen?

Die inkrementelle Aktualisierung gilt für Partitionen im Importmodus innerhalb eines zusammengesetzten Modells. Als DirectQuery konfigurierte Tabellen verwenden keine inkrementelle Aktualisierung – sie fragen die Quelle bei jeder Interaktion in Echtzeit ab. Die häufigste Kombination ist die Verwendung einer inkrementellen Aktualisierung auf historischen Partitionen im Importmodus und gleichzeitiger Verwendung von DirectQuery für die Daten des aktuellen Zeitraums. Hierbei handelt es sich um die Funktion „Hybridtabellen“, bei der es sich um eine spezielle Form der zusammengesetzten Modellierung innerhalb einer einzelnen Tabelle handelt.

Welche Auswirkungen haben zusammengesetzte Modelle im Vergleich zum reinen Import auf die Leistung?

Zusammengesetzte Modelle mit DirectQuery-Komponenten sind für entsprechende Abfragen immer langsamer als entsprechende reine Importmodelle. Die Leistungslücke hängt von der Leistung des Quellsystems und dem Anteil der Abfragen ab, die DirectQuery im Vergleich zu Importpartitionen treffen. Bei gut gestalteten Aggregationstabellen erreichen die meisten Benutzerabfragen die Importaggregation und kehren in weniger als einer Sekunde zurück, sodass die Leistung akzeptabel ist. Abfragen, die einen Drilldown zu DirectQuery-Details durchführen, können je nach Quellleistung 3 bis 15 Sekunden dauern.

Soll ich zusammengesetzte Modelle verwenden oder einfach häufigere Aktualisierungen einplanen?

Für die meisten Anwendungsfälle, in denen „nahezu Echtzeit“ akzeptabel ist, sind häufigere Aktualisierungen (alle 15 Minuten im Importmodus) ausreichend. Zusammengesetzte Modelle mit DirectQuery erhöhen die Komplexität erheblich – verwenden Sie sie nur, wenn: (a) Sie Daten benötigen, die wirklich auf die Minute oder Sekunde genau sind, (b) der Datensatz zu groß ist, um innerhalb des verfügbaren Fensters selbst bei inkrementeller Aktualisierung aktualisiert zu werden, oder (c) Sie Daten aus Quellen kombinieren müssen, die nicht in einer einzigen Warehouse-Aktualisierung konsolidiert werden können.


Nächste Schritte

Zusammengesetzte Modelle sind ein leistungsstarkes Werkzeug für anspruchsvolle Power BI-Architekturen – sie erfordern jedoch einen sorgfältigen Entwurf, um Leistungs- und Korrektheitsprobleme zu vermeiden. Die erfolgreichsten Implementierungen verwenden zusammengesetzte Modelle für spezifische, begründete Szenarien und nicht als Standardarchitektur.

Die Power BI-Datenmodellierungsdienste von ECOSIRE umfassen den Entwurf zusammengesetzter Modelle, die Implementierung von Aggregationstabellen und die Leistungsoptimierung. Kontaktieren Sie uns, um zu beurteilen, ob zusammengesetzte Modelle die richtige Lösung für Ihre spezifischen Datenaktualitäts- und Leistungsanforderungen sind.

E

Geschrieben von

ECOSIRE Research and Development Team

Entwicklung von Enterprise-Digitalprodukten bei ECOSIRE. Einblicke in Odoo-Integrationen, E-Commerce-Automatisierung und KI-gestützte Geschäftslösungen.

Chatten Sie auf WhatsApp