Automatisieren von Snowpipe für Microsoft Azure Blob-Speicher¶
Unter diesem Thema finden Sie Anweisungen zum automatischen Auslösen des Ladens von Snowpipe-Daten mithilfe von Microsoft Azure Event Grid-Meldungen für Blob-Speicherereignisse. In den Anweisungen wird erläutert, wie Sie eine Ereignismeldung für den Zielpfad im Blob-Speicher erstellen, in dem Ihre Datendateien gespeichert sind.
Snowflake unterstützt die folgenden Typen von Blob-Speicherkonten:
Blob-Speicher
Data Lake Storage Gen2
General Purpose v2
Beachten Sie, dass nur Microsoft.Storage.BlobCreated
-Ereignisse das Laden von Dateien mit Snowpipe auslösen. Nur das Hinzufügen neuer Objekte zum Blob-Speicher löst diese Ereignisse aus. Das Umbenennen eines Verzeichnisses oder Objekts löst diese Ereignisse nicht aus. Snowflake unterstützt die folgenden Microsoft.Storage.BlobCreated
-APIs:
CopyBlob
PutBlob
PutBlockList
FlushWithClose
SftpCommit
Snowflake empfiehlt, nur unterstützte Ereignisse für Snowpipe zu senden, um Kosten, Ereignisrauschen und Latenz zu reduzieren.
Bei Data Lake Storage Gen2-Speicherkonten werden Microsoft.Storage.BlobCreated
-Ereignisse ausgelöst, wenn Clients die Operationen CreateFile
und FlushWithClose
verwenden. Wenn das SSH File Transfer Protocol (SFTP) verwendet wird, werden Microsoft.Storage.BlobCreated
-Ereignisse durch SftpCreate
- und SftpCommit
-Operationen ausgelöst. Die CreateFile
- oder SftpCreate
-API allein bedeutet nicht, dass eine Datei in das Speicherkonto übertragen wurde. Snowpipe erfasst die Datei nur dann, wenn die Meldung FlushWithClose
oder SftpCommit
an die Snowflake-Warteschlange gesendet wird.
Unter diesem Thema:
Unterstützung von Cloudplattformen¶
Das Auslösen automatisierter Snowpipe-Datenladevorgänge unter Verwendung von Azure Event Grid-Meldungen wird von Snowflake-Konten unterstützt, die auf unterstützten Cloudplattformen gehostet werden.
Prozessablauf¶
Microsoft Azure Event Grid-Benachrichtigungen für einen Azure-Container lösen Snowpipe-Datenladevorgänge automatisch aus.
Die folgende Abbildung veranschaulicht den Prozessablauf der automatischen Erfassung mit Snowpipe:
Datendateien werden in einen Stagingbereich geladen.
Eine Blob-Speicherereignismeldung informiert Snowpipe über Event Grid, dass Dateien ladebereit sind. Snowpipe kopiert die Dateien in eine Warteschlange.
Ein von Snowflake bereitgestelltes virtuelles Warehouse lädt Daten aus den Warteschlangendateien in die Zieltabelle, basierend auf den in der angegebenen Pipe definierten Parametern.
Anweisungen dazu finden Sie unter Automatisieren von Snowpipe für Microsoft Azure Blob-Speicher.
Konfigurieren des sicheren Zugriffs auf Cloudspeicher¶
Bemerkung
Wenn Sie bereits den sicheren Zugriff auf den Azure Blob-Speichercontainer konfiguriert haben, in dem Ihre Datendateien gespeichert sind, können Sie diesen Abschnitt überspringen.
In diesem Abschnitt wird beschrieben, wie Sie ein Snowflake-Speicherintegrationsobjekt konfigurieren, um die Authentifizierungsverantwortung für den Cloudspeicher an eine Snowflake-Entität für die Identitäts- und Zugriffsverwaltung (IAM) zu delegieren.
Bemerkung
Diese Option wird dringend empfohlen, um beim Zugriff auf Cloudspeicher keine IAM-Anmeldeinformationen angeben zu müssen. Weitere Speicherzugriffsoptionen finden Sie unter Konfigurieren eines Azure-Containers zum Laden von Daten.
In diesem Abschnitt wird beschrieben, wie Sie mit Speicherintegrationen dafür sorgen können, dass Snowflake Daten in einem Azure-Container lesen und in einen Azure-Container schreiben kann, auf den in einem externen (Azure) Stagingbereich verwiesen wird. Integrationen sind benannte First-Class-Snowflake-Objekte, bei denen keine expliziten Cloudanbieter-Anmeldeinformationen wie geheime Schlüssel oder Zugriffstoken übergeben werden müssen. Integrationsobjekte speichern die Benutzer-ID aus der Identitäts- und Zugriffsverwaltung (IAM) von Azure. Diese wird als App-Registrierung bezeichnet. Ein Administrator in Ihrer Organisation erteilt dieser App die erforderlichen Berechtigungen für das Azure-Konto.
Eine Integration muss auch Container (und optionale Pfade) angeben, um die Speicherorte einzuschränken, die Benutzer beim Erstellen externer Stagingbereiche zur Verwendung mit der Integration angeben können.
Bemerkung
Zum Ausführen der Anweisungen in diesem Abschnitt sind Berechtigungen zum Verwalten von Speicherkonten in Azure erforderlich. Wenn Sie kein Azure-Administrator sind, bitten Sie Ihren Azure-Administrator, diese Aufgaben auszuführen.
Unter diesem Thema:
Schritt 1: Cloud Storage-Integration in Snowflake erstellen¶
Erstellen Sie mit dem Befehl CREATE STORAGE INTEGRATION eine Speicherintegration. Eine Speicherintegration ist ein Snowflake-Objekt, in dem ein für Ihren Azure-Cloudspeicher generierter Dienstprinzipal zusammen mit einem optionalen Satz zulässiger oder blockierter Speicherorte (d. h. Container) gespeichert wird. Cloudanbieter-Administratoren Ihrer Organisation erteilen dem generierten Dienstprinzipal Berechtigungen für die Speicherorte. Dank dieser Option müssen Benutzer beim Erstellen von Stagingbereichen oder beim Laden von Daten keine Anmeldeinformationen eingeben.
Eine einzelne Speicherintegration kann mehrere externe (d. h. Azure) Stagingbereiche unterstützen. Die URL in der Stagingbereichsdefinition muss mit den für den Parameter STORAGE_ALLOWED_LOCATIONS angegebenen Azure-Containern (und optionalen Pfaden) übereinstimmen.
Bemerkung
Dieser SQL-Befehl kann nur von Kontoadministratoren (Benutzer mit der Rolle ACCOUNTADMIN) oder von Rollen mit der globalen Berechtigung CREATE INTEGRATION ausgeführt werden.
CREATE STORAGE INTEGRATION <integration_name>
TYPE = EXTERNAL_STAGE
STORAGE_PROVIDER = 'AZURE'
ENABLED = TRUE
AZURE_TENANT_ID = '<tenant_id>'
STORAGE_ALLOWED_LOCATIONS = ('azure://<account>.blob.core.windows.net/<container>/<path>/', 'azure://<account>.blob.core.windows.net/<container>/<path>/')
[ STORAGE_BLOCKED_LOCATIONS = ('azure://<account>.blob.core.windows.net/<container>/<path>/', 'azure://<account>.blob.core.windows.net/<container>/<path>/') ]
Wobei:
integration_name
ist der Name der neuen Integration.tenant_id
ist die ID Ihres Office 365-Mandanten, zu dem die zulässigen und gesperrten Speicherkonten gehören. Die Authentifizierung einer Speicherintegration kann nur für einen einzigen Mandanten erfolgen. Daher müssen sich die zulässigen und blockierten Speicherorte auf Speicherkonten beziehen, die alle diesem einen Mandanten gehören.Melden Sie sich beim Azure-Portal an, und klicken Sie auf Azure Active Directory » Properties, um Ihre Mandanten-ID zu ermitteln. Die Mandanten-ID wird im Feld Tenant ID angezeigt.
container
ist der Name des Azure-Containers, in dem Ihre Datendateien gespeichert sind (z. B.mycontainer
). Die Parameter STORAGE_ALLOWED_LOCATIONS und STORAGE_BLOCKED_LOCATIONS beschränken bzw. blockieren den Zugriff auf diese Container, wenn Stagingbereiche, die auf diese Integration verweisen, erstellt oder geändert werden.path
ist ein optionaler Pfad, mit dem Sie logische Verzeichnisse im Container genauer steuern können.
Im folgenden Beispiel wird eine Integration erstellt, die die externen Stagingbereiche, die die Integration verwenden, explizit darauf beschränkt, auf zwei Container oder Pfade zu verweisen: In einem späteren Schritt werden wir einen externen Stagingbereich erstellen, der auf einen dieser Container und Pfade verweist. Es können auch mehrere externe Stagingbereiche, die diese Integration verwenden, auf die zulässigen Container und Pfade verweisen:
CREATE STORAGE INTEGRATION azure_int TYPE = EXTERNAL_STAGE STORAGE_PROVIDER = 'AZURE' ENABLED = TRUE AZURE_TENANT_ID = 'a123b4c5-1234-123a-a12b-1a23b45678c9' STORAGE_ALLOWED_LOCATIONS = ('azure://myaccount.blob.core.windows.net/mycontainer1/mypath1/', 'azure://myaccount.blob.core.windows.net/mycontainer2/mypath2/') STORAGE_BLOCKED_LOCATIONS = ('azure://myaccount.blob.core.windows.net/mycontainer1/mypath1/sensitivedata/', 'azure://myaccount.blob.core.windows.net/mycontainer2/mypath2/sensitivedata/');
Schritt 2: Snowflake Zugriff auf die Speicherorte gewähren¶
Führen Sie den Befehl DESCRIBE INTEGRATION aus, um die Zustimmungs-URL abzurufen:
DESC STORAGE INTEGRATION <integration_name>;
Wobei:
integration_name
ist der Name der Integration, die Sie in Schritt 1: Cloud Storage-Integration in Snowflake erstellen erstellt haben.
Beachten Sie die Werte in den folgenden Spalten:
- AZURE_CONSENT_URL:
URL der Microsoft-Berechtigungsanforderungsseite.
- AZURE_MULTI_TENANT_APP_NAME:
Name der Snowflake-Clientanwendung, die für Ihr Konto erstellt wurde. In einem späteren Schritt in dieser Anleitung müssen Sie dieser Anwendung die erforderlichen Berechtigungen erteilen, um ein Zugriffstoken für die zulässigen Speicherorte zu erhalten.
Navigieren Sie in einem Webbrowser zu der in der Spalte AZURE_CONSENT_URL angegebenen URL. Es wird eine Microsoft-Berechtigungsanforderungsseite angezeigt.
Klicken Sie auf die Schaltfläche Accept. Mit dieser Aktion kann dem Azure-Dienstprinzipal, der für Ihr Snowflake-Konto erstellt wurde, ein Zugriffstoken für die angegebenen Ressourcen in Ihrem Mandantenbereich zugewiesen werden. Das Abrufen eines Zugriffstokens ist nur erfolgreich, wenn Sie dem Dienstprinzipal die entsprechenden Berechtigungen für den Container erteilen (siehe nächster Schritt).
Die Microsoft-Berechtigungsanforderungsseite leitet auf die Snowflake-Firmenwebsite (snowflake.com) um.
Melden Sie sich beim Microsoft Azure-Portal an.
Navigieren Sie zu Azure Services » Storage Accounts. Klicken Sie auf den Namen des Speicherkontos, auf das Sie dem Snowflake-Dienstprinzipal Zugriff gewähren.
Klicken Sie auf Access Control (IAM) » Add role assignment.
Wählen Sie die gewünschte Rolle aus, die dem Snowflake-Dienstprinzipal gewährt werden soll:
Storage Blob Data Reader
gewährt nur Lesezugriff. Dies ermöglicht das Laden von Daten aus Stagingdateien, die im Speicherkonto bereitgestellt wurden.Storage Blob Data Contributor
gewährt Lese- und Schreibzugriff. Dies ermöglicht das Laden oder Entladen von Daten in/aus Dateien, die im Speicherkonto bereitgestellt sind. Die Rolle ermöglicht auch die Ausführung des Befehls REMOVE zum Entfernen von Dateien, die im Speicherkonto bereitgestellt sind.
Suchen Sie nach dem Snowflake-Dienstprinzipal. Dies ist die Identität in der Eigenschaft AZURE_MULTI_TENANT_APP_NAME der Ausgabe von DESC STORAGE INTEGRATION (in Schritt 1). Suchen Sie in der Eigenschaft AZURE_MULTI_TENANT_APP_NAME nach der Zeichenfolge vor dem Unterstrich.
Wichtig
Es kann eine Stunde oder länger dauern, bis Azure den über die oben genannte Microsoft-Anforderungsseite angeforderten Snowflake-Dienstprinzipal erstellt hat. Wenn der Dienstprinzipal nicht sofort verfügbar ist, empfehlen wir, ein bis zwei Stunden zu warten und ihn dann erneut zu suchen.
Wenn Sie den Dienstprinzipal löschen, funktioniert die Speicherintegration nicht mehr.
Klicken Sie auf die Schaltfläche Review + assign.
Bemerkung
Gemäß der Microsoft Azure-Dokumentation kann die Weitergabe von Rollenzuweisungen bis zu fünf Minuten dauern.
Snowflake speichert die temporären Anmeldeinformationen im Cache für einen Zeitraum, der die Ablaufzeit von 60 Minuten nicht überschreiten darf. Wenn Sie den Zugriff von Snowflake widerrufen, sind Benutzer vor Ablauf des Cache möglicherweise in der Lage, Dateien auflisten und Daten vom Cloudspeicherort zu laden.
Konfigurieren der Automatisierung mit Azure Event Grid¶
Schritt 1: Konfigurieren des Event Grid-Abonnements¶
In diesem Abschnitt wird beschrieben, wie Sie unter Verwendung der Azure-CLI ein Event Grid-Abonnement für Azure Storage-Ereignisse einrichten. Weitere Informationen zu den in diesem Abschnitt beschriebenen Schritten finden Sie in den folgenden Artikeln der Azure-Dokumentation:
https://docs.microsoft.com/en-us/azure/event-grid/custom-event-to-queue-storage
https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-event-quickstart
Ressourcengruppe erstellen¶
Ein Event Grid-Thema liefert einen Endpunkt, an den die Quelle (d. h. Azure-Speicher) Ereignisse sendet. Ein Thema wird für eine Sammlung verwandter Ereignisse verwendet. Event Grid-Themen sind Azure-Ressourcen und müssen in einer Azure-Ressourcengruppe platziert werden.
Führen Sie den folgenden Befehl aus, um eine Ressourcengruppe zu erstellen:
az group create --name <resource_group_name> --location <location>
Wobei:
resource_group_name
ist der Name der neuen Ressourcengruppe.location
ist in Snowflake-Terminologie der Ort oder die Region Ihres Azure Storage-Kontos.
Event Grid-Ressourcenanbieter aktivieren¶
Führen Sie den folgenden Befehl aus, um den Event Grid-Ressourcenanbieter zu registrieren. Beachten Sie, dass dieser Schritt nur erforderlich ist, wenn Sie Event Grid mit Ihrem Azure-Konto zuvor noch nicht verwendet haben:
az provider register --namespace Microsoft.EventGrid
az provider show --namespace Microsoft.EventGrid --query "registrationState"
Speicherkonto für Datendateien erstellen¶
Führen Sie den folgenden Befehl aus, um ein Speicherkonto zum Speichern Ihrer Datendateien zu erstellen. Dieses Konto muss entweder ein Blob-Speicherkonto (d. h. ein BlobStorage
-Konto) oder ein GPv2-Konto (d. h. ein StorageV2
-Konto) sein, da nur diese beiden Kontotypen Ereignismeldungen unterstützen.
Bemerkung
Wenn Sie bereits über ein Blob-Speicherkonto oder ein GPv2-Konto verfügen, können Sie stattdessen eines dieser Konten verwenden.
Erstellen Sie beispielsweise ein Blob-Speicherkonto:
az storage account create --resource-group <resource_group_name> --name <storage_account_name> --sku Standard_LRS --location <location> --kind BlobStorage --access-tier Hot
Wobei:
resource_group_name
ist der Name der Ressourcengruppe, die Sie unter Ressourcengruppe erstellen erstellt haben.storage_account_name
ist der Name des neuen Speicherkontos.location
ist der Speicherort Ihres Azure Storage-Kontos.
Speicherkonto für die Speicherwarteschlange erstellen¶
Führen Sie den folgenden Befehl aus, um ein Speicherkonto zum Hosten Ihrer Speicherwarteschlange zu erstellen. Dieses Konto muss ein GPv2-Konto sein, da nur diese Art von Konto Ereignismeldungen an eine Speicherwarteschlange unterstützt.
Bemerkung
Wenn Sie bereits über ein GPv2-Konto verfügen, können Sie dieses Konto zum Hosten Ihrer Datendateien und Ihrer Speicherwarteschlange verwenden.
Erstellen Sie zum Beispiel ein GPv2-Konto:
az storage account create --resource-group <resource_group_name> --name <storage_account_name> --sku Standard_LRS --location <location> --kind StorageV2
Wobei:
resource_group_name
ist der Name der Ressourcengruppe, die Sie unter Ressourcengruppe erstellen erstellt haben.storage_account_name
ist der Name des neuen Speicherkontos.location
ist der Speicherort Ihres Azure Storage-Kontos.
Speicherwarteschlange erstellen¶
Eine einzelne Speicherwarteschlange kann die Ereignismeldungen für viele Event Grid-Abonnements erfassen. Für optimale Leistung empfiehlt Snowflake, eine einzelne Speicherwarteschlange zu erstellen, in der alle Ihre Abonnements für Snowflake gespeichert werden.
Führen Sie den folgenden Befehl aus, um eine Speicherwarteschlange zu erstellen. In einer Speicherwarteschlange werden Gruppen von Nachrichten gespeichert, in diesem Fall Ereignismeldungen aus Event Grid:
az storage queue create --name <storage_queue_name> --account-name <storage_account_name>
Wobei:
storage_queue_name
ist der Name der neuen Speicherwarteschlange.storage_account_name
ist der Name des Speicherkontos, das Sie unter Speicherkonto für die Speicherwarteschlange erstellen erstellt haben.
Speicherkonto- und Warteschlangen-IDs zum Verweisen exportieren¶
Führen Sie die folgenden Befehle aus, um Umgebungsvariablen für die Speicherkonto- und Warteschlangen-IDs festzulegen, die später in diesen Anweisungen angefordert werden:
Linux oder macOS:
export storageid=$(az storage account show --name <data_storage_account_name> --resource-group <resource_group_name> --query id --output tsv) export queuestorageid=$(az storage account show --name <queue_storage_account_name> --resource-group <resource_group_name> --query id --output tsv) export queueid="$queuestorageid/queueservices/default/queues/<storage_queue_name>"
Windows:
set storageid=$(az storage account show --name <data_storage_account_name> --resource-group <resource_group_name> --query id --output tsv) set queuestorageid=$(az storage account show --name <queue_storage_account_name> --resource-group <resource_group_name> --query id --output tsv) set queueid="%queuestorageid%/queueservices/default/queues/<storage_queue_name>"
Wobei:
data_storage_account_name
ist der Name des Speicherkontos, das Sie unter Speicherkonto für Datendateien erstellen erstellt haben.queue_storage_account_name
ist der Name des Speicherkontos, das Sie unter Speicherkonto für die Speicherwarteschlange erstellen erstellt haben.resource_group_name
ist der Name der Ressourcengruppe, die Sie unter Ressourcengruppe erstellen erstellt haben.storage_queue_name
ist der Name der Speicherwarteschlange, die Sie unter Speicherwarteschlange erstellen erstellt haben.
Event Grid-Erweiterung installieren¶
Führen Sie den folgenden Befehl aus, um die Event Grid-Erweiterung für die Azure-CLI zu installieren:
az extension add --name eventgrid
Event Grid-Abonnement erstellen¶
Führen Sie den folgenden Befehl aus, um das Event Grid-Abonnement zu erstellen. Durch das Abonnieren eines Themas wird Event Grid darüber informiert, welche Ereignisse verfolgt werden sollen:
Linux oder macOS:
az eventgrid event-subscription create \ --source-resource-id $storageid \ --name <subscription_name> --endpoint-type storagequeue \ --endpoint $queueid \ --advanced-filter data.api stringin CopyBlob PutBlob PutBlockList FlushWithClose SftpCommit
Windows:
az eventgrid event-subscription create \ --source-resource-id %storageid% \ --name <subscription_name> --endpoint-type storagequeue \ --endpoint %queueid% \ -advanced-filter data.api stringin CopyBlob PutBlob PutBlockList FlushWithClose SftpCommit
Wobei:
storageid
undqueueid
sind die Umgebungsvariablen für die Speicherkonto- bzw. die Warteschlangen-ID, die Sie in Speicherkonto- und Warteschlangen-IDs zum Verweisen exportieren festgelegt haben.subscription_name
ist der Name des neuen Event Grid-Abonnements.
Schritt 2: Erstellen der Benachrichtigungsintegration¶
Eine Benachrichtigungsintegration ist ein Snowflake-Objekt, das eine Schnittstelle zwischen Snowflake und dem Cloud-Nachrichtenwarteschlangendienst eines Drittanbieters wie Azure Event Grid bereitstellt.
Bemerkung
Eine einzelne Benachrichtigungsintegration unterstützt genau eine Azure Storage-Warteschlange. Wenn mehrere Benachrichtigungsintegrationen auf dieselbe Speicherwarteschlange verweisen, könnte dies zu fehlenden Daten in den Zieltabellen führen, da Ereignisbenachrichtigungen zwischen Benachrichtigungsintegrationen aufgeteilt werden. Daher wird das Erstellen einer Pipe blockiert, wenn eine Pipe auf dieselbe Speicherwarteschlange verweist wie eine bereits vorhandene Pipe.
Speicherwarteschlangen-URL und Mandanten-ID abrufen¶
Melden Sie sich beim Microsoft Azure-Portal an.
Navigieren Sie zu Storage account » Queue service » Queues. Notieren Sie die URL für die Warteschlange, die Sie unter Erstellen einer Speicherwarteschlange erstellt haben, um später darauf zu verweisen. Die URL hat das folgende Format:
https://<storage_account_name>.queue.core.windows.net/<storage_queue_name>
Navigieren Sie zu Azure Active Directory » Properties. Notieren Sie den Wert Tenant ID zum späteren Verweisen. Die Verzeichnis-ID oder Mandanten-ID wird benötigt, um die Zustimmungs-URL zu generieren, die Snowflake Zugriff auf das Event Grid-Abonnement gewährt.
Benachrichtigungsintegration erstellen¶
Erstellen Sie eine Benachrichtigungsintegration mit dem Befehl CREATE NOTIFICATION INTEGRATION.
Bemerkung
Dieser SQL-Befehl kann nur von Kontoadministratoren (Benutzer mit der Rolle ACCOUNTADMIN) oder von Rollen mit der globalen Berechtigung CREATE INTEGRATION ausgeführt werden.
Der Azure-Dienstprinzipal für Benachrichtigungsintegrationen unterscheidet sich von dem Dienstprinzipal, der für Speicherintegrationen erstellt wird.
CREATE NOTIFICATION INTEGRATION <integration_name>
ENABLED = true
TYPE = QUEUE
NOTIFICATION_PROVIDER = AZURE_STORAGE_QUEUE
AZURE_STORAGE_QUEUE_PRIMARY_URI = '<queue_URL>'
AZURE_TENANT_ID = '<directory_ID>';
Wobei:
integration_name
ist der Name der neuen Integration.queue_URL
unddirectory_ID
sind die Warteschlangen-URL bzw. die Mandanten-ID, die Sie unter Speicherwarteschlangen-URL und Mandanten-ID abrufen notiert haben.
Beispiel:
CREATE NOTIFICATION INTEGRATION my_notification_int
ENABLED = true
TYPE = QUEUE
NOTIFICATION_PROVIDER = AZURE_STORAGE_QUEUE
AZURE_STORAGE_QUEUE_PRIMARY_URI = 'https://myqueue.queue.core.windows.net/mystoragequeue'
AZURE_TENANT_ID = 'a123bcde-1234-5678-abc1-9abc12345678';
Snowflake Zugriff auf die Speicherwarteschlange gewähren¶
Beachten Sie, dass bestimmte Schritte in diesem Abschnitt eine lokale Installation der Azure-Befehlszeilenschnittestelle (CLI) erfordern.
Führen Sie den Befehl DESCRIBE INTEGRATION aus, um die Zustimmungs-URL abzurufen:
DESC NOTIFICATION INTEGRATION <integration_name>;
Wobei:
integration_name
ist der Name der Integration, die Sie unter Benachrichtigungsintegration erstellen erstellt haben.
Beachten Sie die Werte in den folgenden Spalten:
- AZURE_CONSENT_URL:
URL der Microsoft-Berechtigungsanforderungsseite.
- AZURE_MULTI_TENANT_APP_NAME:
Name der Snowflake-Clientanwendung, die für Ihr Konto erstellt wurde. In einem späteren Schritt in dieser Anleitung müssen Sie der Anwendung die erforderlichen Berechtigungen erteilen, um ein Zugriffstoken für die zulässigen Themen zu erhalten.
Navigieren Sie in einem Webbrowser zu der in der Spalte AZURE_CONSENT_URL angegebenen URL. Es wird eine Microsoft-Berechtigungsanforderungsseite angezeigt.
Klicken Sie auf die Schaltfläche Accept. Mit dieser Aktion kann der Azure-Dienstprinzipal, der für Ihr Snowflake-Konto erstellt wurde, ein Zugriffstoken für eine beliebige Ressource in Ihrem Mandantenbereich erhalten. Das Abrufen eines Zugriffstokens ist nur erfolgreich, wenn Sie dem Dienstprinzipal die entsprechenden Berechtigungen für den Container erteilen (siehe nächster Schritt).
Die Microsoft-Berechtigungsanforderungsseite leitet auf die Snowflake-Firmenwebsite (snowflake.com) um.
Melden Sie sich beim Microsoft Azure-Portal an.
Navigieren Sie zu Azure Active Directory » Enterprise applications. Überprüfen Sie, ob der Snowflake-Anwendungsbezeichner, den Sie sich in Schritt 2 in diesem Abschnitt notiert haben, aufgeführt ist.
Wichtig
Wenn Sie die Snowflake-Anwendung zu einem anderen Zeitpunkt in Azure Active Directory löschen, funktioniert die Benachrichtigungsintegration nicht mehr.
Navigieren Sie zu Queues »
storage_queue_name
, wobeistorage_queue_name
der Name der Speicherwarteschlange ist, die Sie unter Speicherwarteschlange erstellen erstellt haben.Klicken Sie auf Access Control (IAM) » Add role assignment.
Suchen Sie nach dem Snowflake-Dienstprinzipal. Dies ist die Identität in der Eigenschaft AZURE_MULTI_TENANT_APP_NAME der Ausgabe von DESC NOTIFICATION INTEGRATION (in Schritt 1). Suchen Sie in der Eigenschaft AZURE_MULTI_TENANT_APP_NAME nach der Zeichenfolge vor dem Unterstrich.
Wichtig
Es kann eine Stunde oder länger dauern, bis Azure den über die oben genannte Microsoft-Anforderungsseite angeforderten Snowflake-Dienstprinzipal erstellt hat. Wenn der Dienstprinzipal nicht sofort verfügbar ist, empfehlen wir, ein bis zwei Stunden zu warten und ihn dann erneut zu suchen.
Wenn Sie den Dienstprinzipal löschen, funktioniert die Benachrichtigungsintegration nicht mehr.
Erteilen Sie der Snowflake-App die folgenden Berechtigungen:
Role: Storage Queue Data Contributor
Assign access to: Azure-AD-Benutzer, -Gruppe oder -Dienstprinzipal
Select: Der
appDisplayName
-Wert.
Der Snowflake-Anwendungsbezeichner sollte jetzt unter Storage Queue Data Contributor (im selben Dialogfeld) aufgeführt sein.
Schritt 3: Stagingbereich erstellen (falls erforderlich)¶
Erstellen Sie mit dem Befehl CREATE STAGE einen externen Stagingbereich, der auf Ihren Azure-Container verweist. Snowpipe ruft Ihre Datendateien aus dem Stagingbereich ab und stellt sie vorübergehend in die Warteschlange, bevor sie in die Zieltabelle geladen werden.
Alternativ können Sie einen vorhandenen externen Stagingbereich verwenden.
Bemerkung
Informationen zum Konfigurieren des sicheren Zugriffs auf den Speicherort in der Cloud finden Sie unter Konfigurieren des sicheren Zugriffs auf Cloudspeicher (unter diesem Thema).
Um in der CREATE STAGE-Anweisung auf eine Speicherintegration zu verweisen, muss die Rolle über USAGE-Berechtigung für das Speicherintegrationsobjekt verfügen.
Im folgenden Beispiel wird im aktiven Schema der Benutzersitzung ein Stagingbereich mit dem Namen mystage
erstellt. Die Cloudspeicher-URL enthält den Pfad load/files
. Der Stagingbereich verweist auf eine Speicherintegration mit dem Namen my_storage_int
.
USE SCHEMA snowpipe_db.public; CREATE STAGE mystage URL = 'azure://myaccount.blob.core.windows.net/mycontainer/load/files/' STORAGE_INTEGRATION = my_storage_int;
Bemerkung
Verwenden Sie den Endpunkt blob.core.windows.net
für alle unterstützten Typen von Azure-Blob-Speicherkonten, einschließlich Data Lake Storage Gen2.
Schritt 4: Pipe mit aktivierter automatischer Erfassung erstellen¶
Erstellen Sie mit dem Befehl CREATE PIPE eine Pipe. Die Pipe definiert die Anweisung COPY INTO <Tabelle>, mit der Snowpipe Daten aus der Erfassungswarteschlange in die Zieltabelle lädt.
Erstellen Sie beispielsweise im Schema snowpipe_db.public
eine Pipe, die die Daten aus den im Stagingbereich mystage
bereitgestellten Dateien in die Tabelle mytable
lädt:
create pipe snowpipe_db.public.mypipe auto_ingest = true integration = 'MY_NOTIFICATION_INT' as copy into snowpipe_db.public.mytable from @snowpipe_db.public.mystage file_format = (type = 'JSON');
Wobei:
notification_integration_name
ist der Name der Benachrichtigungsintegration, die Sie unter Schritt 2: Erstellen der Benachrichtigungsintegration erstellt haben.
Wichtig
Der Integrationsname muss komplett in Großbuchstaben eingegeben werden.
Stellen Sie sicher, dass sich die Speicherortreferenz in der COPY INTO <Tabelle>-Anweisung nicht mit der Referenz in bestehenden Pipes des Kontos überschneidet. Andernfalls könnten mehrere Pipes denselben Satz von Datendateien in die Zieltabellen laden. Diese Situation kann beispielsweise eintreten, wenn mehrere Pipe-Definitionen auf denselben Speicherort mit unterschiedlicher Granularität verweisen, wie
<Speicherort>/path1/
und<Speicherort>/path1/path2/
. Wenn in diesem Beispiel Dateien in<Speicherort>/path1/path2/
bereitgestellt werden, würden beide Pipes eine Kopie der Dateien laden.Prüfen Sie die COPY INTO <Tabelle>-Anweisungen in den Definitionen aller Pipes des Kontos durch Ausführen von SHOW PIPES oder durch Abfragen der Ansicht PIPES in Account Usage oder der Ansicht PIPES in Information Schema.
Snowpipe mit automatischer Erfassung ist nun konfiguriert!
Wenn dem Azure-Container neue Datendateien hinzugefügt werden, weist die Ereignisbenachrichtigung Snowpipe an, diese in die in der Pipe definierte Zieltabelle zu laden.
Schritt 5: Historische Dateien laden¶
Um ein Backlog mit Datendateien zu laden, die vor der Konfiguration von Event Grid-Meldungen im externen Stagingbereich vorhanden waren, führen Sie eine ALTER PIPE … REFRESH-Anweisung aus.
Schritt 6: Stagingdateien löschen¶
Löschen Sie die Stagingdateien, nachdem Sie die Daten erfolgreich geladen haben und die Dateien nicht mehr benötigen. Eine Anleitung dazu finden Sie unter Löschen von Stagingdateien, nachdem Snowpipe die Daten geladen hat.
SYSTEM$PIPE_STATUS-Ausgabe¶
Die Funktion SYSTEM$PIPE_STATUS ruft eine JSON-Darstellung des aktuellen Status einer Pipe ab.
Bei Pipes, bei denen AUTO_INGEST auf TRUE gesetzt ist, gibt die Funktion ein JSON-Objekt zurück, das die folgenden Name/Wert-Paare enthält (falls auf den aktuellen Pipe-Status zutreffend):
{„executionState“:“<Wert>“,“oldestFileTimestamp“:<Wert>,“pendingFileCount“:<Wert>,“notificationChannelName“:“<Wert>“,“numOutstandingMessagesOnChannel“:<Wert>,“lastReceivedMessageTimestamp“:“<Wert>“,“lastForwardedMessageTimestamp“:“<Wert>“,“error“:<Wert>,“fault“:<Wert>}
Weitere Erläuterungen zu den Ausgabewerten finden Sie im Referenzthema zur SQL-Funktion.