Préparation de vos fichiers de données

Ce chapitre fournit des bonnes pratiques, des lignes directrices générales et des considérations importantes concernant la préparation de vos fichiers de données en vue d’un chargement.

Dans ce chapitre :

Meilleures pratiques et limitations en matière de taille de fichier

Pour optimiser les performances de chargement et éviter les limitations de taille, tenez compte des instructions de dimensionnement des fichiers de données suivantes. Notez que ces recommandations s’appliquent aux chargements de données en masse ainsi qu’au chargement continu avec Snowpipe.

Recommandations générales sur la taille des fichiers

Le nombre d’opérations de chargement exécutées en parallèle ne peut pas dépasser le nombre de fichiers de données à charger. Pour optimiser le nombre d’opérations parallèles pour un chargement, nous vous recommandons de générer des fichiers de données d’une taille d’environ 100-250 MB (ou plus) de façon compressée.

Note

Le chargement de fichiers très volumineux (par exemple 100 GB ou plus) n’est pas recommandé.

Si vous devez charger un fichier volumineux, portez une attention particulière à la valeur de l’option de copie ON_ERROR. Abandonner ou ignorer un fichier en raison d’un petit nombre d’erreurs pourrait entraîner des retards et des crédits gaspillés. En outre, si une opération de chargement de données se poursuit au-delà de la durée maximale autorisée de 24 heures, elle peut être interrompue sans qu’aucune partie du fichier ne soit validée.

Agrégez des fichiers plus petits afin de minimiser la surcharge de traitement pour chaque fichier. La division de gros fichiers en un plus grand nombre de fichiers plus petits répartit la charge entre les ressources de calcul d’un entrepôt actif. Le nombre de fichiers de données traités en parallèle est déterminé par le nombre de ressources de calcul d’un entrepôt. Nous vous recommandons de diviser les fichiers volumineux par ligne pour éviter que les enregistrements s’étendent sur plusieurs morceaux.

Si votre base de données source ne vous permet pas d’exporter les fichiers de données en petites parties, vous pouvez utiliser un utilitaire tiers pour fractionner les gros fichiers CSV.

Linux ou macOS

L’utilitaire split vous permet de diviser un fichier CSV en plusieurs petits fichiers.

Syntaxe :

split [-a suffix_length] [-b byte_count[k|m]] [-l line_count] [-p pattern] [file [name]]
Copy

Pour plus d’informations, tapez man split dans une fenêtre de terminal.

Exemple :

split -l 100000 pagecounts-20151201.csv pages
Copy

Cet exemple divise un fichier nommé pagecounts-20151201.csv par longueur de ligne. Supposons que le gros fichier unique ait une taille de 8 GB et contienne 10 millions de lignes. Divisé par 100 000, chacun des 100 plus petits fichiers a une taille de 80 MB (10 millions/100 000 = 100). Les fichiers fractionnés sont nommés pages<suffixes>.

Windows

Windows n’inclut pas d’utilitaire natif de fractionnement de fichiers ; cependant, Windows prend en charge de nombreux outils et scripts tiers qui peuvent fractionner de gros fichiers de données.

Limites de taille des données semi-structurées

Le type de données VARIANT impose une limite de taille de 16 MB sur les lignes individuelles.

En général, les ensembles de données JSON sont une simple concaténation de plusieurs documents. La sortie JSON de certains logiciels est composée d’un seul grand tableau contenant plusieurs enregistrements. Il n’est pas nécessaire de séparer les documents par des sauts de ligne ou des virgules, bien que les deux soient pris en charge.

Nous recommandons plutôt d’activer l’option de format de fichier STRIP_OUTER_ARRAY pour la commande COPY INTO <table> afin de supprimer la structure de tableau externe et de charger les enregistrements dans des lignes de table séparées :

COPY INTO <table>
FROM @~/<file>.json
FILE_FORMAT = (TYPE = 'JSON' STRIP_OUTER_ARRAY = true);
Copy

Charges de données continues (c.-à-d. Snowpipe) et dimensionnement des fichiers

Snowpipe est conçu pour charger de nouvelles données typiquement dans la minute qui suit l’envoi d’une notification de fichier ; cependant, le chargement peut prendre beaucoup plus de temps pour de très gros fichiers ou dans les cas où une quantité inhabituelle de ressources de calcul est nécessaire pour décompresser, déchiffrer et transformer les nouvelles données.

En plus de consommer des ressources, les frais généraux de gestion des fichiers dans la file d’attente de chargement interne sont inclus dans les coûts d’utilisation facturés pour Snowpipe. Ces frais généraux augmentent en fonction du nombre de fichiers mis en file d’attente pour le chargement. Ces frais généraux apparaissent comme des frais de Snowpipe dans votre relevé de facturation parce que Snowpipe est utilisé pour les notifications d’événements pour les rafraîchissements automatiques des tables externes.

Pour optimiser l’expérience de chargement avec Snowpipe, nous vous recommandons de suivre les recommandations de dimensionnement des fichiers décrites dans Meilleures pratiques et limitations en matière de taille de fichier (dans cette rubrique). Le chargement de fichiers de données d’une taille d’environ 100-250 MB ou plus réduit les frais généraux par rapport à la quantité totale de données chargées au point où les frais généraux sont négligeables.

S’il faut plus d’une minute pour accumuler des MBs de données dans votre application source, pensez à créer un nouveau fichier de données (potentiellement plus petit) une fois par minute. Cette approche conduit généralement à un bon équilibre entre le coût (c’est-à-dire les ressources consacrées à la gestion des files d’attente et la charge réelle) et la performance (c’est-à-dire la latence de la charge).

La création de fichiers de données plus petits et leur mise en zone de préparation dans un stockage Cloud plus fréquente qu’une fois par minute présentent les inconvénients suivants :

  • Une réduction de la latence entre la mise en zone de préparation et le chargement des données ne peut être garantie.

  • Les frais généraux de gestion des fichiers dans la file d’attente de chargement interne sont inclus dans les coûts d’utilisation facturés pour Snowpipe. Ces frais généraux augmentent en fonction du nombre de fichiers mis en file d’attente pour le chargement.

Différents outils permettent d’agréger et de regrouper des fichiers de données par lots. Une option pratique est Amazon Kinesis Firehose. Firehose permet de définir à la fois la taille de fichier souhaitée, appelée taille tampon, et l’intervalle d’attente après lequel un nouveau fichier est envoyé (vers le stockage Cloud, dans ce cas), appelé intervalle tampon. Pour plus d’informations, voir la documentation Kinesis Firehose. Si votre application source accumule généralement suffisamment de données en une minute pour remplir des fichiers plus importants que la taille maximale recommandée pour un traitement parallèle optimal, vous pouvez réduire la taille de tampon pour déclencher la livraison de fichiers plus petits. Maintenir le réglage de l’intervalle tampon à 60 secondes (la valeur minimale) permet d’éviter de créer trop de fichiers ou d’augmenter la latence.

Préparation des fichiers texte délimités

Tenez compte des directives suivantes lorsque vous préparez vos fichiers texte délimités (CSV) au chargement :

  • UTF-8 est le jeu de caractères par défaut. Cependant, des encodages supplémentaires sont pris en charge. Utilisez l’option de format de fichier ENCODING pour spécifier le jeu de caractères des fichiers de données. Pour plus d’informations, voir CREATE FILE FORMAT.

  • Les champs qui contiennent des caractères de délimitation doivent être entourés de guillemets (simples ou doubles). Si les données contiennent des guillemets simples ou doubles, alors ces guillemets doivent faire l’objet d’un échappement.

  • Les retours chariot sont généralement introduits sur les systèmes Windows en conjonction avec un caractère de saut de ligne pour marquer la fin d’une ligne (\r \n). Les champs qui contiennent des retours chariot doivent également être entourés de guillemets (simples ou doubles).

  • Le nombre de colonnes dans chaque ligne doit être cohérent.

Fichiers de données semi-structurés et mise en colonnes

Lorsque des données semi-structurées sont insérées dans une colonne VARIANT, Snowflake applique certaines règles pour extraire autant de données que possible sous forme de colonnes. Le reste des données est stocké sous la forme d’une seule colonne dans une structure semi-structurée analysée.

Par défaut, Snowflake extrait un maximum de 200 éléments par partition, par table. Pour augmenter cette limite, contactez le support Snowflake.

Éléments non extraits

Les éléments présentant les caractéristiques suivantes ne sont pas extraits dans une colonne :

  • Les éléments qui contiennent ne serait-ce qu’une seule valeur « null » ne sont pas extraits dans une colonne. Cela s’applique aux éléments avec des valeurs « null » et non aux éléments avec des valeurs manquantes, qui sont représentés sous forme de colonne.

    Cette règle garantit qu’aucune information n’est perdue (c’est-à-dire que la différence entre les valeurs VARIANT « null » et les valeurs SQL NULL n’est pas perdue).

  • Éléments contenant plusieurs types de données. Par exemple :

    L’élément foo dans une ligne contient un nombre :

    {"foo":1}
    Copy

    Le même élément dans une autre ligne contient une chaîne :

    {"foo":"1"}
    Copy

Impact de l’extraction sur les requêtes

Lorsque vous interrogez un élément semi-structuré, le moteur d’exécution de Snowflake se comporte différemment selon qu’un élément a été extrait ou non.

  • Si l’élément a été extrait dans une colonne, le moteur analyse uniquement la colonne extraite.

  • Si l’élément n’a pas été extrait dans une colonne, le moteur doit analyser toute la structure JSON, puis pour chaque ligne, parcourir la structure pour émettre les valeurs. Cela a un impact sur les performances.

Pour éviter l’impact sur les performances des éléments non extraits, procédez comme suit :

  • Extrayez les éléments de données semi-structurées contenant des valeurs « null » dans des colonnes relationnelles avant leur chargement.

    Sinon, si les valeurs « null » de vos fichiers indiquent des valeurs manquantes et n’ont pas d’autre signification particulière, nous vous recommandons de définir l”option de format de fichier STRIP_NULL_VALUES sur TRUE lors du chargement des fichiers de données semi-structurées. Cette option supprime les éléments OBJECT ou ARRAY contenant des valeurs « nulles ».

  • Assurez-vous que chaque élément unique stocke des valeurs d’un seul type de données natif du format (par exemple, une chaîne ou un nombre pour JSON).

Lignes directrices sur les données numériques

  • Évitez les caractères imbriqués, comme les virgules (p. ex, 123,456).

  • Si un nombre comprend une composante fractionnaire, il doit être séparé de la partie entière du nombre par un point décimal (p. ex, 123456.789).

  • Oracle uniquement. Les types NUMBER ou NUMERIC d’Oracle permettent une échelle arbitraire, ce qui signifie qu’ils acceptent des valeurs avec des composantes décimales même si le type de données n’a pas été défini avec une précision ou une échelle. Dans Snowflake, en revanche, les colonnes conçues pour les valeurs à composantes décimales doivent être définies avec une échelle afin de préserver la portion décimale.

Lignes directrices relatives aux données d’horodatage et de date

  • Pour plus d’informations sur les formats pris en charge pour les données de date, d’heure et d’horodatage, voir Formats d’entrée et de sortie de la date et de l’heure.

  • Oracle uniquement. Le type de données DATE d’Oracle peut contenir des informations de date ou d’horodatage. Si votre base de données Oracle comprend des colonnes DATE qui stockent également des informations temporelles, associez ces colonnes à un type de données TIMESTAMP dans Snowflake plutôt que DATE.

Note

Snowflake vérifie les valeurs temporelles des données au moment du chargement. Des valeurs de date, d’heure et d’horodatage non valides (par exemple, 0000-00-00) produisent une erreur.

Langage: Français