Résoudre les conflits de chemin de stockage

Un conflit de chemin de stockage se produit lorsqu'un emplacement externe chevauche le chemin de stockage Unity Catalog default de tout Workspace dans votre compte Databricks. Ce chevauchement interfère avec le traitement interne de certaines fonctionnalités de Unity Catalog. Si votre compte présente un conflit de chemin de stockage, vous devez mettre à jour la configuration de votre emplacement externe.

Unity Catalog valide les emplacements externes par rapport à chaque configuration de stockage enregistrée sur votre compte Databricks, et pas seulement dans le workspace où l’emplacement a été créé. Par conséquent, un conflit peut survenir si plusieurs espaces de travail du même compte partagent le même compartiment.

Comment le conflit se produit

Un conflit survient lorsque vous créez ou mettez à jour un emplacement externe qui chevauche le chemin de stockage Unity Catalog default de tout Workspace de votre compte. Ce chemin default est configuré à l'aide de l'objet de configuration de stockage lors du déploiement classique du workspace. Voir Créer une configuration de stockage. Par exemple :

• Chemin de stockage du Workspace par default utilisé pour créer un Workspace : s3://<your-bucket>/<region>/
• Emplacement externe en chevauchement (conflit) : s3://<your-bucket>/

Ce chevauchement empêche Unity Catalog d'utiliser l'emplacement de stockage du Workspace pour le traitement interne, et il bloque certaines fonctionnalités d'Unity Catalog. Un chevauchement affaiblit également la gouvernance des données, car les données internes du workspace pourraient être exposées par l'emplacement externe. Par conséquent, les chemins d’emplacement externes ne doivent pas chevaucher un chemin de stockage Unity Catalog par default du Workspace dans votre compte.

Vous pouvez, cependant, créer un emplacement externe sur des chemins plus spécifiques sous un chemin de stockage default de Workspace, comme l'emplacement racine DBFS. Cela est dû au fait que l'emplacement racine DBFS est un élément frère du chemin de stockage interne du Workspace et ne crée pas de conflit.

Identifiez votre scénario

Passez en revue vos emplacements externes dans **Catalog Explorer** de l'interface utilisateur Databricks pour voir si le chemin de votre emplacement externe inclut ou est plus large que le chemin de stockage par default de votre workspace.
Exemple :

• Emplacement externe : s3://<your-bucket>/
• Chemin d'accès au stockage par default du Workspace : s3://<your-bucket>/<region>/

Tenez compte des scénarios suivants pour vous aider à déterminer comment procéder.

Scénario A : Mises à jour de l'emplacement externe sans déplacer les données

Vous définissez un emplacement externe à un chemin large (tel que s3://<customer-bucket>/) mais accédez aux données dans un dossier frère plus spécifique, tel que les données du système de fichiers Databricks hérité stockées à s3://<customer-bucket>/<region>/<workspace-id>/.

Action : (Recommandé) Mettez à jour votre emplacement externe existant vers le chemin d'accès plus spécifique. Cette modification résout le conflit tout en continuant à permettre l'accès à toutes les données. Par exemple, vous mettriez à jour le chemin d'accès de s3://<your-bucket>/ à s3://<your-bucket>/<region>/<workspace-id>/. Cela évite également les fuites de données accidentelles des données internes du workspace.

Scénario B : Tables gérées stockées à l'emplacement racine du compartiment

Vous définissez un emplacement externe à la racine de votre compartiment (par exemple, s3://<your-bucket>/) et créez des tables gérées directement en dessous, telles que s3://<your-bucket>/__unity_storage/catalogs/<catalog_id>/tables/<table_id>.

Dans ce cas, la mise à jour du chemin n'est pas possible. Vous devez migrer vos tables gérées vers un nouvel emplacement.

important

Les étapes suivantes sont une procédure suggérée, pas un plan de migration complet ou garanti. Ils ne couvrent pas chaque type d'objet (par exemple, les volumes ou les modèles enregistrés) ni chaque modèle de charge de travail. Utilisez votre propre jugement pour planifier et valider la migration, et travaillez avec votre équipe de compte Databricks sur tout problème spécifique à votre environnement.

**Action :** Suivez les étapes suivantes pour résoudre le conflit :

1. Identifiez toutes les tables gérées concernées. En tant qu'administrateur du métastore, exécutez la query system.information_schema.tables pour obtenir une liste complète des tables gérées dans tous les catalogues :

   SQL

   SELECT table_catalog, table_schema, table_name
   FROM system.information_schema.tables
   WHERE table_type = 'MANAGED';

2. Choisissez un nouveau sous-répertoire racine du métastore. Sélectionnez un chemin d'accès qui n'est pas un parent de chemins de stockage internes existants (chemins d'accès contenant __unity_storage). Exemple : s3://<your-bucket>/uc-root/.

3. Mettez à jour l'emplacement de stockage géré du métastore. Consultez Ajouter un stockage géré à un métastore existant. Les nouvelles tables gérées sont stockées au nouvel emplacement après cette mise à jour. Les tables gérées existantes ne sont pas déplacées automatiquement.

4. Sauvegardez les octrois de privilèges sur chaque table affectée avant la migration. Exécutez ceci en tant que propriétaire de la table ou administrateur du métastore afin que tous les octrois soient visibles :

   SQL

   SHOW GRANTS ON TABLE <catalog>.<schema>.<table_name>;

5. Arrêtez toutes les charges de travail qui lisent ou écrivent dans les tables concernées, et assurez-vous qu'aucune charge de travail ou aucun administrateur ne modifie les autorisations sur celles-ci pendant la durée de la migration. Les écritures ou les modifications de privilèges qui se produisent après le clonage des tables ne sont pas capturées et peuvent entraîner une perte de données.

6. Recréer chaque table affectée au nouvel emplacement de stockage géré. Utilisez DEEP CLONE pour préserver l'historique des tables Delta Lake :

   SQL

   -- Recommended: deep clone preserves Delta history
   CREATE TABLE <catalog>.<schema>.<table_name>
   DEEP CLONE <old_catalog>.<schema>.<table_name>;

7. Réappliquer tous les droits aux tables recréées :

   SQL

   GRANT <privilege> ON TABLE <catalog>.<schema>.<table_name> TO <principal>;

8. Mettez à jour toutes les charges de travail en aval (jobs, notebooks, tableaux de bord) pour référencer les tables recréées. Utilisez la data lineage pour identifier les charges de travail dépendantes avant la bascule. Reprenez les charges de travail seulement après qu'elles pointent vers les tables recréées.

9. Vérifiez les tables recréées, puis supprimez les anciennes tables.

10. Mettez à jour l'emplacement externe vers un chemin non conflictuel plus spécifique, comme décrit dans Scénario A.