Clonage superficiel pour les tables Unity Catalog
Aperçu
Cette fonctionnalité est en aperçu public.
La prise en charge du clonage superficiel diffère pour les tables gérées et externes d'Unity Catalog. Pour les tables gérées, utilisez Databricks Runtime 13.3 LTS ou une version ultérieure, et pour les tables externes, utilisez Databricks Runtime 14.3 LTS ou une version ultérieure.
Vous ne pouvez cloner les tables gérées Unity Catalog que vers d'autres tables gérées Unity Catalog, et les tables externes Unity Catalog que vers d'autres tables externes Unity Catalog. VACUUM Le comportement diffère entre les tables gérées et les tables externes. Consultez Utiliser VACUUM avec les clones superficiels Unity Catalog.
Utilisez le clone superficiel pour créer des tables Unity Catalog avec des privilèges de contrôle d'accès indépendants de leurs tables source, sans copier les fichiers de données sous-jacents. Le clone superficiel dans Unity Catalog est pris en charge uniquement pour les tables Delta Lake. Vous ne pouvez pas créer de clone superficiel d'une table Iceberg ou d'une autre table non Delta.
Pour des informations sur le clonage d'une table, consultez Cloner une table sur Databricks.
Créer un clone superficiel géré par Unity Catalog
Créez un clone superficiel d'une table gérée dans Unity Catalog.
CREATE TABLE <catalog-name>.<schema-name>.<target-table-name>
SHALLOW CLONE <catalog-name>.<schema-name>.<source-table-name>
Pour créer un clone superficiel géré sur Unity Catalog, vous devez disposer des privilèges suivants sur les ressources source et cible.
Ressource | Autorisations requises |
|---|---|
Schéma source |
|
Catalogue source |
|
Schéma cible |
|
Catalogue cible |
|
Comme avec d'autres instructions de création de table, lorsque vous exécutez SHALLOW CLONE, vous possédez la table cible. Le propriétaire d'une table cible clonée contrôle les droits d'accès de cette table indépendamment de la table source. Le propriétaire d’une table clonée peut être différent de celui d’une table source.
Créez un clone superficiel externe Unity Catalog
Créez un clone superficiel externe Unity Catalog en spécifiant un emplacement externe.
CREATE TABLE <catalog-name>.<schema-name>.<target-table-name>
SHALLOW CLONE <catalog-name>.<schema-name>.<source-table-name>
LOCATION 's3://<bucket-name>/<path-name>/<target-table-name>'
Pour créer un clone léger externe sur Unity Catalog, vous devez disposer des privilèges suivants sur les ressources source et cible.
Ressource | Autorisations requises |
|---|---|
Schéma source |
|
Catalogue source |
|
Schéma cible |
|
Catalogue cible |
|
Emplacement externe cible |
|
Travailler avec des tables clonées en mode léger en mode d'accès standard
Pour interroger un clone superficiel en mode d'accès standard (anciennement mode d'accès partagé), vous devez disposer des privilèges suivants sur la table et les Ressources contenues :
Ressource | Autorisations requises |
|---|---|
Catalogue |
|
Schéma |
|
Table |
|
Vous devez également disposer des autorisations MODIFY sur la cible de l'opération de clonage pour exécuter les opérations suivantes :
INSERTDELETEUPDATEMERGECREATE TABLEDROP TABLE
Travailler avec des tables clonées superficielles en mode d'accès dédié
Lorsque vous travaillez avec des clones légers Unity Catalog en mode d'accès dédié (anciennement mode d'accès utilisateur unique), vous devez disposer des autorisations sur les ressources de la source de la table clonée et de la table cible.
Pour les queries simples, en plus des autorisations requises sur la table cible, vous devez disposer des autorisations USE sur le catalogue et le schéma source et des autorisations SELECT sur la table source. Pour toutes les queries qui mettent à jour ou insèrent des enregistrements dans la table cible, vous devez également disposer des autorisations MODIFY sur la table source.
Databricks recommande l’utilisation de clones Unity Catalog sur un compute avec le mode d’accès standard, car cela permet des modifications indépendantes des autorisations pour les cibles de clone superficiel Unity Catalog et leurs tables sources.
Utiliser VACUUM avec les clones superficiels de Unity Catalog
Lorsque vous utilisez les tables Unity Catalog comme source et cible d'une opération de clone superficiel, Unity Catalog gère les fichiers de données sous-jacents afin d'améliorer la fiabilité pour la source et la cible de l'opération de clone. Exécuter VACUUM sur la source d'un clone superficiel ne corrompt pas la table clonée.
Normalement, lorsque VACUUM identifie des fichiers valides pour un threshold de rétention donné, seules les métadonnées de la table actuelle sont prises en compte. Cependant, la prise en charge du clonage superficiel pour Unity Catalog assure le suivi des relations entre toutes les tables clonées et les fichiers de données sources, de sorte que les fichiers valides sont étendus pour inclure les fichiers de données nécessaires au retour des queries pour les tables clonées superficiellement et la table source.
Pour VACUUM sur un clone superficiel d'Unity Catalog, un fichier de données valide est tout fichier se trouvant dans le threshold de rétention spécifié pour la table source ou toute table clonée. Les tables gérées et les tables externes ont des comportements légèrement différents.
Ce suivi amélioré des métadonnées modifie la manière dont les VACUUM opérations affectent les fichiers de données sous-jacents pour les tables Delta Lake, avec le comportement suivant :
- Pour les tables gérées, les
VACUUMopérations sur la source ou la cible d'une opération de clone superficielle pourraient supprimer des fichiers de données de la table source. - Pour les tables externes, les opérations
VACUUMne suppriment les fichiers de données de la table source que lorsqu'elles sont exécutées sur la table source. - Seuls les fichiers de données considérés comme non valides pour la table source ou tout clone léger de la source sont supprimés.
- Si plusieurs clones superficiels sont définis pour une seule table source, l'exécution de
VACUUMsur l'une des tables clonées ne supprime pas les fichiers de données valides pour les autres tables clonées.
Databricks recommande de ne jamais exécuter VACUUM avec un paramètre de rétention de moins de 7 jours afin d'éviter de corrompre les transactions longues en cours. Si vous avez besoin d'un threshold de rétention inférieur, découvrez en quoi VACUUM sur les clones superficiels dans Unity Catalog diffère de la façon dont VACUUM affecte les autres tables clonées sur Databricks. Pour plus d'informations, consultez Cloner une table sur Databricks.
Même si vous supprimez une table clonée superficiellement, vous pourriez avoir besoin de l'accès SELECT à cette table clonée superficiellement pour exécuter VACUUM sur la table de base. Databricks lit le log Delta du clone peu profond pour vérifier quels fichiers de données de table de base le clone référence toujours avant de les vacuumiser. Databricks maintient ce Link pendant 7 jours après la suppression d'une table clonée en surface pour prendre en charge l'opération UNDROP. En mode d'accès standard, cependant, cette autorisation n'est pas requise.
Supprimer la table de base pour un clonage superficiel
Vous pouvez supprimer la table de base d'une table gérée par Unity Catalog même si des clones légers en direct y font toujours référence. Les clones continuent de lire les données jusqu'à ce que les fichiers de données de la table de base soient supprimés, ce qui les rend alors inutilisables. Vous pouvez restaurer la table de base avec UNDROP pendant sa période de récupération, qui est default de 7 jours et peut être définie au niveau du catalogue ou du schéma sur 0 (pour désactiver la récupération) ou sur une valeur de 7 à 30 jours. La configuration de la période de récupération est en préversion publique. Si vous ne restaurez pas la table, un processus de purge asynchrone supprime ses fichiers de données après la fin de la période de récupération, de sorte que les clones peuvent continuer à lire les données pendant un certain temps après que la table de base n'est plus récupérable. Pour récupérer une table de base supprimée, utilisez UNDROP.
Certains workspaces appliquent une protection au moment de la suppression pour les tables de base qui comportent des clones superficiels. Si DROP TABLE sur une telle table de base échoue avec l'erreur CANNOT_DROP_BASE_TABLE_REFERENCED_BY_SHALLOW_CLONE, votre workspace applique cette protection. Pour supprimer malgré tout la table de base, utilisez DROP TABLE ... FORCE. La suppression de la table de base avec FORCE rompt les clones superficiels de référence. Les clones échouent sur les opérations qui lisent des données ou des métadonnées (par exemple, SELECT, INSERT, UPDATE, DESCRIBE HISTORY, CLONE), mais restent visibles pour les opérations au niveau des métadonnées (par exemple, SHOW TABLES, DROP TABLE) afin de vous permettre de les nettoyer. Cette protection s'applique uniquement aux tables gérées par Unity Catalog.
Limitations
- Le clone léger est pris en charge uniquement pour les tables Delta Lake. Vous ne pouvez pas créer un clone léger d'une table Iceberg ou d'une autre table non-Delta.
- Vous ne pouvez pas utiliser
CREATE OR REPLACEpour remplacer un clone superficiel existant. UtilisezDROP TABLEsuivi deCREATE TABLE, ou utilisez un nouveau nom de table. - Les clones superficiels sur des tables externes doivent être des tables externes. Les clones peu profonds sur les tables gérées doivent être des tables gérées.
- Vous ne pouvez pas partager de clones superficiels à l'aide d'OpenSharing.
- Vous ne pouvez pas imbriquer de clones superficiels, ce qui signifie que vous ne pouvez pas créer un clone superficiel à partir d'un clone superficiel.
- Pour les tables externes,
DROP TABLEne supprime pas les fichiers de données sous-jacents, de sorte que les clones superficiels ne sont pas affectés lorsque la table source est supprimée. - Pour les tables gérées dans Databricks Runtime 13.3 LTS et versions supérieures, les clones légers d’une table source supprimée continuent de fonctionner jusqu’à ce que les fichiers de données source soient supprimés. Consultez Supprimer la table de base pour un clone léger.