Cloner une table sur Azure Databricks

Clonez une table Delta Lake ou Apache Iceberg à l’aide de la CLONE commande pour créer une copie indépendante à une version spécifique. Les clones profonds copient les données et les métadonnées. Les clones peu profonds copient uniquement les métadonnées et référencent les fichiers de données sources, en utilisant moins de calcul et de stockage que les clones profonds.

Azure Databricks prend également en charge le clonage de tables Parquet et Apache Iceberg. Consultez Cloner de manière incrémentielle les tables Parquet et Apache Iceberg vers Delta Lake et Cloner une table Iceberg gérée.

Pour plus d’informations sur l’utilisation de clones avec Unity Catalog, consultez Clone superficiel pour les tables Unity Catalog.

Types de clones

Les types de clones suivants sont disponibles :

Les métadonnées clonées incluent : schéma, informations de partitionnement, invariants, nullabilité et TBLPROPERTIES. Pour les clones profonds uniquement, les flux et les métadonnées COPY INTO sont également clonés. Les métadonnées non clonées sont la description de la table, les métadonnées de validation définies par l’utilisateur, l’historique des tables Delta Lake et les propriétés catalogue Unity, telles que les balises.

Cloner une métrique

CLONE indique les métriques suivantes sous la forme d’une ligne unique de DataFrame une fois l’opération terminée :

• source_table_size: Taille de la table source clonée en octets.
• source_num_of_files : nombre de fichiers dans la table source.
• num_removed_files : si la table est en cours de remplacement, nombre de fichiers supprimés de la table actuelle.
• num_copied_files : nombre de fichiers copiés à partir de la source (0 pour des clones superficiels).
• removed_files_size : taille en octets des fichiers en cours de suppression de la table en cours.
• copied_files_size : taille en octets des fichiers copiés vers la table.

Permissions

Vous devez configurer des autorisations pour le contrôle d’accès aux table d’Azure Databricks et votre fournisseur de cloud.

Contrôle d’accès aux tables

Les autorisations suivantes sont requises pour les clones tant profonds que superficiels :

• Autorisation SELECT sur la table source.
• Si vous utilisez CLONE pour créer une table, autorisation CREATE sur la base de données dans laquelle vous la créez.
• Si vous utilisez CLONE pour remplacer une table, vous devez disposer de l’autorisation MODIFY sur celle-ci.

Autorisations du fournisseur de cloud

Les lecteurs d’un clone profond ont besoin d’un accès en lecture au répertoire du clone. Les utilisateurs doivent disposer d’un accès en écriture au répertoire du clone.

Les lecteurs d’un clone peu profond ont besoin d’un accès en lecture aux fichiers de données de la table source et au répertoire du clone, car les fichiers de données restent dans la source. Les utilisateurs doivent disposer d’un accès en écriture au répertoire du clone.

Examples

Créer des clones complets ou superficiels

Les exemples de code suivants montrent comment créer des clones profonds et peu profonds :

SQL

Créez un clone profond :

CREATE TABLE target_table CLONE source_table;

Remplacez une cible existante :

CREATE OR REPLACE TABLE target_table CLONE source_table;

Créez un clone profond ou ignorez si la cible existe déjà :

CREATE TABLE IF NOT EXISTS target_table CLONE source_table;

Créez un clone superficiel sur la dernière version, sur une version spécifique ou à un horodatage spécifique. L’horodatage peut être une chaîne de date comme '2019-01-01' ou une expression comme date_sub(current_date(), 1).

CREATE TABLE target_table SHALLOW CLONE source_table;

CREATE TABLE target_table SHALLOW CLONE source_table VERSION AS OF version;

CREATE TABLE target_table SHALLOW CLONE source_table TIMESTAMP AS OF timestamp_expression;

Python

L’API DeltaTable Python est spécifique à Delta Lake.

Clonez la source dans sa version la plus récente :

from delta.tables import *

deltaTable = DeltaTable.forName(spark, "source_table")
deltaTable.clone(target="target_table", isShallow=True, replace=False)

Clonez le code source dans une version spécifique :

deltaTable.cloneAtVersion(version=1, target="target_table", isShallow=True, replace=False)

Clonez la source à un horodatage spécifique :

deltaTable.cloneAtTimestamp(timestamp="2019-01-01", target="target_table", isShallow=True, replace=False)

Scala

L’API Scala DeltaTable est spécifique à Delta Lake.

Clonez la source dans sa version la plus récente :

import io.delta.tables._

val deltaTable = DeltaTable.forName(spark, "source_table")
deltaTable.clone(target="target_table", isShallow=true, replace=false)

Clonez le code source dans une version spécifique :

deltaTable.cloneAtVersion(version=1, target="target_table", isShallow=true, replace=false)

Clonez la source à un horodatage spécifique :

deltaTable.cloneAtTimestamp(timestamp="2019-01-01", target="target_table", isShallow=true, replace=false)

Pour plus d’informations sur la syntaxe, consultez CREATE TABLE CLONE.

Vérifier les métadonnées copiées pendant CLONE

Cet exemple montre les métadonnées qui sont ou non copiées lors des opérations CLONE, en particulier TBLPROPERTIES, les tags Unity Catalog et l’historique Delta Lake.

Créez une table source avec une propriété personnalisée et une durée de rétention de journal non par défaut, puis insérez des données pour générer l’historique des tables :

CREATE OR REPLACE TABLE test_clone_source (id INT, val STRING)
TBLPROPERTIES ('my.custom.prop' = 'hello', 'delta.logRetentionDuration' = '12 days');

ALTER TABLE test_clone_source SET TAGS ('team' = 'data-eng', 'env' = 'prod');
INSERT INTO test_clone_source VALUES (1, 'a');
INSERT INTO test_clone_source VALUES (2, 'b');

Créez un clone profond et un clone peu profond :

CREATE OR REPLACE TABLE test_clone_deep DEEP CLONE test_clone_source;

CREATE TABLE test_clone_shallow SHALLOW CLONE test_clone_source;

Vérifiez que TBLPROPERTIES sont copiés sur les deux clones :

SHOW TBLPROPERTIES test_clone_source;
SHOW TBLPROPERTIES test_clone_deep;
SHOW TBLPROPERTIES test_clone_shallow;

Vérifiez que les étiquettes du catalogue Unity ne sont pas copiées dans des clones :

SELECT catalog_name, schema_name, table_name, tag_name, tag_value FROM information_schema.table_tags WHERE table_name = 'test_clone_source';
SELECT catalog_name, schema_name, table_name, tag_name, tag_value FROM information_schema.table_tags WHERE table_name = 'test_clone_deep';
SELECT catalog_name, schema_name, table_name, tag_name, tag_value FROM information_schema.table_tags WHERE table_name = 'test_clone_shallow';

Vérifiez que l’historique de Delta Lake n’est pas copié vers les clones :

DESCRIBE HISTORY test_clone_source;
DESCRIBE HISTORY test_clone_deep;
DESCRIBE HISTORY test_clone_shallow;

Nettoyer:

DROP TABLE IF EXISTS test_clone_shallow;
DROP TABLE IF EXISTS test_clone_source;
DROP TABLE IF EXISTS test_clone_deep;

Archivage des données

Vous pouvez utiliser un clone profond pour conserver l’état d’une table à un point dans le temps donné à des fins d’archivage. Vous pouvez synchroniser les clones profonds de manière incrémentielle pour maintenir l’état mis à jour d’une table source pour la récupération d’urgence.

Exécutez la commande suivante une fois par mois pour synchroniser l’archive :

CREATE OR REPLACE TABLE archive_table CLONE my_prod_table

Reproduction du modèle ML

Pour les cas d’utilisation du Machine Learning, vous souhaiterez peut-être archiver une version d’une table utilisée pour entraîner un modèle ML. Les futurs modèles peuvent être testés à l’aide de ce jeu de données archivé. Pour archiver une version de jeu de données avec CLONE, procédez comme suit :

Par exemple, pour archiver la version d’une table utilisée pour entraîner un modèle à la version 15 :

CREATE TABLE model_dataset CLONE entire_dataset VERSION AS OF 15

Expériences à court terme sur une table de production

Pour tester un flux de travail sur une table de production sans endommager la table, créez un clone peu profond. Les clones superficiels vous permettent d’exécuter des charges de travail sur la table clonée, qui référence l’ensemble des données de production, sans affecter les charges de travail de production.

Créez un clone peu profond de la table de production :

CREATE TABLE my_test SHALLOW CLONE my_prod_table;

Exécutez les mises à jour et les validations sur le clone :

UPDATE my_test WHERE user_id is null SET invalid=true;

Une fois prêt, réintégrez les modifications. La fusion utilise les informations de mise à jour dans le clone pour se limiter, lorsque c’est possible, aux seuls fichiers modifiés :

MERGE INTO my_prod_table
USING my_test
ON my_test.user_id <=> my_prod_table.user_id
WHEN MATCHED AND my_test.user_id is null THEN UPDATE *;

Supprimez le clone lorsque vous avez terminé :

DROP TABLE my_test;

Remplacer les propriétés de la table

Les substitutions des propriétés du tableau sont utiles pour :

• Annoter des tables avec des informations sur les propriétaires ou les utilisateurs lors du partage de données avec différentes unités commerciales.
• Archivage de tables Delta Lake si vous avez besoin du versionnement temporel dans l’archive. Vous pouvez spécifier séparément les périodes de rétention des données et des journaux pour la table d’archivage. Par exemple:

SQL

Pour une table Delta Lake :

CREATE OR REPLACE TABLE archive_table CLONE prod.my_table
TBLPROPERTIES (
delta.logRetentionDuration = '3650 days',
delta.deletedFileRetentionDuration = '3650 days'
)

Pour une table Iceberg :

CREATE OR REPLACE TABLE archive_table CLONE prod.my_table
TBLPROPERTIES (
iceberg.logRetentionDuration = '3650 days',
iceberg.deletedFileRetentionDuration = '3650 days'
)

Python

L’API DeltaTable Python est spécifique à Delta Lake.

dt = DeltaTable.forName(spark, "prod.my_table")
tblProps = {
"delta.logRetentionDuration": "3650 days",
"delta.deletedFileRetentionDuration": "3650 days"
}
dt.clone(target="archive_table", isShallow=False, replace=True, tblProps)

Scala

L’API Scala DeltaTable est spécifique à Delta Lake.

val dt = DeltaTable.forName(spark, "prod.my_table")
val tblProps = Map(
"delta.logRetentionDuration" -> "3650 days",
"delta.deletedFileRetentionDuration" -> "3650 days"
)
dt.clone(target="archive_table", isShallow = false, replace = true, properties = tblProps)

Comportement de l’opération de clonage pour l’ancien metastore Hive

Pour une table Delta Lake inscrite dans le metastore Hive ou une collection de fichiers non inscrits en tant que table, le clone a les comportements suivants :

• Les modifications apportées aux clones profonds ou peu profonds n’affectent pas la table source.
• Les clones superficiels référencent les fichiers de données dans le répertoire source. Si vous exécutez VACUUM sur la table source, les clients ne peuvent plus lire ces fichiers de données et cela déclenche un FileNotFoundException. Pour corriger cela, exécutez `clone` avec replace sur le clone superficiel. Si cela se produit souvent, envisagez d’utiliser un clone profond, qui ne dépend pas de la table source.
• Les clones profonds ne dépendent pas de la table source, mais sont coûteux à créer, car ils copient les données et les métadonnées.
• Le clonage avec replace vers une cible qui contient déjà une table à cet emplacement crée un journal Delta s’il n’en existe pas déjà. Exécutez VACUUM pour nettoyer les données existantes.
• Pour les tables Delta Lake existantes, le clonage crée un commit incrémentiel qui inclut uniquement les nouvelles métadonnées et les nouvelles données de la table source depuis le dernier clonage.
• Le clonage d’une table diffère de Create Table As Select (CTAS). Un clone copie les métadonnées de la table source en plus des données. Vous n’avez pas besoin de spécifier de partitionnement, de format, d’invariants, de nullabilité ou d’autres paramètres.
• Une table clonée possède un historique indépendant de sa table source. Les requêtes de déplacement temporel sur une table clonées ne fonctionnent pas avec les mêmes entrées que sur la table source.