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
Si vous supprimez la table de base d'un clone superficiel, le clone devient inutilisable. Par default, Databricks vous empêche de supprimer une table de base si elle contient encore des clones superficiels y faisant référence.
Pour contourner cette protection, utilisez la syntaxe DROP TABLE ... FORCE. Si vous utilisez FORCE:
- La table de base est immédiatement supprimée.
- Tous les clones superficiels référençant deviennent rompus et :
- Les clones superficiels échouent lors d'opérations qui nécessitent la lecture de données ou de métadonnées (par exemple,
SELECT,INSERT,UPDATE,DESCRIBE HISTORY,CLONE). - Pour permettre le nettoyage, les clones superficiels restent visibles via des Opérations au niveau des métadonnées (par exemple,
SHOW TABLES,DROP TABLE).
- Les clones superficiels échouent lors d'opérations qui nécessitent la lecture de données ou de métadonnées (par exemple,
Ce comportement s'applique uniquement aux tables gérées par Unity Catalog. Pour plus d'information, consultez DROP TABLE.
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 gérées, la suppression de la table source rompt la table cible pour les clones superficiels. Les fichiers de données sous-jacents pour les 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 de
UNDROPtables gérées pendant environ 7 jours après une commandeDROP TABLE. À partir de Databricks Runtime 13.3 LTS, les clones peu profonds gérés d'une table source supprimée continuent de fonctionner pendant la période de 7 jours durant laquelle Unity Catalog prend en chargeUNDROP. Si la table source n'est pas restaurée dans ce délai, le clone superficiel cesse de fonctionner lorsque les fichiers de données source sont supprimés lors de la récupération de mémoire.