Partage via


Meilleures pratiques pour DBFS et Unity Catalog

Unity Catalog introduit un certain nombre de nouvelles configurations et de nouveaux concepts qui ont une approche complètement différente de la gouvernance des données que DBFS. Cet article décrit plusieurs meilleures pratiques concernant l’utilisation des emplacements externes d’Unity Catalog et de DBFS.

Databricks ne recommande pas d’utiliser DBFS et le stockage d’objets cloud monté pour la plupart des cas d’usage dans les espaces de travail Azure Databricks compatibles avec Unity Catalog. Cet article décrit quelques scénarios dans lesquels vous devez utiliser le stockage d’objets cloud monté. Notez que Databricks ne recommande pas d’utiliser la racine DBFS conjointement avec Unity Catalog, sauf si vous devez migrer des fichiers ou des données stockés qui y sont stockés, dans Unity Catalog.

Comment DBFS est-il utilisé dans les espaces de travail compatibles avec Unity Catalog ?

Les actions effectuées sur des tables dans le hive_metastore utilisent des modèles d’accès aux données hérités, qui peuvent inclure des informations d’identification de stockage et des données gérées par DBFS. Les tables managées dans le hive_metastore étendu à l’espace de travail sont stockées sur la racine DBFS.

Comment DBFS fonctionne-t-il en mode d’accès utilisateur unique ?

Les clusters configurés avec le mode d’accès utilisateur unique disposent d’un accès complet à DBFS, y compris tous les fichiers de la racine DBFS et des données montées.

Comment DBFS fonctionne-t-il en mode d’accès partagé ?

Le mode d’accès partagé combine la gouvernance des données Unity Catalog avec les listes de contrôle d’accès héritées Azure Databricks. L’accès aux données dans hive_metastore est uniquement disponible aux utilisateurs disposant d’autorisations explicitement accordées.

Pour interagir avec des fichiers directement à l’aide de DBFS, vous devez disposer de l’octroi pour les autorisations ANY FILE. Étant donné que ANY FILE autorisent les utilisateurs à contourner les listes de contrôle d’accès des tables héritées dans hive_metastore et d’accéder à toutes les données managées par DBFS, Databricks recommande la prudence lors de l’octroi de ce privilège.

N’utilisez pas DBFS avec les emplacements externes d’Unity Catalog

Unity Catalog sécurise l’accès aux données dans des emplacements externes à l’aide de chemins d’URI cloud complets pour identifier les octrois sur les répertoires de stockage d’objets managés. Les montages DBFS utilisent un modèle d’accès aux données entièrement différent qui contourne complètement Unity Catalog. Databricks vous recommande de ne pas réutiliser les volumes de stockage d’objets cloud entre les montages DBFS et les volumes externes d’UC, notamment lors du partage de données entre espaces de travail ou comptes.

Sécuriser votre stockage managé par Unity Catalog

Unity Catalog en tirant parti d’emplacements de stockage gérés pour stocker des fichiers de données pour des volumes et des tables gérées.

Databricks recommande ce qui suit pour les emplacements de stockage gérés :

  • Utilisez de nouveaux comptes de stockage ou compartiments.
  • Définissez une stratégie d’identité personnalisée pour Unity Catalog.
  • Limitez tout l’accès à Azure Databricks géré par Unity Catalog.
  • Limitez tout l’accès aux stratégies d’accès aux identités créées pour Unity Catalog.

Ajouter des données existantes à des emplacements externes

Il est possible de charger des comptes de stockage existants dans Unity Catalog à l’aide d’emplacements externes. Pour une sécurité optimale, Databricks recommande de charger uniquement des comptes de stockage vers des emplacements externes après la révocation de tous les autres modèles d’accès et d’informations d’identification de stockage.

Vous ne devez jamais charger un compte de stockage utilisé comme racine DBFS comme emplacement externe dans Unity Catalog.

Les configurations de cluster sont ignorées par l’accès au système de fichiers Unity Catalog

Unity Catalog ne respecte pas les configurations de cluster pour les paramètres du système de fichiers. Cela signifie que les paramètres du système de fichiers Hadoop pour la configuration du comportement personnalisé avec le stockage d’objets cloud ne fonctionnent pas lors de l’accès aux données à l’aide d’Unity Catalog.

Limitation concernant l’accès à plusieurs chemins

Bien que vous puissiez généralement utiliser Unity Catalog et DBFS ensemble, les chemins d’accès égaux ou partageant une relation parent/enfant ne peuvent pas être référencés dans la même commande ou cellule de notebook à l’aide de différentes méthodes d’accès.

Par exemple, si une table externe foo est définie dans hive_metastore à l’emplacement a/b/c et qu’un emplacement externe est défini dans Unity Catalog sur a/b/, le code suivant génère une erreur :

spark.read.table("foo").filter("id IS NOT NULL").write.mode("overwrite").save("a/b/c")

Cette erreur ne se produit pas si cette logique est divisée en deux cellules :

df = spark.read.table("foo").filter("id IS NOT NULL")
df.write.mode("overwrite").save("a/b/c")