Clone superficiel pour les tables Unity Catalog

Utilisez un clone peu profond pour créer des tables de catalogue Unity avec des privilèges de contrôle d’accès indépendants de leurs tables sources, sans copier les fichiers de données sous-jacents. Le clonage superficiel dans Unity Catalog est pris en charge uniquement pour les tables Delta Lake. Vous ne pouvez pas créer un clone peu profond d’un iceberg ou d’une autre table non delta.

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

Créer un clone superficiel géré par Unity Catalog

Créez un clone peu profond d’une table gérée dans le catalogue Unity.

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

Pour créer un clone peu profond managé sur le catalogue Unity, vous devez disposer des privilèges suivants sur les ressources source et cible.

Comme d’autres instructions de création de table, lorsque vous exécutez SHALLOW CLONE, vous êtes propriétaire de la table cible. Le propriétaire d’une table cible cloné 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 du propriétaire d’une table d’origine.

Créer un clone externe peu profond du catalogue Unity

Créez un clone externe peu profond dans 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 peu profond externe sur le catalogue Unity, vous devez disposer des privilèges suivants sur les ressources source et cible.

Utiliser des tables clonées peu profondes 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 qui la contiennent :

Vous devez également disposer MODIFY d’autorisations sur la cible de l’opération clone pour exécuter les opérations suivantes :

• INSERT
• DELETE
• UPDATE
• MERGE
• CREATE TABLE
• DROP TABLE

Utiliser des tables clonées peu profondes en mode d’accès dédié

Lorsque vous utilisez des clones superficiels dans 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 table source du clone ainsi que de la table cible.

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

Databricks recommande d’utiliser des clones Unity Catalog sur un calcul avec mode d’accès standard, car cela permet de modifier indépendamment les autorisations des cibles de clonage superficiel Unity Catalog et des tables sources correspondantes.

Utiliser VACUUM avec des clones superficiels du catalogue Unity

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’endommage 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. Toutefois, la prise en charge du clonage superficiel dans Unity Catalog assure le suivi des relations entre toutes les tables clonées et les fichiers de données source, de sorte que la liste des fichiers valides est étendue pour inclure les fichiers de données nécessaires pour répondre aux requêtes visant à la fois les tables clonées superficiellement et la table source.

Pour VACUUM un clone peu profond du catalogue Unity, un fichier de données valide est n’importe quel fichier dans le seuil de rétention spécifié pour la table source ou toute table cloné. Les tables managées et les tables externes ont des comportements légèrement différents.

Ce suivi amélioré des métadonnées modifie la façon dont VACUUM les 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, VACUUM les opérations sur la source ou la cible d’une opération de clone peu profond 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.

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 journal Delta du clone superficiel pour vérifier les fichiers de données de table de base auxquels le clone fait toujours référence avant de les vider. Databricks maintient ce lien pendant 7 jours après la suppression d’une table clonée superficiellement afin de prendre en charge l’opération UNDROP. En mode d’accès standard, toutefois, cette autorisation n’est pas requise.

Supprimer la table de base pour un clone peu profond

Vous pouvez supprimer la table de base d’une table gérée par Unity Catalog même lorsque des clones superficiels actifs y font encore référence. Les clones continuent de lire 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, dont la durée par défaut est de 7 jours et qui 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 comprise entre 7 et 30 jours. La configuration de la période de récupération se fait en Aperçu public. 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, permettant aux clones de continuer à lire un certain temps après que la table de base ne soit plus récupérable. Pour récupérer une table de base tombée, utilisez UNDROP.

Limitations

• Le clone superficiel n’est pris en charge que pour les tables Delta Lake. Vous ne pouvez pas créer un clone peu profond d’un iceberg ou d’une autre table non delta.
• Vous ne pouvez pas utiliser CREATE OR REPLACE pour remplacer un clone peu profond existant. Utilisez DROP TABLE suivi de CREATE TABLE, ou utilisez un nouveau nom de table.
• 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 peu profonds à l’aide d’OpenSharing.
• Il est impossible d'imbriquer des clones superficiels, c'est-à-dire que vous ne pouvez pas créer un clone superficiel à partir d'un autre clone superficiel.
• Pour les tables externes, DROP TABLE cela ne supprime pas les fichiers de données sous-jacents, donc 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 ultérieures, les clones superficiels d’une table source supprimée continuent de fonctionner jusqu’à la suppression des fichiers de données source. Consultez Supprimer la table de base pour un clone peu profond.