Snowflake-Stagingbereiche mit Diensten verwenden

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.

Angabe des Snowflake-Stagingbereichs in der Dienstspezifikation

Um einen Service zu erstellen, bei dem Container einen Snowflake-Stagingbereich verwenden, geben Sie die erforderliche Konfiguration in der Dienstspezifikation wie folgt an:

  1. Geben Sie das spec.volumes-Feld an, um den zu verwendenden Stagingbereich zu definieren.

    volumes:
- name: <name>
  source: <stage name>
    Copy

    Die folgenden Felder sind erforderlich:

    • name: Eindeutiger Name des Volumes.

    • source: Der zu montierende interne Stagingbereich von Snowflake, zum Beispiel @my_stage, @my_stage/folder. Dieser Wert muss von doppelten Anführungszeichen umgeben sein.

  2. Geben Sie das Feld spec.containers.volumeMounts an, um zu beschreiben, wo ein Volume in Ihren Anwendungs-Containern eingehängt werden soll. Die Angaben, die Sie in diesem Feld machen, sind für alle unterstützten Speichervolumes gleich. Beispiel:

    volumeMounts:
- name: <name>
  mountPath: <absolute-directory-path>
    Copy

In der folgenden Beispielspezifikation montiert der app-Container den internen @model_stage-Stagingbereich:

spec:
  containers:
  - name: app
    image: <image1-name>
    volumeMounts:
    - name: models
      mountPath: /opt/models
  volumes:
  - name: models
    source: "@model_stage"
Copy

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 Rolle des Eigentümers nicht die WRITE-Berechtigung für einen Stagingbereich hat, ist der Mount 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 und Einschränkungen

Die folgenden Richtlinien und Beschränkungen gelten, wenn Anwendungs-Container Stagingbereiche verwenden:

Einschränkungen

  • Im Folgenden finden Sie allgemeine Beschränkungen. Wenn Sie Probleme mit diesen Beschränkungen haben, wenden Sie sich an Ihren Kundenbetreuer.

    • Jeder Dienst kann bis zu fünf Stagingbereiche pro Dienst unterstützen. Dies verweist auf das Feld spec.volumes in der Dienstspezifikation <label-snowpark_containers_spec_volume>.

    • Es werden nur acht Stagingbereiche pro Knoten unterstützt. Snowflake verwaltet die Beschränkung des Stagingbereichs pro Knoten ähnlich wie Speicher, CPU und GPU. Der Start einer neuen Dienstinstanz kann dazu führen, dass Snowflake neue Knoten startet, wenn kein vorhandener Knoten die Kapazität hat, den angefragten Stagingbereich zu unterstützen.

  • Sie können nur einen Stagingbereich oder ein Unterverzeichnis in einem Stagingbereich mounten. Zum Beispiel @my_stage, @my_stage/folder. Sie können keine einzelne Datei in einen Stagingbereich mounten, z. B. @my_stage/folder/file.

  • Externe Stagingbereiche werden nicht unterstützt. Es werden nur interne Snowflake-Stagingbereiche mit SSE-Verschlüsselung (siehe Interne Stagingbereichsparameter) unterstützt. Verwenden Sie CREATE STAGE, um einen solchen Stagingbereich zu erstellen: CREATE STAGE my_stage ENCRYPTION = (type = 'SNOWFLAKE_SSE');.

  • Gleichzeitige Schreibvorgänge auf dieselbe Datei aus mehreren Stagingbereichen (dasselbe Stagingbereich -Volume in verschiedenen Containern) werden nicht unterstützt.

  • 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.

Hinweise

  • Der Stagingbereich ist für sequentielles Lesen und Schreiben optimiert.

  • Vermeiden Sie das gleichzeitige Schreiben in mehrere Dateien innerhalb eines Stagingbereichs.

  • 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.

  • Um die Leistung aufrechtzuerhalten, sollten Sie es vermeiden, Dateien zu erstellen oder zu ändern, die größer als 25 GB sind.

  • 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.

  • 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.

Sprache: Deutsch