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.

Important

Cette fonctionnalité est disponible en préversion publique.

Notes

Cette fonctionnalité requiert Databricks Runtime 11.3 ou version ultérieure.

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 :

Notes

Le terme table source fait référence aux fichiers de table et de données à cloner, tandis que la table cible fait référence à la table Delta créée ou mise à jour par l’opération.

• 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.

Notes

Le clonage pour Parquet et Iceberg a des exigences et des garanties différentes du clonage ou de la conversion en Delta. Consultez Conditions requises et limitations pour cloner des tableaux Parquet et Iceberg.

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 inscrire des tables Parquet avec des partitions dans un catalogue comme le metastore Hive avant de cloner 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 modifications du schéma et les propriétés de la table source. Les modifications du schéma et les fichiers de données écrits localement dans la table clonée sont remplacés.
• Unity Catalog ne prend pas en charge les clones superficiels.
• Vous ne pouvez pas utiliser de modèles Glob lors de la définition d’un chemin d’accès.

Remarque

Dans Databricks Runtime 11.3, cette opération ne collecte pas de statistiques au niveau du fichier. Par conséquent, les tables cibles ne bénéficient pas du saut de données Delta Lake. Les statistiques au niveau des fichiers sont collectées dans Databricks Runtime 12.2 LTS et versions ultérieures.