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

Note

L’utilisation des volumes de zones de préparation Snowflake avec des services n’est pas disponible actuellement pour les comptes dans Google Cloud.

Snowflake prend en charge les différents types de volumes de stockage pour vos conteneurs d’application, y compris les volumes de zone de préparation interne, de stockage interne, de stockage local, de stockage en mémoire et de stockage en blocs. Cette section explique comment configurer les volumes et les montages de volumes pour les zones de préparation internes.

Les volumes de zone de préparation fournissent à votre service un accès aux zones de préparation internes en utilisant les APIs FileSystem, ce qui simplifie votre code par rapport à l’utilisation d’un pilote Snowflake et des commandes SQL GET et PUT.

Les volumes de zone de préparation peuvent également être plus performants pour les scénarios avec lectures ou écritures en continu de fichiers de données volumineux. Les volumes de zone de préparation fonctionnent mieux lorsque l’application utilise le volume de zone de préparation comme une API alternative pratique pour les zones de préparation, plutôt que d’attendre un système de fichiers pleinement opérationnel.

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 plus récente actuellement disponible en avant-première.

À propos de la nouvelle implémentation des volumes de zone de préparation¶

L’implémentation des volumes de zone de préparation disponible de manière générale utilise un cache partagé pour les lectures et les écritures. Bien que celle-ci fonctionne bien pour certains scénarios, vous ne pouvez pas contrôler si les données sont lues à partir du cache ou directement à partir de la zone de préparation, ce qui peut ne pas convenir pour toutes les applications. De plus, lorsque vous utilisez le cache pour les lectures et les écritures, cela peut entraîner une surcharge des performances.

La nouvelle implémentation des volumes de zone de préparation, actuellement en prévisualisation, n’utilise qu’une mise en cache en mémoire limitée. Cela favorise un comportement plus prévisible et un débit nettement plus rapide. À terme, cette version remplacera l’implémentation actuelle disponible de manière générale. Snowflake recommande d’évaluer cette version en prévisualisation, sauf si votre charge de travail nécessite des écritures aléatoires ou des ajouts de fichiers, qui ne sont pas actuellement pris en charge.

Gardez à l’esprit les considérations supplémentaires suivantes lorsque vous utilisez la nouvelle implémentation des volumes de zone de préparation :

Elle est optimisée pour les grandes lectures et écritures séquentielles, offrant des performances solides pour ces modèles d’accès. Pour obtenir de meilleurs résultats, lisez et écrivez des données par grands morceaux contigus.
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.

Spécifier un volume de zone de préparation Snowflake dans une spécification de service¶

Pour créer un service dans lequel les conteneurs de services utilisent un volume de zone de préparation Snowflake, spécifiez les paramètres requis dans la spécification de service comme indiqué dans les étapes suivantes :

Pour spécifier le volume de la zone de préparation, utilisez le champ spec.volumes.
- Utilisez la version disponible de manière générale de l’implémentation des volumes de zone de préparation, comme indiqué dans l’exemple suivant :
  volumes: - name: <name> source: <stage_name>
  Copy
  Les champs suivants sont obligatoires :
  - name : nom du volume.
  - source : Zone de préparation interne Snowflake ou dossier de la zone de préparation à monter, par exemple @my_stage ou @my_stage/folder. Cette valeur doit être mise entre guillemets.
- Utilisez la nouvelle version en prévisualisation de l’implémentation des volumes de zone de préparation, comme indiqué dans l’exemple suivant :
  volumes: - name: <name> source: stage stageConfig: name: <stage_name>
  Copy
  Les champs suivants sont obligatoires :
  - name : nom du volume.
  - source : Identifie le type du volume (stage).
  - stageConfig : Identifie la zone de préparation interne Snowflake ou le dossier d’une zone de préparation à monter, par exemple @my_stage, @my_stage/folder ou @my_db.my_schema.my_stage/folder/nestedfolder. Cette valeur doit être mise entre guillemets doubles.
Utilisez le champ spec.containers.volumeMounts pour décrire où monter le volume de zone de préparation dans vos conteneurs d’application, comme montré dans l’exemple suivant :
```
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¶

Cet exemple illustre la différence entre le montage d’une zone de préparation Snowflake à l’aide des volumes de zone de préparation existants ou à l’aide des nouveaux volumes de zone de préparation. Dans l’exemple de spécification de service, le conteneur de l’app monte une zone de préparation interne @model_stage en utilisant à la fois les implémentations existante et nouvelle des volumes de zone de préparation.

La configuration @model-legacy des volumes de zone de préparation indique à Snowflake d’utiliser l’implémentation disponible de manière générale des volumes de zone de préparation.
La configuration @model-new des volumes de zone de préparation spécifie le champ stageConfig, qui indique à Snowflake d’utiliser l’implémentation en prévisualisation des volumes de zone de préparation.

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

Le champ volumeMounts spécifie l’endroit du conteneur où monter le volume de zone de préparation. Cette spécification reste la même pour les deux implémentations des volumes de zone de préparation.

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.

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

Cette section vous fournit des instructions à suivre lorsque vous implémentez du code d’application dans lequel les conteneurs utilisent des volumes de zone de préparation.

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.

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

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

Instructions pour l’utilisation de la nouvelle version en prévisualisation de l’implémentation des volumes de zone de préparation¶

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.
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 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 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 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 nouvelle version en prévisualisation de l’implémentation des volumes de zone de préparation¶

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. Consultez Paramètres des zones de préparation internes.
- Les comptes sur Azure et Google Cloud 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 é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.