Aller au contenu principal
Dernière mise à jour le

Cloner une table sur Databricks

Clonez une table Delta Lake ou Apache Iceberg à l’aide de la commande CLONE 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 superficiels copient uniquement les métadonnées et référencent les fichiers de données sources, utilisant moins de compute et de stockage que les clones profonds.

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

Pour plus de détails sur l'utilisation du clone avec Unity Catalog, consultez le clone superficiel pour les tables Unity Catalog.

remarque

Databricks recommande d'utiliser OpenSharing pour fournir un accès en lecture seule aux tables entre différentes organisations. Consultez Qu'est-ce qu'OpenSharing ?.

Types de clone​

Les types de clonage suivants sont disponibles :

Type

Syntaxe SQL

Description

Clonage profond

CLONE OU DEEP CLONE

Copie à la fois les données et les métadonnées de la table source vers la cible du clone, y compris les métadonnées de stream. Un Stream qui écrit dans la table source peut être arrêté et poursuivi sur la cible du clone depuis l'endroit où il s'est arrêté.

Clonage superficiel

SHALLOW CLONE

Copie uniquement les métadonnées de la table source vers la cible de clone. Les fichiers de données ne sont pas copiés. Les clones superficiels sont moins chers à créer, car l'opération utilise moins de ressources de compute et d'espace de stockage.

Type

Syntaxe SQL

Description

Clonage profond

CLONE OU DEEP CLONE

Copie à la fois les données et les métadonnées de la table source vers la cible du clone, y compris les métadonnées de stream. Un Stream qui écrit dans la table source peut être arrêté et poursuivi sur la cible du clone depuis l'endroit où il s'est arrêté.

Clonage superficiel

SHALLOW CLONE

Copie uniquement les métadonnées de la table source vers la cible de clone. Les fichiers de données ne sont pas copiés. Les clones superficiels sont moins chers à créer, car l'opération utilise moins de ressources de compute et d'espace de stockage.

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

remarque

Les tables de streaming et les vues matérialisées ne prennent pas en charge CLONE. Vous ne pouvez pas utiliser une table de streaming ou une vue matérialisée comme source ou cible d'un clone profond ou superficiel. Consultez Limitations et Limitations.

Cloner les métriques​

CLONE renvoie les métriques suivantes sous la forme d'un DataFrame à ligne unique une fois l'Opération terminée :

  • source_table_size: Taille de la table source qui est clonée en octets.
  • source_num_of_files: Le nombre de fichiers dans la table source.
  • num_removed_files: Si la table est remplacée, combien de fichiers sont supprimés de la table actuelle.
  • num_copied_files: Nombre de fichiers copiés depuis la source (0 pour les clones superficiels).
  • removed_files_size: Taille en octets des fichiers qui sont supprimés de la table actuelle.
  • copied_files_size: taille en octets des fichiers copiés vers la table.

Exemple de clonage de métriques

Autorisations​

Vous devez configurer les autorisations pour le contrôle d'accès aux tables Databricks et votre fournisseur cloud.

Contrôle d'accès aux tables​

Les autorisations suivantes sont requises pour les clones profonds et superficiels :

  • SELECT autorisation sur la table source.
  • Si vous utilisez CLONE pour créer une nouvelle table, CREATE autorisation sur la base de données dans laquelle vous créez la table.
  • Si vous utilisez CLONE pour remplacer une table, vous devez disposer de la permission MODIFY sur la table.

Autorisations de fournisseur cloud​

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

Les lecteurs d'un clone superficiel 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 rédacteurs ont besoin d’un accès en écriture au répertoire du clone.

Exemples​

Créer des clones profonds ou superficiels​

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

Créer un clone en profondeur :

SQL
CREATE TABLE target_table CLONE source_table;

Remplacez une cible existante :

SQL
CREATE OR REPLACE TABLE target_table CLONE source_table;

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

SQL
CREATE TABLE IF NOT EXISTS target_table CLONE source_table;

Créez une copie superficielle de la dernière version, d'une version spécifique ou d'un timestamp spécifique. Le timestamp peut être une chaîne de date comme '2019-01-01' ou une expression comme date_sub(current_date(), 1).

SQL
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;

Pour plus de détails sur la syntaxe, reportez-vous à CREATE TABLE CLONE.

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

Cet exemple montre les métadonnées qui sont et ne sont pas copiées pendant les CLONE Opérations, spécifiquement 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 des Logs non default, puis insérez des données pour générer l'historique de la table :

SQL
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 superficiel :

SQL
CREATE OR REPLACE TABLE test_clone_deep DEEP CLONE test_clone_source;

CREATE TABLE test_clone_shallow SHALLOW CLONE test_clone_source;
remarque

Dans Unity Catalog, vous ne pouvez pas utiliser CREATE OR REPLACE pour écraser un clone superficiel existant. Utilisez DROP TABLE suivi de CREATE TABLE, ou utilisez un nouveau nom de table. Voir les Limitations.

Confirmez que TBLPROPERTIES sont copiés dans les deux clones :

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

Confirmez que les tags Unity Catalog ne sont pas copiés aux clones :

SQL
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';

Confirmez que l'historique de Delta Lake n'est pas copié vers les clones :

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

Nettoyage :

SQL
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 le clonage profond pour préserver l'état d'une table à un moment donné à des fins d'archivage. Vous pouvez synchroniser les clones profonds de manière incrémentielle pour maintenir un état à jour d'une table source pour la reprise après sinistre.

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

SQL
CREATE OR REPLACE TABLE archive_table CLONE my_prod_table

Reproductibilité du modèle ML​

Pour les cas d'utilisation du Machine Learning, vous souhaiterez peut-être archiver une version d'une table qui a été utilisée pour entraîner un modèle de ML. Les futurs modèles peuvent être testés à l'aide de ce dataset archivé. Pour archiver une version de dataset 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 :

SQL
CREATE TABLE model_dataset CLONE entire_dataset VERSION AS OF 15

Experimentations à court terme sur une table de production​

Pour tester un workflow sur une table de production sans corrompre la table, créez un clone superficiel. Les clones superficiels vous permettent d'exécuter des charges de travail sur la table clonée, qui référence toutes les données de production, mais n'affecte aucune charge de travail de production.

Créer un clone superficiel de la table de production :

SQL
CREATE TABLE my_test SHALLOW CLONE my_prod_table;
remarque

Dans Unity Catalog, vous ne pouvez pas utiliser CREATE OR REPLACE pour écraser un clone superficiel existant. Utilisez DROP TABLE suivi de CREATE TABLE, ou utilisez un nouveau nom de table. Voir les Limitations.

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

SQL
UPDATE my_test WHERE user_id is null SET invalid=true;

Lorsque vous êtes prêt, Merge les modifications. Merge utilise les informations de mise à jour dans le clone pour élaguer uniquement les fichiers modifiés lorsque cela est possible :

SQL
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 une fois terminé :

SQL
DROP TABLE my_test;

Remplacer les propriétés de la table​

Les remplacements de propriétés de table sont utiles pour :

  • Annoter les tables avec des information sur le propriétaire ou l'utilisateur lors du partage de données avec différentes unités commerciales.
  • Archivage des tables Delta Lake lorsque vous avez besoin de time travel sur l'archive. Vous pouvez spécifier indépendamment les périodes de conservation des données et des logs pour la table d'archive. Par exemple :

Pour une table Delta Lake :

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

Pour une table Iceberg :

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

Comportement de l'opération de clonage pour le Hive metastore hérité​

important

Dans Databricks Runtime 13.3 LTS et versions ultérieures, les tables gérées par Unity Catalog prennent en charge les clonages superficiels. Le comportement de clonage pour les tables Unity Catalog diffère du comportement de clonage dans d'autres environnements. Consultez Clonage superficiel pour les tables Unity Catalog.

Pour une table Delta Lake enregistrée dans le Hive metastore ou une collection de fichiers non enregistrés en tant que table, le clonage a les comportements suivants :

  • Les modifications apportées aux clones profonds ou superficiels n'affectent pas la table source.
  • Les clones superficiels font référence aux 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 soulève une FileNotFoundException. Pour réparer, exécutez un clone avec replace sur le clone superficiel. Si cela se produit souvent, envisagez d'utiliser un clone en profondeur, 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 à la fois les données et les métadonnées.
  • Le clonage avec replace vers une cible qui possède déjà une table à ce chemin crée un Log Delta s'il n'en existe pas. Exécuter VACUUM pour nettoyer toutes les données existantes.
  • Pour les tables Delta Lake existantes, le clonage crée un nouveau commit incrémental qui inclut uniquement les nouvelles métadonnées et 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 le partitionnement, le format, les invariants, la nullabilité ou d’autres paramètres.
  • Une table clonée a un historique indépendant de sa table source. Les query Time travel sur une table clonée ne fonctionnent pas avec les mêmes entrées que sur la table source.
Sur cette page