In Azure Synapse SQL unterstützte Transact-SQL-Funktionen

  • Artikel

Azure Synapse SQL ist ein Big Data-Analysedienst, mit dem Sie Ihre Daten per T-SQL-Sprache abfragen und analysieren können. Sie können einen ANSI-kompatiblen Standarddialekt der SQL-Sprache verwenden, die in SQL Server und Azure SQL-Datenbank für die Datenanalyse verwendet wird.

Die Transact-SQL-Sprache wird im serverlosen SQL-Pool verwendet. Das dedizierte Modell kann auf verschiedene Objekte verweisen, und bei den unterstützten Funktionen gibt es gewisse Unterschiede. Auf dieser Seite finden Sie allgemeine Transact-SQL-Sprachunterschiede zwischen den Verbrauchsmodellen von Synapse SQL.

Datenbankobjekte

Verbrauchsmodelle in Synapse SQL ermöglichen die Verwendung verschiedener Datenbankobjekte. Die folgende Tabelle gibt Aufschluss über die unterstützten Objekttypen:

Object Dediziert Serverlos
Tabellen Ja Nein, datenbankbasierte Tabellen werden nicht unterstützt. Vom serverlosen SQL-Pool können nur externe Tabellen abgefragt werden, die auf Daten verweisen, die in Azure Data Lake Storage oder Dataverse gespeichert sind.
Ansichten Ja. Von Sichten können Abfragesprachelemente verwendet werden, die im dedizierten Modell verfügbar sind. Ja. Sie können Sichten für externe Tabellen, Abfragen mit der OPENROWSET-Funktion und andere Sichten erstellen. Von Sichten können Abfragesprachelemente verwendet werden, die im serverlosen Modell verfügbar sind.
Schemas Ja Ja, Schemas werden unterstützt. Verwenden Sie Schemas, um verschiedene Mandanten zu isolieren und ihre Tabellen pro Schema zu platzieren.
Temporäre Tabellen Ja Temporäre Tabellen können verwendet werden, um lediglich einige Informationen aus Systemsichten, Literalen oder anderen temporären Tabellen zu speichern. „UPDATE/DELETE“ wird für temporäre Tabellen ebenfalls unterstützt. Temporäre Tabellen können mit den Systemsichten verknüpft werden. Sie können keine Daten aus einer externen Tabelle auswählen, um sie in eine temporäre Tabelle einzufügen, und Sie können keine temporäre Tabelle mit einer externen Tabelle verknüpfen. Diese Vorgänge sind nicht erfolgreich, da externe Daten und temporäre Tabellen nicht in der gleichen Abfrage verwendet werden können.
Benutzerdefinierte Prozeduren Ja Ja, gespeicherte Prozeduren können in beliebigen Benutzerdatenbanken (nicht in der master-Datenbank) platziert werden. Von Prozeduren können nur externe Daten gelesen und Elemente der Abfragesprache verwendet werden, die im serverlosen Pool verfügbar sind.
User defined functions (UDFs) in Azure Cosmos DB (Benutzerdefinierte Funktionen (UDFs) in Azure Cosmos DB) Ja Ja, nur Inline-Tabellenwertfunktionen werden unterstützt. Benutzerdefinierte Skalarfunktionen werden nicht unterstützt.
Trigger Nein Nein, serverlose SQL-Pools lassen keine Änderung von Daten zu, sodass die Trigger nicht auf Datenänderungen reagieren können.
Externe Tabellen Ja. Weitere Informationen finden Sie in den unterstützten Datenformaten. Ja. Externe Tabellen sind verfügbar und können zum Lesen von Daten aus Azure Data Lake Storage oder Dataverse verwendet werden. Weitere Informationen finden Sie unter unterstützte Datenformate.
Zwischenspeichern von Abfragen Ja. Es sind mehrere Varianten verfügbar (SSD-basierte Zwischenspeicherung, In-Memory, Resultset-Zwischenspeicherung). Außerdem wird die materialisierte Sicht unterstützt. Nein. Nur die Dateistatistiken werden zwischengespeichert.
Zwischenspeichern von Resultsets Ja Nein. Die Abfrageergebnisse werden nicht zwischengespeichert. Nur die Dateistatistik wird zwischengespeichert.
Materialisierte Sichten Ja Nein. Die materialisierten Sichten werden in den serverlosen SQL-Pools nicht unterstützt.
Tabellenvariablen Nein. Verwenden Sie temporäre Tabellen. Nein, Tabellenvariablen werden nicht unterstützt.
Tabellenverteilung Ja Nein, Tabellenverteilungen werden nicht unterstützt.
Tabellenindizes Ja Nein, Indizes werden nicht unterstützt.
Tabellenpartitionierung Ja. Externe Tabellen unterstützen keine Partitionierung. Sie können Dateien mithilfe der Hive-Partitionsordnerstruktur partitionieren und partitionierte Tabellen in Spark erstellen. Die Spark-Partitionierung wird mit dem serverlosen Pool synchronisiert. Wenn Sie nicht Spark verwenden, können Sie Ihre Dateien in der Ordnerstruktur partitionieren und partitionierte Sichten für die Ordnerpartitionsstruktur erstellen. Die externen Tabellen können jedoch nicht für partitionierte Ordner erstellt werden.
Statistik Ja Ja, Statistiken werden für externe Dateien erstellt.
Workloadverwaltung, Ressourcenklassen und Gleichzeitigkeitssteuerung Ja, siehe Workloadverwaltung, Ressourcenklassen und Parallelitätssteuerung. Nein. Sie können die Ressourcen, die den Abfragen zugewiesen sind, nicht verwalten. Der serverlose SQL-Pool verwaltet die Ressourcen automatisch.
Kostenkontrolle Ja, mithilfe von Aktionen zum Hochskalieren und Herunterskalieren Ja. Sie können die tägliche, wöchentliche oder monatliche Nutzung des serverlosen Pools mithilfe des Azure-Portals oder der T-SQL-Prozedur einschränken.

Abfragesprache

Die unterstützten Funktionen der in Synapse SQL verwendeten Abfragesprachen können sich abhängig vom Verbrauchsmodell unterscheiden. In der folgenden Tabelle sind die wichtigsten Unterschiede bei der Abfragesprache in Transact-SQL-Dialekten aufgeführt:

-Anweisung. Dediziert Serverlos
SELECT-Anweisung Ja. Die SELECT-Anweisung wird unterstützt, aber einige Transact-SQL-Abfrageklauseln wie FOR XML/FOR JSON, MATCH und OFFSET/FETCH werden nicht unterstützt. Ja. Die SELECT-Anweisung wird unterstützt, aber einige Transact-SQL-Abfrageklauseln wie FOR XML, MATCH, PREDICT, GROUPING SETS und die Abfragehinweise werden nicht unterstützt.
INSERT-Anweisung Ja Nein. Laden Sie neue Daten mit Spark oder anderen Tools in Data Lake hoch. Verwenden Sie für Workloads mit hohem Transaktionsaufkommen Azure Cosmos DB mit dem analytischen Speicher. Sie können CETAS verwenden, um eine externe Tabelle zu erstellen und Daten einzufügen.
UPDATE-Anweisung Ja Nein. Aktualisieren Sie Parquet-/CSV-Daten mithilfe von Spark. Die Änderungen sind dann automatisch im serverlosen Pool verfügbar. Verwenden Sie für Workloads mit hohem Transaktionsaufkommen Azure Cosmos DB mit dem analytischen Speicher.
DELETE-Anweisung Ja Nein. Löschen Sie Parquet-/CSV-Daten mithilfe von Spark. Die Änderungen sind dann automatisch im serverlosen Pool verfügbar. Verwenden Sie für Workloads mit hohem Transaktionsaufkommen Azure Cosmos DB mit dem analytischen Speicher.
MERGE-Anweisung Ja (Vorschau) Nein. Führen Sie Parquet-/CSV-Daten mithilfe von Spark zusammen. Die Änderungen sind dann automatisch im serverlosen Pool verfügbar.
CTAS-Anweisung Ja Nein. Die Anweisung CREATE TABLE AS SELECT wird im serverlosen SQL-Pool nicht unterstützt.
CETAS-Anweisung Ja. Das erste Laden in eine externe Tabelle kann mithilfe von CETAS durchgeführt werden. Ja. Das erste Laden in eine externe Tabelle kann mithilfe von CETAS durchgeführt werden. CETAS unterstützt Parquet- und CSV-Ausgabeformate.
Transaktionen Ja Ja. Transaktionen sind nur auf die Metadatenobjekte anwendbar.
Bezeichnungen Ja Nein. Bezeichnungen werden in serverlosen SQL-Pools nicht unterstützt.
Ladevorgänge für Daten Ja. Das bevorzugte Hilfsprogramm ist zwar die COPY-Anweisung, vom System werden jedoch auch Massenladen (BCP) sowie CETAS zum Laden von Daten unterstützt. Nein. Sie können keine Daten in den serverlosen SQL-Pool laden, da Daten in externem Speicher gespeichert werden. Sie können Daten zunächst mithilfe der CETAS-Anweisung in eine externe Tabelle laden.
Datenexport Ja. Unter Verwendung von CETAS. Ja. Sie können Daten mithilfe von CETAS aus einem externen Speicher (Azure Data Lake, Dataverse, Azure Cosmos DB) in Azure Data Lake exportieren.
Typen Ja. Alle Transact-SQL-Typen außer cursor, hierarchyid, ntext, text und image, rowversion, räumliche Typen, sql_variant und xml Ja. Alle Transact-SQL-Typen außer cursor, hierarchyid, ntext, text und image, rowversion, räumliche Typen, sql_variant, xml und Tabellentyp werden unterstützt. Informationen zum Zuordnen von Parquet-Spaltentypen zu SQL-Typen finden Sie hier.
Datenbankübergreifende Abfragen Nein Ja. Die datenbankübergreifenden Abfragen und die dreiteiligen Namensverweise werden einschließlich USE-Anweisung unterstützt. Die Abfragen können auf die serverlosen SQL-Datenbanken oder auf die Lake-Datenbanken im gleichen Arbeitsbereich verweisen. Arbeitsbereichsübergreifende Abfragen werden nicht unterstützt.
Integrierte Funktionen/Systemfunktionen (Analyse) Ja. Alle Transact-SQL-Funktionen im Zusammenhang mit Analyse, Konvertierung, Datum und Uhrzeit, Logik und Mathematik mit Ausnahme von CHOOSE und PARSE Ja. Alle Transact-SQL-Funktionen im Zusammenhang mit Analyse, Konvertierung, Datum und Uhrzeit, Logik und Mathematik werden unterstützt.
Integrierte Funktionen/Systemfunktionen (string) Ja. Alle Transact-SQL-Funktionen im Zusammenhang mit Zeichenfolgen, JSON und Sortierung mit Ausnahme von STRING_ESCAPE und TRANSLATE. Ja. Alle Transact-SQL-Funktionen im Zusammenhang mit Zeichenfolgen, JSON und Sortierung werden unterstützt.
Integrierte Funktionen/Systemfunktionen (kryptografisch) Einige HASHBYTES ist die einzige unterstützte kryptografische Funktion in serverlosen SQL-Pools.
Integrierte Funktionen/Tabellen-Wert-Systemfunktionen Ja. Transact-SQL-Rowsetfunktionen mit Ausnahme von OPENXML, OPENDATASOURCE, OPENQUERY und OPENROWSET. Ja. Alle Transact-SQL-Rowsetfunktionen mit Ausnahme von OPENXML, OPENDATASOURCE und OPENQUERY werden unterstützt.
Integrierte Aggregate/Systemaggregate Integrierte Transact-SQL-Aggregate mit Ausnahme von CHECKSUM_AGG und GROUPING_ID. Ja. Alle integrierten Aggregate von Transact-SQL werden unterstützt.
Operatoren Ja. Alle Transact-SQL-Operatoren mit Ausnahme von !>> und !< Ja. Alle Transact-SQL-Operatoren werden unterstützt.
Ablaufsteuerung Ja. Alle Transact-SQL-Ablaufsteuerungsanweisungen mit Ausnahme von CONTINUE, GOTO, RETURN, USE und WAITFOR. Ja. Alle Transact-SQL-Ablaufsteuerungsanweisungen werden unterstützt. Die SELECT-Abfrage in der Bedingung WHILE (...) wird nicht unterstützt.
DDL-Anweisungen (CREATE, ALTER, DROP) Ja. Alle auf die unterstützten Objekttypen anwendbaren Transact-SQL-DDL-Anweisungen. Ja. Alle auf die unterstützten Objekttypen anwendbaren Transact-SQL-DDL-Anweisungen werden unterstützt.

Sicherheit

Synapse SQL-Pools ermöglichen die Verwendung integrierter Sicherheitsfeatures, um Ihre Daten zu schützen und den Zugriff zu steuern. In der folgenden Tabelle werden allgemeine Unterschiede zwischen den Synapse-SQL-Verbrauchsmodellen gegenübergestellt:

Funktion Dediziert Serverlos
Anmeldungen Nicht zutreffend (In Datenbanken werden nur enthaltene Benutzer unterstützt.) Ja, Microsoft Entra ID- und SQL-Anmeldungen auf Serverebene werden unterstützt.
Benutzer Nicht zutreffend (In Datenbanken werden nur enthaltene Benutzer unterstützt.) Ja. Datenbankbenutzer werden unterstützt.
Eigenständige Benutzer Ja. Hinweis: Nur ein Microsoft Entra-Benutzer oder eine Microsoft Entra-Benutzerin kann uneingeschränkter Administrator bzw. Administratorin sein. Nein. Die enthaltenen Benutzer werden nicht unterstützt.
Authentifizierung mit SQL-Benutzername/Kennwort Ja Ja. Benutzer können mit ihrem Benutzernamen und Kennwort auf den serverlosen SQL-Pool zugreifen.
Microsoft Entra-Authentifizierung Ja, Microsoft Entra-Benutzer*innen Ja, Microsoft Entra-Anmeldungen und -Benutzer*innen können mithilfe ihrer Microsoft Entra-Identitäten auf serverlose SQL-Pools zugreifen.
Microsoft Entra-Passthrough-Authentifizierung für Speicher Ja Ja, die Microsoft Entra-Passthrough-Authentifizierung gilt für Microsoft Entra-Anmeldungen. Die Identität des Microsoft Entra-Benutzers bzw. der Benutzerin wird an den Speicher übergeben, wenn keine Anmeldeinformationen angegeben werden. Für die SQL-Benutzer*innen ist die Microsoft Entra-Passthrough-Authentifizierung nicht verfügbar.
SAS-Tokenauthentifizierung für den Speicher Nein Ja, bei Verwendung von DATABASE SCOPED CREDENTIAL mit SAS-Token in EXTERNAL DATA SOURCE oder von CREDENTIAL auf Instanzebene mit SAS.
Authentifizierung per Speicherzugriffsschlüssel Ja, unter Verwendung von DATABASE SCOPED CREDENTIAL in EXTERNAL DATA SOURCE. Nein. Verwenden Sie ein SAS-Token anstelle eines Speicherzugriffsschlüssels.
Authentifizierung für den Speicher mittels verwalteter Identität Ja, unter Verwendung von Anmeldeinformationen für eine verwaltete Dienstidentität. Ja. Die Abfrage kann unter Verwendung der verwalteten Identität des Arbeitsbereichs auf den Speicher zugreifen.
Authentifizierung beim Speicher mittels Anwendungsidentität/Dienstprinzipalname (Service Principal Name, SPN) Ja Ja. Sie können Anmeldeinformationen mit einer Dienstprinzipal-Anwendungs-ID erstellen, die für die Authentifizierung beim Speicher verwendet wird.
Serverrollen Nein Ja. Systemadministrator sowie öffentliche und andere Serverrollen werden unterstützt.
ANMELDEINFORMATION AUF SERVEREBENE Nein Ja, die Anmeldeinformationen auf Serverebene werden von der Funktion OPENROWSET verwendet ohne Verwendung einer expliziten Datenquelle.
Berechtigungen – Serverebene Nein Ja, z. B. CONNECT ANY DATABASE und SELECT ALL USER SECURABLES ermöglichen es einem Benutzer, Daten aus beliebigen Datenbanken zu lesen.
Datenbankrollen Ja Ja. Sie können die Rollen db_owner, db_datareader und db_ddladmin verwenden.
DATABASE SCOPED CREDENTIAL Ja, wird in externen Datenquellen verwendet. Ja. Datenbankweit gültige Anmeldeinformationen können in externen Datenquellen zum Definieren der Speicherauthentifizierungsmethode verwendet werden.
Berechtigungen – Datenbankebene Ja Ja. Sie können Berechtigungen für die Datenbankobjekte erteilen, verweigern oder widerrufen.
Berechtigungen – Schemaebene Ja, einschließlich der Möglichkeit zum Gewähren (GRANT), Verweigern (DENY) und Widerrufen (REVOKE) von Berechtigungen für Benutzer/Anmeldungen für das Schema. Ja. Sie können Berechtigungen auf Schemaebene angeben, einschließlich der Möglichkeit zum Gewähren (GRANT), Verweigern (DENY) und Widerrufen (REVOKE) von Berechtigungen für Benutzer/Anmeldungen im Schema.
Berechtigungen – Objektebene Ja, einschließlich der Möglichkeit zum Gewähren (GRANT), Verweigern (DENY) und Widerrufen (REVOKE) von Berechtigungen für Benutzer. Ja. Sie können Benutzern/Anmeldungen Berechtigungen für die unterstützten Systemobjekte erteilen (GRANT), verweigern (DENY) und entziehen (REVOKE).
Berechtigungen – Sicherheit auf Spaltenebene Ja Die Sicherheit auf Spaltenebene wird in serverlosen SQL-Pools für Sichten unterstützt, nicht für externe Tabellen. Im Falle von externen Tabellen können Sie eine logische Ansicht oberhalb der externen Tabelle erstellen und dann die Sicherheit auf Spaltenebene anwenden.
Sicherheit auf Zeilenebene Ja Nein. Es gibt keine integrierte Unterstützung für die Sicherheit auf Zeilenebene. Verwenden Sie benutzerdefinierte Sichten als Problemumgehung.
Datenmaskierung Ja Nein. Die integrierte Datenmaskierung wird in den serverlosen SQL-Pools nicht unterstützt. Verwenden Sie stattdessen Wrapper-SQL-Sichten, die einige Spalten explizit maskieren.
Integrierte Funktionen/Systemsicherheits- und Identitätsfunktionen Einige Transact-SQL-Sicherheitsfunktionen und -operatoren: CURRENT_USER, HAS_DBACCESS, IS_MEMBER, IS_ROLEMEMBER, SESSION_USER, SUSER_NAME, SUSER_SNAME, SYSTEM_USER, USER, USER_NAME, EXECUTE AS, OPEN/CLOSE MASTER KEY Einige Transact-SQL-Sicherheitsfunktionen und -operatoren werden unterstützt: CURRENT_USER, HAS_DBACCESS, HAS_PERMS_BY_NAME, IS_MEMBER, IS_ROLEMEMBER, IS_SRVROLEMEMBER, SESSION_USER, SESSION_CONTEXT, SUSER_NAME, SUSER_SNAME, SYSTEM_USER, USER, USER_NAME, EXECUTE AS und REVERT. Sicherheitsfunktionen können nicht zum Abfragen externer Daten verwendet werden. (Speichern Sie das Ergebnis in einer Variablen, die in der Abfrage verwendet werden kann.)
Transparente Datenverschlüsselung (TDE) Ja Nein. Transparent Data Encryption wird nicht unterstützt.
Datenermittlung und -klassifizierung Ja Nein. Die Datenermittlung und -klassifizierung wird nicht unterstützt.
Sicherheitsrisikobewertung Ja Nein. Die Sicherheitsrisikobewertung ist nicht verfügbar.
Advanced Threat Protection für Azure SQL-Datenbank Ja Nein. Advanced Threat Protection wird nicht unterstützt.
Überwachung Ja Ja. In serverlosen SQL-Pools wird die Überwachung unterstützt.
Firewallregeln Ja Ja. Die Firewallregeln können für den serverlosen SQL-Endpunkt festgelegt werden.
Privater Endpunkt Ja Ja. Der private Endpunkt kann für den serverlosen SQL-Pool festgelegt werden.

Ein dedizierter SQL-Pool und ein serverloser SQL-Pool verwenden die Transact-SQL-Standardsprache, um Daten abzufragen. Ausführliche Informationen zu den Unterschieden finden Sie in der Transact-SQL-Sprachreferenz.

Plattformfeatures

Funktion Dediziert Serverlos
Skalierung Ja Der serverlose SQL-Pool wird je nach Workload automatisch skaliert.
Anhalten/Fortsetzen Ja Der serverlose SQL-Pool wird automatisch deaktiviert, wenn er nicht verwendet wird, und er wird bei Bedarf aktiviert. Eine Benutzeraktion ist nicht erforderlich.
Datenbanksicherungen Ja Nein. Daten werden in externen Systemen (ADLS, Cosmos DB) gespeichert. Stellen Sie daher sicher, dass Sie Sicherungen der Daten an der Quelle durchführen. Stellen Sie sicher, dass Sie SQL-Metadaten (Tabelle, Ansicht, Prozedurdefinitionen und Benutzerberechtigungen) in der Quellcodeverwaltung speichern. Tabellendefinitionen in der Lake-Datenbank werden in Spark-Metadaten gespeichert. Stellen Sie daher sicher, dass Sie Spark-Tabellendefinitionen auch in der Quellcodeverwaltung beibehalten.
Datenbankwiederherstellung Ja Nein. Daten werden in externen Systemen (ADLS, Cosmos DB) gespeichert. Sie müssen deshalb Quellsysteme wiederherstellen, um Ihre Daten zu erhalten. Stellen Sie sicher, dass sich Ihre SQL-Metadaten (Tabelle, Ansicht, Prozedurdefinitionen und Benutzerberechtigungen) in der Quellcodeverwaltung befinden, damit Sie die SQL-Objekte neu erstellen können. Tabellendefinitionen in der Lake-Datenbank werden in Spark-Metadaten gespeichert. Stellen Sie daher sicher, dass Sie Spark-Tabellendefinitionen auch in der Quellcodeverwaltung beibehalten.

Tools

Sie können verschiedene Tools verwenden, um eine Verbindung mit Synapse SQL herzustellen und Daten abzufragen.

Tool Dediziert Serverlos
Synapse Studio Ja, SQL-Skripts. Ja. SQL-Skripts können in Synapse Studio verwendet werden. Verwenden Sie SSMS oder ADS anstelle von Synapse Studio, wenn Sie eine große Datenmenge als Ergebnis zurückgeben.
Power BI Ja Ja. Sie können Power BI verwenden, um Berichte für den serverlosen SQL-Pool zu erstellen. Für die Berichterstellung wird der Importmodus empfohlen.
Azure Analysis Service Ja Ja. Sie können Daten unter Verwendung des serverlosen SQL-Pools in Azure Analysis Services laden.
Azure Data Studio (ADS) Ja Ja. Sie können Azure Data Studio verwenden (ab Version 1.18.0), um einen serverlosen SQL-Pool abzufragen. SQL-Skripts und -Notebooks werden unterstützt.
SQL Server Management Studio (SSMS) Ja Ja. Sie können SQL Server Management Studio verwenden (ab Version 18.5), um einen serverlosen SQL-Pool abzufragen. Von SSMS werden nur die in den serverlosen SQL-Pools verfügbaren Objekte angezeigt.

Hinweis

Sie können mithilfe von SSMS eine Verbindung mit einem serverlosen SQL-Pool herstellen und Abfragen durchführen. Es wird ab Version 18.5 teilweise unterstützt, kann aber nur zum Herstellen einer Verbindung und für Abfragen verwendet werden.

Die meisten Anwendungen verwenden die Transact-SQL-Standardsprache und können sowohl dedizierte als auch serverlose Verbrauchsmodelle von Synapse SQL abfragen.

Datenzugriff

Die zu analysierenden Daten können in verschiedenen Arten von Speicher gespeichert sein. In der folgenden Tabelle sind alle verfügbaren Speicheroptionen aufgeführt:

Speichertyp Dediziert Serverlos
Interner Speicher Ja Nein. Daten werden in Azure Data Lake oder im Analysespeicher von Azure Cosmos DB platziert.
Azure Data Lake v2 Ja Ja, Sie können externe Tabellen und die OPENROWSET-Funktion verwenden, um Daten aus ADLS zu lesen. Hier erfahren Sie, wie Sie die Zugriffssteuerung einrichten.
Azure Blob Storage Ja Ja, Sie können externe Tabellen und die OPENROWSET-Funktion verwenden, um Daten aus Azure Blob Storage zu lesen. Hier erfahren Sie, wie Sie die Zugriffssteuerung einrichten.
Azure SQL/SQL Server (remote) Nein Nein, der serverlose SQL-Pool kann nicht auf die Azure SQL-Datenbank verweisen. Sie können aus Azure SQL mithilfe von elastischen Abfragen oder Verbindungsservern auf serverlose SQL-Pools verweisen.
Dataverse Nein. Sie können Azure CosmosDB-Daten mithilfe von Azure Synapse Link in einem serverlosen SQL-Pool (über ADLS) oder Spark in einen dedizierten Pool laden. Ja, Sie können Dataverse-Tabellen mit Azure Synapse Link für Dataverse mit Azure Data Lake lesen.
Transaktionsspeicher von Azure Cosmos DB Nein Nein. Sie können nicht auf Azure Cosmos DB-Container zugreifen, um Daten zu aktualisieren oder Daten aus dem Azure Cosmos DB-Transaktionsspeicher zu lesen. Verwenden Sie Spark-Pools, um den Transaktionsspeicher von Azure Cosmos DB zu aktualisieren.
Analysespeicher von Azure Cosmos DB Nein, Sie können Azure CosmosDB-Daten mit Azure Synapse Link in einem serverlosen SQL-Pool (über ADLS), ADF, Spark oder einem anderen Ladetool in einen dedizierten Pool laden. Ja. Sie können den Analysespeicher von Azure Cosmos DB abfragen (mithilfe von Azure Synapse Link).
Apache Spark-Tabellen (im Arbeitsbereich) Nein Ja. Der serverlose Pool kann PARQUET- und CSV-Tabellen unter Verwendung der Metadatensynchronisierung lesen.
Apache Spark-Tabellen (Remote) Nein Nein. Der serverlose Pool kann nur auf PARQUET- und CSV-Tabellen zugreifen, die in Apache Spark-Pools im gleichen Synapse-Arbeitsbereich erstellt wurden. Sie können jedoch manuell eine externe Tabelle erstellen, die auf den Speicherort der externen Spark-Tabelle verweist.
Databricks-Tabellen (Remote) Nein Nein. Der serverlose Pool kann nur auf PARQUET- und CSV-Tabellen zugreifen, die in Apache Spark-Pools im gleichen Synapse-Arbeitsbereich erstellt wurden. Sie können jedoch manuell eine externe Tabelle erstellen, die auf den Speicherort der Databricks-Tabelle verweist.

Datenformate

Zu analysierende Daten können in verschiedenen Speicherformaten gespeichert sein. In der folgenden Tabelle sind alle für die Analyse verfügbaren Datenformate aufgeführt:

Datenformat Dediziert Serverlos
Mit Trennzeichen Ja Ja. Sie können Dateien mit Trennzeichen abfragen.
CSV Ja. (Trennzeichen mit mehreren Zeichen werden nicht unterstützt.) Ja. Sie können CSV-Dateien abfragen. Verwenden Sie zur Verbesserung der Leistung PARSER_VERSION 2.0. Diese Version bietet eine schnellere Analyse. Wenn Sie Zeilen an Ihre CSV-Dateien anfügen, achten Sie darauf, dass Sie die Dateien als erweiterbare Dateien abfragen.
Parquet Ja Ja. Sie können Parquet-Dateien abfragen – einschließlich Dateien mit geschachtelten Typen.
Hive ORC Ja Nein. Das Hive-ORC-Format kann von serverlosen SQL-Pools nicht gelesen werden.
Hive RC Ja Nein. Das Hive-RC-Format kann von serverlosen SQL-Pools nicht gelesen werden.
JSON Ja Ja. Sie können JSON-Dateien abfragen (unter Verwendung des Textformats mit Trennzeichen und der T-SQL-Funktionen vom Typ JSON).
Avro Nein Nein. Das Avro-Format kann von serverlosen SQL-Pools nicht gelesen werden.
Delta Lake Nein Ja. Sie können Delta Lake-Dateien abfragen – einschließlich Dateien mit geschachtelten Typen.
Common Data Model (CDM) Nein Nein. Daten, die unter Verwendung des Common Data Model gespeichert wurden, können von serverlosen SQL-Pools nicht gelesen werden.

Nächste Schritte

Weitere Informationen zu bewährten Methoden für dedizierte SQL-Pools und serverlose SQL-Pools finden Sie in den folgenden Artikeln: