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

Vous pouvez utiliser la fonctionnalité de clonage de Databricks pour convertir progressivement des données de sources de données Parquet ou Apache Iceberg en tables Delta gérées ou externes.

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

info

Aperçu

Cette fonctionnalité est en aperçu public.

remarque

Cette fonctionnalité nécessite Databricks Runtime 11.3 LTS ou une version ultérieure.

Quand utiliser le clonage pour l'ingestion incrémentielle de données Parquet ou Iceberg

Databricks offre plusieurs options pour l'ingestion de données dans le lakehouse. Databricks recommande d'utiliser le clone pour ingérer des données Parquet ou Iceberg dans les situations suivantes :

remarque

Le terme table source fait référence à la table et aux fichiers 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 devez continuer à utiliser les tables sources.
• Vous devez maintenir une synchronisation d'ingestion seule 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 aux propriétés ACID de vos données sources pour le reporting, le Machine Learning ou l'ETL par lot.

Quelle est la syntaxe de clonage ?

Le clonage pour Parquet et Iceberg utilise la même syntaxe de base que pour cloner les tables Delta, avec prise en charge des clones peu profonds et profonds. Pour plus d'informations, consultez Types de clones.

Databricks recommande d'utiliser le clonage incrémentiel pour la plupart des charges de travail. La prise en charge du clonage pour Parquet et Iceberg utilise la syntaxe SQL.

remarque

Le clonage pour Parquet et Iceberg a des exigences et des garanties différentes de celles du clonage ou de la conversion en Delta. Voir Exigences et limitations pour le clonage des tables Parquet et Iceberg.

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

SQL

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 superficiellement une table Parquet ou Iceberg à l’aide d’un chemin de fichier, utilisez la syntaxe suivante :

SQL

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 enregistrées dans le métastore, comme illustré dans les exemples suivants :

SQL

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

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

Exigences et limites pour le clonage de tables 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émentale avec le clonage est unidirectionnelle, permettant aux modifications apportées aux tables sources d'être automatiquement appliquées aux tables Delta cibles.

Les limitations supplémentaires suivantes s'appliquent lors de l'utilisation de clone avec les tables Parquet et Iceberg :

• Vous devez enregistrer les tables Parquet avec des partitions dans un catalogue tel que Unity Catalog ou le Hive metastore hérité 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 un chemin pour les tables Parquet avec des partitions.

• Vous ne pouvez pas cloner les tables Iceberg qui ont subi une évolution de partition.

• Voici les limitations pour le clonage des tables Iceberg avec des partitions définies sur des colonnes tronquées :

  • Dans Databricks Runtime 12.2 LTS et versions antérieures, le seul type de colonne tronqué pris en charge est string.
  • Dans Databricks Runtime 13.3 LTS et versions ultérieures, vous pouvez travailler avec des colonnes tronquées de types string, long ou int.
  • Databricks ne prend pas en charge l’utilisation de colonnes tronquées de type decimal.

• Le clone incrémentiel réplique les modifications de schéma et les propriétés de la table source. Toutes les modifications de schéma et les fichiers de données écrits directement dans la table clonée sont remplacées.

• Unity Catalog ne prend pas en charge les clones superficiels pour les tables Parquet ou Iceberg.

• Vous ne pouvez pas utiliser de modèles glob lors de la définition d'un chemin.

remarque

Dans Databricks Runtime 11.3 LTS, cette opération ne collecte pas de statistiques au niveau des fichiers. De ce fait, les tables cibles ne bénéficient pas de l'ignoration de données de Delta Lake. Les statistiques au niveau des fichiers sont collectées dans Databricks Runtime 12.2 LTS et versions ultérieures.