DirectQuery-Modus in tabellarischen Modellen
Gilt für:
SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium
In diesem Artikel wird der DirectQuery-Modus für Analysis Services-Tabellarische Modelle mit den Kompatibilitätsgraden 1200 und höher beschrieben. Der DirectQuery-Modus kann für Modelle aktiviert werden, die Sie in Visual Studio entwerfen, oder für tabellarische Modelle, die bereits bereitgestellt wurden, können Sie mithilfe von SQL Server Management Studio (SSMS) in den DirectQuery-Modus wechseln. Bevor Sie den DirectQuery-Modus auswählen, ist es wichtig, sowohl die Vorteile als auch die Einschränkungen zu verstehen.
Vorteile
Standardmäßig verwenden Tabellenmodelle einen Cache im Arbeitsspeicher, um Daten zu speichern und abzufragen. Wenn Tabellenmodelle Daten aus dem Arbeitsspeicher abfragen, können selbst komplexe Abfragen äußerst schnell ausgeführt werden. Es gibt jedoch einige Einschränkungen bei der Verwendung von zwischengespeicherten Daten. Beispielsweise können sehr große Datasets den verfügbaren Arbeitsspeicher überschreiten, und die Verarbeitung (Aktualisierung) von In-Memory-Modelldaten kann bei häufigem Bedarf übermäßige Mengen an verfügbaren Ressourcen erfordern.
DirectQuery überwindet diese Einschränkungen, während es gleichzeitig die RDBMS-Funktionen nutzt, die die Ausführung von Abfragen effizienter gestalten können. Mit DirectQuery:
Die Daten sind auf dem neuesten Stand. Da Daten immer an der Datenquelle abgefragt werden, erhalten Clientberichtsanwendungen immer die neuesten Daten.
Es gibt keinen zusätzlichen Verwaltungsaufwand, wenn eine separate Kopie der Daten (im Speichercache) verwaltet werden muss. Es ist keine Verarbeitung (Aktualisierung) von Modelldaten erforderlich. Änderungen an den zugrunde liegenden Quelldaten werden umgehend in Abfragen des Datenmodells sichtbar.
Datasets können größer als die Speicherkapazität einer Analysis Services-Serverressource sein.
DirectQuery kann die anbieterseitige Abfragebeschleunigung nutzen, z. B. durch speicheroptimierte Spaltenindizes.
Die Sicherheit kann von der Back-End-Quelldatenbank erzwungen werden, indem Sicherheitsfeatures auf Zeilenebene aus der Datenbank verwendet werden (alternativ können Sie sicherheitsregeln auf Zeilenebene verwenden, die im Modell mithilfe von DAX definiert sind).
Wenn das Modell komplexe Formeln enthält, die unter Umständen mehrere Abfragen erfordern, kann Analysis Services eine Optimierung ausführen, um sicherzustellen, dass der Abfrageplan für die Abfrage, die für die Back-End-Datenbank ausgeführt wird, so effizient wie möglich ist.
Einschränkungen
Tabellarische Modelle im DirectQuery-Modus weisen einige Einschränkungen auf. Vor einem Moduswechsel sollten Sie entscheiden, ob die Vorteile einer Ausführung der Abfrage auf dem Back-End-Server gegenüber einer Verringerung der Funktionalität überwiegen. Wenn Sie den Modus eines vorhandenen Modells in Visual Studio ändern, benachrichtigt Sie der Designer für tabellarische Modelle über alle Features in Ihrem Modell, die mit dem DirectQuery-Modus nicht kompatibel sind. Beachten Sie die folgenden Einschränkungen:
| Funktion | Einschränkung |
|---|---|
| Datenquellen | DirectQuery-Modelle können nur Daten aus einer einzelnen relationalen Datenbank der folgenden Typen verwenden: Azure SQL Database, Azure Synapse Analytics, SQL Server, Oracle und Teradata. |
| Gespeicherte SQL-Prozeduren | Für DirectQuery-Modelle können gespeicherte Prozeduren nicht in einer SQL-Anweisung angegeben werden, um Tabellen zu definieren. |
| Berechnete Tabellen | Berechnete Tabellen werden in DirectQuery-Tabellenmodellen nicht unterstützt, berechnete Spalten hingegen schon. Wenn Sie versuchen, ein Tabellenmodell zu konvertieren, das eine berechnete Tabelle enthält, tritt eine Fehlermeldung auf, die besagt, dass das Modell keine eingefügten Daten enthalten darf. |
| Abfragegrenzwerte | Das Standardzeilenlimit beträgt eine Million Zeilen. Dieser Grenzwert kann durch Angabe von MaxIntermediateRowSize erhöht werden. Weitere Informationen finden Sie unter DAX-Eigenschaften. |
| DAX-Formeln | Beim Abfragen eines tabellarischen Modells im DirectQuery-Modus konvertiert Analysis Services DAX-Formeln und Measuredefinitionen in SQL-Anweisungen. DAX-Formeln mit Elementen, die nicht in SQL-Syntax konvertiert werden können, lösen Überprüfungsfehler für das Modell aus. Diese Einschränkung ist größtenteils auf bestimmte DAX-Tabellenfunktionen beschränkt. Bei Measures werden DAX-Formeln mit dem relationalen Datenspeicher in setbasierte Vorgänge konvertiert. Das bedeutet, dass alle implizit erstellten Measures unterstützt werden. Wenn ein Überprüfungsfehler auftritt, müssen Sie die Formel neu schreiben, durch eine andere Funktion ersetzen oder dieses Problem umgehen, indem Sie in der Datenquelle mit abgeleiteten Spalten arbeiten. Wenn ein tabellarisches Modell Formeln enthält, die inkompatible Funktionen enthalten, wird dies gemeldet, wenn Sie im Designer zum DirectQuery-Modus wechseln. Hinweis: Einige Formeln im Modell können überprüfen, wenn Sie das Modell in den DirectQuery-Modus wechseln, geben jedoch unterschiedliche Ergebnisse zurück, wenn sie für den Cache und den relationalen Datenspeicher ausgeführt werden. Dies liegt daran, dass Berechnungen für den Cache die Semantik der In-Memory-Analyse-Engine verwenden, die Features enthält, die das Verhalten von Excel emulieren sollen, während Abfragen für in der relationalen Datenquelle gespeicherte Daten die Semantik von SQL verwenden. |
| Formelkonsistenz | In bestimmten Fällen gibt dieselbe Formel in einem zwischengespeicherten Modell andere Ergebnisse zurück als in einem DirectQuery-Modell, in dem nur der relationale Datenspeicher verwendet wird. Diese Unterschiede sind eine Folge der semantischen Unterschiede zwischen der In-Memory-Analyse-Engine und der Datenquelle. |
| MDX-Einschränkungen | Keine relativen Objektnamen. Alle Objektnamen müssen vollqualifiziert sein. MDX-Anweisungen auf Sitzungsebene (benannte Mengen, berechnete Elemente, berechnete Zellen, sichtbare Gesamtwerte, Standardelemente usw.). Allerdings können Sie abfragebasierte Konstrukte wie die „WITH“-Klausel verwenden. Kein Tupel mit Elementen aus verschiedenen Ebenen in einzeln ausgewählten MDX-Klauseln für Unterauswahl. Keine benutzerdefinierten Hierarchien. Keine nativen SQL-Abfragen (normalerweise unterstützt Analysis Services eine Teilmenge von T-SQL, allerdings nicht bei DirectQuery-Modellen). |
Aufbauen der Verbindung zu einer Datenquelle
Beim Entwerfen eines DirectQuery-Modells in Visual Studio ist das Herstellen einer Verbindung mit einer Datenquelle und die Auswahl der Tabellen und Felder, die in Ihr Modell eingeschlossen werden sollen, in etwa identisch mit In-Memory-Modellen.
Wenn Sie DirectQuery bereits aktiviert haben, aber noch keine Verbindung mit einer Datenquelle hergestellt haben, können Sie Daten abrufen (oder den Datenimport-Assistenten für Legacyanbieterdatenquellen) verwenden, um eine Verbindung mit einer Datenquelle herzustellen, Tabellen und Felder auszuwählen usw. Der Unterschied besteht darin, dass nach Beendigung keine Daten in den In-Memory-Cache importiert werden.
Wenn Sie daten abrufen bereits zum Importieren von Daten verwendet, den DirectQuery-Modus aber noch nicht aktiviert haben, wird der Speichercache gelöscht.
Hinzufügen von Beispieldaten zu einem DirectQuery-Modellprojekt
Wenn Sie den Tabellarischen Modell-Designer in Visual Studio (SSDT) zum Entwerfen eines DirectQuery-Tabellarischen Modellprojekts verwenden, enthält die Arbeitsbereichsdatenbank des Modells standardmäßig keine Daten. Es gibt eine Standardpartition für jede Tabelle, und diese Partition leitet alle Abfragen an die Datenquelle weiter. Seit der Einführung von DirectQuery enthält der Designer für tabellarische Modelle ein Set as Sample-Feature im Partitions-Manager. Dieses Feature ermöglicht das Hinzufügen einer Kopierpartition zu Tabellen, die zum Importieren einer kleinen Menge von Beispieldaten in die Arbeitsbereichsdatenbank verwendet werden können. Dieses Feature soll helfen, Modellierungsentscheidungen zu überprüfen, ohne die Datenquelle zu beeinträchtigen.
Wichtig
Derzeit wird das Feature Als Beispiel festlegenim Designer für tabellarische Modelle nicht unterstützt. Außer Table <TableName> enthält keine Beispielpartition. Um Daten in SSDT zu verwenden, fügen Sie eine Beispielpartitionswarnung hinzu.
Bereitstellen von DirectQuery-Modellen
DirectQuery-Modelle werden wie Importmodelle bereitgestellt. Wenn ein DirectQuery-Modell jedoch im Gegensatz zu Importmodellen berechnete Elemente wie berechnete Spalten oder Berechnungsgruppen enthält, müssen Sie nach der Bereitstellung eine Prozessneuberechnung für alle Tabellen ausführen. Weitere Informationen finden Sie unter Verarbeiten von Datenbank, Tabelle oder Partition.
Weitere Informationen
Aktivieren des DirectQuery-Modus in Visual Studio
Aktivieren des DirectQuery-Modus in SSMS
Definieren von Partitionen in DirectQuery-ModellenTesten eines Modells im DirectQuery-Modus
In Azure Analysis Services unterstützte Datenquellen
Datenquellen, die in SQL Server Analysis Services tabellarischen Modellen 1400 und höher unterstützt werden.