Convertir les tables Delta Lake externes ou étrangères en tables gérées par Unity Catalog

info

Aperçu public

La conversion d'une table externe en table gérée est généralement disponible.

La conversion d'une table externe en table gérée est en Aperçu public. Seules les tables étrangères fédérées à l'aide de Hive metastore et Glue Federation sont prises en charge.

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

Pour les conversions de tables externes, SET MANAGED également :

Minimise les temps d'arrêt pour la lecture et l'écriture.
Gère les écritures concurrentes pendant la conversion.
Permet de rétablir une table gérée convertie en une table externe.
Redirige les lectures et écritures basées sur le chemin pour permettre au code hérité de fonctionner après la conversion.

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

Pour les conversions de tables externes, Databricks définit l'optimisation prédictive sur la table convertie à INHERIT plutôt que de l'activer automatiquement. Consultez les tables externes utilisant SQL.

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

Prérequis

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

Tables externes

La conversion des tables externes en tables gérées présente les prérequis suivants :

Format : la table doit utiliser le format Delta Lake.
Runtime : Vous devez utiliser Databricks Runtime 17.3 LTS ou une version ultérieure, ou le compute Serverless pour utiliser SET MANAGED, UNSET MANAGED ou TRUNCATE UNIFORM HISTORY.
Lecteurs et rédacteurs : les fonctions de lecture et d'écriture Databricks pour vos tables sources doivent utiliser Databricks Runtime 15.4 LTS ou version ultérieure. Si vos fonctions de lecture ou d'écriture utilisent 14.3 LTS ou version inférieure, consultez fonctions de lecture et d'écriture héritées.
Clients externes : Les clients externes (qui ne sont pas Databricks) doivent prendre en charge les lectures vers les tables gérées par Unity Catalog. Consultez Accéder aux tables avec les clients Delta.
- Utilisez le tableau de bord Access Insights pour voir si les lecteurs et les auteurs qui accèdent à vos tables sont Databricks Runtime ou des entités externes non-Databricks.
Compatibilité des fonctionnalités : si votre table contient 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 de DESCRIBE DETAIL. Voir compatibilité des fonctionnalités et protocoles de Delta Lake.

Après la conversion, les lectures et les écritures basées sur le chemin sont automatiquement redirigées vers le nouvel emplacement géré avec un léger surcoût de performance. Databricks recommande de migrer tout accès basé sur le chemin vers un accès basé sur le nom afin d’éviter les surcharges de performances. Voir redirection basée sur le chemin.

important

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

Tables étrangères

info

Aperçu public

La conversion d'une table étrangère en table gérée est en Public Preview.

La conversion des tables étrangères en tables gérées comporte les prérequis suivants :

Format de données : La table externe 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 du Hive metastore (HMS) doit être une table HMS externe. La commande échoue si la table est une table HMS gérée.
Autorisations : OWNER ou MANAGE autorisations sur la table et CREATE autorisation sur le EXTERNAL LOCATION.

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

La commande SET MANAGED minimise ou élimine les temps d'arrêt par rapport aux approches alternatives, telles que DEEP CLONE.

Tables externes

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

Copie initiale des données (sans interruption) : la commande copie les données de la table et le journal des transactions Delta de l'emplacement externe vers l'emplacement géré. Les lecteurs et rédacteurs actifs vers la table externe fonctionnent sans interruption.
Passage à l'emplacement géré (courte interruption) : Les commits effectués vers l'emplacement externe lors de la première étape sont déplacés vers l'emplacement géré, et les métadonnées de la table sont mises à jour pour enregistrer le nouvel emplacement géré. Au cours de cette étape, toutes les écritures vers l'emplacement externe sont temporairement bloquées, ce qui entraîne une interruption pour les rédacteurs. Les lecteurs sur Databricks Runtime 16.4 LTS ou version supérieure ne subissent aucune interruption, mais les lecteurs sur Databricks Runtime 15.4 LTS et versions inférieures pourraient subir une interruption.

Le tableau suivant présente les temps d'arrêt estimés en fonction de la taille de la table source et un taux de throughput estimé de 0,5 à 2 Go/cœur de processeur/minute :

Taille de la table	Taille de cluster recommandée	Durée estimée de copie des données	Estimation du temps d'arrêt des fonctions de lecture et d'écriture
100 Go ou moins	SQL warehouse X-Large / 32 cœurs	~ 6 min ou moins	~ de 1 à 2 min ou moins
1 To	SQL Warehouse 64 cœurs/2X-Large	environ 30 min	Environ 1 à 2 min
10 To	SQL warehouse 256 cœurs / 4X-Large	~1,5 h	environ 1 à 5 min

Taille de la table	Taille de cluster recommandée	Durée estimée de copie des données	Estimation du temps d'arrêt des fonctions de lecture et d'écriture
100 Go ou moins	SQL warehouse X-Large / 32 cœurs	~ 6 min ou moins	~ de 1 à 2 min ou moins
1 To	SQL Warehouse 64 cœurs/2X-Large	environ 30 min	Environ 1 à 2 min
10 To	SQL warehouse 256 cœurs / 4X-Large	~1,5 h	environ 1 à 5 min

remarque

Les temps d'arrêt peuvent varier en fonction de facteurs tels que la taille des fichiers, le nombre de fichiers et le nombre de commits.

Tables étrangères

Le temps d'arrêt de conversion de la table étrangère dépend de l'utilisation de MOVE ou de COPY:

Pour MOVE, des temps d'arrêt peuvent survenir comme décrit pour les tables externes. Voir 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 géré, créant ainsi deux copies distinctes des données. Vous êtes responsable de la désactivation des lectures et des écritures vers la table source dans le catalogue externe, et de la migration des charges de travail pour utiliser la nouvelle table gérée.

Convertir en une table gérée

Convertissez une table externe à l'aide de Catalog Explorer ou de SQL, ou convertissez une table étrangère à l'aide de SQL.

Tables externes à l'aide de l'Explorateur de catalogues (Beta)

info

Bêta

La conversion de tables externes en tables gérées à l'aide de l'explorateur de catalogues est en version bêta.

Avec 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 Catalog Explorer.
Sous À propos de cette table (page de détails de la table) ou À propos de ce schéma (page de détails du schéma), cliquez sur Explorer les optimisations .
Dans Pourquoi migrer vers des tables gérées par Unity Catalog ? dialogue, cliquez sur Continuer .
Sélectionnez les tables externes que vous souhaitez convertir. Si vous avez ouvert la boîte de dialogue depuis une page de détails de table, l'Explorateur de catalogues présélectionne votre table. Utilisez la barre de recherche pour trouver des tables supplémentaires. Les tables gérées ne sont pas sélectionnables.
Cliquez sur **Créer un notebook de conversion**.
En option, saisissez un nom pour le Notebook. Par default, cela enregistre le Notebook dans votre dossier personnel. Cliquez sur **Parcourir** pour l'enregistrer à un emplacement différent.
Dans le Notebook, examinez les meilleures pratiques et vérifiez que vous remplissez tous les prérequis.
Exécutez la cellule Requêtes GÉRÉES PAR SET .

Après l'exécution de la cellule, le type de table s'affiche comme **GÉRÉE** au lieu d'**EXTERNE** dans l'Explorateur de catalogues. refresh la page si le statut ne se met pas à jour immédiatement.

Tables externes utilisant SQL

Selon que votre table externe a des lectures Apache Iceberg (UniForm) activées, exécutez l'une des commandes suivantes. Pour vérifier si votre table a des lectures Iceberg activées, consultez Vérifier que les lectures Iceberg sont activées.

Pour les tables externes Unity Catalog sans les lectures Iceberg activées, exécutez la commande suivante :
SQL
```
ALTER TABLE catalog.schema.my_external_table SET MANAGED;
```
Après la conversion, vous pouvez activer les lectures Iceberg sur votre table gérée sans problème de compatibilité.
Pour les tables externes Unity Catalog avec les lectures Iceberg déjà activées, exécutez la commande suivante :
SQL
```
ALTER TABLE catalog.schema.my_external_table SET MANAGED TRUNCATE UNIFORM HISTORY;
```
Incluez TRUNCATE UNIFORM HISTORY pour maintenir une performance et une compatibilité optimales de la table. TRUNCATE UNIFORM HISTORY tronque uniquement l’historique UniForm Iceberg et ne supprime pas l’historique Delta. Cette commande entraîne une courte période d'indisponibilité en lecture et en écriture pour Iceberg après la troncation.

Après la conversion de la table, 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 d'accès. Vérifiez que vos fonctions de lecture et d'écriture fonctionnent avec la table gérée. Consultez 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.

Databricks conserve les données de votre emplacement externe Unity Catalog pendant 14 jours pour permettre une annulation. Voir Annuler la conversion d'une table gérée. Après 14 jours, avec l'optimisation prédictive activée, Databricks supprime automatiquement ces données pour récupérer le stockage et réduire les coûts. Si vous désactivez l'optimisation prédictive, exécutez VACUUM (nécessite Databricks Runtime 17.3 LTS ou une version ultérieure ou un compute Serverless) sur la table gérée nouvellement convertie après 14 jours pour récupérer le stockage vous-même.

SQL
VACUUM my_converted_table

remarque

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

Databricks ne supprime que les données de l'emplacement externe. Le journal des transactions Delta et la référence à la table dans Unity Catalog sont conservés.

Tables étrangères utilisant SQL

info

Aperçu public

La conversion d'une table étrangère en table gérée est en Public Preview.

Pour convertir votre table externe Unity Catalog en table gérée par Unity Catalog, exécutez la commande suivante :

SQL
ALTER TABLE source_table SET MANAGED {MOVE | COPY}

table source

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 avoir converti la table. Tous les lecteurs et rédacteurs de la table doivent utiliser l'espace de noms Unity Catalog pour y accéder. Par exemple :
  SQL
```
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 avoir converti la table. Par exemple :
  SQL
```
SELECT * FROM delta.`protocol://path/to/table`;
```
- La version du lecteur/rédacteur et les exigences de compatibilité client sont les mêmes que celles décrites dans les Prérequis et les lecteurs et rédacteurs hérités.
- L'optimisation prédictive est définie sur INHERIT, sauf si vous l'avez configurée 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 table gérée sans modifier ni désactiver l'accès à la table source dans le catalogue externe.
- Lors de la conversion en géré, le processus de conversion copie les données de la table source dans l'emplacement de stockage géré défini pour la table externe, créant deux copies distinctes : la nouvelle table gérée et la table source dans le catalogue externe.
- Contrairement à MOVE où les lectures et les écritures échouent, lorsque vous utilisez COPY, vous êtes responsable de la désactivation correcte des lectures et des écritures vers la table source dans le catalogue externe et de vous assurer que les charges de travail ont migré vers le nouveau catalogue.

Après la conversion de la table, vous devez redémarrer tous les Jobs de streaming (lecture ou écriture) utilisant la table externe et vérifier que vos lecteurs et rédacteurs 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 gérée par Unity Catalog.

Si la commande est interrompue pendant la copie des données, redémarrez-la. La commande reprend là où elle s'est arrêtée.

attention

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

Présentation vidéo

Cette vidéo explique comment fédérer un métastore AWS Glue et ensuite convertir des tables étrangères en tables gérées (10 minutes). La conversion des tables étrangères en tables gérées commence à 5 h 30.

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 nouveau tab et accédez à l'Explorateur de catalogues. Dans le tab Détails , sous À propos de cette table , le Type de table s’affiche comme Géré.

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

SQL
DESCRIBE EXTENDED catalog_name.schema_name.table_name

Pour vérifier plusieurs tables à la fois ou scripter la vérification, utilisez la query information_schema.tables à la place :

SQL
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 rédacteurs hérités

Databricks recommande de mettre à niveau tous les lecteurs et rédacteurs vers Databricks Runtime 15.4 LTS ou une version supérieure pour utiliser toutes les capacités de SET MANAGED, y compris la rétention de l'historique des tables.

Vous pouvez toujours utiliser SET MANAGED si vous avez des lecteurs ou des auteurs sur Databricks Runtime 15.3 ou une version antérieure. Cependant, après conversion en table gérée, vous pouvez utiliser le time travel pour accéder aux commits historiques uniquement par version, et non par timestamp.

Si vous restaurez vers une table externe dans les 14 jours, le Time Travel vers les commits historiques effectués avant la conversion est réactivé. Le time travel à l'aide de Timestamp n'est pas pris en charge pour les commit effectués sur la table gérée convertie entre la conversion et l'annulation. Consultez l'annulation d'une conversion de table gérée.

L'écriture dans une table après la conversion avec Databricks Runtime 15,3 ou une version antérieure nécessite la suppression de la fonctionnalité inCommitTimestamp :

SQL
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 gérée par Unity Catalog, les lectures et écritures basées sur le chemin vers l'emplacement externe précédent sont automatiquement redirigées vers le nouvel emplacement géré. Une lecture basée sur le chemin est un code tel que SELECT * FROM delta.`/path/to/my_table`. La redirection basée sur le chemin réduit le temps et les efforts nécessaires pour migrer vers des tables gérées en permettant au code existant qui utilise des chemins de stockage de 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, 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 ajoute plusieurs centaines de millisecondes de surcoût pour chaque lecture ou écriture basée sur le chemin, et exige que les anciens Logs Delta restent actifs dans votre emplacement externe Unity Catalog. Les lectures et écritures basées sur le nom n'ont pas de surcoût de performance supplémentaire. Voir Migrer le code basé sur le chemin vers le nom.

Migrer le code basé sur le chemin vers le code basé sur le nom

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

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

SQL
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 le nom à une table externe, comme dans le code suivant :

SQL
SELECT * FROM catalog_name.schema_name.customers_table;

Comportement de streaming

Le streaming avec redirection basée sur le chemin prend en charge les lectures et les écritures 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 les versions ultérieures.

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

Les lectures et écritures en streaming basées sur le chemin échouent et s'arrêtent au prochain point de contrôle avec un message de migration :

Pour les lectures, le Stream 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, le premier micro-batch après la conversion déclenche 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 Streams avec les mêmes configurations. L'accès basé sur les chemins d'accès redirige automatiquement vers la table gérée.

Pour les limitations de redirection basées sur le chemin, consultez Limitations.

Dépannage 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 Unity Catalog à l'aide de SET MANAGED.

`VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED`

Si la conversion échoue, essayez toujours à nouveau en utilisant la même version de Databricks Runtime. Les métadonnées peuvent être sérialisées différemment selon les versions, ce qui provoque un échec VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED si vous relancez une conversion sur une version différente de Databricks Runtime.

Arrêt du cluster pendant la conversion

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

Table externe corrompue

Si la table externe est déjà corrompue (par exemple, état de table non valide), la conversion peut échouer avec des erreurs telles que DELTA_TRUNCATED_TRANSACTION_LOG, DELTA_TXN_LOG_FAILED_INTEGRITY ou 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 la validation du fichier

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

Pour résoudre ce problème :

Vérifiez vos Logs de driver 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 commande ALTER TABLE ... SET MANAGED.

Si le problème persiste, contactez l'assistance Databricks.

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

important

Les commandes de restauration nécessitent un compute Serverless ou Databricks Runtime 17.3 LTS et versions ultérieures.

Table externe

Après avoir converti une table externe en table gérée, vous pouvez annuler la conversion dans un délai de 14 jours à l'aide de la commande UNSET MANAGED. Ceci met à jour les métadonnées de la table pour qu'elles renvoient vers l'emplacement externe d'origine. Databricks conserve toutes les écritures effectuées vers l'emplacement géré après conversion.

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

SQL
ALTER TABLE catalog.schema.my_managed_table UNSET MANAGED;

Gardez les informations suivantes à l'esprit :

Si la commande d'annulation est interrompue ou échoue, réexécutez-la pour réessayer.
Vous devez redémarrer vos jobs de streaming après avoir effectué une restauration, similaire à la conversion.
Les commits effectués vers l'emplacement géré entre la conversion et l'annulation permettent le time travel par version, mais pas par timestamp.
Sept jours après la restauration, Databricks supprime automatiquement les données dans l'emplacement géré.

Table étrangère : `MOVE`

attention

Vous DEVEZ exécuter UNSET MANAGED avant de supprimer la table gérée. La suppression de la table sans exécuter UNSET MANAGED au préalable pourrait entraîner une perte de données ou des incohérences.

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

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

SQL
ALTER TABLE catalog.schema.my_managed_table UNSET MANAGED

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

SQL
DROP TABLE catalog.schema.my_managed_table

La table étrangère est disponible après la prochaine synchronisation du catalogue.

Gardez les informations suivantes à l'esprit :

Pour les commits que vous avez effectués à l'emplacement externe entre la conversion et l'annulation, vous pouvez utiliser le time travel par version, mais pas par Timestamp.
Sept jours après la restauration, Databricks supprime les données de l'emplacement géré.

Table étrangère : `COPY`

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

Vérifier la restauration

Vérifiez les restaurations différemment pour les tables externes et étrangères.

Tables externes

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

Ouvrez un nouveau tab et accédez à l'Explorateur de catalogues. Dans l'onglet Détails , sous À propos de cette table , le Type de table s'affiche comme Externe .

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

SQL
DESCRIBE EXTENDED catalog_name.schema_name.table_name

Pour vérifier plusieurs tables à la fois ou scripter la vérification, utilisez la query information_schema.tables à la place :

SQL
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 été correctement restaurée vers une table externe, vérifiez si la table Type est FOREIGN. Vous pouvez effectuer l'une des opérations suivantes :

Ouvrez un nouveau tab et accédez à l'Explorateur de catalogues. Dans l'onglet **Détails**, sous **À propos de cette table**, le **Type** de table s'affiche comme **Étrangère**.

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

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

La colonne table_type s'affiche sous la forme de FOREIGN.

remarque

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

Sujets avancés

Cette section contient des sujets avancés pour la conversion des tables étrangères et externes en tables gérées.

Convertir au niveau du schéma ou du catalogue

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

Itérez sur vos tables dans vos schémas pour convertir chaque table individuellement.
Utilisez le projet discoverx labs pour convertir des schémas ou des catalogues entiers en une seule fois :
Python
```
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 étranger

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 géré défini dans Unity Catalog : si vous exécutez CREATE TABLE foreign_catalog.schema.table, cela crée une table gérée ou externe de Unity Catalog. Databricks ne pousse ni ne synchronise la table vers le catalogue externe.
Pour les schémas provenant de connexions internes au Hive metastore : si vous essayez de créer une table dans un schéma externe, une table externe est quand même créée et une table est également créée dans hive_metastore.
**Pour le Hive metastore de l'ancien Workspace** : Comme celui-ci dispose d'une fédération en lecture et écriture, si vous créez une table dans le catalogue étranger, cela crée également une table dans le Hive metastore interne.

Tables étrangères adossées à DBFS

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

Limitations

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

L'historique des tables pour les commits effectués après la conversion mais avant l'annulation permet le time travel par version mais pas par timestamp.
OpenSharing n'est pas entièrement compatible avec la commande SET MANAGED. Open OpenSharing est pris en charge, mais le partage Databricks-to-Databricks ne met pas automatiquement à jour l'emplacement géré de la table du destinataire. Le destinataire continue de lire à partir de l'ancien emplacement jusqu'à ce que vous repartagiez la table. Pour repartager la table, exécutez les commandes suivantes :
SQL
```
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 géré par default 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 pourriez encourir des coûts supplémentaires de transfert de données inter-régions de la part de votre fournisseur cloud.

Pour vérifier l'emplacement de votre schéma et de votre catalogue, exécutez les commandes suivantes :
SQL
```
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 :
SQL
```
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 Jobs de streaming après la conversion. Consultez Comportement du streaming.
La redirection basée sur le chemin d'accès n'a une compatibilité rétroactive que pour le processus de migration et n'active pas le nouvel accès basé sur le chemin aux tables gérées par Unity Catalog.

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

Prérequis​

Tables externes​

Tables étrangères​

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

Tables externes​

Tables étrangères​

Convertir en une table gérée​

Tables externes à l'aide de l'Explorateur de catalogues (Beta)​

Tables externes utilisant SQL​

Tables étrangères utilisant SQL​

Présentation vidéo​

Vérifier la conversion​

Lecteurs et rédacteurs hérités​

Redirection basée sur le chemin​

Migrer le code basé sur le chemin vers le code basé sur le nom​

Comportement de streaming​

Dépannage des échecs de conversion​

VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED​

Arrêt du cluster pendant la conversion​

Table externe corrompue​

Échec de la validation du fichier​

Annuler la conversion d'une table gérée​

Table externe​

Table étrangère : MOVE​

Table étrangère : COPY​

Vérifier la restauration​

Tables externes​

Tables étrangères​

Sujets avancés​

Convertir au niveau du schéma ou du catalogue​

Créer des tables dans un catalogue étranger​

Tables étrangères adossées à DBFS​

Limitations​

Prérequis

Tables externes

Tables étrangères

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

Tables externes

Tables étrangères

Convertir en une table gérée

Tables externes à l'aide de l'Explorateur de catalogues (Beta)

Tables externes utilisant SQL

Tables étrangères utilisant SQL

Présentation vidéo

Vérifier la conversion

Lecteurs et rédacteurs hérités

Redirection basée sur le chemin

Migrer le code basé sur le chemin vers le code basé sur le nom

Comportement de streaming

Dépannage des échecs de conversion

`VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED`

Arrêt du cluster pendant la conversion

Table externe corrompue

Échec de la validation du fichier

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

Table externe

Table étrangère : `MOVE`

Table étrangère : `COPY`

Vérifier la restauration

Tables externes

Tables étrangères

Sujets avancés

Convertir au niveau du schéma ou du catalogue

Créer des tables dans un catalogue étranger

Tables étrangères adossées à DBFS

Limitations