Cloner de manière incrémentielle les tableaux Parquet et Iceberg vers Delta Lake

Vous pouvez utiliser la fonctionnalité de clonage d’Azure Databricks pour convertir de manière incrémentielle des données de sources de données Parquet ou Iceberg en tables Delta managées ou externes.

Le clone Azure Databricks pour Parquet et Iceberg combine les fonctionnalités utilisées pour cloner des tables Delta et convertir des tables en Delta Lake. Cet article décrit les cas d’usage et les limitations de cette fonctionnalité et fournit des exemples.

Quand utiliser un clone pour l’ingestion incrémentielle de données Parquet ou Iceberg

Azure Databricks fournit un certain nombre d’options pour ingérer des données dans le lakehouse. Databricks recommande d’utiliser le clonage pour ingérer des données Parquet ou Iceberg dans les situations suivantes :

• Vous effectuez une migration de Parquet ou Iceberg vers Delta Lake, mais vous devez continuer à utiliser les tables sources.
• Vous devez maintenir une synchronisation d’ingestion uniquement entre une table cible et une table source de production qui reçoit des ajouts, des mises à jour et des suppressions.
• Vous souhaitez créer un instantané conforme ACID des données sources pour la création de rapports, le Machine Learning ou l’ETL par lots.

Quelle est la syntaxe du clonage ?

Le clonage pour Parquet et Iceberg utilise la même syntaxe de base que celle utilisée pour cloner les tables Delta, avec la prise en charge des clones superficiels et profonds. Pour plus d’informations, consultez Cloner des types.

Databricks recommande d’utiliser le clonage de manière incrémentielle pour la plupart des charges de travail. La prise en charge du clonage pour Parquet et Iceberg utilise la syntaxe SQL.

Pour cloner en profondeur une table Parquet ou Iceberg à l’aide d’un chemin d’accès de fichier, utilisez la syntaxe suivante :

CREATE OR REPLACE TABLE <target-table-name> CLONE parquet.`/path/to/data`;

CREATE OR REPLACE TABLE <target-table-name> CLONE iceberg.`/path/to/data`;

Pour cloner de manière superficielle une table Parquet ou Iceberg à l’aide d’un chemin d’accès de fichier, utilisez la syntaxe suivante :

CREATE OR REPLACE TABLE <target-table-name> SHALLOW CLONE parquet.`/path/to/data`;

CREATE OR REPLACE TABLE <target-table-name> SHALLOW CLONE iceberg.`/path/to/data`;

Vous pouvez également créer des clones profonds ou superficiels pour les tables Parquet inscrites dans le metastore, comme illustré dans les exemples suivants :

CREATE OR REPLACE TABLE <target-table-name> CLONE <source-table-name>;

CREATE OR REPLACE TABLE <target-table-name> SHALLOW CLONE <source-table-name>;

Conditions requises et limitations pour cloner des tableaux Parquet et Iceberg

Que vous utilisiez des clones profonds ou superficiels, les modifications appliquées à la table cible après le clonage ne peuvent pas être resynchronisées avec la table source. La synchronisation incrémentielle avec le clone est unidirectionnelle, ce qui permet d’appliquer automatiquement les modifications apportées aux tables sources aux tables Delta cibles.

Les limitations supplémentaires suivantes s’appliquent lors de l’utilisation de clones avec des tables Parquet et Iceberg :

• Vous devez enregistrer les tables Parquet avec des partitions dans un catalogue tel que Unity Catalog ou l’ancien metastore Hive hérité avant de procéder au clonage et d’utiliser le nom de la table pour identifier la table source. Vous ne pouvez pas utiliser la syntaxe de clonage basée sur le chemin d’accès pour les tables Parquet avec des partitions.
• Vous ne pouvez pas cloner des tables Iceberg qui ont connu une évolution de partition.
• Vous ne pouvez pas cloner des tables de fusion en lecture Iceberg ayant été mises à jour, supprimées ou fusionnées.
• Voici des limitations pour cloner des tables Iceberg avec des partitions définies sur des colonnes tronquées :
  • Dans Databricks Runtime 12.2 LTS et versions ultérieures, le seul type de colonne tronqué pris en charge est string.
  • Dans Databricks Runtime 13.3 LTS et versions ultérieures, vous pouvez utiliser des colonnes tronquées de types string, long ou int.
  • Azure Databricks ne prend pas en charge l’utilisation de colonnes tronquées de type decimal.
• Le clone incrémentiel synchronise les changements et propriétés du schéma à partir de la table source. Les changements de schéma et fichiers de données écrits directement dans la table clonée sont remplacés.
• Unity Catalog ne prend pas en charge les clones superficiels pour les tables Parquet et Iceberg.
• Vous ne pouvez pas utiliser de modèles Glob lors de la définition d’un chemin d’accès.