Freigeben über

Steuern des Speicherkontozugriffs für einen serverlosen SQL-Pool in Azure Synapse Analytics

  • Artikel

Eine Abfrage eines serverlosen SQL-Pools liest Dateien direkt aus Azure Storage. Berechtigungen für den Zugriff auf Dateien in Azure Storage werden auf zwei Ebenen gesteuert:

  • Speicherebene: Der Benutzer sollte über die Berechtigung für den Zugriff auf zugrunde liegende Speicherdateien verfügen. Der Speicheradministrator oder die Speicheradministratorin muss dem Microsoft Entra-Prinzipal das Lesen/Schreiben von Dateien gestatten oder einen SAS-Schlüssel (Shared Access Signature) generieren, der für den Speicherzugriff verwendet wird.
  • SQL-Dienstebene: Benutzern müssen die Berechtigung zum Lesen von Daten mithilfe einer externen Tabelle oder zum Ausführen der Funktion OPENROWSET erteilt haben. Informationen zu den erforderlichen Berechtigungen finden Sie in diesem Abschnitt.

In diesem Artikel wird beschrieben, welche Arten von Anmeldeinformationen Sie verwenden können und wie die Suche nach Anmeldeinformationen für SQL- und Microsoft Entra-Benutzer*innen funktioniert.

Speicherberechtigungen

Ein serverloser SQL-Pool im Synapse Analytics-Arbeitsbereich kann den Inhalt der in Azure Data Lake Storage gespeicherten Dateien lesen. Sie müssen Berechtigungen für den Speicher konfigurieren, damit ein Benutzer, der eine SQL-Abfrage ausführt, die Dateien lesen kann. Es gibt drei Methoden zum Aktivieren des Zugriffs auf die Dateien:

  • Mit der rollenbasierten Zugriffssteuerung (Role Based Access Control, RBAC) können Sie einem*r Microsoft Entra-Benutzer*in in dem Mandanten, in dem sich Ihr Speicher befindet, eine Rolle zuweisen. Ein Leser muss Mitglied der Rolle „Storage Blob Data Reader“, „Storage Blob Data Contributor“ oder „Storage Blob Data Owner“ für das Speicherkonto sein. Benutzer*innen, die Daten im Azure-Speicher schreiben, müssen Mitglied der Rolle „Mitwirkender an Storage-Blobdaten“ oder „Besitzer von Storage-Blobdaten“ sein. Die Rolle „Speicherbesitzer“ impliziert nicht, dass Benutzer*innen auch „Speicherdatenbesitzer“ sind.
  • Mit Zugriffssteuerungslisten (Access Control Lists, ACL) können Sie differenzierte Berechtigungen zum Lesen (Read, R), Schreiben (Write, W) und Ausführen (Execute, X) für die Dateien und Verzeichnisse im Azure-Speicher definieren. ACL kann Microsoft Entra-Benutzern zugewiesen werden. Wenn Leser eine Datei in einem Pfad in Azure Storage lesen möchten, müssen sie über eine ACL vom Typ „Ausführen“ (X) für jeden Ordner im Dateipfad und über eine ACL vom Typ „Lesen“ (R) für die Datei verfügen. Weitere Informationen zum Festlegen von ACL-Berechtigungen auf Speicherebene
  • Eine Shared Access Signature (SAS) ermöglicht einem Leser den Zugriff auf die Dateien in Azure Data Lake Storage mithilfe des zeitlich begrenzten Tokens. Der Leser muss nicht einmal als Microsoft Entra-Benutzer*in authentifiziert sein. Das SAS-Token enthält die Berechtigungen, die dem Leser gewährt wurden, sowie den Zeitraum, in dem das Token gültig ist. Das SAS-Token ist eine gute Wahl für den zeitlich eingeschränkten Zugriff für alle Benutzer*innen, die sich nicht einmal in demselben Microsoft Entra-Mandanten befinden müssen. SAS-Token können für das Speicherkonto oder für bestimmte Verzeichnisse definiert werden. Informieren Sie sich ausführlicher über das Gewähren von eingeschränktem Zugriff auf Azure Storage-Ressourcen mithilfe von SAS (Shared Access Signature).

Alternativ können Sie Ihre Dateien öffentlich verfügbar machen, indem Sie anonymen Zugriff zulassen. Dieser Ansatz sollte NICHT verwendet werden, wenn Sie nicht öffentliche Daten besitzen.

Unterstützte Autorisierungstypen für den Speicherzugriff

Ein bei einem serverlosen SQL-Pool angemeldeter Benutzer muss für den Zugriff auf und die Abfrage von Dateien in Azure Storage autorisiert sein, wenn die Dateien nicht öffentlich verfügbar sind. Sie können vier Autorisierungstypen für den Zugriff auf nicht öffentlichen Speicher verwenden: Benutzeridentität, SAS (Shared Access Signature), Dienstprinzipal und verwaltete Identität.

Hinweis

Microsoft Entra-Passthrough ist das Standardverhalten, wenn Sie einen Arbeitsbereich erstellen.

Die Benutzeridentität (auch „Microsoft Entra-Passthrough“ genannt) ist ein Autorisierungstyp, bei dem die Identität der bei einem serverlosen SQL-Pool angemeldeten Microsoft Entra-Benutzer*innen verwendet wird, um den Datenzugriff zu autorisieren. Vor dem Zugriff auf die Daten muss der Azure Storage-Administrator oder die Azure Storage-Administratorin den Microsoft Entra-Benutzer*innnen die erforderlichen Berechtigungen erteilen. Wie in der Tabelle Unterstützte Autorisierungstypen für Datenbankbenutzer angegeben, wird dies für den SQL-Benutzertyp nicht unterstützt.

Wichtig

Ein Microsoft Entra-Authentifizierungstoken wird von den Clientanwendungen möglicherweise zwischengespeichert. Beispielsweise speichert Power BI Microsoft Entra-Token zwischen und verwendet dasselbe Token noch eine Stunde lang. Zeitintensive Abfragen können fehlschlagen, wenn das Token während der Ausführung der Abfrage abläuft. Wenn durch ein während der Abfrage ablaufendes Microsoft Entra-Zugriffstoken Abfragefehler auftreten, sollten Sie eine Umstellung auf einen Dienstprinzipal, eine verwaltete Identität oder Shared Access Signature in Erwägung ziehen.

Sie müssen Mitglied der Rolle „Besitzer von Speicherblobdaten“, „Mitwirkender an Speicherblobdaten“ oder „Leser von Speicherblobdaten“ sein, um Ihre Identität für den Zugriff auf die Daten verwenden zu können. Alternativ können Sie differenzierte ACL-Regeln für den Zugriff auf Dateien und Ordner angeben. Auch wenn Sie Besitzer eines Speicherkontos sind, müssen Sie sich selbst zu einer der Rollen für den Zugriff auf Storage-Blobdaten hinzufügen. Weitere Informationen zur Zugriffssteuerung in Azure Data Lake Storage Gen2 finden Sie im Artikel Zugriffssteuerung in Azure Data Lake Storage Gen2.

Mandantenübergreifende Szenarios

Wenn sich Azure Storage in einem anderen Mandanten als der serverlose Synapse-SQL-Pool befindet, wird die Autorisierung über den Dienstprinzipal empfohlen. SAS-Autorisierung ist ebenfalls möglich, während die verwaltete Identität nicht unterstützt wird.

Autorisierungstyp Per Firewall geschützter Speicher Nicht durch Firewall geschützter Speicher
SAS Unterstützt Unterstützt
Dienstprinzipal Nicht unterstützt Unterstützt

Hinweis

Wenn Azure Storage durch eine Azure Storage-Firewall geschützt ist, wird der Dienstprinzipal nicht unterstützt.

Unterstützte Autorisierungstypen für Datenbankbenutzer

Die folgende Tabelle enthält verfügbare Azure Storage-Autorisierungstypen für verschiedene Anmeldemethoden bei einem serverlosen SQL-Endpunkt von Azure Synapse Analytics:

Autorisierungstyp SQL-Benutzer Microsoft Entra-Benutzer*innen Dienstprinzipal
Benutzeridentität Nicht unterstützt Unterstützt Unterstützt
SAS Unterstützt Unterstützt Unterstützt
Dienstprinzipal Unterstützt Unterstützt Unterstützt
Verwaltete Identität Unterstützt Unterstützt Unterstützt

Unterstützte Speicher- und Autorisierungstypen

Sie können die folgenden Kombinationen von Autorisierungstypen und Azure Storage-Typen verwenden:

Autorisierungstyp Blob Storage ADLS Gen1 ADLS Gen2
SAS Unterstützt Nicht unterstützt Unterstützt
Dienstprinzipal Unterstützt Unterstützt Unterstützt
Verwaltete Identität Unterstützt Unterstützt Unterstützt
Benutzeridentität Unterstützt Unterstützt Unterstützt

Mandantenübergreifende Szenarios

Wenn sich Azure Storage in einem anderen Mandanten als der serverlose Azure Synapse Analytics-SQL-Pool befindet, wird die Autorisierung über den Dienstprinzipal empfohlen. Die SAS- (Shared Access Signaturen)-Autorisierung ist ebenfalls möglich. Die verwaltete Dienstidentität wird nicht unterstützt.

Autorisierungstyp Per Firewall geschützter Speicher Nicht durch Firewall geschützter Speicher
SAS Unterstützt Unterstützt
Dienstprinzipal Nicht unterstützt Unterstützt

Hinweis

Wenn Azure Storage durch eine Azure Storage-Firewall geschützt ist und sich in einem anderen Mandanten befindet, wird der Dienstprinzipal nicht unterstützt. Verwenden Sie stattdessen SAS (Shared Access Signature).

Per Firewall geschützter Speicher

Sie können Speicherkonten so konfigurieren, dass der Zugriff auf einen bestimmten serverlosen SQL-Pool zulässig ist, indem Sie eine Ressourceninstanzregel erstellen. Zum Zugriff auf Speicher, der durch die Firewall geschützt ist, verwenden Sie die Benutzeridentität oder die verwaltete Identität.

Hinweis

Das Firewallfeature in Azure Storage befindet sich in der Public Preview-Phase und ist in allen öffentlichen Cloudregionen verfügbar.

Die folgende Tabelle enthält verfügbare durch eine Firewall geschützte Azure Storage-Autorisierungstypen für verschiedene Anmeldemethoden bei einem serverlosen SQL-Endpunkt von Azure Synapse Analytics:

Autorisierungstyp SQL-Benutzer Microsoft Entra-Benutzer*innen Dienstprinzipal
Benutzeridentität Nicht unterstützt Unterstützt Unterstützt
SAS Nicht unterstützt Nicht unterstützt Nicht unterstützt
Dienstprinzipal Nicht unterstützt Nicht unterstützt Nicht unterstützt
Verwaltete Identität Unterstützt Unterstützt Unterstützt

Für den Zugriff auf den durch die Firewall geschützten Speicher über die Benutzeridentität können Sie die Benutzeroberfläche des Microsoft Azure-Portals oder das PowerShell-Modul „Az.Storage“ verwenden.

Azure Storage-Firewallkonfiguration über das Azure-Portal

  1. Suchen Sie Ihr neues Speicherkonto im Azure-Portal.
  2. Wechseln Sie im Hauptnavigationsmenü unter Einstellungen zu Netzwerk.
  3. Fügen Sie im Abschnitt Ressourceninstanzen eine Ausnahme für Ihren Azure Synapse-Arbeitsbereich hinzu.
  4. Wählen Sie Microsoft.Synapse/workspaces als Ressourcentyp aus.
  5. Wählen Sie den Namen des Arbeitsbereichs als Instanznamen aus.
  6. Wählen Sie Speichern aus.

Azure Storage-Firewallkonfiguration über das PowerShell

Führen Sie diese Schritte aus, um das Speicherkontozu konfigurieren und eine Ausnahme für den Azure Synapse-Arbeitsbereich hinzuzufügen.

  1. Öffnen Sie PowerShell, oder installieren Sie PowerShell.

  2. Installieren Sie die neuesten Versionen des Moduls „Az.Storage“ und des Moduls „Az.Synapse“, z. B. im folgenden Skript:

    Install-Module -Name Az.Storage -RequiredVersion 3.4.0
Install-Module -Name Az.Synapse -RequiredVersion 0.7.0

    Wichtig

    Stellen Sie sicher, dass Sie mindestens Version 3.4.0 verwenden. Ihre Az.Storage-Version können Sie mithilfe des folgenden Befehls überprüfen:

    Get-Module -ListAvailable -Name Az.Storage | Select Version

  3. Stellen Sie eine Verbindung mit Ihrem Azure-Mandanten her:

    Connect-AzAccount

  4. Definieren Sie Variablen in PowerShell:

    • Ressourcengruppenname: Sie finden diesen Namen im Azure-Portal in der Übersicht Ihres Speicherkontos.
    • Kontoname: Name des Speicherkontos, das durch Firewallregeln geschützt wird
    • Mandanten-ID: Sie finden diese ID im Azure-Portal in Microsoft Entra ID unter Eigenschaften in Mandanteneigenschaften.
    • Arbeitsbereichname: Name des Azure Synapse-Arbeitsbereichs.
        $resourceGroupName = "<resource group name>"
    $accountName = "<storage account name>"
    $tenantId = "<tenant id>"
    $workspaceName = "<Azure Synapse workspace name>"

    $workspace = Get-AzSynapseWorkspace -Name $workspaceName
    $resourceId = $workspace.Id
    $index = $resourceId.IndexOf("/resourceGroups/", 0)
    # Replace G with g - /resourceGroups/ to /resourcegroups/
    $resourceId = $resourceId.Substring(0,$index) + "/resourcegroups/" ` 
        + $resourceId.Substring($index + "/resourceGroups/".Length)

    $resourceId

    Wichtig

    Der Wert von $resourceid, der vom PowerShell-Skript zurückgegeben wird, muss dieser Vorlage entsprechen: /subscriptions/{subscription-id}/resourcegroups/{resource-group}/providers/Microsoft.Synapse/workspaces/{name-of-workspace} Es ist wichtig, resourcegroups in Kleinbuchstaben zu schreiben.

  5. Fügen Sie eine Netzwerkregel für das Azure-Speicherkonto hinzu:

        $parameters = @{
        ResourceGroupName = $resourceGroupName
        Name = $accountName
        TenantId = $tenantId 
        ResourceId = $resourceId
    }

    Add-AzStorageAccountNetworkRule @parameters

  6. Vergewissern Sie sich, dass die Netzwerkregel des Speicherkontos in Ihrer Speicherkontofirewall angewendet wurde. Das folgende PowerShell-Skript vergleicht die Variable $resourceid aus den vorherigen Schritten mit der Ausgabe der Netzwerkregel des Speicherkontos.

        $parameters = @{
        ResourceGroupName = $resourceGroupName
        Name = $accountName
    }

    $rule = Get-AzStorageAccountNetworkRuleSet @parameters
    $rule.ResourceAccessRules | ForEach-Object { 
        if ($_.ResourceId -cmatch "\/subscriptions\/(\w\-*)+\/resourcegroups\/(.)+") { 
            Write-Host "Storage account network rule is successfully configured." -ForegroundColor Green
            $rule.ResourceAccessRules
        } else {
            Write-Host "Storage account network rule is not configured correctly. Remove this rule and follow the steps in detail." -ForegroundColor Red
            $rule.ResourceAccessRules
        }
    }

Anmeldeinformationen

Um eine Datei in Azure Storage abzufragen, benötigt der Endpunkt für Ihren serverlosen SQL-Pool Anmeldeinformationen, die die Authentifizierungsinformationen enthalten. Es werden zwei Arten von Anmeldeinformationen verwendet:

  • Anmeldeinformationen auf Serverebene werden für Ad-hoc-Abfragen verwendet, die mit der OPENROWSET-Funktion ausgeführt werden. Der Name der Anmeldeinformationen muss mit der Speicher-URL identisch sein.
  • Datenbankbezogene Anmeldeinformationen werden für externe Tabellen verwendet. Eine externe Tabelle verweist mit der Anmeldeinformation auf DATA SOURCE, die für den Speicherzugriff verwendet werden soll.

Erteilen von Berechtigungen zum Verwalten von Anmeldeinformationen

So erteilen Sie die Berechtigung, Anmeldeinformationen zu verwalten:

  • Damit Benutzer*innen Anmeldeinformationen auf Serverebene erstellen oder löschen können, müssen Administrator*innen den entsprechenden Anmeldungen die Berechtigung ALTER ANY CREDENTIAL in der Masterdatenbank erteilen. Beispiel:

    GRANT ALTER ANY CREDENTIAL TO [login_name];

  • Damit Benutzer*innen Anmeldeinformationen auf Datenbankebene erstellen oder löschen können, müssen Administrator*innen den entsprechenden Datenbankbenutzer*innen in der Benutzerdatenbank die Berechtigung CONTROL für die Datenbank erteilen. Beispiel:

    GRANT CONTROL ON DATABASE::[database_name] TO [user_name];

Erteilen von Berechtigungen zur Verwendung einer Anmeldeinformation

Datenbankbenutzer, die auf den externen Speicher zugreifen, müssen über die Berechtigung zur Verwendung von Anmeldeinformationen verfügen. Um eine Anmeldeinformation verwenden zu können, müssen Benutzer*innen über die Berechtigung REFERENCES für diese Anmeldeinformation verfügen.

Um Anmeldungen die Berechtigung REFERENCES auf Serverebene zu erteilen, verwenden Sie die folgende T-SQL-Abfrage in der Masterdatenbank:

GRANT REFERENCES ON CREDENTIAL::[server-level_credential] TO [login_name];

Um Datenbankbenutzer*innen die Berechtigung REFERENCES auf Datenbankebene zu erteilen, verwenden Sie die folgende T-SQL-Abfrage in der Benutzerdatenbank:

GRANT REFERENCES ON DATABASE SCOPED CREDENTIAL::[database-scoped_credential] TO [user_name];

Anmeldeinformation auf Serverebene

Anmeldeinformationen auf Serverebene werden verwendet, wenn eine SQL-Anmeldung die OPENROWSET-Funktion ohne DATA_SOURCE aufruft, um Dateien in einem Speicherkonto zu lesen.

Der Name der Anmeldeinformationen auf Serverebene muss mit der Basis-URL des Azure-Speichers übereinstimmen – optional gefolgt von einem Containernamen. Eine Anmeldeinformation wird durch Ausführen von CREATE CREDENTIAL hinzugefügt. Sie müssen das Argument CREDENTIAL NAME angeben.

Hinweis

Das Argument FOR CRYPTOGRAPHIC PROVIDER wird nicht unterstützt.

Der Name der Anmeldeinformationen auf Serverebene muss dem folgenden Format entsprechen: <prefix>://<storage_account_path>[/<container_name>]. Die Speicherkontopfade sind in der folgenden Tabelle aufgeführt:

Externe Datenquelle Präfix Speicherkontopfad
Azure Blob Storage https <storage_account>.blob.core.windows.net
Azure Data Lake Storage Gen1 https <storage_account>.azuredatalakestore.net/webhdfs/v1
Azure Data Lake Storage Gen2 https <storage_account>.dfs.core.windows.net

Anmeldeinformationen auf Serverebene können dann mithilfe der folgenden Authentifizierungstypen auf den Azure-Speicher zugreifen:

Microsoft Entra-Benutzer*innen können auf jede Datei in Azure Storage zugreifen, wenn sie Mitglieder der Rollen „Besitzer von Speicherblobdaten“, „Mitwirkender an Storage-Blobdaten“ oder „Storage-Blobdatenleser“ sind. Microsoft Entra-Benutzer*innen benötigen keine Anmeldeinformationen für den Zugriff auf den Speicher.

Authentifizierte SQL-Benutzer*innen können die Microsoft Entra-Authentifizierung nicht für den Zugriff auf den Speicher verwenden. Sie können mithilfe von verwalteter Identität, SAS-Schlüssel oder Dienstprinzipal über Datenbankanmeldeinformationen auf den Speicher zugreifen oder wenn der Speicher öffentlich zugänglich ist.

Datenbankbezogene Anmeldeinformationen

Datenbankbezogene Anmeldeinformationen werden verwendet, wenn ein Prinzipal die OPENROWSET-Funktion mit DATA_SOURCE aufruft oder Daten aus externen Tabellen auswählt, die nicht auf öffentliche Dateien zugreifen. Die datenbankbezogenen Anmeldeinformationen müssen nicht mit dem Namen des Speicherkontos übereinstimmen, da in DATA SOURCE, die den Speicherort des Speichers definiert, darauf verwiesen wird.

Datenbankbezogene Anmeldeinformationen ermöglichen den Zugriff auf den Azure-Speicher mithilfe der folgenden Authentifizierungstypen:

Microsoft Entra-Benutzer*innen können auf jede Datei in Azure Storage zugreifen, wenn sie Mitglieder der Rollen „Besitzer von Speicherblobdaten“, „Mitwirkender an Storage-Blobdaten“ oder „Storage-Blobdatenleser“ sind. Microsoft Entra-Benutzer*innen benötigen keine Anmeldeinformationen für den Zugriff auf den Speicher.

CREATE EXTERNAL DATA SOURCE mysample
WITH (    LOCATION   = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>'
)

Authentifizierte SQL-Benutzer*innen können die Microsoft Entra-Authentifizierung nicht für den Zugriff auf den Speicher verwenden. Sie können mithilfe von verwalteter Identität, SAS-Schlüssel oder Dienstprinzipal über Datenbankanmeldeinformationen auf den Speicher zugreifen oder wenn der Speicher öffentlich zugänglich ist.

Datenbankbezogene Anmeldinformationen werden in externen Datenquellen verwendet, um anzugeben, welche Authentifizierungsmethode für den Zugriff auf diesen Speicher verwendet werden soll:

CREATE EXTERNAL DATA SOURCE mysample
WITH (    LOCATION   = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>',
          CREDENTIAL = <name of database scoped credential> 
)

Beispiele

Zugreifen auf eine öffentlich verfügbare Datenquelle

Verwenden Sie das folgende Skript, um eine Tabelle zu erstellen, die auf eine öffentlich verfügbare Datenquelle zugreift.

CREATE EXTERNAL FILE FORMAT [SynapseParquetFormat]
       WITH ( FORMAT_TYPE = PARQUET)
GO
CREATE EXTERNAL DATA SOURCE publicData
WITH ( LOCATION = 'https://<storage_account>.dfs.core.windows.net/<public_container>/<path>' )
GO

CREATE EXTERNAL TABLE dbo.userPublicData ( [id] int, [first_name] varchar(8000), [last_name] varchar(8000) )
WITH ( LOCATION = 'parquet/user-data/*.parquet',
       DATA_SOURCE = [publicData],
       FILE_FORMAT = [SynapseParquetFormat] )

Der Datenbankbenutzer kann den Inhalt der Dateien aus der Datenquelle mithilfe einer externen Tabelle oder der OPENROWSET-Funktion lesen, die auf die Datenquelle verweist:

SELECT TOP 10 * FROM dbo.userPublicData;
GO
SELECT TOP 10 * FROM OPENROWSET(BULK 'parquet/user-data/*.parquet',
                                DATA_SOURCE = 'mysample',
                                FORMAT='PARQUET') as rows;
GO

Zugreifen auf eine Datenquelle mithilfe von Anmeldeinformationen

Ändern Sie das folgende Skript, um eine externe Tabelle zu erstellen, die mit dem SAS-Token, der Microsoft Entra-Identität des Benutzers oder der Benutzerin oder der verwalteten Identität des Arbeitsbereichs auf den Azure-Speicher zugreift.

-- Create master key in databases with some password (one-off per database)
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong password>'
GO

-- Create databases scoped credential that use Managed Identity, SAS token or service principal. User needs to create only database-scoped credentials that should be used to access data source:

CREATE DATABASE SCOPED CREDENTIAL WorkspaceIdentity
WITH IDENTITY = 'Managed Identity'
GO
CREATE DATABASE SCOPED CREDENTIAL SasCredential
WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = 'sv=2019-10-1********ZVsTOL0ltEGhf54N8KhDCRfLRI%3D'
GO
CREATE DATABASE SCOPED CREDENTIAL SPNCredential WITH
IDENTITY = '**44e*****8f6-ag44-1890-34u4-22r23r771098@https://login.microsoftonline.com/**do99dd-87f3-33da-33gf-3d3rh133ee33/oauth2/token' 
, SECRET = '.7OaaU_454azar9WWzLL.Ea9ePPZWzQee~'
GO
-- Create data source that one of the credentials above, external file format, and external tables that reference this data source and file format:

CREATE EXTERNAL FILE FORMAT [SynapseParquetFormat] WITH ( FORMAT_TYPE = PARQUET)
GO

CREATE EXTERNAL DATA SOURCE mysample
WITH ( LOCATION = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>'
-- Uncomment one of these options depending on authentication method that you want to use to access data source:
--,CREDENTIAL = WorkspaceIdentity 
--,CREDENTIAL = SasCredential 
--,CREDENTIAL = SPNCredential
)

CREATE EXTERNAL TABLE dbo.userData ( [id] int, [first_name] varchar(8000), [last_name] varchar(8000) )
WITH ( LOCATION = 'parquet/user-data/*.parquet',
       DATA_SOURCE = [mysample],
       FILE_FORMAT = [SynapseParquetFormat] );

Der Datenbankbenutzer kann den Inhalt der Dateien aus der Datenquelle mithilfe einer externen Tabelle oder der OPENROWSET-Funktion lesen, die auf die Datenquelle verweist:

SELECT TOP 10 * FROM dbo.userdata;
GO
SELECT TOP 10 * FROM OPENROWSET(BULK 'parquet/user-data/*.parquet', DATA_SOURCE = 'mysample', FORMAT='PARQUET') as rows;
GO

Nächste Schritte

In diesen Artikeln finden Sie wichtige Informationen dazu, wie Sie verschiedene Arten von Ordnern und Dateien abfragen und Sichten erstellen und verwenden: