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

Si vous supprimez la table de base d’un clone peu profond, le clone devient inutilisable. Par défaut, Databricks vous empêche de supprimer une table de base si elle possède toujours des clones superficiels qui la référencent.

Pour remplacer cette protection, utilisez la DROP TABLE ... FORCE syntaxe. Si vous utilisez FORCE:

• La table de base est supprimée immédiatement.
• Tous les clones superficiels font l’objet d’une rupture et :
  • Les clones peu profonds échouent sur les opérations qui nécessitent la lecture de données ou de métadonnées (par exemple, SELECT, , INSERTUPDATE, DESCRIBE HISTORY, CLONE).
  • Pour permettre le nettoyage, les clones peu profonds sont toujours visibles par le biais d’opérations au niveau des métadonnées (par exemple, , SHOW TABLESDROP TABLE).

Ce comportement s’applique uniquement aux tables gérées par le catalogue Unity. Pour plus d’informations, consultez DROP TABLE.

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 gérées, la suppression de la table source rend la table cible inutilisable pour les clones peu profonds. Les fichiers de données sous-jacents pour les tables externes ne sont pas supprimés par DROP TABLE les opérations, et les clones peu profonds 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 peu profonds gérés d’une table source supprimée continuent de fonctionner pour la période de 7 jours pendant laquelle Unity Catalog prend en charge UNDROP. Si la table source n’est pas restaurée dans cette fenêtre, le clone peu profond cesse de fonctionner lorsque les fichiers de données sources sont supprimés pendant la collecte des ordures.