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 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 10 MB à 100 MB de façon compressé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 serveurs d’un entrepôt actif. Le nombre de fichiers de données traités en parallèle est déterminé par le nombre et la capacité des serveurs d’un entrepôt. Nous vous recommandons de diviser les fichiers volumineux par ligne pour éviter que les enregistrements s’étendent sur plusieurs parties.

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]]

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

Exemple :

split -l 100000 pagecounts-20151201.csv pages

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 (compressée) sur les lignes individuelles.

En général, les ensembles de données JSON et Avro sont une simple concaténation de plusieurs documents. La sortie JSON ou Avro 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);

Limites relatives à la taille des données Parquet

Actuellement, les chargements de données de fichiers volumineux Parquet (p. ex. plus grands que 3 GB) peuvent échouer en raison d’un délai expiré. Divisez les fichiers volumineux en fichiers de 1 GB en taille (ou plus petits) pour le chargement.

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. Snowpipe facture 0,06 crédit par tranche de 1 000 fichiers mis en file d’attente.

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). 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 augmenter la taille du tampon. 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 extrait autant de données que possible sous forme de colonnes, selon certaines règles. Le reste est stocké sous la forme d’une colonne unique dans une structure semi-structurée analysée. Actuellement, 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. Notez que 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 que l’information n’est pas perdue, c’est-à-dire que la différence entre les valeurs « null » VARIANT et les valeurs SQL NULL n’est pas floue.

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

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

    {"foo":1}
    

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

    {"foo":"1"}
    

Lorsqu’un élément semi-structuré est interrogé :

  • Si le champ a été extrait dans une colonne, le moteur d’exécution de Snowflake (qui est en colonnes) analyse uniquement la colonne extraite.

  • Si l’élément n’a pas été extrait dans une colonne, le moteur d’exécution doit balayer toute la structure JSON, puis pour chaque ligne, parcourir la structure jusqu’aux valeurs de sortie, ce qui a un impact sur les performances.

Pour éviter cet impact sur les performances :

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

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

  • Assurez-vous que chaque élément unique stocke les valeurs d’un seul type de données natif (chaîne ou nombre).

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

  • Les données de date, d’heure et d’horodatage doivent être formatées en fonction des éléments suivants :

    Format

    Description

    YYYY

    Année à quatre chiffres.

    YY

    Année à deux chiffres, contrôlée par le paramètre de session TWO_DIGIT_CENTURY_START , par exemple lorsqu’il est réglé sur 1980, les valeurs de 79 et 80 sont respectivement analysées en tant que valeurs 2079 et 1980.

    MM

    Mois à deux chiffres (01=janvier, etc.).

    MON

    Nom complet ou abrégé du mois.

    DD

    Jour du mois à deux chiffres (01 au 31).

    DY

    Jour de la semaine abrégé.

    HH24

    Deux chiffres pour l’heure (00 à 23) ; am/pm non autorisé.

    HH12

    Deux chiffres pour l’heure (01 à 12) ; am/pm autorisé.

    AM , PM

    Ante meridiem (am) / post meridiem (pm) ; pour une utilisation avec HH12.

    MI

    Deux chiffres pour la minute (00 à 59).

    SS

    Deux chiffres pour la seconde (00 à 59).

    FF

    Fractions de seconde avec une précision de 0 (secondes) à 9 (nanosecondes), par ex. FF, FF0, FF3, FF9. Spécifier FF équivaut à FF6 (microsecondes).

    TZH:TZM , TZHTZM , TZH

    Heure et minute du fuseau horaire, décalage par rapport à UTC. Peut être préfixé par un signe +/-.

  • 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 incorrectes (par exemple, 0000-00-00) produisent une erreur.