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.
Databricks recommande d'utiliser des tables gérées afin de tirer parti des avantages suivants, par rapport aux tables externes et aux tables étrangères:
- Réduction des coûts de stockage et de compute.
- Performances de query plus rapides pour tous les types de clients.
- Maintenance et optimisation automatiques des tables.
- Sécurisez l'accès pour les clients externes via des APIs ouvertes.
- Prise en charge des formats Delta Lake et Apache Iceberg.
- Mises à niveau automatiques vers les dernières fonctionnalités de la plateforme.
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 |
|---|---|---|
Permet des transactions multi-énoncés entre les tables, une planification de requêtes plus rapide en servant les métadonnées directement depuis Unity Catalog, des modifications de schéma et de contraintes applicables, et 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 de vos données et le compute à l'aide de l'IA, sans nécessiter d'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. Exécutions automatiques :
| Activé par default pour tous les nouveaux comptes créés à partir du 11 novembre 2024. Pour les comptes actuels, Databricks active progressivement l'optimisation prédictive par default. Voir Vérifier si l'optimisation prédictive est activée. Pour configurer, consultez Activer l'optimisation prédictive. | |
Vous permet d'exécuter plusieurs instructions SQL sur une ou plusieurs tables sous la forme d'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 le scriptage SQL dans les charges de travail d'entreposage de données stratégiques. Les transactions qui écrivent dans les tables gérées Apache Iceberg sont en aperçu privé. | Désactivé par default. Utilisez | |
Pour les tables avec une optimisation prédictive, le clustering liquide sélectionne intelligemment les clés de clustering et les met à jour automatiquement à mesure que les modèles de query changent pour améliorer les performances et réduire les coûts. | Désactivé par default. Pour configurer, consultez Activer le clustering fluide. | |
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 query en minimisant les requêtes vers les Logs de transaction stockés 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 En bêta et nécessite Databricks Runtime 18.2 et versions ultérieures. | Désactivé par default. Créer avec | |
Suppression automatique des fichiers après une commande | Si 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.
- Le catalogue Iceberg REST (IRC) offre un accès en lecture, écriture et création aux clients Apache Iceberg pour les tables Apache Iceberg gérées, et un accès en lecture seule aux tables Delta Lake avec les lectures Apache Iceberg activées (UniForm).
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 d'accès aux tables gérées par Unity Catalog n'est pas pris en charge (sauf en Mode de compatibilité), car il contourne les contrôles d'accès de Unity Catalog et peut entraîner une éventuelle corruption ou perte de données selon votre version de Databricks Runtime ou de client OSS.
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 définie à 0 heure (pour désactiver la récupération) ou entre 7 et 30 jours inclus. Une période de récupération plus longue (jusqu'à 30 jours) offre une protection supplémentaire contre les suppressions accidentelles de données de production critiques. Une période de récupération plus courte, ou sa définition à 0, entraîne la suppression plus rapide des données abandonnées — utile pour les économies de coûts dans les charges de travail qui créent et suppriment fréquemment des tables dans le cadre de pipelines ETL. Définir la période de récupération à 0 signifie que les tables supprimées ne sont pas récupérables à l'aide de UNDROP. Les fichiers de données sont supprimés du stockage cloud dans les 48 heures suivant la suppression de la table.
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()