Clonage léger pour les tables Unity Catalog

Important

Cette fonctionnalité est disponible en préversion publique.

Important

La prise en charge des clones peu profonds diffère pour les tables gérées et externes de Unity Catalog. Pour les tables managées, utilisez Databricks Runtime 13.3 et versions ultérieures, et pour les tables externes, utilisez Databricks Runtime 14.2 et versions ultérieures.

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 L'utilisation de VACUUM avec les clones superficiels du catalogue Unity.

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 le catalogue Unity vous permet de créer des tables dont les privilèges de contrôle d'accès sont indépendants de ceux des tables parentes, sans avoir à copier les fichiers de données sous-jacents.

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.

Ressource	Autorisations requises
schéma source	USE SCHEMA
Catalogue source	USE CATALOG
Schéma cible	USE SCHEMA, CREATE TABLE
Catalogue cible	USE CATALOG

Comme d’autres instructions de création de table, l’utilisateur qui crée un clone peu profond possè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. Cela signifie que le propriétaire d’une table cloné peut être différent du propriétaire d’une table source.

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.

Ressource	Autorisations requises
schéma source	USE SCHEMA
Catalogue source	USE CATALOG
Schéma cible	USE SCHEMA, CREATE TABLE
Catalogue cible	USE CATALOG
Emplacement cible externe	CREATE EXTERNAL TABLE

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 contenues.

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

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

• Insérer des enregistrements
• Supprimer des enregistrements
• Mettre à jour les enregistrements
• MERGE
• CREATE TABLE
• DROP TABLE

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

Lorsque vous utilisez des clones peu profonds du catalogue Unity en mode d’accès dédié (anciennement mode d’accès utilisateur unique), vous devez disposer d’autorisations sur les ressources de la source de table clonées, 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 des USE autorisations sur le catalogue et le schéma source, ainsi que des SELECT autorisations 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 sur le calcul avec le mode d’accès standard, car cela permet une évolution indépendante des autorisations pour les cibles de clone superficiel Unity Catalog et leurs tables sources.

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’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. Toutefois, la prise en charge du clonage superficiel pour Unity Catalog effectue le suivi des relations entre toutes les tables clonées et les fichiers de données sources. Par conséquent, les fichiers valides sont étendus pour inclure les fichiers de données nécessaires pour retourner des requêtes pour toute table clonée superficiellement 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 modifie la façon dont VACUUM les opérations affectent les fichiers de données sous-jacents pour 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. Pour plus d’informations, consultez Cloner une table sur Azure Databricks.

En outre, même si une table clonée peu profondément est supprimée, vous aurez peut-être besoin d'accéder à cette table clonée peu profondément pour exécuter SELECT sur la table de base. Databricks lit le journal Delta du clone peu profond 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 conserve ce lien pendant 7 jours après la suppression d’une table clonée de manière superficielle pour 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 la table de base d’un clone peu profond est supprimée, 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 peu profonds font l’objet d’une rupture et :
  • Échec sur les opérations qui nécessitent la lecture de données ou de métadonnées (par exemple, SELECT, INSERT, UPDATE, DESCRIBE HISTORY, CLONE).
  • Sont toujours visibles par le biais d’opérations au niveau des métadonnées (par exemple, SHOW TABLES, DROP TABLE) pour autoriser le nettoyage.

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

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 utiliser REPLACE ou CREATE OR REPLACE pour remplacer un clone peu profond existant. Au lieu de cela, DROP le clone peu profond et exécuter une nouvelle instruction CREATE.
• Vous ne pouvez pas partager de clones superficiels à l’aide du partage Delta.
• 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.