Utilisation des volumes de zones de préparation Snowflake avec des services¶

Snowflake supports various storage volume types for your application containers, including internal stage, local storage, memory storage, and block storage volumes. This section explains how to configure volumes and volume mounts for internal stages. A An internal stage volume is a volume configured to use a Snowflake stage as persistent storage.

Avec les volumes de zone de préparation, votre service peut accéder aux objets d’une zone de préparation interne comme s’il s’agissait de fichiers sur votre système de fichiers, ce qui simplifie le code de votre service par rapport à l’utilisation d’un pilote Snowflake et des commandes SQL GET et PUT pour accéder à ces objets. Les volumes de zone de préparation peuvent également offrir de meilleures performances pour les scénarios avec lectures ou écritures en continu de fichiers de données volumineux.

Si les opérations sur votre système de fichiers peuvent facilement être traduites en opérations en continu GET et PUT, les volumes de zone de préparation fonctionneront bien pour votre scénario. Si votre application doit renommer ou déplacer des fichiers, modifier des fichiers existants, ou effectuer un verrouillage basé sur le système de fichiers, alors le volume de zone de préparation n’est pas adapté à votre charge de travail.

Note

Il existe actuellement deux implémentations des volumes de zone de préparation, à savoir la version disponible de manière générale et une version obsolète. Snowflake vous recommande d’utiliser la version disponible de manière générale pour les nouveaux services et de migrer vos applications existantes depuis la version obsolète.

La mise en œuvre d’un volume de zone de préparation transfère directement le contenu des fichiers vers et depuis le stockage Cloud, vous garantissant ainsi de toujours disposer du contenu le plus récent. Tenez compte des points suivants lorsque vous utilisez un volume de zone de préparation :

A stage volume is optimized for large, sequential reads and writes, providing strong performance for these access patterns. For best results, read and write data in large, contiguous chunks.
Reads always return the latest data, which lets data sharing occur between services.
Les écritures aléatoires ou les ajouts de fichiers ne sont pas pris en charge. Toute tentative d’exécution de ces opérations entraîne une erreur. Snowflake vous recommande d’utiliser des volumes de stockage en blocs pour ces charges de travail.

Configure a Snowflake stage as a storage volume in a service specification¶

To create a service where service containers use a stage volume, you perform two steps to specify the required settings in the service specification:

Définissez un volume de zone de préparation qui identifie la zone de préparation Snowflake à utiliser comme volume de stockage.
Specify where to mount the stage volume in your application container.

Étape 1 : Définir un volume de zone de préparation¶

To define a stage volume, add the spec.volumes field in the service specification as shown in the following example:

spec:
  containers:
    ..
  volumes:
  - name: <name>
    source: stage
     stageConfig:
       name: <stage_name>
       medataCache: <time_period>
       resources:
         requests:
           memory: <amount-of-memory>
           cpu: <cpu-units>
         limits:
           memory: <amount-of-memory>
           cpu: <cpu-units>

Copy

The following list defines the fields from the example:

name: Provides the name of the volume.
source: Identifies the type of the volume (stage).
stageConfig.name: Identifies the Snowflake internal stage or folder on a stage to mount; for example @my_stage, @my_stage/folder, or @my_db.my_schema.my_stage/folder/nestedfolder. Double quotes must surround this value.

Vous pouvez inclure les champs facultatifs suivants dans stageConfig :

Champ stageConfig.resources : Le composant Snowflake qui fournit le volume de zone de préparation monté nécessite des ressources de CPU et de mémoire. Utilisez ce champ pour spécifier ces exigences en matière de CPU et de mémoire, similaires aux spécifications de ressources pour vos conteneurs d’application. Pour plus d’informations, consultez les champs champ containers.resources. Si ce champ n’est pas spécifié, les paramètres de ressources par défaut suivants s’appliquent :
- resources.requests.cpu: 0
- resources.requests.memory: 0.5Gi
- resources.limits.cpu: 0.5
- resources.limits.memory: 1Gi
Pour la plupart des applications avec un trafic de données typique vers des volumes de zone de préparation, vous n’avez pas besoin de définir ce champ, car les paramètres de ressources par défaut devraient être suffisants. Toutefois, si votre application effectue un volume élevé de lectures et d’écritures, les paramètres par défaut peuvent entraîner des limites de performances ou des échecs de lecture/écriture. Pour plus d’informations, voir Instructions communes pour les deux implémentations des volumes de zones de préparation.

Pour éviter ces problèmes, consultez les métriques du CPU et de la mémoire pour le conteneur (stage-mount-v2-sidecar-<stage-volume-name>). Snowflake ajoute ce conteneur à votre service qui fournit l’implémentation du volume de zone de préparation que vous avez configuré. Cela vous permet de voir exactement les ressources que votre volume de zone de préparation utilise et de déterminer s’il est limité par le CPU ou la mémoire. Utilisez ces métriques pour mettre à jour les limites du CPU et de la mémoire selon vos besoins.
Champ stageConfig.metadataCache : Si votre application récupère fréquemment des métadonnées de fichiers ou répertorie des fichiers sur une zone de préparation Snowflake dans une boucle, et si vous ne vous attendez pas à ce que les données changent souvent, vous pouvez activer la mise en cache des métadonnées pour le volume de stockage de la zone de préparation Snowflake afin d’améliorer significativement les performances. Le cache stocke ces métadonnées pour une période donnée, après quoi elles sont effacées. Si l’application tente ensuite d’accéder aux métadonnées, Snowflake actualise le cache. Utilisez les heures, les minutes et les secondes pour spécifier le metadataCache. Par exemple, 90s, 5m, 1h, 1h30m ou 1h30m45s. S’il n’est pas spécifié, il n’y a pas de mise en cache.

Note

Configurez la mise en cache des métadonnées uniquement lorsque les données dans votre zone de préparation Snowflake ne changent pas pendant la durée de vie du service ; par exemple, un service qui a des charges de travail en lecture seule qui doivent travailler sur un ensemble statique de données dans la zone de préparation. Ne configurez pas la mise en cache des métadonnées pour les charges de travail dont les données dans votre zone de préparation Snowflake sont mises à jour pendant que le service est en cours d’exécution.

Le champ spec.volumes suivant définit un volume de zone de préparation Snowflake. Le champ comprend les champs stageConfig facultatifs :

spec:
  containers:
    ..
  volumes:
  - name: <name>
    source: stage
    stageConfig:
      name: <stage_name>
      metadataCache: 1h
      resources:
        requests:
          cpu: 0.35
          memory: 0.4Gi
        limits:
          cpu: 2.0
          memory: 1Gi

Copy

Étape 2 : Indiquer l’emplacement de montage du volume de zone de préparation dans le conteneur¶

After you define a Snowflake stage storage volume by adding the spec.volumes field, use the spec.containers.volumeMounts field to describe where to mount the stage volume in your application containers, as shown in the following example:

spec:
  containers:
  - name: ...
    image: ...
    volumeMounts:
    - name: <name>
      mountPath: <absolute_directory_path>

Copy

Les informations que vous fournissez dans ce champ sont cohérentes pour tous les types de volumes de stockage pris en charge et s’appliquent aux deux implémentations des volumes de zone de préparation.

Exemple¶

Créer un service avec une zone de préparation mydb.myschema.ai_models_stage montée sur /path/to/stage dans le conteneur principal.

CREATE SERVICE my_service
IN COMPUTE POOL tutorial_compute_pool
FROM SPECIFICATION $$
spec:
  containers:
  - name: echo
    image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
    volumeMounts:
    - name: stage-vol
      mountPath: /path/to/stage
  volumes:
  - name: stage-vol
    source: stage
    stageConfig:
      name: "@mydb.myschema.ai_models_stage"
$$;

Copy

Créer un service avec un sous-chemin de zone de préparation mydb.myschema.ai_models_stage/subpath monté sur /path/to/stage dans le conteneur principal.

CREATE SERVICE my_service
IN COMPUTE POOL tutorial_compute_pool
FROM SPECIFICATION $$
spec:
  containers:
  - name: echo
    image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
    volumeMounts:
    - name: stage-vol
      mountPath: /path/to/stage
  volumes:
  - name: stage-vol
    source: stage
    stageConfig:
      name: "@mydb.myschema.ai_models_stage/subpath"
      metadataCache: 1h
      resources:
        requests:
          cpu: 0.35
          memery: 0.4Gi
        limits:
          cpu 2.0
          memory: 1Gi
$$;

Copy

Exigences en matière de contrôle d’accès¶

Le rôle de propriétaire du service est le rôle utilisé pour créer le service. C’est également le rôle que les services utilisent lors de leur interaction avec Snowflake. Le rôle de propriétaire détermine les permissions accordées aux conteneurs d’applications pour accéder à une zone de préparation montée. Le rôle de propriétaire doit avoir le privilège READ sur la zone de préparation.

Si le rôle de propriétaire ne dispose pas du privilège WRITE sur une zone de préparation, le montage de cette zone de préparation est en lecture seule. En d’autres termes, les conteneurs ne peuvent lire que les fichiers de la zone de préparation. Le rôle de propriétaire nécessite le privilège WRITE sur une zone de préparation pour que le montage de la zone de préparation prenne en charge à la fois la lecture et l’écriture.

About the deprecated implementation¶

The deprecated stage-volume implementation uses a shared cache for reads and writes. Although this works well for some scenarios, you can’t control whether data is read from the cache or directly from the stage, which might not be suitable for all applications. Additionally, when you use the cache for reads and writes, this can introduce performance overhead.

Migration du code à partir de l’implémentation obsolète¶

La nouvelle implémentation remplace l’implémentation obsolète, avec les changements de comportement suivants :

La nouvelle implémentation zone de préparation-volume transfère le contenu des fichiers directement vers et depuis le stockage Cloud, vous garantissant ainsi de toujours disposer du contenu le plus récent. Cela favorise un comportement prévisible et un débit nettement plus rapide. L’implémentation zone de préparation-volume obsolète met en cache des morceaux de données de fichiers, ce qui fait qu’il est difficile de savoir si vous lisez les données les plus récentes.
Les performances de lecture aléatoire peuvent être inférieures avec la nouvelle implémentation, en raison de la suppression de la mise en cache. Cependant, sans cache de disque local, la cohérence entre les volumes est améliorée. Les modifications de fichier sont écrites directement dans la zone de préparation de sauvegarde lorsque le fichier est fermé, sans mise en mémoire tampon du disque local.
Les lectures renvoient toujours les données les plus récentes, ce qui rend cette configuration meilleure pour le partage de données entre les services.
Les écritures aléatoires ou les ajouts de fichiers ne sont pas pris en charge. Toute tentative d’exécution de ces opérations entraîne une erreur. Snowflake vous recommande d’utiliser des volumes de stockage en blocs pour ces charges de travail.

Specify a Snowflake stage volume in a service specification (deprecated)¶

To create a service where service containers use Snowflake stage volume, specify the required settings in the service specification as shown in the following steps:

To specify the stage volume, use the spec.volumes field as shown in the following example:
```
volumes:
- name: <name>
  source: <stage_name>
```
Copy
Les champs suivants sont obligatoires :
- name: The name of the volume.
- source: The Snowflake internal stage or folder on the stage to mount; for example @my_stage, @my_stage/folder. Quotes must surround this value.
To describe where to mount the stage volume in your application containers, use the spec.containers.volumeMounts field, as shown in the following example:
```
volumeMounts:
- name: <name>
  mountPath: <absolute_directory_path>
```
Copy
Les informations que vous fournissez dans ce champ sont cohérentes pour tous les types de volumes de stockage pris en charge et s’appliquent aux deux implémentations des volumes de zone de préparation.

Exemple (obsolète)¶

In the example service specification, the app container mounts an internal stage @model_stage by using the deprecated stage volume implementations:

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

Copy

The volumeMounts field specifies where inside the container to mount the stage volume. This specification remains the same for both the stage volume implementations.

Instructions pour l’utilisation des volumes de zone de préparation¶

This section provides you with guidelines to follow when you implement application code in which a container uses a Snowflake stage as storage volume.

Instructions communes pour les deux implémentations des volumes de zones de préparation¶

Le montage de zone de préparation est optimisé pour les lectures et écritures séquentielles.
Les opérations d’E/S de montage de zone de préparation peuvent avoir des latences plus élevées que les opérations d’E/S sur le système de fichiers du conteneur et les volumes de stockage en blocs. Vous devez toujours vérifier le code de statut des opérations d’E/S pour vous assurer qu’elles ont réussi.
Les montages de zone de préparation téléchargent les mises à jour de fichiers de manière asynchrone. Les modifications apportées aux fichiers sur un montage de zone de préparation ne sont garanties d’être conservées dans la zone de préparation qu’une fois le descripteur de fichier fermé ou vidé avec succès. Il peut y avoir un certain délai avant que les modifications apportées aux fichiers sur un montage de zone de préparation deviennent visibles pour les autres conteneurs et Snowflake.
Chaque répertoire d’une zone de préparation montée doit contenir moins de 100 000 fichiers. Attendez que la latence readdir augmente avec le nombre de fichiers dans le répertoire.

Guidelines when using the deprecated version of the stage volume implementation¶

Évitez d’écrire simultanément dans plusieurs fichiers au sein d’un montage de zone de préparation.
Le montage de zone de préparation n’est pas un système de fichiers réseau. N’utilisez pas de montages de zone de préparation pour la coordination multi-clients.
N’ouvrez pas plusieurs handles du même fichier simultanément. Utilisez les descripteurs de fichiers ouverts pour les opérations de lecture ou d’écriture, mais pas un mélange des deux. Pour lire un fichier après y avoir écrit, fermez le fichier, puis rouvrez-le avant de le lire.

Guidelines when using the generally available stage volume implementation¶

Les écritures simultanées sur le même fichier à partir de plusieurs montages de zones de préparation (même volume de zone de préparation monté sur différents conteneurs) ne sont pas recommandées.
L’absence de cache de disque local améliore la cohérence entre les montages. Les modifications de fichier sont transférées directement vers la zone de préparation de sauvegarde après fermeture du fichier, sans mise en mémoire tampon du disque local. Les lectures renvoient toujours les données les plus récentes, ce qui rend le nouveau montage de zone de préparation meilleur pour le partage des données entre les services.
Pour des performances optimales, lisez et écrivez des données par grands morceaux contigus. La perte de performances pour les petites lectures et écritures par rapport à l’implémentation des volumes de zone de préparation disponible de manière générale peut atténuer les gains de performances de la nouvelle implémentation.

Limitations lors de l’utilisation des volumes de zone de préparation¶

Cette section décrit les limitations dont vous devez avoir connaissance lorsque vous implémentez du code d’application dans lequel les conteneurs utilisent des volumes de zone de préparation. Si vous rencontrez des problèmes avec ces limites, contactez votre représentant de compte.

Limitations communes aux deux implémentations des volumes de zones de préparation¶

Vous ne pouvez monter qu’une zone de préparation ou un sous-répertoire dans une zone de préparation, par exemple @my_stage/folder. Vous ne pouvez pas monter un seul fichier dans une zone de préparation, par exemple @my_stage/folder/file.
Les zones de préparation externes ne sont pas prises en charge. Seuls les zones de préparation internes Snowflake sont prises en charge.
Les montages de zones de préparation ne sont pas des systèmes de fichiers entièrement compatibles avec POSIX. Par exemple :
- Les renommages de fichiers et de répertoires ne sont pas atomiques.
- Les liens physiques ne sont pas pris en charge.
La notification d’inode du sous-système du noyau Linux (inotify) qui surveille les modifications apportées aux systèmes de fichiers ne fonctionne pas sur les montages en zone de préparation.

Limitations when using the deprecated version of the stage volume implementation¶

Un maximum de 5 volumes de zone de préparation est autorisé par service. Pour plus d’informations, consultez volumes.spéc..
Un maximum de 8 volumes de zones de préparation par nœud du pool de calcul est pris en charge. Snowflake gère la limite de montage de zone de préparation par nœud de la même manière qu’il gère la mémoire, le CPU, et la GPU. Le lancement d’une nouvelle instance de service peut amener Snowflake à lancer de nouveaux nœuds lorsqu’aucun nœud existant n’a la capacité de prendre en charge les montages de zone de préparation demandés.
Les capacités des volumes de zone de préparation varient en fonction de la plateforme Cloud de votre compte Snowflake :
- Les comptes sur AWS prennent en charge les zones de préparation internes avec les chiffrements des zones de préparation SNOWFLAKE_FULL et SNOWFLAKE_SSE. Pour plus d’informations, consultez Paramètres des zones de préparation internes.
- Les comptes sur Azure prennent actuellement en charge les zones de préparation internes avec le chiffrement SNOWFLAKE_SSE. Lors de l’exécution de CREATE STAGE, utilisez le paramètre ENCRYPTION pour spécifier le type de chiffrement : CREATE STAGE my_stage ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');.
- Les comptes sur Google Cloud ne sont pas pris en charge.
Les écritures simultanées sur le même fichier à partir de plusieurs montages de zones de préparation (c’est-à-dire le même volume de zone de préparation monté sur différents conteneurs) ne sont pas prises en charge.

Limitations lors de l’utilisation de la version disponible de manière générale de l’implémentation des volumes de zone de préparation¶

Les écritures aléatoires et les ajouts de fichiers ne sont pas pris en charge.
Chaque zone de préparation montée nécessite 512 MB de mémoire par zone de préparation. Cela signifie qu’il existe une limite du nombre de volumes de zones de préparation qui peuvent être utilisés en fonction de la taille de l’instance. Le montage du volume sur plusieurs conteneurs n’augmente pas la consommation de mémoire.
A maximum of 20 stage volumes are allowed per service. For more information, see spec.volumes.