Préparation de vos fichiers de données¶

Meilleures pratiques en matière de taille des fichiers¶

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.

Limites de taille des objets de la base de données¶

Lorsque vous utilisez l’une des méthodes disponibles pour le chargement de données dans Snowflake, vous pouvez stocker des objets dont la taille ne dépasse pas les limites suivantes :

La taille par défaut pour des colonnes VARCHAR est 16 MB (8 MB pour les binaires). Pour créer des tables dont la taille des colonnes est supérieure à 16 MB, spécifiez la taille explicitement. Par exemple :

CREATE OR REPLACE TABLE my_table (
  c1 VARCHAR(134217728),
  c2 BINARY(67108864));

Pour utiliser les nouvelles limites pour les colonnes VARCHAR, vous pouvez modifier les tables pour changer la taille des colonnes. Par exemple :

ALTER TABLE my_table ALTER COLUMN col1 SET DATA TYPE VARCHAR(134217728);

Pour appliquer la nouvelle taille aux colonnes de type BINARY dans ces tables, recréez les tables. Vous ne pouvez pas modifier la longueur d’une colonne BINARY dans une table existante.

Pour les colonnes de type ARRAY, GEOGRAPHY, GEOMETRY, OBJECT et VARIANT, vous pouvez stocker des objets de plus de 16 MB dans les tables existantes et les nouvelles tables, par défaut, sans spécifier la longueur. Par exemple :

CREATE OR REPLACE TABLE my_table (c1 VARIANT);

Si vous avez des procédures et des fonctions qui ont été créées dans le passé et qui utilisent des valeurs d’entrée VARIANT, VARCHAR, ou BINARY, vous devrez peut-être les recréer (sans longueur spécifiée) pour prendre en charge des objets de plus de 16 MB. Par exemple :

CREATE OR REPLACE FUNCTION udf_varchar(g1 VARCHAR)
  RETURNS VARCHAR
  AS $$
    'Hello' || g1
  $$;

Pour les Tables Iceberg gérées en externe, la longueur par défaut des colonnes VARCHAR et BINARY est 128 MB. Cette longueur par défaut s’applique aux nouvelles tables créées ou aux tables actualisées. Si vous avez des tables qui ont été créées dans le passé, des limites plus petites peuvent s’appliquer. Vous pouvez actualiser ces tables pour qu’elles prennent en charge des limites de taille plus importantes.

Pour les tables Iceberg gérées, la longueur par défaut des colonnes VARCHAR et BINARY est de 128 MB. Les tables créées avant l’activation des nouvelles limites de taille conservent les longueurs par défaut antérieures. Pour appliquer la nouvelle taille aux colonnes de type VARCHAR dans ces tables, recréez les tables ou modifiez les colonnes. L’exemple suivant modifie une colonne pour utiliser la nouvelle limite de taille :

ALTER ICEBERG TABLE my_iceberg_table ALTER COLUMN col1 SET DATA TYPE VARCHAR(134217728);

Pour appliquer la nouvelle taille aux colonnes de type BINARY dans ces tables, recréez les tables. Vous ne pouvez pas modifier la longueur d’une colonne BINARY dans une table existante.

100067 (54000): The data length in result column <column_name> is not supported by this version of the client.
Actual length <actual_size> exceeds supported length of 16777216.

Chargements de données en continu — c.-à-d., Snowpipe — et dimensionnement de 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 une expérience de chargement la plus efficace et la plus rentable possible avec Snowpipe, nous vous recommandons de suivre les recommandations de dimensionnement des fichiers dans Meilleures pratiques en matière de taille des fichiers (dans ce sujet). Le chargement de fichiers de données 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. Option pratique : Amazon Data 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 sur Amazon Data 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 de 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ées et création de sous-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.

Lignes directrices sur les données numériques¶

• Évitez les caractères imbriqués, comme les virgules (par exemple, 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 (par exemple,:code: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 sur les 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.