Tables gérées par Unity Catalog pour Delta Lake et Apache Iceberg
Les tables gérées par Unity Catalog sont le type de table par default et recommandé dans Databricks pour Delta Lake et Apache Iceberg. Unity Catalog gère toutes les responsabilités de lecture, d'écriture, de stockage et d'optimisation. Voir Convertir les tables Delta Lake externes ou étrangères en tables gérées par Unity Catalog.
Les fichiers de données pour les tables gérées sont stockés dans le schéma ou le catalogue qui les contient. Voir Spécifier un emplacement de stockage géré dans Unity Catalog.
Par rapport aux tables externes et étrangères, les tables gérées coûtent moins cher à stocker et à interroger, se maintiennent et s'optimisent automatiquement, et restent accessibles aux clients externes via des APIs ouvertes.
Vous pouvez travailler avec des tables gérées dans toutes les langues et tous les produits pris en charge dans Databricks. Vous avez besoin de certains privilèges pour créer, mettre à jour, supprimer ou interroger des tables gérées. Voir Gérer les privilèges dans Unity Catalog.
Cette page décrit uniquement les tables gérées par Unity Catalog. Pour les tables gérées dans le Hive metastore hérité, consultez Objets de base de données dans le Hive metastore hérité.
Avantages des tables gérées par Unity Catalog
Les tables gérées par Unity Catalog optimisent les coûts de stockage et la vitesse des requêtes, et permettent l’interopérabilité avec des outils tiers pour Delta Lake et Apache Iceberg. Pour simplifier la gestion de données et les performances, ces tables gérées utilisent des technologies basées sur l’IA, telles que la compaction de la taille des fichiers et la collecte intelligente de statistiques.
Les tables gérées prennent en charge l'interopérabilité en permettant l'accès depuis les clients Delta Lake et Apache Iceberg. Consultez l'accès aux données Databricks via des systèmes externes.
Les fonctionnalités suivantes sont propres aux tables gérées Unity Catalog et ne sont pas disponibles pour les tables externes et les tables étrangères :
Fonctionnalité | Avantages | Configuration |
|---|---|---|
Active les transactions multi-déclarations sur les tables, une planification de query plus rapide, des modifications de schéma et de contraintes applicables, ainsi que des écritures sécurisées depuis des moteurs externes. | Désactivé par « default ». Pour l’activer, définissez la propriété de table | |
Optimise automatiquement le layout des données et le compute à l'aide de l'IA, sans opérations de maintenance manuelles. Databricks recommande d'activer l'optimisation prédictive pour toutes les tables gérées afin de réduire les coûts de stockage et de compute. | Activé par default pour les comptes créés le ou après le 11 novembre 2024. Databricks l'active progressivement pour les comptes existants. Pour configurer, consultez Enable predictive optimization. | |
Exécutez plusieurs instructions SQL sur une ou plusieurs tables en un seul commit atomique avec des garanties ACID. Toutes les modifications réussissent ensemble ou sont annulées ensemble. À utiliser pour les procédures stockées et les scripts SQL. | Désactivé par default. Pour choisir un mode de transaction, consultez Transaction modes. Les écritures dans les tables Apache Iceberg gérées sont en Private Preview. | |
Pour les tables avec optimisation prédictive, sélectionne et met à jour automatiquement les clés de clustering à mesure que les modèles de query changent afin d'améliorer les performances et de réduire les coûts. | Désactivé par default. Pour configurer, consultez Enable liquid clustering. | |
Mise en cache des métadonnées | La mise en cache en mémoire des métadonnées de transaction améliore les performances des queries en minimisant les requêtes vers le Log des transactions stocké dans le cloud. | Activé par default. Non configurable. |
Accélère les recherches de sous-chaînes et de mots-clés sur les colonnes de texte à l'aide des fonctions | Désactivé par default. Créer avec En bêta. Nécessite Databricks Runtime 18.2 et versions ultérieures. | |
Suppression automatique des fichiers après une commande | Lorsque vous supprimez une table gérée, Databricks supprime les fichiers de données dans le stockage cloud après l'expiration de la période de récupération (7 jours par default), ce qui réduit les coûts de stockage. Pour les tables externes, vous devez supprimer manuellement les fichiers de votre compartiment de stockage. | Activé par default. Vous pouvez configurer la période de récupération au niveau du catalogue ou du schéma. Consultez Supprimer une table gérée. |
Accéder aux données Databricks à l'aide de systèmes externes
Les tables gérées prennent en charge l'interopérabilité en autorisant l'accès depuis les clients Delta Lake et Apache Iceberg.
Grâce aux APIs ouvertes et à la distribution d'identifiants, Unity Catalog permet aux moteurs externes tels que Trino, DuckDB, Apache Spark, Daft et aux moteurs intégrés au catalogue REST Iceberg, tels que Dremio, d'accéder aux tables gérées. Pour les clients externes qui ne prennent pas en charge les APIs ouvertes, vous pouvez utiliser le Mode de compatibilité pour lire les tables gérées à l'aide de n'importe quel client Delta Lake ou Apache Iceberg. OpenSharing, un protocole open source, permet le Data Sharing sécurisé et gouverné avec des Partenaires et des plateformes externes.
Consultez les intégrations pour obtenir une liste des moteurs externes pris en charge, ou consultez la documentation de votre moteur s'il ne figure pas dans cette liste.
Les APIs ouvertes suivantes permettent aux systèmes externes d'accéder aux tables gérées par Unity Catalog :
- L' API REST Unity dispose d'un accès en lecture, en écriture et en création pour les clients Delta Lake aux tables Delta Lake gérées.
- Iceberg REST Catalog (IRC) dispose d'un accès en lecture, écriture et création pour les clients Apache Iceberg vers les tables Apache Iceberg gérées, et d'un accès en lecture seule aux tables Delta Lake avec lectures Apache Iceberg activées.
Les deux APIs prennent en charge la fourniture d'informations d'identification, qui procure des informations d'identification temporaires et limitées, héritant des privilèges du principal Databricks demandeur, ce qui permet de maintenir les contrôles de gouvernance et de sécurité.
OpenSharing est un protocole open source qui permet un accès sécurisé et gouverné aux données pour les Partenaires et plateformes externes. Vous pouvez utiliser OpenSharing pour accorder aux Partenaires un accès temporaire en lecture seule.
Toutes les lectures et écritures vers des tables gérées doivent utiliser les noms de table, de catalogue et de schéma là où ils existent. Par exemple, catalog_name.schema_name.table_name. L'accès basé sur le chemin aux tables gérées Unity Catalog n'est pas pris en charge (sauf en Mode de compatibilité) car il contourne les contrôles d'accès Unity Catalog et empêche les fonctionnalités de table gérée de fonctionner correctement.
Créer une table gérée
Pour créer une table gérée, vous devez avoir :
USE SCHEMAsur le schéma parent de la table.USE CATALOGsur le catalogue parent de la table.CREATE TABLEsur le schéma parent de la table.
Utilisez la syntaxe suivante pour créer une table gérée vide. Remplacez les valeurs d'espace réservé :
<catalog-name>: Le nom du catalogue qui contiendra la table.<schema-name>: le nom du schéma contenant la table.<table-name>: un nom pour la table.<column-specification>: Le nom et le type de données de chaque colonne.
- SQL
- Python
-- Create a managed Delta table
CREATE TABLE <catalog-name>.<schema-name>.<table-name>
(
<column-specification>
);
-- Create a managed Iceberg table
CREATE TABLE <catalog-name>.<schema-name>.<table-name>
(
<column-specification>
)
USING iceberg;
Créez une table Delta Lake gérée à l'aide de saveAsTable():
from pyspark.sql.types import StructType, StructField, StringType
schema = StructType([StructField("<column-name>", StringType())])
spark.createDataFrame([], schema).write \
.saveAsTable("<catalog-name>.<schema-name>.<table-name>")
Vous pouvez également utiliser l'DeltaTableBuilder API pour les options spécifiques à Delta, telles que les colonnes générées et les propriétés de table :
from delta.tables import DeltaTable
DeltaTable.create(spark) \
.tableName("<catalog-name>.<schema-name>.<table-name>") \
.addColumn("<column-name>", "<data-type>") \
.property("<key>", "<value>") \
.execute()
Créer une table Apache Iceberg gérée :
from pyspark.sql.types import StructType, StructField, StringType
schema = StructType([StructField("<column-name>", StringType())])
spark.createDataFrame([], schema).write \
.format("iceberg") \
.saveAsTable("<catalog-name>.<schema-name>.<table-name>")
Pour maintenir les performances sur les lectures et les écritures, Databricks exécute périodiquement des opérations pour optimiser les métadonnées des tables Apache Iceberg gérées. Cette tâche est effectuée à l'aide du compute Serverless, qui dispose de MODIFY autorisations sur la table Apache Iceberg. Cette opération écrit uniquement dans les métadonnées de la table, et le compute ne maintient les autorisations sur la table que pendant la durée du job.
Pour créer une table Apache Iceberg, spécifiez explicitement USING iceberg. Autrement, Databricks crée une table Delta Lake by default.
Vous pouvez créer des tables gérées à partir des résultats de query ou des Opérations d'écriture de DataFrame. Les articles suivants présentent quelques-uns des nombreux modèles que vous pouvez utiliser pour créer une table gérée sur Databricks :
Pour créer une copie d'une table gérée existante, utilisez clone. Les tables Delta Lake gérées prennent en charge le clonage profond et superficiel. Les tables Apache Iceberg gérées prennent uniquement en charge le clonage profond. Voir Cloner une table sur Databricks et Cloner une table Iceberg gérée.
Suppression d'une table gérée.
Pour supprimer une table gérée, vous devez disposer des éléments suivants :
MANAGEsur la table ou vous devez être le propriétaire de la table.USE SCHEMAsur le schéma parent de la table.USE CATALOGsur le catalogue parent de la table.
Pour supprimer une table gérée, exécutez la commande suivante :
- SQL
- Python
DROP TABLE IF EXISTS catalog_name.schema_name.table_name;
spark.sql("DROP TABLE IF EXISTS catalog_name.schema_name.table_name")
Alternativement, dans Databricks Runtime 18.2 et versions ultérieures, utilisez spark.catalog.dropTable():
spark.catalog.dropTable("catalog_name.schema_name.table_name", ifExists=True)
Unity Catalog prend en charge la commande UNDROP TABLE pour récupérer les tables gérées supprimées accidentellement. By default, les tables sont récupérables pendant 7 jours après avoir été supprimées. Une fois la période de récupération terminée, Databricks supprime les fichiers de données sous-jacents de votre tenant cloud dans les 48 heures.
Configurer la période de récupération
Aperçu public
La période de récupération configurable est en préversion publique.
Vous pouvez configurer la durée pendant laquelle les tables gérées supprimées restent récupérables au niveau du catalogue ou du schéma. Si les périodes de récupération sont définies aux deux niveaux, le paramètre au niveau du schéma prévaut pour les tables de ce schéma.
Pour configurer la période de récupération, vous devez disposer du privilège MANAGE ou être propriétaire du catalogue ou du schéma. Ce paramètre s'applique uniquement aux tables supprimées après sa configuration. Cela n'affecte pas les tables qui ont déjà été supprimées.
La période de récupération peut être de 0 heure, ce qui désactive la récupération, ou comprise entre 7 et 30 jours. Une période plus longue protège contre les suppressions accidentelles de données critiques, tandis qu'une période plus courte supprime plus rapidement les données supprimées afin d'économiser les coûts de stockage dans les pipelines ETL qui créent et suppriment fréquemment des tables. Lorsqu'elle est définie sur 0, les tables supprimées ne peuvent pas être récupérées avec UNDROP. Databricks supprime les fichiers de données du stockage cloud dans les 48 heures suivant la suppression.
Pour définir la période de récupération, utilisez ALTER CATALOG ou ALTER SCHEMA avec la clause RETAIN DROPPED TO :
- SQL
- Python
-- Set a 30-day recovery period on a catalog
ALTER CATALOG my_catalog RETAIN DROPPED TO 30 DAYS;
-- Set a 7-day recovery period on a schema (overrides the catalog setting)
ALTER SCHEMA my_catalog.my_schema RETAIN DROPPED TO 7 DAYS;
spark.sql("ALTER CATALOG my_catalog RETAIN DROPPED TO 30 DAYS")
spark.sql("ALTER SCHEMA my_catalog.my_schema RETAIN DROPPED TO 7 DAYS")
Vous pouvez également définir la période de récupération lors de la création d'un catalogue ou d'un schéma avec la clause RETAIN DROPPED FOR :
- SQL
- Python
CREATE CATALOG my_catalog RETAIN DROPPED FOR 30 DAYS;
CREATE SCHEMA my_catalog.my_schema RETAIN DROPPED FOR 7 DAYS;
spark.sql("CREATE CATALOG my_catalog RETAIN DROPPED FOR 30 DAYS")
spark.sql("CREATE SCHEMA my_catalog.my_schema RETAIN DROPPED FOR 7 DAYS")
Pour vérifier la période de récupération actuelle, exécutez DESCRIBE EXTENDED. La sortie comprend une ligne Recovery Period Hours :
- SQL
- Python
DESCRIBE CATALOG EXTENDED my_catalog;
DESCRIBE SCHEMA EXTENDED my_catalog.my_schema;
spark.sql("DESCRIBE CATALOG EXTENDED my_catalog").show()
spark.sql("DESCRIBE SCHEMA EXTENDED my_catalog.my_schema").show()