Chargement des données

Ce chapitre fournit des bonnes pratiques, des lignes directrices générales et des considérations importantes concernant le chargement de données préparées.

Dans ce chapitre :

Options de sélection de fichiers de données en zone de préparation

La commande COPY prend en charge plusieurs options pour charger des fichiers de données à partir d’une zone de préparation :

  • Par chemin (zones de préparation internes) / préfixe (compartiment Amazon S3). Voir Organisation des données par chemin pour plus d’informations.

  • Spécification d’une liste de fichiers spécifiques à charger.

  • Utilisation de correspondance de modèles pour identifier des fichiers spécifiques par modèle.

Ces options vous permettent de copier une fraction des données préparées dans Snowflake avec une seule commande. Cela vous permet d’exécuter des instructions COPY concurrentes qui correspondent à un sous-ensemble de fichiers, en tirant parti des opérations parallèles.

Listes de fichiers

La commande COPY INTO <table> inclut un paramètre FILES pour charger les fichiers par un nom spécifique.

Astuce

Parmi les trois options d’identification/spécification des fichiers de données à charger à partir d’une zone de préparation, la fourniture d’une liste discrète de fichiers est généralement la plus rapide ; cependant, le paramètre FILES prend en charge un maximum de 1 000 fichiers, ce qui signifie qu’une commande COPY exécutée avec le paramètre FILES ne peut charger que 1 000 fichiers au maximum.

Par exemple :

COPY INTO load1 FROM @%load1/data1/ FILES=('test1.csv', 'test2.csv', 'test3.csv')
Copy

Les listes de fichiers peuvent être combinées avec des chemins pour un meilleur contrôle du chargement des données.

Correspondance de modèles

La commande COPY INTO <table> inclut un paramètre PATTERN pour charger les fichiers en utilisant une expression régulière.

Par exemple :

COPY INTO people_data FROM @%people_data/data1/
   PATTERN='.*person_data[^0-9{1,3}$$].csv';
Copy

La correspondance de modèles à l’aide d’une expression régulière est généralement la plus lente des trois options d’identification/spécification des fichiers de données à charger à partir d’une zone de préparation ; cependant, cette option fonctionne bien si vous exportez vos fichiers dans l’ordre indiqué depuis votre application externe et voulez charger les fichiers en lots dans le même ordre.

La correspondance de modèles peut être combinée avec des chemins pour un meilleur contrôle du chargement des données.

Note

L’expression régulière est appliquée différemment aux chargements de données en masse et aux chargements de données Snowpipe.

  • Snowpipe supprime tous les segments de chemin dans la définition de la zone de préparation de l’emplacement de stockage et applique l’expression régulière à tous les segments de chemin et noms de fichiers restants. Pour visualiser la définition de la zone de préparation, exécutez la commande DESCRIBE STAGE pour la zone de préparation. La propriété URL est constituée du nom du compartiment ou du conteneur et de zéro ou plusieurs segments de chemin d’accès. Par exemple, si l’emplacement FROM dans une instruction COPY INTO <table> est @s/path1/path2/ et que la valeur URL de la zone de préparation @s est s3://mybucket/path1/, Snowpipe extrait /path1/ de l’emplacement de stockage dans la clause FROM et applique l’expression régulière à path2/ et aux noms de fichiers du chemin d’accès.

  • Les opérations de chargement de données en masse appliquent l’expression régulière à l’ensemble de l’emplacement de stockage dans la clause FROM.

Snowflake recommande d’activer le filtrage des événements dans le Cloud pour Snowpipe afin de réduire les coûts, le bruit des événements et la latence. N’utilisez l’option PATTERN que lorsque la fonction de filtrage des événements de votre fournisseur de Cloud n’est pas suffisante. Pour plus d’informations sur la configuration du filtrage des événements pour chaque fournisseur de Cloud, consultez les pages suivantes :

Exécution en parallèle d’instructions COPY qui font référence aux mêmes fichiers de données

Lorsqu’une instruction COPY est exécutée, Snowflake définit un statut de chargement dans les métadonnées de la table pour les fichiers de données référencés dans l’instruction. Cela empêche les instructions COPY exécutées en parallèle de charger les mêmes fichiers dans la table, évitant ainsi la duplication des données.

Lorsque le traitement de l’instruction COPY est terminé, Snowflake ajuste le statut de chargement des fichiers de données au besoin. Si un ou plusieurs fichiers de données ne parviennent pas à se charger, Snowflake définit le statut de chargement de ces fichiers comme ayant échoué. Ces fichiers sont disponibles à charger pour une instruction COPY ultérieure.

Chargement d’anciens fichiers

Cette section décrit comment la commande COPY INTO <table> empêche la duplication des données différemment selon que le statut de chargement d’un fichier est connu ou inconnu. Si vous partitionnez vos données par zones de préparation en utilisant des chemins logiques et granulaires par date (comme recommandé dans Organisation des données par chemin) et que vous chargez des données rapidement après leur préparation, cette section ne s’applique généralement pas à vous. Cependant, si la commande COPY ignore les anciens fichiers (c’est-à-dire les fichiers de données historiques) dans un chargement de données, cette section décrit comment contourner le comportement par défaut.

Chargement de métadonnées

Snowflake conserve des métadonnées détaillées pour chaque table dans laquelle les données sont chargées, y compris :

  • Nom de chaque fichier à partir duquel les données ont été chargées

  • Taille du fichier

  • ETag pour le fichier

  • Nombre de lignes analysées dans le fichier

  • Horodatage du dernier chargement du fichier

  • Informations sur les erreurs éventuelles rencontrées dans le fichier lors du chargement

Ces métadonnées de chargement expirent après 64 jours. Si la date LAST_MODIFIED d’un fichier de données préparé est inférieure ou égale à 64 jours, la commande COPY peut déterminer son statut de chargement pour une table donnée et empêcher le rechargement (et la duplication des données). La date LAST_MODIFIED est la date à laquelle le fichier a été initialement préparé ou modifié pour la dernière fois, la date la plus récente étant retenue.

Si la date LAST_MODIFIED est antérieure à 64 jours, le statut de chargement est toujours connu si l’un des événements suivants s’est produit moins de 64 jours avant la date du jour :

  • Le fichier a été chargé avec succès.

  • L’ensemble initial de données de la table (c’est-à-dire le premier lot après la création de la table) a été chargé.

Cependant, la commande COPY ne peut pas déterminer de façon définitive si un fichier a déjà été chargé si la date LAST_MODIFIED est antérieure à 64 jours et l’ensemble initial de données a été chargé dans la table plus de 64 jours auparavant (et si le fichier a été chargé dans la table, cela s’est également passé plus de 64 jours auparavant). Dans ce cas, pour éviter un rechargement accidentel, la commande ignore automatiquement le fichier.

Solutions de contournement

Pour charger des fichiers dont les métadonnées ont expiré, définissez l’option de copie LOAD_UNCERTAIN_FILES à true. L’option de copie fait référence aux métadonnées de chargement, si disponibles, pour éviter la duplication des données, mais tente également de charger des fichiers avec des métadonnées de chargement expirées.

Vous pouvez également définir l’option FORCE pour charger tous les fichiers, sans tenir compte des métadonnées de chargement si elles existent. Notez que cette option recharge les fichiers, dupliquant potentiellement les données dans une table.

Exemples

../_images/data-load-status1.png

Dans cet exemple :

  • Une table est créée le 1er janvier et le chargement initial de la table a lieu le même jour.

  • 64 jours s’écoulent. Le 7 mars, les métadonnées de chargement expirent.

  • Un fichier est préparé et chargé dans la table le 27 juillet et le 28 juillet, respectivement. Comme le fichier a été préparé un jour avant d’être chargé, la date LAST_MODIFIED a eu lieu au cours des 64 jours. Le statut de chargement était connu. Il n’y a aucun problème de données ou de formatage avec le fichier, et la commande COPY le charge avec succès.

  • 64 jours s’écoulent. Le 28 septembre, la date LAST_MODIFIED du fichier préparé dépasse les 64 jours. Le 29 septembre, les métadonnées de chargement pour le chargement réussi du fichier expirent.

  • On tente de recharger le fichier dans la même table le 1er novembre. Comme la commande COPY ne peut pas déterminer si le fichier a déjà été chargé, le fichier est ignoré. L’option de copie LOAD_UNCERTAIN_FILES (ou l’option de copie FORCE) est nécessaire pour charger le fichier.

../_images/data-load-status2.png

Dans cet exemple :

  • Un fichier est préparé le 1er janvier.

  • 64 jours s’écoulent. Le 7 mars, la date LAST_MODIFIED du fichier préparé dépasse les 64 jours.

  • Une nouvelle table est créée le 29 septembre, et le fichier préparé est chargé dans la table. Comme le chargement initial de la table s’est produit moins de 64 jours auparavant, la commande COPY peut déterminer que le fichier n’avait pas déjà été chargé. Il n’y a aucun problème de données ou de formatage avec le fichier, et la commande COPY le charge avec succès.

Données JSON : Suppression des valeurs « nulles »

Dans une colonne VARIANT, des valeurs nulles (NULL) sont stockées sous la forme d’une chaîne contenant le mot « null » et non la valeur SQL NULL. Si les valeurs nulles de vos documents JSON indiquent des valeurs manquantes et n’ont pas d’autre signification particulière, nous recommandons de définir l’option de format de fichier STRIP_NULL_VALUES sur TRUE pour la commande COPY INTO <table> lors du chargement des fichiers JSON. Le fait de conserver les valeurs « nulles » gaspille souvent le stockage et ralentit le traitement des requêtes.

Données CSV : Découpage des espaces de début

Si votre logiciel externe exporte des champs entre guillemets mais insère un espace d’en-tête avant le guillemet ouvrant pour chaque champ, Snowflake lit l’espace d’en-tête plutôt que le caractère guillemet comme début du champ. Les guillemets sont interprétés comme des données de chaîne.

Utilisez l’option TRIM_SPACE de format de fichier pour supprimer les espaces indésirables pendant le chargement des données.

Par exemple, chacun des champs suivants dans un exemple de fichier CSV comprend un espace d’en-tête :

"value1", "value2", "value3"
Copy

La commande COPY suivante supprime l’espace d’en-tête et supprime les guillemets qui délimitent chaque champ :

COPY INTO mytable
FROM @%mytable
FILE_FORMAT = (TYPE = CSV TRIM_SPACE=true FIELD_OPTIONALLY_ENCLOSED_BY = '0x22');

SELECT * FROM mytable;

+--------+--------+--------+
| col1   | col2   | col3   |
+--------+--------+--------+
| value1 | value2 | value3 |
+--------+--------+--------+
Copy
Langage: Français