Convertir des tables Delta Lake externes ou étrangères en tables gérées par le catalogue Unity

Important

La conversion d’une table externe en table managée est généralement disponible.

La conversion d’une table étrangère en table gérée est disponible en préversion publique. Seules les tables étrangères fédérées au moyen de Hive metastore et Glue Federation sont prises en charge.

Pour convertir une table Delta Lake externe ou étrangère en table gérée par le catalogue Unity dans Azure Databricks, utilisez la ALTER TABLE ... SET MANAGED commande ou, pour les tables externes, l’Explorateur de catalogues. La conversion conserve les configurations de table, notamment le nom, les paramètres, les autorisations et les vues, et conserve l’historique des tables.

Par ailleurs, pour les conversions de tables externes, SET MANAGED :

Réduit le temps d’arrêt du lecteur et de l’enregistreur.
Gère les écritures simultanées pendant la conversion.
Vous permet de restaurer une table managée convertie en table externe.
Redirige les lectures et les écritures basées sur le chemin d’accès pour autoriser le code hérité à fonctionner après la conversion.

Bien que vous puissiez également utiliser CREATE TABLE AS SELECT (CTAS) pour convertir une table externe, Databricks SET MANAGED recommande ces avantages.

Pour les conversions de tables étrangères, Databricks définit l’optimisation prédictive sur la table convertie au INHERIT lieu de l’activer automatiquement. Consultez les tables étrangères à l’aide de SQL.

Pour convertir des tables étrangères en tables externes, consultez Convertir une table étrangère en table de catalogue Unity externe.

Prerequisites

Les conditions préalables diffèrent selon que vous convertissez une table externe ou une table étrangère.

Tables externes

La conversion de tables externes en tables managées présente les conditions préalables suivantes :

Format : le tableau doit utiliser le format Delta Lake.
Runtime : vous devez utiliser Databricks Runtime 17.3 LTS ou une version ultérieure, ou le calcul serverless, pour utiliser SET MANAGED, UNSET MANAGED ou TRUNCATE UNIFORM HISTORY.
Lecteurs et enregistreurs : Azure Databricks lecteurs et enregistreurs pour vos tables sources doivent utiliser Databricks Runtime 15.4 LTS ou version ultérieure. Si vos lecteurs ou writers utilisent la version 14.3 LTS ou une version antérieure, veuillez consulter la section Lecteurs et writers hérités.
Clients externes : les clients externes (non Databricks) doivent prendre en charge les lectures dans des tables gérées par le catalogue Unity. Consultez Accéder aux tables avec les clients Delta.
- Utilisez le tableau de bord Accéder aux aperçus pour déterminer si les lecteurs et les enregistreurs qui accèdent à vos tables utilisent Databricks Runtime ou des non Databricks externes.
Compatibilité des fonctionnalités : si votre table comporte minReaderVersion=2, minWriterVersion=7 et tableFeatures={..., columnMapping}, la commande SET MANAGED échoue avec une erreur DELTA_TRUNCATED_TRANSACTION_LOG. Vérifiez si votre table possède ces propriétés à l’aide DESCRIBE DETAILde . Consultez les protocoles et la compatibilité des fonctionnalités Delta Lake.

Après la conversion, les lectures et les écritures basées sur le chemin d’accès sont automatiquement redirigées vers le nouvel emplacement géré avec une légère surcharge de performances. Databricks recommande de migrer tous les accès basés sur le chemin vers l’accès basé sur le nom pour éviter la surcharge des performances. Consultez la redirection basée sur le chemin.

Important

Pour éviter les conflits, annulez les travaux de commande existants OPTIMIZE (clustering liquide, compactage, ZORDER) fonctionnant sur votre table externe et ne planifiez aucun travail pendant que vous convertissez vos tables externes en tables managées.

Tables étrangères

Important

La conversion d’une table étrangère en table gérée est disponible en préversion publique.

La conversion de tables étrangères en tables managées présente les conditions préalables suivantes :

Format de données : la table étrangère doit utiliser le format Delta Lake. Pour effectuer une conversion unique pour Parquet, consultez Convertir en Delta Lake.
Runtime : Databricks Runtime 17.3 ou version ultérieure.
Type de table : le type de table hive metastore (HMS) doit être une table HMS externe. La commande échoue si la table est une table HMS gérée.
Autorisations : autorisations OWNER ou MANAGE sur la table et autorisation CREATE sur le EXTERNAL LOCATION.

Temps d’arrêt et temps de copie des données

La SET MANAGED commande réduit ou élimine les temps d’arrêt par rapport à d’autres approches, telles que DEEP CLONE.

Tables externes

Le processus de conversion pour les tables externes utilise une approche en deux étapes :

Copie de données initiale (sans temps d’arrêt) : la commande copie les données de table et le journal des transactions Delta de l’emplacement externe vers l’emplacement managé. Les lecteurs actifs et les processus d’écriture vers la table externe continuent de fonctionner sans interruption.
Basculer vers l’emplacement managé (temps d’arrêt bref) : les validations effectuées à l’emplacement externe lors de la première étape sont déplacées vers l’emplacement managé, et les métadonnées de la table sont mises à jour pour inscrire le nouvel emplacement managé. Pendant cette étape, toutes les écritures dans l’emplacement externe sont temporairement bloquées, ce qui entraîne un temps d’arrêt pour le processus d’écriture. Les lecteurs sur Databricks Runtime 16.4 LTS ou versions ultérieures n’ont pas de temps d’arrêt, mais les lecteurs sur Databricks Runtime 15.4 LTS et les versions antérieures peuvent rencontrer des temps d’arrêt.

Le tableau suivant indique les temps d’arrêt estimés en fonction de la taille de la table source et sur la base d’un débit estimé de 0,5 à 2 Go par cœur de processeur et par minute :

Taille de la table	Taille de cluster recommandée	Durée estimée de la copie des données	Temps d’arrêt estimé en lecture et en écriture
100 Go ou moins	Entrepôt SQL 32 cœurs / X-Large	~6 min ou moins	~1 à 2 min ou moins
1 To	64 cœurs / 2X-Large SQL Warehouse	Environ 30 minutes	~1 à 2 min
10 To	256 cœurs / 4X-Large SQL Warehouse	~1,5 heures	~1 à 5 min

Note

Les temps d’arrêt peuvent varier en fonction de facteurs tels que la taille du fichier, le nombre de fichiers et le nombre de validations.

Tables étrangères

Le temps d’arrêt de la conversion de table étrangère varie selon que vous utilisez MOVE ou COPY:

Pour MOVE, une interruption de service peut se produire, comme décrit pour les tables externes. Consultez les tables externes.
Pour COPY, vous êtes responsable de la gestion des temps d’arrêt, car le processus de conversion copie la table source vers l’emplacement de stockage managé, créant deux copies distinctes des données. Vous êtes responsable de la désactivation des lectures et des écritures dans la table source dans le catalogue externe et de la migration des charges de travail pour utiliser la nouvelle table managée.

Convertir en table managée

Convertissez une table externe à l’aide de l’Explorateur de catalogues ou de SQL, ou convertissez une table étrangère à l’aide de SQL.

Tables externes à l’aide de l’Explorateur de catalogues (bêta)

Important

La conversion de tables externes en tables managées à l’aide de l’Explorateur de catalogues est en version bêta.

À l’aide de l’Explorateur de catalogues, vous pouvez convertir une ou plusieurs tables externes dans un schéma à la fois.

Accédez à la table ou au schéma que vous souhaitez convertir dans l’Explorateur de catalogues.
Sous À propos de ce tableau (page détails du tableau) ou à propos de ce schéma (page détails du schéma), cliquez sur Explorer les optimisations.
Dans la boîte de dialogue Pourquoi migrer vers des tables gérées par le catalogue Unity ? Cliquez sur Continuer.
Sélectionnez les tables externes à convertir. Si vous avez ouvert la boîte de dialogue à partir d’une page de détails de tableau, l’Explorateur de catalogues sélectionne préalablement votre table. Utilisez la barre de recherche pour rechercher des tables supplémentaires. Les tables managées ne sont pas sélectionnables.
Cliquez sur Créer un bloc-notes de conversion.
Si vous le souhaitez, entrez un nom pour le bloc-notes. Par défaut, cela enregistre le bloc-notes dans votre dossier d’accueil. Cliquez sur Parcourir pour le sauvegarder à un autre emplacement.
Dans le notebook, passez en revue les bonnes pratiques et vérifiez que vous remplissez tous les prérequis.
Exécutez la cellule SET MANAGED Queries.

Une fois la cellule exécutée, le type de tableau s’affiche sous la forme MANAGED au lieu d’EXTERNAL dans l’Explorateur de catalogues. Actualisez la page si l’état ne se met pas à jour immédiatement.

Tables externes utilisant SQL

En fonction de si les lectures Apache Iceberg (UniForm) sont activées pour votre table externe, exécutez l’une des commandes suivantes. Pour vérifier si les lectures Iceberg sont activées dans votre table, consultez Vérifier que les lectures Iceberg sont activées.

Pour les tables externes du catalogue Unity sans lectures Iceberg activées, exécutez la commande suivante :
```
ALTER TABLE catalog.schema.my_external_table SET MANAGED;
```
Après la conversion, vous pouvez activer les lectures Iceberg sur votre table managée sans problèmes de compatibilité.
Pour les tables externes du catalogue Unity avec les lectures Iceberg déjà activées, exécutez la commande suivante :
```
ALTER TABLE catalog.schema.my_external_table SET MANAGED TRUNCATE UNIFORM HISTORY;
```
Inclure TRUNCATE UNIFORM HISTORY pour maintenir les performances et la compatibilité optimales des tables. TRUNCATE UNIFORM HISTORY tronque l’historique UniForm Iceberg uniquement et ne supprime pas l’historique Delta. Cette commande entraîne un bref temps d’arrêt de lecture et d'écriture pour Iceberg après la troncation.

Une fois la conversion de table terminée, les flux de lecture et d’écriture existants échouent. Redémarrez les flux avec les mêmes configurations pour utiliser automatiquement la redirection basée sur le chemin. Vérifiez que vos lecteurs et enregistreurs fonctionnent avec la table managée. Consultez le comportement de streaming.

L’optimisation prédictive est automatiquement activée après la conversion, sauf si vous l’avez désactivée manuellement. Consultez Vérifier si l’optimisation prédictive est activée.

Azure Databricks conserve les données dans votre emplacement externe du catalogue Unity pendant 14 jours pour autoriser la restauration. Consultez Annuler une conversion de table gérée. Après 14 jours, avec l’optimisation prédictive activée, Azure Databricks supprime automatiquement ces données pour récupérer le stockage et économiser des coûts. Si vous désactivez l’optimisation prédictive, exécutez VACUUM (nécessite Databricks Runtime 17.3 LTS ou un calcul serverless ou supérieur) sur la table managée nouvellement convertie après 14 jours pour récupérer vous-même le stockage.

VACUUM my_converted_table

Note

Même avec l’optimisation prédictive activée, les données de votre emplacement externe du catalogue Unity peuvent ne pas être supprimées après 14 jours. Par exemple, cela peut se produire lorsque la table managée est rarement utilisée ou petite. Si les données précédentes sont toujours présentes, exécutez VACUUM manuellement pour les supprimer.

Azure Databricks supprime uniquement les données dans l’emplacement externe. Le journal des transactions Delta et la référence à la table dans le catalogue Unity sont conservés.

Tables étrangères utilisant SQL

Important

La conversion d’une table étrangère en table gérée est disponible en préversion publique.

Pour convertir votre table étrangère du catalogue Unity en vue d’être gérée par Unity Catalog, exécutez la commande suivante :

ALTER TABLE source_table SET MANAGED {MOVE | COPY}

source_table

Une table étrangère existante fédérée dans Unity Catalog.
MOVE

Convertit la table en table gérée et désactive l’accès à la table source dans le catalogue externe.
- L'accès via le catalogue externe ou l'accès basé sur le chemin échoue après la conversion de la table. Tous les lecteurs et les enregistreurs de la table doivent utiliser l’espace de noms Unity Catalog pour l’accès. Par exemple:
```
SELECT * FROM catalog_name.schema_name.table_name;
```
- L'accès basé sur le chemin n'est pas pris en charge et échoue après la conversion de la table. Par exemple:
```
SELECT * FROM delta.`protocol://path/to/table`;
```
- Les exigences relatives à la version du lecteur/writer et à la compatibilité du client sont identiques à celles décrites dans Prérequis et Lecteurs et writers hérités.
- L’optimisation prédictive est définie à INHERIT moins que vous ne l’ayez configuré manuellement. Pour vérifier si l’optimisation prédictive est activée, consultez Vérifier si l’optimisation prédictive est activée.
COPY

Convertit la table en gestion sans modifier ou désactiver l’accès à la table source dans le catalogue externe.
- Pendant la conversion en mode managé, le processus de conversion copie les données de la table source dans l’emplacement de stockage managé défini pour la table étrangère, créant deux copies distinctes : la nouvelle table managée et la table source dans le catalogue externe.
- Contrairement à MOVE où les lectures et écritures échouent, lors de l’utilisation de COPY, vous êtes chargé de désactiver correctement les lectures et les écritures dans la table source du catalogue externe et d'assurer que les charges de travail ont migré vers le nouveau catalogue.

Après la conversion de table, vous devez redémarrer tous les travaux de diffusion en continu (lecture ou écriture) à l’aide de la table étrangère et vérifier que vos lecteurs et enregistreurs fonctionnent avec la table gérée.

Avant la conversion, si vous supprimez la table source dans le catalogue externe, Unity Catalog supprime également la table étrangère. Après avoir converti la table en table gérée, la suppression de la table source dans le catalogue externe n’affecte pas la table managée du catalogue Unity.

Si la commande est interrompue lors de la copie des données, redémarrez-la. La commande reprend à partir de l’endroit où elle s’est arrêtée.

Warning

Databricks vous recommande d’éviter d’exécuter plusieurs SET MANAGED commandes simultanément sur la même table, ce qui peut entraîner un état de table incohérent.

Vérifier la conversion

Pour vérifier que votre table a été convertie en table gérée avec succès, vérifiez si la table Type est MANAGED. Vous pouvez effectuer l’une des opérations suivantes :

Ouvrez un nouvel onglet et accédez à l’Explorateur de catalogues. Sous l’onglet Détails , sous À propos de ce tableau, le type de tableau s’affiche en tant que géré.

Vérifiez la table Type en exécutant la commande SQL suivante :

DESCRIBE EXTENDED catalog_name.schema_name.table_name

Pour vérifier plusieurs tables à la fois ou scripter la vérification, interrogez information_schema.tables plutôt :

SELECT table_type FROM system.information_schema.tables
WHERE table_catalog = 'catalog_name' AND table_schema = 'schema_name' AND table_name = 'table_name';

Lecteurs et writers hérités

Databricks recommande de mettre à niveau tous les clients en lecture et en écriture vers Databricks Runtime 15.4 LTS ou une version supérieure afin d’utiliser toutes les fonctionnalités de SET MANAGED, y compris la conservation de l’historique des tables.

Vous pouvez toujours utiliser SET MANAGED si vous avez des lecteurs ou des enregistreurs sur Databricks Runtime 15.3 ou ci-dessous. Toutefois, après la conversion en table managée, vous pouvez parcourir le temps vers des validations historiques uniquement par version, et non par horodatage.

Si vous restaurez une table externe dans un délai de 14 jours, le voyage dans le temps vers les validations historiques effectuées avant la conversion est réactivé. Le voyage dans le temps à l'aide d'horodatages n'est pas pris en charge pour les validations effectuées sur la table managée convertie entre la conversion et la restauration. Consultez Annuler une conversion de table gérée.

Écrire dans une table après conversion avec Databricks Runtime 15.3 ou version antérieure nécessite de supprimer la fonctionnalité inCommitTimestamp :

ALTER TABLE <table_name> DROP FEATURE inCommitTimestamp;

Redirection basée sur le chemin

Dans Databricks Runtime 18.1 et versions ultérieures, après avoir converti une table externe en table managée Du catalogue Unity, des lectures et des écritures basées sur des chemins dans l’emplacement externe précédent sont automatiquement redirigées vers le nouvel emplacement managé. Une lecture basée sur un chemin correspond à du code tel que SELECT * FROM delta.`/path/to/my_table`. La redirection basée sur le chemin réduit le temps et l’effort nécessaires à la migration vers des tables managées en autorisant le code hérité qui utilise des chemins de stockage pour continuer à fonctionner sans refactorisation.

Les conversions de tables étrangères ne redirigent pas l'accès basé sur le chemin.

Pour les cas d’utilisation à faible latence, Azure Databricks vous recommande de migrer l’accès basé sur le chemin vers l’accès basé sur le nom. La redirection basée sur le chemin entraîne une surcharge de plusieurs centaines de millisecondes pour chaque opération de lecture ou d'écriture basée sur le chemin et nécessite que les anciens journaux Delta restent actifs dans votre emplacement externe dans Unity Catalog. Les lectures et écritures basées sur des noms n’ont pas de surcharge de performances supplémentaires. Consultez Migrer le code basé sur les chemins d’accès vers du code basé sur les noms.

Migrer le code basé sur les chemins en code basé sur les noms

Si vous décidez de ne pas utiliser la redirection basée sur le chemin d’accès, vous pouvez migrer le code hérité. Pour migrer, remplacez les références basées sur le chemin d’accès par des références basées sur des noms.

L’exemple de code suivant contient une référence de table basée sur le chemin d’accès aux fichiers :

SELECT * FROM delta.`/path/to/customers_table`;

Remplacez la référence basée sur le chemin par une référence basée sur un nom à une table externe, comme dans le code suivant :

SELECT * FROM catalog_name.schema_name.customers_table;

Comportement de diffusion en continu

Le streaming avec redirection basée sur le chemin d’accès prend en charge les opérations de lecture et d’écriture dans les versions suivantes de Databricks Runtime :

Les lectures sont prises en charge dans Databricks Runtime 18.1 et versions ultérieures.
Les écritures sont prises en charge dans Databricks Runtime 18.2 et versions ultérieures.

Après la conversion, vous devez redémarrer tous les travaux de streaming afin d’éviter de lire ou d'écrire à l’emplacement précédent de la table.

Les lectures et écritures en streaming basées sur le chemin échouent et s’interrompent au point de contrôle suivant avec un message de migration :

Pour les lectures, le flux génère une erreur : DELTA_STREAMING_INTERRUPTED_BY_MANAGED_TABLE_CONVERSION: The table at <path> has been converted to a Unity Catalog managed table. The stream has been stopped to ensure data consistency. Restart the stream and it will automatically resume from the last committed offset using the converted table.
Pour les écritures de données, le premier micro-lot après la conversion génère une erreur : Operation not allowed: STREAMING WRITE cannot be performed on a table with redirect feature. The no redirect rules are not satisfied [].

Pour résoudre les erreurs, redémarrez les flux avec les mêmes configurations. L’accès basé sur le chemin redirige automatiquement vers la table gérée.

Pour connaître les limitations de redirection basées sur le chemin d’accès, consultez Limitations.

Résolution des échecs de conversion

Cette section décrit comment résoudre les problèmes courants lors de la conversion de tables externes en tables gérées par Unity Catalog à l’aide de SET MANAGED.

`VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED`

Si la conversion échoue, réessayez toujours à l’aide de la même version de Databricks Runtime. Les métadonnées peuvent être sérialisées différemment entre les versions, ce qui provoque un VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED échec si vous réessayez une conversion sur une autre version de Databricks Runtime.

Arrêt du cluster pendant la conversion

Si votre cluster s’arrête pendant la conversion, la commande peut échouer avec DELTA_ALTER_TABLE_SET_MANAGED_INTERNAL_ERROR. Réessayez la commande pour reprendre la conversion.

Table externe endommagée

Si la table externe est déjà endommagée (par exemple, l’état de la table n’est pas valide), la conversion peut échouer avec des erreurs telles que DELTA_TRUNCATED_TRANSACTION_LOG, DELTA_TXN_LOG_FAILED_INTEGRITYou DELTA_STATE_RECOVER_ERRORS. Avant de tenter la conversion, vérifiez que vous pouvez exécuter des opérations de base sur la table externe, telles que DESCRIBE DETAIL.

Échec de validation de fichier

La SET MANAGED commande valide qu’elle a copié tous les fichiers dans la dernière capture instantanée de la table vers le nouvel emplacement de la table managée. Si des fichiers sont manquants, la commande échoue avec une DELTA_ALTER_TABLE_SET_MANAGED_FAILED.FILE_VALIDATION_FAILED erreur.

Pour résoudre ce problème :

Vérifiez les journaux de votre pilote Spark pour identifier les fichiers qui n’ont pas pu être migrés.
Vérifiez que ces fichiers existent à l’emplacement de la table externe source et sont accessibles.
Réessayez la ALTER TABLE ... SET MANAGED commande.

Si le problème persiste, contactez le support Databricks.

Annuler la conversion d’une table gérée

Important

Les commandes de restauration nécessitent le calcul serverless ou Databricks Runtime 17.3 LTS ou une version ultérieure.

Table externe

Après avoir converti une table externe en table managée, vous pouvez restaurer dans les 14 jours à l’aide de la UNSET MANAGED commande. Cela met à jour les métadonnées de table pour qu’elles pointent vers l’emplacement externe d’origine. Databricks conserve toutes les écritures effectuées à l’emplacement managé après la conversion.

Pour revenir à une table externe, exécutez la commande suivante :

ALTER TABLE catalog.schema.my_managed_table UNSET MANAGED;

Gardez à l’esprit les informations suivantes :

Si la commande de restauration est interrompue ou échoue, réexécutez-la pour réessayer.
Vous devez redémarrer vos travaux de streaming après la restauration, comme après une conversion.
Les commits effectués à l’emplacement managé entre la conversion et la restauration autorisent le voyage dans le temps par version, mais pas par horodatage.
Sept jours après la restauration, Azure Databricks supprime automatiquement les données dans l’emplacement managé.

Table étrangère : `MOVE`

Warning

Vous devez exécuter UNSET MANAGED avant de supprimer la table managée. La suppression de la table sans exécution UNSET MANAGED peut entraîner une perte de données ou des incohérences.

Vous pouvez restaurer la migration de la table et récupérer l’accès à la table source dans le catalogue externe à l’aide de la UNSET MANAGED commande. La restauration nécessite deux étapes : vous devez d'abord restaurer la table en tant que table externe, puis supprimer la table externe afin de la fédérer de nouveau en tant que table étrangère.

Pour revenir à une table externe, exécutez la commande suivante :

ALTER TABLE catalog.schema.my_managed_table UNSET MANAGED

Pour re-fédérer la table à une table étrangère, supprimez la table externe avec la commande suivante :

DROP TABLE catalog.schema.my_managed_table

La table étrangère est disponible après la synchronisation de catalogue suivante.

Gardez à l’esprit les informations suivantes :

Pour les validations effectuées sur l'emplacement externe entre la conversion et la restauration, vous pouvez utiliser le voyage dans le temps par version, mais pas par horodatage.
Sept jours après le retour arrière, Databricks supprime les données de l’emplacement géré.

Table étrangère : `COPY`

Pour restaurer la migration de table, vous n’avez pas besoin d’exécuter la UNSET MANAGED commande, car la table source du catalogue externe n’a pas été modifiée. Supprimez la table gérée et Databricks la refédère comme table étrangère après la prochaine synchronisation du catalogue.

Vérifier l'annulation

Vérifiez les restaurations différemment selon qu'il s'agit de tables externes ou de tables étrangères.

Tables externes

Pour vérifier que votre table gérée a bien été reconvertie en table externe, vérifiez si la table Type est EXTERNAL. Vous pouvez effectuer l’une des opérations suivantes :

Ouvrez un nouvel onglet et accédez à l’Explorateur de catalogues. Sous l’onglet Détails , sous À propos de ce tableau, le type de tableau s’affiche en tant qu’externe.

Vérifiez la table Type en exécutant la commande SQL suivante :

DESCRIBE EXTENDED catalog_name.schema_name.table_name

Pour vérifier plusieurs tables à la fois ou scripter la vérification, interrogez information_schema.tables plutôt :

SELECT table_type FROM system.information_schema.tables
WHERE table_catalog = 'catalog_name' AND table_schema = 'schema_name' AND table_name = 'table_name';

Tables étrangères

Pour vérifier que votre table gérée a bien été reconvertie en table étrangère, vérifiez que la table Type est FOREIGN. Vous pouvez effectuer l’une des opérations suivantes :

Ouvrez un nouvel onglet et accédez à l’Explorateur de catalogues. Dans l’onglet Détails , sous À propos de ce tableau, le type de tableau s’affiche en tant qu’étranger.

Vérifiez le type de table en exécutant la commande SQL suivante :

SELECT table_type FROM system.information_schema.tables
WHERE table_catalog = 'catalog_name' AND table_schema = 'schema_name' AND table_name = 'table_name';

La table_type colonne s’affiche sous la forme FOREIGN.

Note

N'utilisez pas DESCRIBE EXTENDED pour vérifier les conversions ou les restaurations de tables étrangères. La fédération utilise le comportement de catalogue hive_metastore pour cette commande, et affiche donc la table Type comme EXTERNAL, quel que soit l’état réel de la table.

Sujets avancés

Cette section contient des rubriques avancées pour convertir des tables étrangères et externes en tables managées.

Convertir au niveau du schéma ou du catalogue

Vous disposez des deux options suivantes pour automatiser la conversion de tables au niveau du schéma ou du catalogue :

Parcourez les tables de vos schémas pour convertir chaque table une par une.

Utilisez le projet discoverx labs pour convertir des schémas ou catalogues entiers à la fois :

df = (dx.from_tables("prod.*.*")
.with_sql("ALTER TABLE {full_table_name} SET MANAGED;")
.apply())

Consultez Databricks Labs et discoverx.

Créer des tables dans un catalogue externe

Vous pouvez créer des tables externes ou gérées dans un catalogue étranger. Le comportement dépend de la configuration du schéma :

Pour les schémas Glue ou eHMS, ou pour les schémas avec un emplacement managé défini dans le catalogue Unity : si vous exécutez CREATE TABLE foreign_catalog.schema.table, cela crée une table managée ou externe du catalogue Unity. Databricks ne transmet pas ou ne synchronise pas la table vers le catalogue externe.
Pour les schémas des connexions de metastore Hive internes : si vous essayez de créer une table dans un schéma étranger, elle crée toujours une table étrangère et crée également une table dans hive_metastore.
Pour le metastore Hive des espaces de travail hérités : étant donné qu'il dispose d'une fédération en lecture et en écriture, si vous créez une table dans le catalogue étranger, une table est également créée dans le metastore Hive interne.

Tables étrangères basées sur DBFS

Lors de la conversion d'une table reposant sur DBFS, Databricks stocke le mappage actuel du chemin DBFS en tant qu'emplacement du chemin cloud de la table externe.

Limites

La conversion de tables externes ou étrangères en tables managées présente les limitations suivantes :

L’historique des tables pour les commits effectués après la conversion, mais avant la restauration permet de voyager dans le temps par version, mais pas par horodatage.
OpenSharing n’est pas entièrement compatible avec la SET MANAGED commande. Open OpenSharing est pris en charge, mais le partage Databricks vers Databricks ne met pas automatiquement à jour l'emplacement managé de la table du destinataire. Le destinataire continue de lire les données à partir de l'ancien emplacement jusqu'à ce que vous repartagiez la table. Pour partager de nouveau la table, exécutez les commandes suivantes :
```
ALTER SHARE <share_name> REMOVE TABLE <table_name>;
ALTER SHARE <share_name> ADD TABLE <table_name> AS <table_share_name> WITH HISTORY;
```
Si l’emplacement managé par défaut de votre metastore, catalogue ou schéma Unity Catalog se trouve dans une région cloud différente de l’emplacement de stockage de la table source, vous risquez d’entraîner des coûts de transfert de données interrégions supplémentaires à partir de votre fournisseur de cloud.

Pour vérifier l’emplacement de votre schéma et catalogue, exécutez les commandes suivantes :
```
DESC SCHEMA EXTENDED <catalog_name>.<schema_name>;

DESC CATALOG EXTENDED <catalog_name>;
```
Pour vérifier l’emplacement de votre metastore, exécutez l’une des commandes suivantes :
```
DESC METASTORE; -- Option 1
SELECT * FROM system.information_schema.metastores; -- Option 2
```

Limitations de redirection basées sur le chemin :

Vous devez redémarrer tous les travaux de streaming après la conversion. Consultez le comportement de streaming.
La redirection basée sur le chemin a uniquement une compatibilité descendante pour le processus de migration et n’active pas de nouvel accès basé sur le chemin aux tables gérées par le catalogue Unity.

Limitations des tables étrangères :

Seules les tables externes fédérées à l’aide de Hive metastore et Glue Federation sont prises en charge pour la conversion.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-07-13

Convertir des tables Delta Lake externes ou étrangères en tables gérées par le catalogue Unity

Prerequisites

Tables externes

Tables étrangères

Temps d’arrêt et temps de copie des données

Tables externes

Tables étrangères

Convertir en table managée

Tables externes à l’aide de l’Explorateur de catalogues (bêta)

Tables externes utilisant SQL

Tables étrangères utilisant SQL

Vérifier la conversion

Lecteurs et writers hérités

Redirection basée sur le chemin

Migrer le code basé sur les chemins en code basé sur les noms

Comportement de diffusion en continu

Résolution des échecs de conversion

VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED

Arrêt du cluster pendant la conversion

Table externe endommagée

Échec de validation de fichier

Annuler la conversion d’une table gérée

Table externe

Table étrangère : MOVE

Table étrangère : COPY

Vérifier l'annulation

Tables externes

Tables étrangères

Sujets avancés

Convertir au niveau du schéma ou du catalogue

Créer des tables dans un catalogue externe

Tables étrangères basées sur DBFS

Limites

Commentaires

Ressources supplémentaires

`VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED`

Table étrangère : `MOVE`

Table étrangère : `COPY`