Partager via

Clone superficiel pour les tables Unity Catalog

  • Article

Important

La prise en charge des clones superficiels pour les tables managées Unity Catalog est en préversion publique dans Databricks Runtime 13.3 et versions ultérieures. La prise en charge des clones superficiels pour les tables externes Unity Catalog est en préversion publique dans Databricks Runtime 14.2 et versions ultérieures.

Vous pouvez utiliser un clone superficiel pour créer des tables Unity Catalog à partir de tables Unity Catalog existantes. La prise en charge des clones superficiels pour Unity Catalog vous permet de créer des tables avec des privilèges de contrôle d’accès indépendants de leurs tables parentes sans avoir à copier les fichiers de données sous-jacents.

Important

Vous pouvez uniquement cloner des tables managées de Unity Catalog vers des tables managées par Unity Catalog et des tables externes de Unity Catalog vers des tables externes de Unity Catalog. Le comportement VACUUM diffère entre les tables managées et externes. Consultez Clones superficiels vides et Unity Catalog.

Pour plus d’informations sur le clone Delta, consultez Cloner une table sur Azure Databricks.

Pour plus d’informations sur les tables d’Unity Catalog, consultez Créer des tables dans Unity Catalog.

Créer un clone superficiel dans Unity Catalog

Vous pouvez créer un clone superficiel dans Unity Catalog à l’aide de la même syntaxe que celle disponible pour les clones superficiels dans tout le produit, comme illustré dans l’exemple de syntaxe suivant :

CREATE TABLE <catalog-name>.<schema-name>.<target-table-name> SHALLOW CLONE <catalog-name>.<schema-name>.<source-table-name>

Pour créer un clone superficiel sur Unity Catalog, vous devez disposer de privilèges suffisants sur les ressources sources comme cibles, comme indiqué dans le tableau suivant :

Ressource Autorisations requises
Table source SELECT
source_schema USE SCHEMA
Catalogue source USE CATALOG
Schéma cible USE SCHEMA, CREATE TABLE
Catalogue cible USE CATALOG
Gérer les emplacements externes (tables externes uniquement) CREATE EXTERNAL TABLE

Comme d’autres instructions « create table », l’utilisateur qui crée un clone superficiel est le propriétaire de la table cible. Le propriétaire d’une table clonée cible peut contrôler les droits d’accès de cette table indépendamment de la table source.

Remarque

Le propriétaire d’une table clonée peut être différent du propriétaire d’une table source.

Interroger ou modifier une table clonée superficielle sur Unity Catalog

Important

Les instructions de cette section décrivent les privilèges nécessaires pour le calcul configuré avec le mode d’accès partagé. Pour le mode d’accès utilisateur unique, consultez Utiliser des tables clonées superficielles en mode d’accès utilisateur unique.

Pour interroger un clone superficiel sur Unity Catalog, vous devez disposer des privilèges suffisants sur la table et les ressources qu’elle contient, comme indiqué dans le tableau suivant :

Ressource Autorisations requises
Catalogue USE CATALOG
schéma USE SCHEMA
Table SELECT

Vous devez également disposer d’autorisations MODIFY sur la cible de l’opération de clonage pour effectuer les actions suivantes :

  • Insérer des enregistrements
  • Supprimer des enregistrements
  • Enregistrements de mises à jour
  • MERGE
  • CREATE OR REPLACE TABLE
  • DROP TABLE

Clones superficiels vides et Unity Catalog

Important

Ce comportement est disponible en préversion publique dans Databricks Runtime 13.3 LTS et versions ultérieures pour les tables managées et Databricks Runtime 14.2 et versions ultérieures pour les tables externes.

Lorsque vous utilisez des tables managées Unity Catalog pour la source et la cible d’une opération de clonage superficiel, Unity Catalog gère les fichiers de données sous-jacents pour améliorer la fiabilité de la source et de la cible de l’opération de clonage. L’exécution de VACUUM sur la source d’un clone superficiel n’interrompt pas la table clonée.

Normalement, lorsque VACUUM identifie des fichiers valides pour un seuil de rétention donné, seules les métadonnées de la table actuelle sont prises en compte. L’assistance des clones superficiels pour Unity Catalog suit les relations entre toutes les tables clonées et les fichiers de données sources. Les fichiers valides sont ainsi développés pour inclure les fichiers de données nécessaires pour retourner des requêtes pour toute table clonée superficielle ainsi que la table source.

Cela signifie que pour la sémantique VACUUM de clonage superficiel Unity Catalog, un fichier de données valide correspond à n’importe quel fichier situé dans le seuil de rétention spécifié pour la table source ou toute table clonée. Les tables managées et les tables externes ont une sémantique légèrement différente.

Ce suivi amélioré des métadonnées change l’impact des opérations VACUUM sur les fichiers de données qui sauvegardent les tables Delta, avec la sémantique suivante :

  • Pour les tables managées, les opérations VACUUM sur la source ou la cible d’une opération de clonage superficiel peuvent supprimer des fichiers de données de la table source.
  • Pour les tables externes, les opérations VACUUM suppriment uniquement les fichiers de données de la table source lors de l’exécution sur la table source.
  • Seuls les fichiers de données qui ne sont pas considérés comme valides pour la table source ou tout clone superficiel sur la source sont supprimés.
  • Si plusieurs clones superficiels sont définis sur une table source unique, l’exécution de VACUUM sur l’une des tables clonées ne supprime pas les fichiers de données valides pour d’autres tables clonées.

Remarque

Databricks recommande de ne jamais exécuter VACUUM avec un paramètre de rétention inférieur à 7 jours pour éviter d’endommager les transactions en cours. Si vous devez exécuter VACUUM avec un seuil de rétention inférieur, assurez-vous de comprendre pourquoi l’exécution de VACUUM sur les clones superficiels dans Unity Catalog est différente de la façon dont VACUUM interagit avec d’autres tables clonées sur Azure Databricks. Consultez Cloner une table sur Azure Databricks.

Utiliser des tables clonées superficielles en mode d’accès utilisateur unique

Lorsque vous utilisez des clones superficiels Unity Catalog en mode d’accès utilisateur unique, vous devez disposer d’autorisations sur les ressources de la source de table clonée ainsi que sur la table cible.

Cela signifie que pour les requêtes simples, en plus des autorisations requises sur la table cible, vous devez disposer d’autorisations USE sur le catalogue et le schéma source et d’autorisations SELECT sur la table source. Pour toutes les requêtes qui mettent à jour ou insèrent des enregistrements dans la table cible, vous devez également disposer d’autorisations MODIFY sur la table source.

Databricks recommande d’utiliser des clones Unity Catalog pour le calcul avec le mode d’accès partagé. Cela permet une évolution indépendante des autorisations pour les cibles de clones superficiels Unity Catalog et leurs tables sources.

Limites

  • Les clones superficiels sur des tables externes doivent être des tables externes. Les clones superficiels sur les tables managées doivent être des tables managées.
  • Vous ne pouvez pas partager de clones superficiels à l’aide du partage Delta.
  • Vous ne pouvez pas imbriquer de clones superficiels et ne pouvez donc pas créer de clone superficiel à partir d’un clone superficiel.
  • Pour les tables managées, la suppression de la table source interrompt la table cible pour les clones superficiels. Les fichiers de données qui sauvegardent des tables externes ne sont pas supprimés par les opérations DROP TABLE, et les clones superficiels des tables externes ne sont donc pas affectés par la suppression de la source.
  • Unity Catalog permet aux utilisateurs d’accéder à des tables managées UNDROP pendant environ 7 jours après une commande DROP TABLE. Dans Databricks Runtime 13.3 LTS et versions ultérieures, les clones superficiels managés basés sur une table managée supprimée continuent de fonctionner pendant cette période de 7 jours. Si vous n’exécutez pas UNDROP sur la table source dans cette fenêtre, le clone superficiel cesse de fonctionner une fois que les fichiers de données de la table source sont récupérés par le garbage collector.