Snowflake-Stagingbereiche mit Diensten verwenden¶

Bemerkung

Die Verwendung von Snowflake Staging-Volumes mit Diensten ist derzeit für Konten in Google Cloud nicht verfügbar.

Snowflake unterstützt verschiedene Arten von Speicher-Volumes für Ihre Anwendungs-Container, einschließlich interner Stagingbereiche, lokaler Speicher, Speicher und Blockspeicher-Volumes. In diesem Abschnitt wird erklärt, wie Sie Volumes und Volume-Einhängungen für interne Stagingbereiche konfigurieren.

Stagingbereich-Volumes bieten Ihrem Service Zugriff auf interne Stagingbereiche durch Verwendung von FileSystem-APIs. Das vereinfacht Ihren Code im Vergleich zur Verwendung eines Snowflake-Treibers und der Befehle GET und PUT SQL.

Stagingbereich-Volumes können für Szenarien mit Streaming-Lese- oder Schreibvorgängen großer Datendateien ebenfalls eine höhere Performance bieten. Stagingbereich-Volumes funktionieren am besten, wenn die Anwendung das Stagingbereich-Volume als praktische alternative API für Stagingbereiche verwendet, anstatt ein voll funktionsfähiges Dateisystem zu erwarten.

Derzeit gibt es zwei Implementierungen von Stagingbereich-Volumes: die allgemein verfügbare Version und eine neuere Version, die sich derzeit in der Vorschau befindet.

Allgemeine Informationen zur Implementierung der neuen Stagingbereich-Volumes¶

Die allgemein verfügbare Stagingbereich-Volume-Implementierung verwendet einen gemeinsamen Cache für Lese- und Schreibvorgänge. Obwohl dies für einige Szenarien gut funktioniert, können Sie nicht kontrollieren, ob die Daten aus dem Cache oder direkt aus dem Stagingbereich gelesen werden, was möglicherweise nicht für alle Anwendungen geeignet ist. Wenn Sie den Cache für Lese- und Schreibvorgänge verwenden, kann dies außerdem zusätzlichen Leistungsaufwand verursachen.

Die neue Stagingbereich-Volume-Implementierung, die sich derzeit in der Vorschau befindet, verwendet nur ein begrenztes In-Memory-Caching. Dies führt zu besser vorhersehbaren Verhaltensweisen und einem deutlich schnelleren Durchsatz. Diese Version wird schließlich die derzeitige, allgemein verfügbare Implementierung ersetzen. Snowflake empfiehlt, diese Vorschauversion zu evaluieren, es sei denn, Ihre Workload erfordert zufällige Schreibvorgänge oder Dateianhänge, die derzeit nicht unterstützt werden.

Beachten Sie die folgenden zusätzlichen Hinweise, wenn Sie die neue Stagingbereich-Volume-Implementierung verwenden:

Sie ist für große, sequenzielle Lese- und Schreibvorgänge optimiert und bietet bei diesen Zugriffsmustern eine starke Performance. Die besten Ergebnisse erzielen Sie, wenn Sie Daten in großen, zusammenhängenden Blöcken lesen und schreiben.
Die Performance bei zufälligen Lesevorgängen kann bei der neuen Implementierung geringer sein, da das Caching entfernt wurde. Ohne einen lokalen Festplattencache wird die Konsistenz zwischen Volumes jedoch verbessert. Dateiänderungen werden beim Schließen der Datei direkt in den unterstützenden Stagingbereich geschrieben, ohne dass eine lokale Festplattenpufferung erfolgt.
Lesevorgänge geben immer die neuesten Daten zurück, sodass sich diese Konfiguration besser für das Data Sharing zwischen Services eignet.
Zufällige Schreibvorgänge oder Anhänge von Dateien werden nicht unterstützt. Der Versuch, diese Vorgänge auszuführen, führt zu einem Fehler.

Ein Snowflake-Stagingbereich-Volume in einer Service-Spezifikation angeben¶

Zum Erstellen eines Service, bei dem Service-Container ein Snowflake-Stagingbereich-Volume verwenden, geben Sie die erforderlichen Einstellungen in der Service-Spezifikation wie in den folgenden Schritten gezeigt an:

Zur Angabe des Stagingbereich-Volume verwenden Sie das Feld spec.volumes.
- Verwenden Sie die allgemein verfügbare Version der Stagingbereich-Volume-Implementierung, wie im folgenden Beispiel gezeigt:
  volumes: - name: <name> source: <stage_name>
  Copy
  Die folgenden Felder sind erforderlich:
  - name: Eindeutiger Name des Volumes.
  - source: Der interne Snowflake-Stagingbereich oder der einzubindende Ordner im Stagingbereich, z. B. @my_stage, @my_stage/folder. Dieser Wert muss von Anführungszeichen umgeben sein.
- Verwenden Sie die neue Vorschauversion der Stagingbereich-Volume-Implementierung, wie im folgenden Beispiel gezeigt:
  volumes: - name: <name> source: stage stageConfig: name: <stage_name>
  Copy
  Die folgenden Felder sind erforderlich:
  - name: Eindeutiger Name des Volumes.
  - source: Identifiziert den Typ des Volume (stage).
  - stageConfig: Identifiziert den internen Stagingbereich von Snowflake oder den Ordner im einzubindenden Stagingbereich, z. B. @my_stage, @my_stage/folder oder @my_db.my_schema.my_stage/folder/nestedfolder. Dieser Wert muss von doppelten Anführungszeichen umgeben sein.
Verwenden Sie das Feld spec.containers.volumeMounts, um zu beschreiben, wo das Stagingbereich-Volume in Ihren Anwendungscontainern eingebunden werden soll, wie im folgenden Beispiel gezeigt:
```
volumeMounts:
- name: <name>
  mountPath: <absolute_directory_path>
```
Copy
Die Angaben, die Sie in diesem Feld machen, sind für alle unterstützten Speicher-Volume-Typen konsistent und gelten für beide Implementierungen von Stagingbereich-Volumes.

Beispiel¶

Diese Beispiele veranschaulichen den Unterschied zwischen dem Einbinden eines Snowflake-Stagingbereichs unter Verwendung des vorhandenen und des neuen Stagingbereich-Volumes. In der beispielhaften Service-Spezifikation bindet der app-Container einen internen Stagingbereich @model_stage ein, indem sowohl die bestehenden als auch die neuen Implementierungen von Stagingbereich-Volumes verwendet werden.

Die @model-legacy-Konfiguration des Stagingbereich-Volume weist Snowflake an, die allgemein verfügbare Implementierung des Stagingbereich-Volume zu verwenden.
Die @model-new-Konfiguration des Stagingbereich-Volume gibt das Feld stageConfig an, das Snowflake anweist, die Vorschauimplementierung des Stagingbereich-Volume zu verwenden.

spec:
  containers:
  - name: app
    image: <image1-name>
    volumeMounts:
    - name: models-legacy
      mountPath: /opt/model-legacy
    - name: models-new
      mountPath: /opt/model-new
  volumes:
  - name: models-legacy
    source: "@model_stage"
  - name: models-new
    source: stage
    stageConfig:
      name: "@model_stage"

Copy

Das Feld volumeMounts gibt an, wo innerhalb des Containers das Stagingbereich-Volume eingebunden werden soll. Diese Spezifikation bleibt für die beiden Stagingbereich-Volume-Implementierungen gleich.

Anforderungen an die Zugriffssteuerung¶

Die Rolle des Eigentümers des Dienstes ist die Rolle, mit der der Dienst erstellt wird. Es ist auch die Rolle, die die Dienste bei der Interaktion mit Snowflake verwenden. Diese Eigentümerrolle legt die Berechtigungen fest, die Anwendungs-Containern für den Zugriff auf einen gemounteten Stagingbereich gewährt werden. Der Eigentümer muss über die READ-Berechtigung für den Stagingbereich verfügen.

Wenn die Eigentümerrolle nicht die WRITE-Berechtigung für einen Stagingbereich hat, ist die Einbindung für diesen Stagingbereich schreibgeschützt. Das heißt, die Container können die Dateien nur aus dem Stagingbereich lesen. Die Rolle des Eigentümers benötigt die WRITE-Berechtigung auf einem Stagingbereich, damit das Staging-Mount sowohl Lese- als auch Schreibzugriffe unterstützt.

Richtlinien bei der Verwendung von Stagingbereich-Volumes¶

Dieser Abschnitt enthält Richtlinien, die Sie bei der Implementierung von Anwendungscode befolgen müssen, in dem Container Stagingbereich-Volumes verwenden.

Gemeinsame Richtlinien für beide Implementierungen von Stagingbereich-Volumes¶

Der Stagingbereich ist für sequentielles Lesen und Schreiben optimiert.
E/A-Operationen im Stagingbereich können höhere Latenzen aufweisen als E/A-Operationen auf dem Dateisystem und den Blockspeicher-Volumes des Containers. Sie sollten immer den Statuscode von E/A-Operationen überprüfen, um sicherzustellen, dass sie erfolgreich waren.
Im Stagingbereich werden Uploaddateien asynchron aktualisiert. Änderungen an Dateien auf einem Stagingbereich werden erst dann garantiert, wenn der Datei-Deskriptor erfolgreich geschlossen oder geleert wurde. Es kann eine gewisse Verzögerung geben, bevor die Änderungen an Dateien in einem Stagingbereich für andere Container und Snowflake sichtbar werden.
Jedes Verzeichnis in einem gemounteten Stagingbereich sollte weniger als 100.000 Dateien enthalten. Rechnen Sie damit, dass die Latenz von readdir mit der Anzahl der Dateien im Verzeichnis zunimmt.

Richtlinien bei der Verwendung der allgemein verfügbaren Version der Stagingbereich-Volume-Implementierung¶

Vermeiden Sie das gleichzeitige Schreiben in mehrere Dateien innerhalb eines Stagingbereichs.
Der Stagingbereich ist kein Netzwerkdateisystem. Verwenden Sie keine Stagingbereiche für die Koordination mehrerer Clients.
Öffnen Sie nicht mehrere Handles für dieselbe Datei gleichzeitig. Verwenden Sie geöffnete Datei-Handles entweder für Lese- oder für Schreiboperationen, aber nicht für eine Mischung aus beidem. Um aus einer Datei zu lesen, nachdem Sie in sie geschrieben haben, schließen Sie die Datei und öffnen Sie sie dann erneut, bevor Sie lesen.

Richtlinien bei der Verwendung der neuen Vorschauversion der Stagingbereich-Volume-Implementierung¶

Gleichzeitige Schreibvorgänge auf dieselbe Datei aus mehreren Stagingbereichen (dasselbe Stagingbereich-Volume in verschiedenen Containern) werden nicht empfohlen.
Das Fehlen eines lokalen Festplattencaches verbessert die Konsistenz zwischen Einbindungen. Dateiänderungen werden beim Schließen der Datei direkt in den unterstützenden Stagingbereich geleert, ohne dass eine lokale Festplattenpufferung erfolgt. Lesevorgänge geben immer die neuesten Daten zurück, sodass sich die neue Einbindung von Stagingbereichen besser für das Data Sharing zwischen Services eignet.
Die optimalen Ergebnisse erzielen Sie, wenn Sie Daten in großen, zusammenhängenden Blöcken lesen und schreiben. Die Leistungseinbußen bei kleinen Lese- und Schreibvorgängen im Vergleich zur allgemein verfügbaren Stagingbereich-Volume-Implementierung können die Performancegewinne der neuen Implementierung abschwächen.

Einschränkungen bei der Verwendung von Stagingbereich-Volumes¶

In diesem Abschnitt werden die Einschränkungen beschrieben, die Sie bei der Implementierung von Anwendungscode beachten sollten, in dem Container Stagingbereich-Volumes verwenden. Wenn Sie Probleme mit diesen Beschränkungen haben, wenden Sie sich an Ihren Kundenbetreuer.

Gemeinsame Einschränkungen für beide Implementierungen von Stagingbereich-Volumes¶

Sie können nur einen Stagingbereich oder ein Unterverzeichnis in einen Stagingbereich einbinden, z. B. @my_stage, @my_stage/folder. Sie können keine einzelne Datei in einen Stagingbereich einbinden, z. B. @my_stage/folder.
Externe Stagingbereiche werden nicht unterstützt. Es werden nur Snowflake-interne Stagingbereiche unterstützt.
Pro Service sind maximal 5 Stagingbereich-Volumes erlaubt. Weitere Informationen dazu finden Sie unter spec.volumes.
Es werden maximal 8 Staging-Volumess pro Computepool-Knoten unterstützt. Snowflake verwaltet die Beschränkung des Stagingbereichs pro Knoten ähnlich wie Speicher, CPU und GPU. Das Starten einer neuen Dienstinstanz kann Snowflake dazu veranlassen, neue Knoten zu starten, wenn keine vorhandenen Knoten die Kapazität haben, den angeforderten Stagingbereich zu unterstützen.
Stagingbereiche sind nicht vollständig POSIX-kompatible Dateisysteme. Beispiel:
- Dateien und Verzeichnisse werden nicht atomar umbenannt.
- Harte Links werden nicht unterstützt.
Das Linux-Kernel-Subsystem inode notify (inotify), das Änderungen an Dateisystemen überwacht, funktioniert nicht im Stagingbereich.

Einschränkungen bei der Verwendung der allgemein verfügbaren Version der Stagingbereich-Volume-Implementierung¶

Die Funktionen für Stagingbereich-Volumes variieren je nach Cloudplattform für Ihr Snowflake-Konto:
- Konten auf AWS unterstützen interne Stagingbereiche sowohl mit SNOWFLAKE_FULL- als auch mit SNOWFLAKE_SSE-Stagingbereich-Verschlüsselung. Weitere Informationen dazu finden Sie unter Parameter für interne Stagingbereiche.
- Konten auf Azure unterstützen derzeit interne Stagingbereiche mit SNOWFLAKE_SSE-Verschlüsselung Verwenden Sie bei der Ausführung von CREATE STAGE den Parameter ENCRYPTION zur Angabe des Verschlüsselungstyps: CREATE STAGE my_stage ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');
- Konten auf Google Cloud werden nicht unterstützt.
Gleichzeitige Schreibvorgänge auf dieselbe Datei aus mehreren Stagingbereichen (dasselbe Stagingbereich -Volume in verschiedenen Containern) werden nicht unterstützt.

Einschränkungen bei der Verwendung der neuen Vorschauversion der Stagingbereich-Volume-Implementierung¶

Die Funktionen für Stagingbereich-Volumes variieren je nach Cloudplattform für Ihr Snowflake-Konto:
- Konten auf AWS unterstützen interne Stagingbereiche sowohl mit SNOWFLAKE_FULL- als auch mit SNOWFLAKE_SSE-Stagingbereich-Verschlüsselung (siehe Parameter für interne Stagingbereiche).
- Konten auf Azure und Google Cloud unterstützen derzeit interne Stagingbereiche mit SNOWFLAKE_SSE-Verschlüsselung Verwenden Sie bei der Ausführung von CREATE STAGE den Parameter ENCRYPTION zur Angabe des Verschlüsselungstyps: CREATE STAGE my_stage ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');
Zufällige Schreibvorgänge oder Anhänge von Dateien werden nicht unterstützt.
Jeder eingebundene Stagingbereich erfordert 512 MB Arbeitsspeicher pro Stagingbereich. Das bedeutet, dass die Anzahl der Stagingbereiche, die verwendet werden können, je nach Größe der Instanz begrenzt ist. Das Einbinden des Volumes in mehrere Container erhöht nicht den Speicherverbrauch.