Modèles courants de chargement de données utilisant COPY INTO

Découvrez les modèles courants d’utilisation de COPY INTO pour charger des données à partir de sources de fichiers dans Delta Lake.

Il existe de nombreuses options d’utilisation de COPY INTO. Vous pouvez également utiliser des informations d’identification temporaires avec COPY INTO en combinaison avec ces modèles.

Consultez COPY INTO pour obtenir une référence complète de toutes les options.

Créer des tables cibles pour COPY INTO

COPY INTO doit cibler une table Delta existante.

CREATE TABLE IF NOT EXISTS my_table
[(col_1 col_1_type, col_2 col_2_type, ...)]
[COMMENT <table-description>]
[TBLPROPERTIES (<table-properties>)];

Dans Databricks Runtime 11.3 LTS et versions ultérieures, la définition du schéma pour ces tables est facultative pour les formats qui prennent en charge l’évolution du schéma. Pour plus d’informations, consultez Inférence et évolution de schéma utilisant COPY INTO.

Charger des données JSON utilisant COPY INTO

L’exemple suivant charge les données JSON à partir de cinq fichiers dans Azure Data Lake Storage Gen2 (ADLS Gen2) dans la table Delta appelée my_json_data. Cette table doit être créée avant de pouvoir exécuter COPY INTO. Si des données ont déjà été chargées à partir de l’un des fichiers, les données ne sont pas rechargées pour ce fichier.

COPY INTO my_json_data
  FROM 'abfss://container@storageAccount.dfs.core.windows.net/base/path'
  FILEFORMAT = JSON
  FILES = ('f1.json', 'f2.json', 'f3.json', 'f4.json', 'f5.json')

 -- The second execution will not copy any data since the first command already loaded the data
 COPY INTO my_json_data
   FROM 'abfss://container@storageAccount.dfs.core.windows.net/base/path'
   FILEFORMAT = JSON
   FILES = ('f1.json', 'f2.json', 'f3.json', 'f4.json', 'f5.json')

Charger des données Avro utilisant COPY INTO

L'exemple suivant charge des données Avro sur ADLS Gen2 en utilisant d’autres expressions SQL dans le cadre de l'instruction SELECT.

COPY INTO my_delta_table
  FROM (SELECT to_date(dt) dt, event as measurement, quantity::double
          FROM 'abfss://container@storageAccount.dfs.core.windows.net/base/path')
  FILEFORMAT = AVRO

Charger des fichiers CSV utilisant COPY INTO

L’exemple suivant charge des fichiers CSV depuis Azure Data Lake Storage Gen2 sous abfss://container@storageAccount.dfs.core.windows.net/base/path/folder1 dans une table Delta.

COPY INTO target_table
  FROM (SELECT key, index, textData, 'constant_value'
          FROM 'abfss://container@storageAccount.dfs.core.windows.net/base/path')
  FILEFORMAT = CSV
  PATTERN = 'folder1/file_[a-g].csv'
  FORMAT_OPTIONS('header' = 'true')

-- The example below loads CSV files without headers in ADLS Gen2 using COPY INTO.
-- By casting the data and renaming the columns, you can put the data in the schema you want
COPY INTO target_table
  FROM (SELECT _c0::bigint key, _c1::int index, _c2 textData
        FROM 'abfss://container@storageAccount.dfs.core.windows.net/base/path')
  FILEFORMAT = CSV
  PATTERN = 'folder1/file_[a-g].csv'

Inférence et évolution de schéma utilisant COPY INTO

Cette section fournit des exemples d’inférence de schéma et de configurations d’évolution courantes utilisant COPY INTO.

Syntaxe

COPY INTO my_table
FROM '/path/to/files'
FILEFORMAT = <format>
FORMAT_OPTIONS ('inferSchema' = 'true', `mergeSchema` = `true`)
COPY_OPTIONS ('mergeSchema' = 'true');

Les éléments FORMAT_OPTIONS suivants sont disponibles pour déduire automatiquement le schéma d’entrée avec COPY INTO :

• inferSchema : indique s’il faut déduire les types de données des enregistrements analysés ou supposer que toutes les colonnes sont de type StringType.

• mergeSchema : indique s’il faut déduire le schéma entre plusieurs fichiers sources et fusionner le schéma de chaque fichier source.

  Si les fichiers sources ont le même schéma, Databricks recommande d’utiliser le paramètre par défaut pour mergeSchema dans FORMAT_OPTIONS (false).

Les éléments COPY_OPTIONS suivants sont disponibles pour faire évoluer le schéma cible avec COPY INTO :

• mergeSchema : indique s’il faut faire évoluer le schéma de la table Delta cible en fonction du schéma d’entrée.

  Si le schéma d’entrée et le schéma cible sont identiques, mergeSchema peut être false dans COPY_OPTIONS.

Déduire et faire évoluer le schéma CSV

L’exemple suivant crée une table Delta sans schéma appelée my_pipe_data et charge un fichier CSV délimité par un canal avec un en-tête.

mergeSchema est true dans FORMAT_OPTIONS, car les fichiers d’entrée peuvent avoir des différences d’en-tête ou de délimiteur.

CREATE TABLE IF NOT EXISTS my_pipe_data;

COPY INTO my_pipe_data
  FROM 'abfss://container@storageAccount.dfs.core.windows.net/base/path'
  FILEFORMAT = CSV
  FORMAT_OPTIONS ('mergeSchema' = 'true',
                  'delimiter' = '|',
                  'header' = 'true')
  COPY_OPTIONS ('mergeSchema' = 'true');

Ignorer les fichiers endommagés lors du chargement des données

Si les données que vous chargez ne peuvent pas être lues en raison d’un problème d’altération, ces fichiers peuvent être ignorés en définissant ignoreCorruptFiles sur true dans FORMAT_OPTIONS.

Le résultat de la commande COPY INTO retourne le nombre de fichiers ignorés en raison d’une altération dans la colonne num_skipped_corrupt_files. Cette métrique s’affiche également dans la colonne operationMetrics sous numSkippedCorruptFiles après l’exécution de DESCRIBE HISTORY sur la table Delta.

Les fichiers endommagés ne sont pas suivis par COPY INTO. Ils peuvent donc être rechargés dans une exécution ultérieure si l’altération est corrigée. Vous pouvez voir quels fichiers sont endommagés en exécutant COPY INTO en mode VALIDATE.

COPY INTO my_table
FROM '/path/to/files'
FILEFORMAT = <format>
[VALIDATE ALL]
FORMAT_OPTIONS ('ignoreCorruptFiles' = 'true')